On 6/9/10 11:45 PM, Thomson, Martin wrote: > Yes, it would be counter-productive to increase scope arbitrarily. > > Let's just drop anything about the "why". The rathole that opens is > scary deep.
/me pulls back from the edge of the abyss... > I'm not looking for anything on validation either. What concerns me > is that a) the implications of the override are not articulated; and > b) this "pinning" or override function applies to certificates > regardless of their RFC5280-determined validity; That sounds too broad. I don't think we want to let a "pinned" certificate off the hook regarding all aspects of PKIX-validity. All we're saying is that the user has explicitly approved this certificate as acceptable for this application server, despite an identity mismatch. > and c) your > readership isn't being told any of this, most are working it out for > themselves. Yes, and that's not good, so we need to clarify things. > Perhaps I can offer text for 3.6.3.1: > > A cached or "pinned" certificate need not be valid according to > [PKIX]. A server that presents a pinned certificate is found to > match based solely on its ability to prove that it possesses the > private key that corresponds to the public key in the certificate. Again, I think that's probably too lenient. Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ certid mailing list [email protected] https://www.ietf.org/mailman/listinfo/certid
