Re: [lamps] Benjamin Kaduk's Discuss on draft-ietf-lamps-hash-of-root-key-cert-extn-05: (with DISCUSS and COMMENT)

[Benjamin Kaduk <[e-mail]>]

On Fri, Jun 28, 2019 at 12:34:40PM -0400, Russ Housley wrote:
> Ben:
> 
> Dropping parts where we have reached agreement ...
> 
> 
> >>>>>> ----------------------------------------------------------------------
> >>>>>> DISCUSS:
> >>>>>> ----------------------------------------------------------------------
> > 
> >> I propose to replace the paragraph after that with one that handles the non-repository case and points out that the Wen PKI falls in that case.  See below.
> >> 
> >>>>> The id-ad-caRepository OID is used when the subject is a CA that
> >>>>> publishes certificates it issues in a repository.  The accessLocation
> >>>>> field is defined as a GeneralName, which can take several forms.
> >>>>> 
> >>>>> ...
> >>>>> 
> >>>>> Where the information is available via HTTP or FTP, accessLocation
> >>>>> MUST be a uniformResourceIdentifier and the URI MUST point to either
> >>>>> a single DER encoded certificate as specified in [RFC2585] or a
> >>>>> collection of certificates in a BER or DER encoded "certs-only" CMS
> >>>>> message as specified in [RFC2797].
> >>>>> 
> >>>>> I am willing to RECOMMEND the inclusion of this extension and posting the oldWithNew and newWithOld so that they can be fetched using the "certs-only" (simple PKI response).  This format would allow certificates to be added and removed from the bag of certificates over time.
> >>> 
> >>> That does seem worth doing.
> >>> 
> >>> I think what would best help move the document forward right now would be
> >>> for you to point me at the existing text that is "fairly clear that there
> >>> can be some failure if there is not a repository or directory service.",
> >>> since I seem to have missed it.  Text that matches that description should
> >>> be enough to resolve the Discuss point -- we don't need to bend over
> >>> backwards to satisfy the Web PKI case when the mechanism works fine as-is
> >>> in other use cases.
> >> 
> >> Here is the proposed text for the non-repository case.  The first paragraph offers guidance to the Root CA, and the next one offers guidance to recipients:
> >> 
> >>   In environments without such a directory service or repository, like
> >>   the Web PKI, recipients need a way to obtain the oldWithNew and
> >>   newWithOld certificates.  The Root CA SHOULD include the subject
> >>   information access extension [RFC5280] with the accessMethod set to
> >>   id-ad-caRepository and the assessLocation set to the HTTP URL that
> >>   can be used to fetch a DER-encoded "certs-only" (simple PKI response)
> >>   message as specified in [RFC5272].  The Root CA SHOULD post the
> >>   "certs-only" message with the oldWithNew certificate and the
> >>   newWithOld certificate before the current Root CA self-signed
> >>   certificate is released.  The "certs-only" message format allows
> > 
> > I might be confused, but if "the current Root CA self-signed certificate is
> > released" means that people are using the current root, then this doesn't
> > seem to make much sense -- that requires using the next key to sign
> > OldWithNew before the current key is usable, which seems counter to the
> > point of the flow here.  So I think this maybe was supposed to be
> > "successor" instead of "current"?
> 
> You are not confused.  The original self-signed certificate and the successor self-signed certificate should contain the same URL for the "certs-only" message.  This way, a replying party will find the certificate that is needed no matter which trust anchor they are using.  So, yes, you are right the update the "certs-only" message should happen before the successor self-signed certificate is released.  Here is the corrected text:
> 
>    In environments without such a directory service or repository, like
>    the Web PKI, recipients need a way to obtain the oldWithNew and
>    newWithOld certificates.  The Root CA SHOULD include the subject
>    information access extension [RFC5280] with the accessMethod set to
>    id-ad-caRepository and the assessLocation set to the HTTP URL that
>    can be used to fetch a DER-encoded "certs-only" (simple PKI response)
>    message as specified in [RFC5272] in all of their self-signed
>    certificates.  The Root CA SHOULD publish the "certs-only" message
>    with the oldWithNew certificate and the newWithOld certificate before
>    the subsequent Root CA self-signed certificate is released.  The
>    "certs-only" message format allows certificates to be added and
>    removed from the bag of certificates over time, so the same HTTP URL
>    can be used throughout the lifetime of the Root CA.
> 
> >>   certificates to be added and removed from the bag of certificates
> >>   over time, so the same HTTP URL can be used throughout the lifetime
> >>   of the Root CA.
> >> 
> >>   In environments without such a directory service or repository,
> >>   recipients SHOULD keep both the old and replacement Root CA self-
> >>   signed certificates in the trust anchor store for some amount of time
> >>   to ensure that all end-entity certificates can be validated until
> >>   they expire.  The recipient MAY keep the old Root CA self-signed
> >>   certificate until all of the certificates in the local cache that are
> >>   subordinate to it have expired.
> > 
> > Modulo the above comment, this should be enough to resolve the Discuss.
> 
> I believe that is sorted by the above text.

I do, too -- thanks.

> > I think I'm still left a bit unsatisfied by the document since I don't get
> > a clear picture of what roles "recipients" take.  Presumably this is to
> > some extent intentional, so as to be relevant in many use cases and not
> > have to finesse distinctions such as the Web PKI's TLS client and
> > end-entity server, but my current understanding still includes different
> > recipients using the root CA for different purposes and getting it in
> > different ways, and there's something of an impedance mismatch between the
> > text of the document and my understanding.  I admit the possibility that
> > the document is fine and my understanding wrong, so I don't want to stand
> > in the way of the document moving forward.
> 
> There are many ways that the successor self-signed certificate might "become available" (the words used in the Introduction).  A protocol could be used to push it out, or the recipient could simply process a certification path that includes it.  Flexibility is intentional; the answer may be very different in a private PKI and the Web PKI.  The experimental RFC specifying the syntax of the extension should not need to cover all of the possible use cases.

All true.  Let's move forward with this, then -- please publish the new rev
and I can clear.

-Ben