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
