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

[Alexey Melnikov <[e-mail]>]

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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/uta