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]>]

[ i sent this e-mail earlier by accident to Russ offlist, re-sending it
on-list now ]

On Wed 2019-01-09 18:16:38 -0500, Russ Housley wrote:
> 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 ...

I agree -- the root cert is not mandatory to include in the
certificate_list.

But as you wrote earlier, the certs in certificate_list are a "bag of
certs" -- they might contain any certs.  I don't think we can *stop*
people from shipping C2, and if they do, they'll effectively be revoking
C1.

> They sometime change much more significantly, especially after an acquisition.

This draft doesn't need to support the acquisition case if we decide
it's not in the best interest of the relying parties.

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

i know -- but proposal (a) here suggests that the root trust store
doesn't need to associate "trusted issuer name" with any field in the
current self-signed certificate.  rather, it can keep that information
independent.  anyway, it's one of three suggestions.

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

i agree that the document doesn't need to be overly detailed about it.
I'm not even sure that RFC 2119 language is necessary.  but it needs
some guidance to point out the problems it creates for auditors if
something like this is not done.

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

both Old and New are self-signed certificates (Old.Issuer ==
Old.Subject, and New.Issuer == New.Subject).  Proposal (c) here suggests
that we could require Old.Subject to match New.Subject (fsvo "match"),
in order for the replacement/revocation to proceed.

> I will work on some words to acknowledge the concern if the old and
> new self-signed certificates have very different names.

Thanks!

        --dkg