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.
_______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
