Re: [lamps] Last Call: <draft-ietf-lamps-hash-of-root-key-cert-extn-02.txt> (Hash Of Root Key Certificate Extension) to Informational RFC

[Russ Housley <[e-mail]>]

DKG:

> On Wed 2019-01-09 11:51:33 -0500, Russ Housley wrote:
>>   Guidance on the transition from one trust anchor to another is
>>   available in Section 4.4 of [RFC4210].  In particular, the oldWithNew
>>   and newWithOld advice ensures that relying parties are able to
>>   validate certificates issued under the current Root CA certificate
>>   and the next generation Root CA certificate throughout the
>>   transition.  Further, this advice SHOULD be followed by Root CAs to
>>   avoid the need for all relying parties to make the transition at the
>>   same time.
> 
> thanks, this looks good so far, and i agree that the draft helps to
> avoid needing coordination between all relying parties (RPs).  But it
> doesn't cover coordination by the subscribers (e.g. TLS servers) yet,
> which is what the next point was about:
> 
>> [ dkg wrote: ]
>>> in this example scenario, the relying party visits site end entity A
>>> (which whose cert has been issued by the new C2), and then end entity B
>>> (which is still using a cert issued by C1).
>>> 
>>>       | Trust |       | cert  |
>>> event  | Store | PSE   | chain | valid?   
>>> --------+-------+-------+-------+----------
>>> start   | C1    | C1    |       |
>>> visit A | C2    | C1,C2 | EA←C2 | EA = ✓
>>> visit B | C2    | C1,C2 | EB←C1 | EB = ?
>>> 
>>> 
>>> It looks to me like EB will not validate, since:
>>> 
>>> 1) C1 is no longer a trusted root, despite being in the PSE
>>> 
>>> 2) COwN is not available to the relying party (and might not be known
>>>   to server B either), so no chain can be formed to the only trusted
>>>   root, C2
> 
> Russ responded:
>> First, TLS explicitly says that intermediate certificates can be
>> included in the "certificate_list" during a transition.
> 
> i agree that this "bag of certs" model is where we're at for
> certificates shipped in TLS (and with CMS, and probably should be for
> any other relevant protocols where certificate path discovery is
> needed).  But can you be concrete about which certificates you think
> which parties will include in their certificate_list?  I see two
> possible proposals:
> 
> 0) A should ship EA, COwN, and C2 in order to avoid breaking the RP's
>    access to site B
> 
> 1) B should make sure that B ships COwN *before* A ever ships C2

The self-signed certificates that represent the thrust anchors are not included in the "certificate_list".  I recall a discussion about whether this behavior should change in TLS 1.3, and after a fairly lengthy discussion at one of the meetings, it was decided that it should not.  More below ...

> 
> Or are you suggesting something else?
> 
> The problem with 0 is that there is no clear incentive for A to take
> that action (because C2 will Just Work™ for all clients that implement
> the rollover), and B can be damaged by A failing to take it.
> 
> The problem with 1 is that it requires coordination among the
> subscribers.
> 
> Or did you have some other suggestion about how to use the "bag of
> certs" to get COwN to the RP?  The revocation functionality of the
> current draft seems to require distribution of it, but i don't see who
> is going to reliably distribute it.
> 
> 
> Perhaps the we need to add some additional guidance in the direction of
> 0, to give A some incentive to do the right thing, and hopefully to
> prevent accidental failures when accessing B:
> 
> * a subscriber (TLS server) cannot guarantee that the RP (TLS client)
>   that currently trusts C1 will implement this draft's cert rollover
>   mechanism; so any subscriber that ships C2 SHOULD also ship COwN in
>   its TLS bag of certs, unless it knows that all of the CA's
>   subscribers have completed the transition to using C2.
> 
> * any RP that implements this cert rollover mechanism MUST also retain
>   in its PSE all CA intermediate certs issued by the new self-signed
>   certificate, and sent as part of a subscriber's "bag of certs".
> 
> * all RPs implementing this mechanism MUST perform path discovery based
>   on the union of its PSE and the bag of certs offered by peers.
> 
> Note that this requires a bit more state management by the RP than
> simply adjusting the root store -- it requires retaining a list of
> trusted roots, *and* a distinct pool of certificates (the PSE) that can
> be used for path discovery.

There are whole informational RFCs on path discovery.  The IETF does not have a standards-track RFC on this subject.  Any way that it is done that results in  valid path is acceptable.  MUST statements on this document on it seem very wrong to me.


> I'm still kind of sad about this, because it looks to me like A might
> not have super strong incentives to do the right thing.  For example,
> they might have sufficient knowledge about all their RPs to know that
> COwN isn't strictly necessary, but not have knowledge about all their
> co-subscribers, for example.  And if B is harmed, the cause of the harm
> is very attenuated and difficult to track down or remedy.

To the replying party, the old-in-new and new-in-old certificates are intermediate certificates.  They should not really be treated differently than any other newly issued intermediate certificate.

>> However, there are many repositories within enterprises, and these
>> repositories can be used to locate the old-in-new and new-in-old
>> certificates during a transition.  This is the situation for the PKI
>> that I know about that will be using this extension.
> 
> If it is a requirement of this draft that the RPs have access to some
> external repository of other certificates, the draft needs to explicitly
> say so -- it needs to say that those repositories should be made
> available, how they should be populated, and when.  If coordinated
> access to these repositories is a requirement, though, then the
> statement that we don't require coordination among RPs isn't
> well-supported.
> 
> Without this guidance, someone will implement this who you didn't expect
> in the initial drafting, and they will experience a very
> difficult-to-track-down reliability problem. :(

The repositories, where they are available, need to be populated with the old-in-new and new-in-old certificates before the new self-signed certificate is released.  I will add that to the operational considerations.

>>> One other open question occurs to me: Should the relying party also
>>> verify that Subject information (or other identity info) in the new cert
>>> matches the old certificate?  I'm imagining a case where the old root CA
>>> ("O=L'Emporium de Foobar,OU=Authorité Racine,C=FR") ends up replacing
>>> itself with ("O=Вооружённые Силы Союза Советских Социалистических
>>> Республик,C=SU").  That would be pretty weird and upsetting, especially
>>> if i didn't know how my "new" Soviet military cert got into my trust
>>> store.  Would it be legitimate to cabin the scope of this rollover to
>>> identical Subjects?
>> 
>> I do not think so.  We have seen cases in the Web PKI were the Root CA
>> changed names as part of a key rollover.  Of course, this happens
>> without this extension today, so they establish a new self-signed
>> certificate and once it is well established, they issue new
>> certificate under the new root and stop issuing certificates under the
>> old one.
> 
> I understand that these subject names do often change, sometimes as
> trivially as from "CN=FooCA G1 Root" to "CN=FooCA G2 Root".

Sure.  That is the most common case.

> But if we allow arbitrary changes to the name, and if i install
> "CN=Jane's CA", i can now end up with no trace of "Jane" in my root
> store, and an entirely unrelated "CN=Bob's CA".  right?

They sometime change much more significantly, especially after an acquisition.

>> If trust in the Root CA is lost by the relying party, then they ought
>> to remove the self-signed certificate from the trust anchor store.
> 
> So in the case above, the self-signed certificate that the user had
> added is nowhere to be found, and there is no mention of "Jane".  How
> does the user know which certificate to remove?
> 
>> Further, I do want this extension to say anything about the structure
> 
>  (i assume you mean "do not want" here)
> 
>> of the trust anchor store.  Rather, it depends on the definition of a
>> trust anchor in RFC 5280 (on page 76), which says:
>> 
>>      (d)  trust anchor information, describing a CA that serves as a
>>           trust anchor for the certification path.  The trust anchor
>>           information includes:
>> 
>>         (1)  the trusted issuer name,
>> 
>>         (2)  the trusted public key algorithm,
>> 
>>         (3)  the trusted public key, and
>> 
>>         (4)  optionally, the trusted public key parameters associated
>>              with the public key.
> 
> immediately thereafter, RFC 5280 says:
> 
>>>> The trust anchor information may be provided to the path processing
>>>> procedure in the form of a self-signed certificate.

Indeed, but the path validation algorithm does not depend on any of the other fields in the self-signed certificate, including the validity period.  I am aware of some implementations that remove a self-signed certificate from the trust store when the notAfter date is reached, but that is a trust store management decision, not a path validation decision.

> This draft replaces one self-signed certificate with another, and the
> new one might have a different "trusted issuer name" than the old.
> Unless the trust anchor store retains the name from the
> originally-injected certificate, this makes maintenance and auditing of
> the trust anchor store by the end user (or local system administrator)
> rather unstable/uncertain.  I don't think that's a great outcome.

I do not think this extension is the place to impose rule about Root CA naming.

> We could reduce that uncertainty with a few recommendations:
> 
> a) RPs should retain the original "trusted issuer name" distinctly from
>    the self-signed certificate, and should *not* change the "trusted
>    issuer name" for a root CA even when the certificate rolls over.

It is not a self-signed certificate unless the issuer and subject names match.

> b) RPs should retain a history of such transitions and be able to
>    display them to local operators or audit systems that inspect the
>    root store.

I can see where this is desirable for audit purposes, but I do not think the document should be too detailed about it.  I think a MAY is sufficient, especially in cases where the old-in-new and new-in-old certificates in a repository provide a bit of history in themselves.

> c) require that the Subject of the replacing certificate matches the
>    Subject of the earlier root CA.  (maybe we can allow some sort of
>    variance in a field in the DN, so that we permit the semi-standard
>    "G1" → "G2" naming shifts? i don't have a concrete suggestion here)

Again, it is not a self-signed certificate unless the issuer and subject names match.

> Failing any of these, the draft should acknowledge that it introduces
> this difficulty for auditors of the most common/likely implementations
> of a root store.

I will work on some words to acknowledge the concern if the old and new self-signed certificates have very different names.

Russ