ietf
[Top] [All Lists]

Re: [Uta] Last Call: <draft-ietf-uta-email-tls-certs-05.txt> (Updated TLS Server Identity Check Procedure for Email Related Protocols) to Proposed Standard

2015-11-24 07:31:06
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

<Prev in Thread] Current Thread [Next in Thread>