DKG: > On Jan 10, 2019, at 12:01 PM, Daniel Kahn Gillmor <dkg@xxxxxxxxxxxxxxxxx> wrote: > > [ 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. If the new-in-old and old-in-new advice is followed and the old-in-new is included in the certificate_list, then the replacement of C1 by C2 will not change the validity of any end-entity certificates. I think your point is that the distribution of C2 by another server will cause the recipient to replace C1 by C2 in their trust anchor store. If all of the servers have not put the old-in-new certificate in their certificate_list, then the path construction may not have all of the certificates that are needed. However a small amount of caching will resolve this, and use of enterprise directory services will resole this. I will work on some text to cover both of these points in the operational considerations, but I do not think this specification should mandate any particular behavior one either one. >> 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. As I said previously, I do not think this extension specification should impose any rules on Root CA naming. >>> 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. I see, I misunderstood your paragraph at the end of your list began, "Failing any of these", which I read to mean that you wanted all three of them checked by the recipient. Now that I understand your intention, I already agreed to work on some words to acknowledge the concern if the old and new self-signed certificates have very different names. >>> 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. Okay. >>> 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. That would require no name change at all, including the GA1 --> GA2, which you already acknowledged is commonplace. Russ
