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-09 22:34:47 +0000, Salz, Rich wrote:
>     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:
>
> I think this is beyond the scope of the document.
>
> I do not see how it introduces new problems.  It enables some automation of trust store updates, that is all.

What it introduces is the tight coupling of two previously-distinct
actions for the relying party:

 a) rollout of a new root trust anchor

 b) revocation of the old trust anchor

Previously, these two steps were not tightly coupled in time, which gave
a window for loosely-coordiated deployment (RFC 5280 §4.4, with servers
shipping OldWithNew and NewWithOld certs, as Russ points out).

In the previous model, two things can happen in parallel, in an
uncoordinated fashion:

 x) RPs can learn about the New CA cert

 y) subscribers can update their cert chains, either by:

    1) shipping new end-entity certificates (signed with New, and with
       their chain extended by NewWithOld), or

    2) augmented cert chains (ee cert still signed with Old, but its
       chain extended by OldWithNew)

Once step Y was complete, it was safe to tell the RPs to drop the Old
trust anchor as long as they had completed their part of step X.

This draft says that as soon as an RP learns about New using this
mechanism, it will drop the Old.  This is unsafe unless step Y is
universally complete.  (meanwhile, it also makes Y.2 less plausible,
because it's odd to expect a subscriber to bother shipping OldWithNew if
New isn't available to the public; yet making New available to the
public effectively acts as a revocation of Old for those implementations
which see it).

This is a new problem, and it doesn't exist without this draft's
tight coupling of steps A and B.

The only safe way i see to deploy this is in a carefully staged
sequence:

 * all subscribers complete step Y in manner 1 (new EE cert, shipped
   alongside NewWithOld).  During this time, New MUST be hidden from the
   public, or else subscribers who haven't completed the transition will
   break!

Once that is universally complete:
 
 * deploy New to all RPs (which has a side effect of revoking Old)

Once that is known to be complete, it is safe to:

 * tell all subscribers they can stop shipping NewWithOld intermediate certs

Is there some other safe way to deploy this that i'm missing?

Does no one else see this as a problem?  if not, i'll just shut up about
it and let things break, i guess.  it's not like the ecosystem has never
run into transvalidity problems and unreliable root stores before, this
is just new and interesting automated ways to arrive there…

            --dkg