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?
_______________________________________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta
