Re: [Uta] WGLC for draft-ietf-uta-rfc6125bis-06

["Salz, Rich" <[e-mail]>]

Most items Yaron raised (thanks for the review!)  are addressed in https://github.com/richsalz/draft-ietf-uta-rfc6125bis/pull/50/files

        >> * The DTLS reference should change to DTLS 1.3.
        >> * See Appendix A of [VERIFY]
        >> * The rules are brief - it's not clear from the text if this is a 
        >> summary of the totality of the new RFC, or just the changes from the 
        >> previosu version

Also see below.

I'll open new issues and sub-threads for 
	Definition of FQDN and non-public and .local names https://github.com/richsalz/draft-ietf-uta-rfc6125bis/issues/51
	XmppAddr https://github.com/richsalz/draft-ietf-uta-rfc6125bis/issues/52

        > * Similarly, it is not clear to me whether certs obtained through DANE 
        > are in or out of scope.

        Well, DANE (RFC 6698) post-dates RFC 6125 so we might need to update our 
        recommendations to take account of DANE. I'll need to think about the 
        exact text we need.

See separate sub-thread with comments by Viktor. He suggests that if needed we just say remove "per PKIX" from the last sentence of 1.2:
    In order to ensure proper
    authentication, applications need to verify the entire certification
    path>>> as per [PKIX]<<<.

He is an advocate and expert for DANE, so that is what I did.

	Do path validation
        > * And the same question for delegated credentials 

There should be nothing to do for this draft. The subcerts document is explicit about how the "minted" certificate is just holding a key, and that validation should be based on the "original, full" certificate issued to the origin.

        > * The Common Name RDN... can appear more than once in the subjectName. 
        > I'm probably missing something, but how is this different from multiple 
        > server names appearing in SAN when the certificate protects multiple 
        > services?

As it says at the end of Section 2, there are *two* reasons not to use CN. First, CN is an untyped text string, and interpretation is ambiguous. Second, because of that ambiguity, multiple instances are even more ambiguous; is "smtp" really "smtp.example.com":
	CN=www.example.com, CN=smtp

>    Sorry, should have been clearer. I am referring to this text, that lists two reasons why the Common Name RDN doesn't identify a service. I agree with the first reason but I think the second one is incorrect, because SubjectAltNames have the same property and we still use them.

I changed the second bullet to say:
   It can appear more than once in the subjectName, and the interaction
   of muliple instances is not defined.

Does that address your concern?