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-02 10:26:05 -0800, Paul Hoffman wrote:
>> Using this extension increases the risk of a bad trust anchor rollover
>> at the same time that it makes good rollover more secure.
> 
> I think this may be the root (ha ha) of confusion about the purpose of
> this draft, and it raises some additional concerns for me about whether
> it is clear and useful as it stands (i've been reading -03).
> 
> This draft serves one main purpose as far as i can tell:
> 
> * It provides a technical mechanism that facilitates a root authority
>   releasing a new root certificate.
> 
> This is a good purpose i can get behind, but the introduction implies
> that it also offers another purpose:
> 
>    remove the previous one from the trust anchor store.
> 
> but the only detail in this draft that suggests how that is supposed to
> happen is in the end of the Overview:
> 
>    If either check fails, then [the] potential Root CA
>    certificate is not a valid replacement, and the recipient continues
>    to use the current Root CA certificate.
> 
> The implication here is of course that if both checks succeed, then the
> current Root CA certificate is discarded.  But that is explicitly stated
> nowhere in the document.  Should it be?  If it should, we need more
> text.  If it does not, the draft should remove the text about "remove
> the previous one" and "continues to use the current Root CA
> certificate".

The Abstract of -03 includes:

	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, replacing the current one.

And, the Introduction of -03 includes:

	This hash value is a commitment to a particular public key in
	the next generation self-signed certificate. This commitment
	allows a relying party to unambiguously recognize the next
	generation self-signed certificate when it becomes available,
	install the new self-signed certificate in the trust anchor store,
	and remove the previous one from the trust anchor store.

And, Section 2 of -03 includes:

	Checking the hash of the SubjectPublicKeyInfo ensures that
	the certificate contains the intended public key.  If either check
	fails, then potential Root CA certificate is not a valid replacement,
	and the recipient continues to use the current Root CA certificate.

I could add a sentence here:

	If both checks succeed, then the potential Root CA certificate is
	added to the trust anchor store and the current  Root CA
	certificate is removed.

Does that resolve your concern?

> Section 5 ("Operational Considerations") talks about RFC 2510 (should
> maybe be 4210 today, no?),

Yes, it should be referencing RFC 4210.

> and refers to oldWithNew and newWithOld.
> However, the final sentence of that paragraph is ambiguous:
> 
>   Further, this technique avoids the need for all relying parties to
>   make the transition at the same time.
> 
> Which technique?  The technique in the current draft?  oldWithNew?
> newWithOld?  Both oldWithNew and newWithOld?  If the sentence is talking
> about the two mechanisms from RFC 4210, then Operational Considerations
> should clarify that the current draft explicitly *does* require all
> relying parties (and all subscribers!) to make the transition at the
> same time, since the escape of C2 into the wild means that all
> subscribers MUST start shipping certs signed by C2, because they can't
> know whether their relying parties have switched from C1 to C2 yet.

Please take a look at RFC 4210, Section 4.4 ("Root CA Key Update").  The way that I read the section, it is describing a technique for protecting the new public key using the previous private key and vice versa.  The technique involves both old-with-new and new-with-old.

To be more clear, I will refer to "this advice" in all of the places that reference RFC 4210.  The current text uses "this advice" in one place and "this technique" in another place.  I hope that will be more clear.

> The safest thing is for the subscriber to force the relying party to
> switch to C2 by shipping C2, but of course that will screw over any
> other subscribe that hasn't switched yet.  So i'm not convinced that we
> can safely say that reciept of C2 MUST (or even SHOULD) effectively
> revoke C1.

The whole point of the old-with-new and new-with-old advice is that all of the certificates can be validated to either the old trust anchor or the new one.

> Additionally, the two paragraphs added in -03 make it clear that the
> traditional new-root-cert import mechanism will remain enabled for all
> relying parties, subject to all the pre-existing vagaries and risks.
> (perhaps some other draft can tighten those up, but this draft does not
> do so on its own.)
> 
> So, without this draft offering a strong and immediate revocation
> mechanism, and without it cleaning up the pre-existing new-root-cert
> import mechanism, it does *not* make "rollover more secure" (since all
> existing insecure channels will continue to exist).  It just makes good
> rollover more convenient/automatic.

Yes, that is the point of the extension.

Russ