The asymmetry between 0/1 and 2/3 can be confusing - I had to read 6698 several times to sort it out. (I am glad I did, though.)
IMHO the acronym should clarify things, or at least suggest which angle to hold 6698 while squinting. How about these: 0 - CERT-CA 1 - CERT-EE 2 - ROOT-TA 3 - JUST-EE 0 can be either a root CA, or intermediate CA. If the latter, this cert itself must PKIX-validate. 2 can be either a root CA, or another trust anchor - but must be the root of the validation chain either way. 1 requires PKIX validation, 3 does not, hence "just" an End Entity. Thus, a ROOT-CA cert, can be used as either type 0 or type 2 - but that is the only likely place where there is likely confusion. (Of course, if your EE is a root CA, it could be type 1 - but then you are clearly insane. :-)) Brian On 12/2/13 5:15 PM, "Viktor Dukhovni" <[email protected]> wrote: >On Mon, Dec 02, 2013 at 04:34:37PM -0500, James Cloos wrote: > >> My pref is that the suffices be the same for each of the prefices, >> therefore PKIX-TA vs DANE-TA vs PKIX-EE vs DANE-EE. > >I'm all for neatly aligned text, and I appreciate the increased >cosmetic appeal, but surely the fact that this masks semantic >differences is more important. > > The CA in usage 0 is not a trust anchor, but it is in usage 2. > > The chain in usage 2 still requires PKIX validation, be it with > a dynamically obtained trust anchor. > >So PKIX-TA and DANE-TA are each misleading, the first is not a TA, >the second is still PKIX. Are the acronyms just supposed to be >more memorable than the numbers, or are they supposed to concisely >convey the associated meaning? > >-- > Viktor. >_______________________________________________ >dane mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/dane _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
