One technical point, have you considered the ODI mechanism that we developed for CAA up to the -01 version when the client enforcement bit got kiboshed?
The name is confuising, but lets say we call it the DIGEST URI type and the digest data consists of DIGEST: < Base64 ( <Object-type> + <Digest-alg> + <Digest-value>) The idea was that this is something we could write code into various crypto libs to generate as a fixed ASCII blob that the user can then cut and paste. It is thus easier for the admin to manage than having the digest alg being a separate parameter that they have to get right. A practical benefit here is that it makes it easy to have multiple digests in the same header without the need for bracketing: Pin: DIGEST:w2eoiuweoifuweoi== DIGEST:weowoeifwoeifj== Is easier to parse than: Pin: [alg=sha1 fingerprint=odoiweoifjio==] [alg=sha256 fingerprint=wejwekhjw==] This makes it easy to provide two versions of the digest so that old and new browsers can make use of the same data. This is the type of capability that I think will be essential in emergency response if we ever have a SHA2 breach to cope with. It also means that the digest format is intrinsically proof against content type substitution attacks. If the code expects a cert or a key, it can check that it is not being fed a cunningly crafted object of another type. One minor point, the draft mentions SHA1. Could we just dump that? I can't see a good reason to use SHA1 in new code at this point. I would like all new code to be SHA3 capable from the start. Which is why the ODI scheme used ASN.1. Any code that is going to touch certs is going to have to have an ASN.1 algorithm type mechanism. But knowing what the IANA situation is takes an additional bit of data. [As a matter of policy I would prefer that the IETF get out of the business of giving code points that recognize vanity crypto and only ever issue code points for algorithms that the IETF endorses as MUSTs for IETF protocols.] On Mon, Sep 12, 2011 at 5:56 PM, Chris Palmer <[email protected]> wrote: > Hi all, > > Chris Evans and I work at Google on the Chrome security team. We have > devised this specification for a new extension to Strict Transport > Security to allow site operators to "pin" certificates: UAs will > require that TLS connections be validated with at least one of the > public keys identified in the new "pins" directive in the HSTS header. > (Sites can pin to one or more public keys in end entity, subordinate > CA, and/or root CA certificates, for flexibility and disaster > recovery.) > > We hope that this mechanism opens up the benefits of certificate > pinning to more sites. Currently, Chrome can "pre-load" HSTS behavior > and certificate pins for sites, but the mechanism for doing this > (email us!) does not scale. > > We eagerly anticipate your comments, questions, concerns, et c. As you > can see from the Ideas section, there are some unanswered questions > about the behavior of UAs and hosts, and possible extensions to the > policy. > > _______________________________________________ > websec mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/websec > > -- Website: http://hallambaker.com/
_______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
