Hi Russ--
thanks for the responses!
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
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.
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.
> 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. :(
>> 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".
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?
> 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.
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.
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.
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.
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)
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.
> Finally, I want to thank you for all the careful thought that you have
> put into this discussion.
Thanks for your work on this draft, Russ!
--dkg
Attachment:
signature.asc
Description: PGP signature
