On Fri, 3 May 2013, Phillip Hallam-Baker wrote:
2) The IETF has also proposed two separate mechanisms for asserting a PKI policy information. There is DANE and there is HTTP certificate pinning.
_service3.example.com URII 10 10 "https://ws.example.com/service3/ pin=foo"
If you trust the DNS for certificate information, then pinning is not needed. The whole idea behind pinning as I understood it was that people don't want trust the DNS.
Note that the discovery parameters could also tell us other things we might want to know, whether to look for an A or AAAA record for example.
And then you can merge in the HASTLS requirements too :P
Special pleading is not going to work. There is never going to be consensus that applications should support DANE or TLS cert pinning or any one of the dozens of schemes that have been proposed. At the moment everyone concentrates on the arguments why their pet project should have priority. That is not productive. If we are going to get anywhere then it has got to stop being a choice between extended discovery for DANE vs extended discovery for other purposes. We have to have one mechanism that can satisfy every requirement to hook a little bit of extra data into the discovery process if any of those requirements is going to be satisfied.
I'm unclear what problem you are trying to solve. If you trust the dns, you don't need pinning. If you don't trust the dns, you cannot trust your new discovery scheme either? Paul _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
