[secdir] Re: Secdir review of draft-ietf-lamps-rfc5272bis-08

[Sean Turner <[e-mail]>]

Charlie,

Hi! Responses below.

> On Sep 9, 2025, at 02:09, Charlie Kaufman <[e-mail]> wrote:
> 
> 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.

Tracking issue here:
https://github.com/lamps-wg/cmcbis/issues/144

> 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.

Would something like the following work to highlight that a grace period is gone if do the unpublish:

OLD:

   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.  CAs or other publishing agents are also expected to have
   policies for removing certificates from publication either based on
   new certificates being added or the expiration or revocation of a
   certificate

NEW:

   No special services are provided to distinguish between a rekey
   request and a new certification request (generally for a new
   purpose).  CAs or other publishing agents are also expected to have
   policies for removing certificates from publication either based on
   new certificates being added or the expiration or revocation of a
   certificate. A control to unpublish a certificate would normally be
   included in a rekey request if the CA did not wish to
   have a grace period between the certificates, be omitted
   if the CA wishes to have a grace period between
   certificates, and be omitted from a new certification request.

see:
https://github.com/lamps-wg/cmcbis/pull/145

> 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.


This is a common PKI term; see RFC 5280 and RFC 4949. And, yes we here are only speaking about the intermediary in the context of using the CMC protocol. I guess we could add something about when using CMC, but then it would look weird to do it just here and not in the other definitions. We could add pointers to later section, but then why and not elsewhere…. I am open to suggestions for how to address this ;)

spt