Re: [websec] Comments on draft-ietf-websec-key-pinning-06

[Phillip Hallam-Baker <[e-mail]>]

CAA faced the problem of identifying a CA.

During the evolution of the draft we went through pretty much every scheme
mentioned in this thread. In the end we decided to go with a domain name
that is asserted for that purpose by the CA. So symantec.com / comodo.com /
etc.


At this point the main reason Cert Pinning should follow the same route is
that it is already in use and absent a good reason, TLS CA pinning should
follow the existing approach. This makes it more likely that we will get
the support embedded into platforms accurately.

The main reason for going with domain names in CAA was that it means there
is no need to create a new registry. That is important as it feels wrong to
have an IETF spec differentiate between commercial and private CAs. It
feels even wronger to have IANA managing registries of commercial
providers. There are good business reasons for the CAs to not want their
business under the control of IANA and vice versa.


There are several other advantages though. One is that it makes it much
easier to work out how to put in mechanisms to 'unpin' since these can now
key off Domain names.

So hypothetically let us imagine that there was a Diginotar situation and
several hundred thousand browsers are now pinned to the busted root. Ooops.

One way that we could approach unpinning in this situation would be to use
something involving DNSSEC


Now that is not an argument for writing more code now. But putting DNS
names there are at least as good as any other option but the fact that they
are a discovery index provides a LOT of power that may be useful down the
line.

This might happen in CAA. An obvious next step for CAA is to have a cert
request mechanism where the end entity looks at the CAA record to find out
where it can get certs from.