Re: [websec] Certificate Pinning via HSTS

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 <palmer@google.com> 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
> websec@ietf.org
> https://www.ietf.org/mailman/listinfo/websec
>
>

-- 
Website: http://hallambaker.com/