This is now an open issue
https://github.com/richsalz/draft-ietf-uta-rfc6125bis/issues/44
On 4/19/22, 7:42 PM, "Peter Saint-Andre" <stpe...@stpeter.im> wrote:
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 NOT
> contain 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
sentence
> or 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 not
> supported. 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's
> probably 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
