|
Hi Russ, On 23/11/2015 15:10, Russ Housley wrote: If you are only suggesting to adding this:Alexey: Thanks for addressing my comments. I think the CN-ID, DNS-ID, and SRV-ID definitions would be about 1/2 page. Is that a lot of text? * CN-ID = a Relative Distinguished Name (RDN) in the certificate
subject field that contains one and only one attribute-type-
and-value pair of type Common Name (CN), where the value
matches the overall form of a domain name (informally, dot-
separated letter-digit-hyphen labels); see [PKIX] and also
[LDAP-SCHEMA]
* DNS-ID = a subjectAltName entry of type dNSName; see [PKIX]
* SRV-ID = a subjectAltName entry of type otherName whose name
form is SRVName; see [SRVNAME]
* URI-ID = a subjectAltName entry of type
uniformResourceIdentifier whose value includes both (i) a
"scheme" and (ii) a "host" component (or its equivalent) that
matches the "reg-name" rule (where the quoted terms represent
the associated [ABNF] productions from [URI]); see [PKIX] and
[URI]
then it would be alright. If we start explaining reference identifiers, etc., then it is much harder job and I an worried of not copying enough, which can make this misleading when compared to RFC 6125. Russ On Nov 21, 2015, at 9:41 AM, Alexey Melnikov wrote:Hi Russ, Thank you for your comments. On 20/11/2015 21:36, Russ Housley wrote:I support this document going forward. Below I suggest four improvements to the document. (1) In Introduction says: Note that this document doesn't apply to use of TLS in MTA-to-MTA SMTP. Can this be enhanced to include a pointer to where this can be found?Currently this is discussed in draft-friedl-uta-smtp-mta-certs, but this is not a WG document, so I would rather not have a pointer.(2) The next paragraph in the Introduction says: The main goal of the document is to provide consistent TLS server identity verification procedure across multiple email related protocols. Since this is a standards-track document, I think it would be better to say: This document provides a consistent TLS server identity verification procedure across multiple email related protocols.Changed, thank you.(3) Section 2 does a lot by reference, which is fine. I think it would help the reader to duplicate a bit of context from RFC 6125, in particular repeating the definitions of CN-ID, DNS-ID, and SRV-ID.Yes, I struggled with this as well. This would be lots of cut & pasted text.(4) Section 3 needs to state first that the certificate passes certification path validation as described in Section 6 of RFC 5280, and second passes the email-specific rules in this section.Yes, this was implied. Added to my copy._______________________________________________ Uta mailing list Uta@xxxxxxxx https://www.ietf.org/mailman/listinfo/uta |