Joel Jaeggli has entered the following ballot position for draft-ietf-dane-ops-14: No Objection
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dane-ops/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- from fred baker's opsdir review, I would like to see a commnet on these from the authors. thanks joel I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. Document reviewed: draft-ietf-dane-ops-12 Summary: Ready to go, two comments that might be considered last call or IESG comments if the AD agrees. I think the opening paragraph of the introduction needs some tweaking. The DANE TLSA specification ([RFC6698]) introduces the DNS "TLSA" resource record type. TLSA records associate a certificate or a public key of an end-entity or a trusted issuing authority with the corresponding TLS transport endpoint. DNSSEC validated DANE TLSA records can be used to augment or replace the use of trusted public Certification Authorities (CAs). I'm not an expert on this, but I think it would be more accurate to say that it replaces a PKI, not a CA. A CA probably deploys and operates a PKI. However, it does so in the context of a business - it vets entities that it will sell certificates to, and then sells them certificates, which it stores somewhere such as a PKI. I would expect that the CA, in this model, would have the same business (and hence is not replaced), but store its certificates in TLSA records instead of or in addition to in a PKI. In section 1.1, a number of terms are defined, including "public key". If "public key" needs definition (which it does, as the term is used to specifically refer to a field within a certificate, as opposed to a more general cryptographic usage), I think "Certificate Authority (CA)" and "Public Key Infrastructure (PKI)", which are also used throughout the document, require definition. You note that neither of these comments is substantive with respect to the protocol, the record, or the operational recommendations that the draft makes. Operationally, the document poses no requirements on operators as a general class. It does require that a DNS operator implement DNSSEC (else I'm not sure how one trusts a TLSA), and it has a number specific directions to the CA about the TLSA records it asks the DNS operator to store. However, an operator that simply offers transit service, for example, is not affected. _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
