On Thursday, November 05, 2015 05:05:02 pm Viktor Dukhovni wrote: > On Thu, Nov 05, 2015 at 04:59:18PM -0500, Dave Garrett wrote: > > > On Thursday, November 05, 2015 04:38:34 pm Viktor Dukhovni wrote: > > > I'd like it to say: > > > > > > * The signature algorithms of self-signed certificates are > > > not subject to any constraints on either the supplicant or > > > the verifier. They are not required to match the supported > > > signature algorithms of the peer, are not required to avoid > > > deprecated algorithms, and their self-signatures SHOULD NOT > > > be checked. > > > > Why "SHOULD NOT be checked"? I don't think it needs to say anything about > > checking self-signatures here, one way or another. > > The verifier always has a trusted out-of-band copy of each > trust-anchor. Checking the self-signature may needlessly run into > problems when its deprecated algorithm is no longer even implemented > in the crypto library. And yet the trust-anchor is still fine.
Ideally, if the implementation is trusting certs as a whole, then it should be attempting to validate self-signatures upon addition to the trust store. If the cert received matches exactly, then it has been checked; redoing it isn't helpful. I note "attempt to validate" and agree that failing but still agreeing to trust the cert could be fine. Essentially, I'd rather it say something to the effect of: "Trusted self-signatures SHOULD be validated before adding to a trust store and SHOULD NOT be re-checked at runtime." But we're getting slightly out of scope here, which is why I'm thinking that elaborating on this topic exactly as suggested is not needed in the document. Dave _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
