On Tue, 2012-10-09 at 09:04 +0200, Nikos Mavrogiannopoulos wrote: > On Tue, Oct 9, 2012 at 3:39 AM, John Gilmore <[email protected]> wrote: > > >> Well, my point is that they transfer exactly the same data. 0 transfers > >> an end-entity certificate and so does 2. They differ, as you say, on > >> what the receiving party does on that data. Why bother? How would a > >> server operator ever know what the receiving party will do on the data? > > This is a protocol. It defines what both parties do -- not just > > one party. Two parties interoperate in a protocol when BOTH implement > > it correctly. > > Indeed, but DANE is not a verification protocol. It defines (or should > define) a _part_ of a verification protocol. And this should be > because DANE can be used in many more scenarios than the typical web > browser HTTPS scenario which is implied all over the document. The > "PKIX certification path validation" that is mentioned in the document > happens (or not) in those browsers irrespective of DANE, so there is > no point for DANE to mandate it. What DANE provides is an alternative > method to this path verification. It can be used in addition to path > verification or instead of it. The server operator shouldn't care or > bother how each client would use it (eg. by specifying usage 1 or 3). > He should only specify the key of its server.
This is awfully late to raise an objection. I believe the argument for the current design was that a server operator may care: he may want a revocation via the CA to be effective on DANE clients without having to also pull the certificate from the DNS, particularly if he has to revoke via the CA anyway for the benefit of non-DANE clients. To ensure this, he has to use usage 1 rather than 3. (Or for an intermediate certificate, usage 0 rather than 2 for revocations at or above the intermediate certificate to be effective. Revocations below the intermediate certificate break the chain from the server certificate to the RR, so they are effective under either usage.) -- Matt _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
