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.
Does anyone disagree that support for wildcards is the default state of things?
> 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?
> 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?
> 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?
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
