Re: [Uta] FW: [Ntp] Wildcards in NTS certificate checking

[Peter Saint-Andre <[e-mail]>]

On 5/2/22 8:59 AM, Salz, Rich wrote:
> This is now an open issue https://github.com/richsalz/draft-ietf-uta-rfc6125bis/issues/44

Yep, I'll propose some text.

> On 4/19/22, 7:42 PM, "Peter Saint-Andre" <[e-mail]> 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
>