Subject: [lamps] I-D Action: draft-ietf-lamps-hash-of-root-key-cert-extn-04.txt

From: [email-masked]
Date: Tue, 15 Jan 2019 14:28:42 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Limited Additional Mechanisms for PKIX and SMIME WG of the IETF.

        Title           : Hash Of Root Key Certificate Extension
        Author          : Russ Housley
	Filename        : draft-ietf-lamps-hash-of-root-key-cert-extn-04.txt
	Pages           : 10
	Date            : 2019-01-15

Abstract:
   This document specifies the Hash Of Root Key certificate extension.
   This certificate extension is carried in the self-signed certificate
   for a trust anchor, which is often called a Root Certification
   Authority (CA) certificate.  This certificate extension unambiguously
   identifies the next public key that will be used at some point in the
   future as the next Root CA certificate, eventually replacing the
   current one.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-lamps-hash-of-root-key-cert-extn/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-lamps-hash-of-root-key-cert-extn-04
https://datatracker.ietf.org/doc/html/draft-ietf-lamps-hash-of-root-key-cert-extn-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-lamps-hash-of-root-key-cert-extn-04

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Russ Housley <[email-masked]>
Date: Tue, 15 Jan 2019 17:49:56 -0500

This update covers the very long discussion that took place during IETF Last Call.  I believe that all of the comments were completely resolved, except one.  On that point, there is a disagreement between myself and DKG regarding the amount of guidance that should be given to the Root CA and the recipient.

First, DKG would like to say that if a certificate repository is available, then the oldWithNew certificate MUST be made available in that repository before the new self-signed certificate is published.

I think that the first and third paragraphs of the Operational Considerations already covers this point pretty well.

Second, DKG would like to include guidance to the relying party about which certificates to cache from the repository, if one exists.  As best I can tell, this is protection against future unavailable of the repository.

While I find the criteria that DKG suggests to be quite clever, I do not think that we should include actions to protect against repository unavailability in the description of the certificate extension.

Third, DKG suggests that the lack of a oldWithNew certificate in the repository can be a trigger to remove the previous Root CA self-signed certificate.

I think that the third paragraph of the Operational Considerations already covets this point pretty well.

I would like to continue the discussion on the WG mail list (without copying the IETF-wide mail list).  Of course, Tim will make any consensus calls relate to this document.

Russ

> On Jan 15, 2019, at 5:28 PM, [email-masked] wrote:
> 
>

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Wed, 16 Jan 2019 15:01:01 -0500

Thanks for the summary of our off-list discussion, Russ, and for
accurately describing the three concrete changes i think should be made
so that the document provides robust guidance for the "cert repository
expected" use case.

However, the larger point of disagreement on this draft is about the "no
cert repository expected" use case.  The document currently doesn't
provide much concrete guidance for those use cases, using terms like
"some amount of time" or "an appropriate amount of time" for when the
revocation for C1 should trigger.

As an implementer, i would want to know how to choose those times.  The
draft provides me with no guidance on how to make that decision.  (the
guidance "until all of the certificates in the local cache that are
subordinate to it have expired." is insufficient, because it fails to
protect those certificates not yet in the local cache from failing due
to accidentally-induced transvalidity) If the times selected are too
short, then there remains the risk of very hard-to-track-down
transvalidity of some certificates, potentially introduced by parties
who know nothing about the other parties that they are inconveniencing.

I can see two general ways to move forward if the group thinks these
concerns are important (as i do):

 a) declare this draft as only useful in the "cert repository expected"
    use case, and explicitly discourage its use when no certificate
    repository is systemically available.

 b) provide some mechanism for advising relying parties about how to set
    those timeouts/delays for the revocation, and provide guidance for
    the relying parties about how to interpret that mechanism safely.

Regards,

    --dkg

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 16 Jan 2019 23:26:06 +0000

>     a) declare this draft as only useful in the "cert repository expected"

Does an application (smart home IoT device?) that only holds one cert fall into this group?

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Thu, 17 Jan 2019 21:25:18 -0500

> Does an application (smart home IoT device?) that only holds one cert fall into this group?

I should probably clarify that the subscriber (the entity that holds the
cert) probably *doesn't* need to know anything about the certificate
repository.

The certificate repository, if i'm understanding Russ's model correctly,
is something published by the Root CA (or the enterprise network
operations team, or whatever), and consumed by the relying parties.

So if your smarthome IoT device acts as a relying party and talks to
more than one other entity that is certified by the same Root CA, then
*yes*, it does need to have access to a cert repository to use this
extension safely.

But if your smarthome IoT device never acts as a relying party
(e.g. it's a TLS server but it never does outbound TLS connections, and
doesn't do client certificate validation) or it only ever validates a
single entity (e.g. same as above but it also looks for software updates
over cleartext HTTP, and might discover X.509 certificate chains in the
process of checking CMS signatures over the packages, signatures, and
certs it finds during the update process), then it's probably safe to
use this extension without a cert repository *from the perspective of
the IoT device*.

But if you're a client and you're connecting to more than one such IoT
device, and you want to be sure that one such IoT device can't break
your ability to connect to the other comparable IoT devices, then as a
relying party, *you* need to have access to the certificate repository.

does that make sense?

        --dkg

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 18 Jan 2019 03:37:21 +0000

I disagree with that.  I am thinking of the trust repository as something that is like browser root stores.

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Thu, 17 Jan 2019 22:55:42 -0500

On Fri 2019-01-18 03:37:21 +0000, Salz, Rich wrote:
> I disagree with that.  I am thinking of the trust repository as
> something that is like browser root stores.

You say "trust repository" here -- but we are talking about a
"certificate repository", right?  I agree that the terminology is
confusing!  In
https://tools.ietf.org/html/draft-ietf-lamps-hash-of-root-key-cert-extn-04,
it says:

   In enterprise and application-specific environments where a directory
   service or certificate repository is available, the oldWithNew and
   newWithOld certificates SHOULD be published before the successor to
   the current Root CA self-signed certificate is released.  In
   environments without such a directory service or repository,
   recipients SHOULD keep both the old and replacement Root CA self-
   signed certificate in the trust anchor store for some amount of time
   to ensure that all end-entity certificates can be validated until
   they expire.

The fact the draft contemplates a scenario "without such a directory
service or [certificate] repository" but where the relying party still
has access to a "trust anchor store" suggests that these can't be the
same thing.

That said, i agree that the specification of a certificate repository is
unclear in the document, and it doesn't point to any other documentation
or specific examples of how to operate such a repository, or even what
capabilities such a repository should offer.

I've proposed text to Russ about how a relying party with access to a
cert repo (or what i imagine a certificate repository to be) could
minimize the risk of accidental transvalidity due to cert repo
unavailability, but as Russ said at the top of this thread, he thinks
that guidance is overkill for the draft.

      --dkg

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 18 Jan 2019 16:06:37 +0000

Just goes to show we all bring our preconceptions when we read. :)  Looking forward to clarification.

---

From: Ryan Sleevi <[email-masked]>
Date: Fri, 18 Jan 2019 11:14:51 -0500

Forgive what is probably a very stupid question, but isn't this term
suitably addressed in RFC 5280? Specifically, Sections 3, 3.3, and 4.2.2.2?

The notion of a repository was, I thought, one of those fundamental givens
about dealing with PKI, much in the same way that this term has been an
integral part of most of the standards for publication and auditing of
certificates.

On Thu, Jan 17, 2019 at 11:14 PM Daniel Kahn Gillmor <[email-masked]>
wrote:

> ,
> _______________________________________________
> Spasm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spasm
>

---

From: Russ Housley <[email-masked]>
Date: Fri, 18 Jan 2019 12:53:07 -0500

> I disagree with that.  I am thinking of the trust repository as something that is like browser root stores.

A certificate repository is just a place to find certificates and CRLs.

A trust anchor store is needed to validate the certificates that are found there.

Russ

---

From: Russ Housley <[email-masked]>
Date: Fri, 18 Jan 2019 12:56:45 -0500

Ryan:

I believe that I am using the terms consistent with the figure in Section 3 of RFC 5280.

Further, I am using the definition of trust anchor in a manner that is aligned with RFC 5280, especially the section on path validation.

Russ

> On Jan 18, 2019, at 11:14 AM, Ryan Sleevi <[email-masked]> wrote:
> 
> Forgive what is probably a very stupid question, but isn't this term suitably addressed in RFC 5280? Specifically, Sections 3, 3.3, and 4.2.2.2?
> 
> The notion of a repository was, I thought, one of those fundamental givens about dealing with PKI, much in the same way that this term has been an integral part of most of the standards for publication and auditing of certificates.
> 
> On Thu, Jan 17, 2019 at 11:14 PM Daniel Kahn Gillmor <[email-masked] <mailto:[email-masked]>> wrote:
> https://tools.ietf.org/html/draft-ietf-lamps-hash-of-root-key-cert-extn-04 <https://tools.ietf.org/html/draft-ietf-lamps-hash-of-root-key-cert-extn-04>,
> it says:
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/spasm <https://www.ietf.org/mailman/listinfo/spasm>

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Fri, 18 Jan 2019 15:26:10 -0500

> integral part of most of the standards for publication and auditing of

that does give a more precise definition of "repository" than the
current draft, thanks for those pointers.  maybe the current draft
should point to those references?

however, it's not clear to me from a read-through of those sections (and
their inclusion by reference to the X.509 standards themselves) that
there's a place for the CA to put oldWithNew in the repositories
identified by an id-ad-caRepository in a id-pe-subjectInfoAccess
extension.  In particular, 5280 says:

   The id-ad-caRepository OID is used when the subject is a CA that
   publishes certificates it issues in a repository.

since oldWithNew is *not* issued by the old root cert C1, it seems
slightly off to put it there.  otoh, 5280 doesn't say that *only* certs
signed by the subject may be placed in that repository, so it's not much
of a stretch there.  Would it help if the current draft explicitly
expanded the definition?

Do people have examples of a root cert with an id-ad-caRepository in the
AIA field?  I don't see any in my local root store.

    --dkg

---

From: Russ Housley <[email-masked]>
Date: Fri, 18 Jan 2019 18:17:27 -0500

> On Jan 18, 2019, at 3:26 PM, Daniel Kahn Gillmor <[email-masked]> wrote:
> 
> Signed PGP part

I have not seen the id-ad-caRepository in self-signed certificates.

To address your point about definitions, I suggest:

   Some enterprise and application-specific environments offer a
   directory service or certificate repository to make certificate and
   CRLs available to relying parties.  Section 3 in [RFC5280]
   describes a certificate repository.  When a certificate repository
   is available, the oldWithNew and newWithOld certificates
   SHOULD be published before the successor to the current
   Root CA self-signed certificate is released.  ...

Russ

---

From: Tim Hollebeek <[email-masked]>
Date: Wed, 23 Jan 2019 19:49:52 +0000

Any comments on resolving this issue as Russ suggested?  It seems to clarify
the issue helpfully.

-Tim

> -----Original Message-----
> From: Spasm <[email-masked]> On Behalf Of Russ Housley
> Sent: Friday, January 18, 2019 6:17 PM
> To: Daniel Kahn Gillmor <[email-masked]>
> Cc: LAMPS WG <[email-masked]>
> Subject: Re: [lamps] HashOfRootKey when no certificate repository exists
> [was: Re: draft-ietf-lamps-hash-of-root-key-cert-extn-04.txt]
> 
> 
> 
> >> The notion of a repository was, I thought, one of those fundamental
> >> givens about dealing with PKI, much in the same way that this term
> >> has been an integral part of most of the standards for publication
> >> and auditing of certificates.
> >
> > however, it's not clear to me from a read-through of those sections
> > (and their inclusion by reference to the X.509 standards themselves)
> > that there's a place for the CA to put oldWithNew in the repositories
> > slightly off to put it there.  otoh, 5280 doesn't say that *only*
> > certs signed by the subject may be placed in that repository, so it's
> > not much of a stretch there.  Would it help if the current draft
> > explicitly expanded the definition?
> >
> > Do people have examples of a root cert with an id-ad-caRepository in
> > the AIA field?  I don't see any in my local root store.
>

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Thu, 24 Jan 2019 12:30:36 -0500

> Any comments on resolving this issue as Russ suggested?  It seems to clarify

I agree that it helps to clarify what is meant by a "certificate
repository".  Thanks, Russ!

I still think that the draft lacks concrete guidance on how a relying
party should deal with this new revocation mechanism in the context of a
certificate repository that might sometimes be unavailable.

More seriously, it still lacks concrete guidance for relying parties
that have no expectation or knowledge of a certificate repository in the
first place.

            --dkg

---

From: Russ Housley <[email-masked]>
Date: Thu, 24 Jan 2019 19:18:30 -0500

> On Jan 24, 2019, at 12:30 PM, Daniel Kahn Gillmor <[email-masked]> wrote:
> 

That is right, and I do not think it belongs in this document.

I know this is your position, and you know this is my position.

i would really like other on this list to voice their views.

Russ

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 25 Jan 2019 00:30:14 +0000

I don't think either of you will be surprised when I say that it is not needed in this document. :)

---

From: Tim Hollebeek <[email-masked]>
Date: Fri, 25 Jan 2019 01:54:15 +0000

Is there anyone other than Daniel who thinks this is necessary?

There is always the opportunity to address this in additional drafts and
revisions if it turns out to be needed.

There are no concrete proposals for addressing this, and I'm struggling
to understand why that guidance needs to be in this document, so I'd
suggest that it would be best if this issue did not block adoption of this
draft.

-Tim  

> Sent: Thursday, January 24, 2019 7:19 PM
> >> Any comments on resolving this issue as Russ suggested?  It seems to
> >> clarify the issue helpfully.
> >
> > party should deal with this new revocation mechanism in the context of
> > a certificate repository that might sometimes be unavailable.
> >
> > that have no expectation or knowledge of a certificate repository in
> > the first place.
>

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 24 Jan 2019 21:11:18 -0600

This thread prompted me to read the document.  My main concern is that
section 2 still says that "[a]s discussed in Section 5, the recipient can
remove the current Root CA certificate immediately in some situations", but
Section 5 no longer has any discussion of removing the trust anchor (and
when it is safe to do so).  (We have discussion of retaining both old and
new, but not any explicit discussion of removing the old.)  Given that the
whole point of this extension is to be able to retire the old Root CA
certificate, resolving this disparity by removing the quoted text from
section 2 seems undesirable, which would seem to require us to state more
explicitly when it is safe to effect the immediate removal.

-Ben

---

From: Russ Housley <[email-masked]>
Date: Fri, 25 Jan 2019 00:00:25 -0500

Thanks for the careful read, Ben.

I will break the paragraph into two; it is getting too long anyway.  And, I wall add the part that got lost in the recent edits.

   Some enterprise and application-specific environments offer a
   directory service or certificate repository to make certificate and
   CRLs available to relying parties.  Section 3 in [RFC5280] describes
   a certificate repository.  When a certificate repository is
   available, the oldWithNew and newWithOld certificates SHOULD be
   published before the successor to the current Root CA self-signed
   certificate is released.  Recipients that are able to obtain the
   oldWithNew certificate SHOULD immediately remove the old Root CA
   self-signed certificate from the trust anchor store.

   In environments without such a directory service or repository,
   recipients SHOULD keep both the old and replacement Root CA self-
   signed certificate 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.

Russ

> On Jan 24, 2019, at 10:11 PM, Benjamin Kaduk <[email-masked]> wrote:
>

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 25 Jan 2019 09:27:32 -0600

Hi Russ,

That looks much better; thanks!

-Ben

---

From: Tim Hollebeek <[email-masked]>
Date: Thu, 31 Jan 2019 15:39:05 +0000

It appears that no one else shares DKG's concerns.  The consensus appears to
be to proceed with the document with the edits Russ made for Ben.

-Tim

> From: Benjamin Kaduk <[email-masked]>
> Sent: Friday, January 25, 2019 7:28 AM
> To: Russ Housley <[email-masked]>
> Cc: Tim Hollebeek <[email-masked]>; LAMPS WG
> <[email-masked]>; Daniel Kahn Gillmor <[email-masked]>
> > I will break the paragraph into two; it is getting too long anyway.
And, I wall
> add the part that got lost in the recent edits.
> >
> > > This thread prompted me to read the document.  My main concern is
> > > that section 2 still says that "[a]s discussed in Section 5, the
> > > recipient can remove the current Root CA certificate immediately in
> > > some situations", but Section 5 no longer has any discussion of
> > > removing the trust anchor (and when it is safe to do so).  (We have
> > > discussion of retaining both old and new, but not any explicit
> > > discussion of removing the old.)  Given that the whole point of this
> > > extension is to be able to retire the old Root CA certificate,
> > > resolving this disparity by removing the quoted text from section 2
> > > seems undesirable, which would seem to require us to state more
> > >> There is always the opportunity to address this in additional
> > >> drafts and revisions if it turns out to be needed.
> > >>
> > >> There are no concrete proposals for addressing this, and I'm
> > >> struggling to understand why that guidance needs to be in this
> > >> document, so I'd suggest that it would be best if this issue did
> > >> not block adoption of this draft.
> > >>
> > >> -Tim
> > >>
> > >>>>> Any comments on resolving this issue as Russ suggested?  It
> > >>>>> seems to clarify the issue helpfully.
> > >>>>
> > >>>> I still think that the draft lacks concrete guidance on how a
> > >>>> relying party should deal with this new revocation mechanism in
> > >>>> the context of a certificate repository that might sometimes be
> unavailable.
> > >>>>
> > >>>> More seriously, it still lacks concrete guidance for relying
> > >>>> parties that have no expectation or knowledge of a certificate
> > >>>> repository in the first place.
> > >>>

---

From: Russ Housley <[email-masked]>
Date: Thu, 31 Jan 2019 10:42:19 -0500

Thanks.  I just posted -05 which includes the text proposed earlier in this thread.

Russ

> On Jan 31, 2019, at 10:39 AM, Tim Hollebeek <[email-masked]> wrote:
>