It seems like part of your question is whether it's necessary for the terminal cert in a chain to have subject==issuer. That is absolutely *not* the case, at least in NSS. Any certificate can be marked as trusted, in which case validation will terminate with that cert successfully (or actively distrusted, in which case chains with it will be rejected).
I'm not sure if all libraries have this behavior, but I think it's pretty widespread. Certainly, the PKIX RFCs don't equate trust anchors and self-signed certs; in fact, they refer to a TA as "a public key and associated information". On Wed, Jul 22, 2015 at 5:00 AM, Tom Ritter <t...@ritter.vg> wrote: > Hi all, > > I have a path validation/hierarchy question - specifically wondering > about the path validation problems incurred on various clients. (I > realize there's no definite answer besides "test it on all the clients > you care about".) > > Imagine a four-cert hierarchy R -> A -> B -> L (Root, Leaf, and two > Intermediates A & B). R's Issuer and Subject will match, A's Issuer > will be R; B's Issuer will be A; and L's Issuer will be B. R is a > root because of the dual combination of i) being installed in the > trust store and ii) matching the Subject/Issuer. I send a chain of > A->B->L and clients are happy. > > Now what happens when I decide that I want to trust A, but not > everything else off of R? > > I tested it out, and installing A into the trust store on Firefox and > on my MacBook doesn't cause any problems with > Firefox/Chrome/Safari/curl. It seems the issuer/subject mismatch was > not an issue. IS this technique recommended/not > recommended/documented or otherwise known to work or not work under > any circumstances? > > ---- > > The reverse question I have is in the event of Cross Certification. > Imagine a simpler hierarchy R -> A -> L. However in this model, R is > cross-signed by other CA, C - and some clients only have C in their > trust store (while others have C and R). > > In order for this to actually work, there would need to be two R's: R > (self-signed, where Issuer=Subject for a proper root) and R' (signed > by C, with Issuer=C). Which works fine if you know under what > circumstances to send R and R', but poor L doesn't know when to send > which - right? > > I'm also confused by all the extensions: > - AKI and SKI: Both R and R' would have the same SKI. R's AKI points > to it's own SKI; R''s AKI would point to C's SKI. > - What will A's AIA point to? Presumably R and not R'; correct? > Won't this cause problems? > > Is there an elegant solution to this Cross Certification problem? It > seems like Let's Encrypt is going to deal with this (albeit one level > removed), so what's the plan there? > > -tom > -- > dev-tech-crypto mailing list > dev-tech-crypto@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-tech-crypto > -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
