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

["Salz, Rich" <[e-mail]>]

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" <[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