On 4/19/22 12:14 PM, Salz, Rich wrote:
A new reader in the NTP working group had some feedback on 6125bis.The part that I was looking for was an explicit statement that the "SHOULD NOTcontain the wildcard" has been dropped. It might help to add something like that to the 3rd bullet in section 1.2 I propose to add one sentence: * Wildcard support is now the default. Constrain wildcard certificates so that the wildcard can only be the complete left-most component of a domain name.
+1
Does anyone disagree that support for wildcards is the default state of things?
Bowing to deployment reality, I agree.
IP Addresses are out of scope. I'd like to know more, preferably a sentenceor paragraph but at least a good reference. It seems like a good way to avoid all the security tangles with DNS. As the draft is about *names* I am not sure what should be done here. Any ideas from the WG? It does say * Identifiers other than FQDNs. Identifiers such as IP address are not discussed. In addition, the focus of ... Do we need more rationale?
Personally I don't see the need for a rationale (e.g., pointing out the percentage of certificates containing IP addresses - IIRC Jeff had some numbers on that when we were working on RFC 6125 and it was 1% or less). If someone wants to write a specification about IP addresses as names in certificates, they are free to do so. In RFC 6125, Jeff and I had to limit the scope or the document would have been even longer.
Last paragraph before section 4: "MUST state" that wildcards are notsupported. How does that apply to existing RFCs? Has that item been added to the reviewers checklist? I think it would clarify things if future RFCs would state that wildcards are supported. The current draft says that if you don't support wildcards you MUST state so in your documents. Existing RFCs aren't bound by this draft. Does anyone think this is a problem?
Having this apply to future documents that cite 6125bis seems fine to me.
Section 6.2, last paragraph, matching DNS name and service type. It'sprobably obvious, but worth stating. If I'm trying to find a match for www:www.example.com or sip:voice.example.com, will that match a certificate for sip:www.example.com? Any suggestions on wording to address this? I think the rules in section 4.1 are clear, but any thoughts on how to improve it?
Perhaps we should add more examples, specifically to Section 6.4 on application service types. As I understand the situation mentioned by the original poster, sip:www.example.com (with both domain name and application service type) would not result in a match.
Peter _______________________________________________ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
