Actually, the inheritance mechanism should probably be prohibited altogether.
As things stand it allows a CA to poison a cert issued by another CA! Let us imagine CA X issues a cert for Alice, the chain is X -> XI -> A. Now imagine that CA Y issues a cross cert for XI, we now have a chain Y-> XI -> A The parameters for the key now depend on the path! Yuk! I don't know if there is a practical attack possible , this just occurred to me. But even if there is no attack there is potential for error. [The sort of attack I am thinking of is a kleptography like attack when country A sells sabotaged crypto equipment to country B. Country B may verify that only certs issued through the sub CA XI they control are used but this gives a way to defeat that control.] On Tue, Dec 13, 2011 at 10:20 AM, Adam Langley <[email protected]> wrote: > On Tue, Dec 13, 2011 at 7:56 AM, Phillip Hallam-Baker <[email protected]> > wrote: > > I don't like a solution for pinning that depends on the CA delivering the > > 'right' sort of cert. I would prefer to add in a second hash over the > > parameter values or specify them explicitly in the pin or to have the > hash > > be over what the values would be if completely specified in the Key Info. > > In the case of ECDSA, it'll be very rare for the parameters to be > omitted since they can be compactly represented by a named curve. In > fact, I've not seen code in SSL libraries that'll go hunting for EC > parameters in a CA key - I strongly suspect that support for this is > minimal at best. > > Therefore I'm happy to simply exclude the possibility in the spec and > save the complexity. > > > Cheers > > AGL > -- Website: http://hallambaker.com/
_______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
