On Sun, Aug 02, 2015 at 06:12:25PM +1000, Elwyn Davies wrote:
> Minor issues:
> I am not totally convinced about the remaining usage of RFC 2118 keywords,
> but I'll leave that for the ADs to consider.
Thanks for the feedback. Rereading to see what SHOULDs/MUSTs/...
might warrant adjustment.
> Nits/editorial comments:
>
> There are a couple of nits introduced by the edits (or left over from the
> previous version):
>
> s3, para 2: s/ When a servers does/When a server does/,
> s/SHOULD respond/the server SHOULD respond/
>
> s8, para 3, last sentence: s/the only other/The only other/
>
> s10.1, next to last para: s/as when significantly/as the full certificates
> are significantly/
>
> s12, bullet 4: s/to processes extended/to process extended/
>
> s14, last para: s/PKIX-TA(0(/PKIX-TA(0)/
Queued for the next revision. Thanks.
--
Viktor.
https://github.com/vdukhovni/ietf/commits/master
commit dbce022a4dc2e813aa5bd0a0ab9d667a1af655eb
Author: Viktor Dukhovni <[email protected]>
Date: Sun Aug 2 21:50:50 2015 -0400
IESG and GEN-ART Review feedback
diff --git a/draft-ietf-dane-ops b/draft-ietf-dane-ops
index 5f6befd..4705de9 100644
--- a/draft-ietf-dane-ops
+++ b/draft-ietf-dane-ops
@@ -91,17 +91,18 @@
a certificate or a public key of an end-entity or a trusted
issuing authority with the corresponding TLS transport endpoint.
DANE relies on the DNS Security Extensions (DNSSEC, <xref
- target="RFC4033"/>). DNSSEC validated DANE TLSA records can be
- used to augment or replace the use of trusted public Certification
- Authorities (CAs).
+ target="RFC4033"/>). DANE TLSA records validated by DNSSEC can
+ be used to augment or replace the use of trusted public
+ Certification Authorities (CAs).
</t>
<t>
- <xref target="RFC6698"/> defines three TLSA record fields with
- respectively 4, 2 and 3 currently specified values. These yield
- 24 distinct combinations of TLSA record types. This document
- recommends a smaller set of best-practice combinations of these
- fields to simplify protocol design, implementation and deployment.
+ <xref target="RFC6698"/> defines three TLSA record fields, the
+ first with 4 possible values, the second with 2, and the third
+ with 3. These yield 24 distinct combinations of TLSA record
+ types. This document recommends a smaller set of best-practice
+ combinations of these fields to simplify protocol design,
+ implementation and deployment.
</t>
<t>
@@ -303,12 +304,12 @@ _25._tcp.mail.example.com. IN TLSA 2 0 1 (
(SNI) extension of TLS (<xref target="RFC6066" />). Servers
MAY support SNI and respond with a matching certificate chain,
but MAY also ignore SNI and respond with a default certificate
- chain. When a servers does support SNI, but is not configured
- with a certificate chain that exactly matches the client's SNI
- extension, SHOULD respond with some other (default or closest
- match) certificate chain, since clients may support more than
- one server name, but can only put a single name in the SNI
- extension.
+ chain. When a server supports SNI but is not configured with
+ a certificate chain that exactly matches the client's SNI
+ extension, the server SHOULD respond with another certificate
+ chain (a default or closest match). This is because clients
+ might support more than one server name, but can only put a
+ single name in the SNI extension.
</t>
</section><!-- TLS Requirements -->
@@ -1060,7 +1061,7 @@ _25._tcp.mx2.example.net. IN TLSA 3 1 1 (
PKIX Certificate Usages. Some clients may prefer to negotiate
<xref target="RFC7250"/> raw public keys, which are only
compatible with TLSA records whose Certificate Usage is DANE-EE(3)
- with selector SPKI(1). the only other TLSA record type that
+ with selector SPKI(1). The only other TLSA record type that
is potentially compatible with raw public keys is DANE-EE(3)
Cert(0) Full(0), but support for raw public keys with that TLSA
record type is not expected to be broadly implemented.
@@ -1390,7 +1391,7 @@ _25._tcp.mail.example.com. IN TLSA 3 1 0 (
While TLSA records using a TLSA Selector of SPKI(1) and a
TLSA Matching Type of Full(0) (which publish the bare public
keys without the overhead of a containing X.509 certificate)
- are generally more compact, these are also best avoided as
+ are generally more compact, these are also best avoided
when significantly larger than their digests. Rather,
servers SHOULD publish digest-based TLSA Matching Types in
their TLSA records. Instead, the complete corresponding
@@ -1598,7 +1599,7 @@ _25._tcp.mail.example.com. IN TLSA 2 0 1 (
<t><xref target="type1"/> and <xref target="type0"/> explain
that PKIX-EE(1) and PKIX-TA(0) are generally NOT RECOMMENDED.
This document notes that with usage PKIX-TA(0) clients may need
- to processes extended trust chains beyond the first trusted
+ to process extended trust chains beyond the first trusted
issuer, when that issuer is not self-signed. </t>
<t><xref target="cname"/> recommends that DANE application
@@ -1663,7 +1664,7 @@ _25._tcp.mail.example.com. IN TLSA 2 0 1 (
<t>
Thus, when TLSA records are used with opportunistic protocols
- where the PKIX-TA(0( and PKIX-EE(1) do not apply, the recommended
+ where the PKIX-TA(0) and PKIX-EE(1) do not apply, the recommended
protocol design is for servers to not publish such TLSA records,
and for opportunistic TLS clients to use them to only enforce
the use of (albeit unauthenticated) TLS, but otherwise treat
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
