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

[Daniel Kahn Gillmor <[e-mail]>]

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".

Section 5 ("Operational Considerations") talks about RFC 2510 (should
maybe be 4210 today, no?), 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.

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.

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.

      --dkg