Hi Russ,
On 23/11/2015 15:10, Russ Housley wrote:
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?
If you are only suggesting to adding this:
* 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
<https://tools.ietf.org/html/rfc6125#ref-PKIX>] and also
[LDAP-SCHEMA <https://tools.ietf.org/html/rfc6125#ref-LDAP-SCHEMA>]
* DNS-ID = a subjectAltName entry of type dNSName; see [PKIX
<https://tools.ietf.org/html/rfc6125#ref-PKIX>]
* SRV-ID = a subjectAltName entry of type otherName whose name
form is SRVName; see [SRVNAME
<https://tools.ietf.org/html/rfc6125#ref-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 <https://tools.ietf.org/html/rfc6125#ref-ABNF>] productions
from [URI <https://tools.ietf.org/html/rfc6125#ref-URI>]); see [PKIX
<https://tools.ietf.org/html/rfc6125#ref-PKIX>] and
[URI <https://tools.ietf.org/html/rfc6125#ref-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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/uta