Reviewer: Charlie Kaufman
Review result: Ready

I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written primarily for the benefit of the security area directors.  Document editors and WG chairs should treat these comments just like any other last call comments.

This long and important but somewhat tedious document describes the widely deployed Certificate Management over CMS (CMC) protocol. It is mainly a cleanup revision combining rfc5272, rfc6402, and a long list of previously published errata.

I have no comments worthy of holding this up, but since I included these comments on a previous review and they weren't addressed, I didn't feel right about deleting them. These are based on my opinion and I did not suggest alternative text, so ignoring them is a perfectly reasonable response.

1) (page 7) This encourages questionable behavior:

   No special services are provided to distinguish between a rekey
   request and a new certification request (generally for a new
   purpose).  A control to unpublish a certificate would normally be
   included in a rekey request, and be omitted in a new certification
   request.

It is not uncommon for a rekey request to be accompanied by a request to unpublish the certificate being replaced, but it is rarely a good idea. It invites errors caused by creating timing windows where a certificate is expected but not yet deployed. It is better where possible to have both the old and new certificates be valid for an overlap period sufficient for everyone to be brought up to date and all caches refreshed.

2) (page 9) The definition of RA (Registration Authority) could be clearer:

      Registration Authority (RA) or Local RA (LRA) refers to an
         entity that acts as an intermediary between the EE and the CA.
         Multiple RAs can exist between the end-entity and the
         Certification Authority.  RAs may perform additional services
         such as key generation or key archival.  This document uses the
         term RA for both RA and LRA.

There are many sorts of entities that may act as an intermediary between the EE and the CA, and it's not clear whether this document means to include all such intermediaries or only those that speak the CMC protocol to both the EE and the CA. An example of a very different sort of intermediary is one that operates in a cloud environment and requests certificates (perhaps using CMC) from a CA and then stores those certificates and the corresponding private keys and deploys them into instances of the EE as they are dynamically created.


      —Charlie