On Sat, 2010-09-25 at 02:22 +0200, Martin Rex wrote: > Section 5.1.4 here: > > http://www.w3.org/TR/wsc-ui/#selfsignedcerts > > is much closer what I this would be useful and sensible. > > "Pinning" of certs is useful for both, certs that validate fine > and certs that do not validate for the two reasons "not trusted" > and "server-id-mismatch".
Once again (http://www.ietf.org/mail-archive/web/certid/current/msg00338.html), the purpose of pinning is to make it possible to connect to servers with unverifiable certificates, not to replace the public-CA trust model, which is much more difficult to do properly. The definition of "strongly TLS-protected" (http://www.w3.org/TR/wsc-ui/#def-strong-tls) includes validated certificates regardless of whether there is a pinned certificate. > What is the idea behind visualizing the full chain? > > I've seen the same in 5.1.4 of the WSC-UI document but there's > no rationale given and I can not think of one. If the purpose is > memorizing and "pinning" a server cert, there is no point in > visualizing the certificate chain. > > Either there is no trust, then the chain can be crafted to look > like anything, Not necessarily. There are some CAs I don't want to enable unconditionally as trust anchors, but whose certificates I am willing to accept after additional manual verification. In that case, I would check the fingerprint of the top certificate of the presented chain against the one I expect. But you're right that "forcing the user to view the entire certification path" may have no real security benefit in general, though it sounds impressive. -- Matt _______________________________________________ certid mailing list [email protected] https://www.ietf.org/mailman/listinfo/certid
