Re: About RFC4985, SRVName

The use of “_” as the service name would probably meet your use case.

 

Jim

 

 

From: pkix [mailto:[email protected]] On Behalf Of Erwann Abalea
Sent: Wednesday, July 20, 2016 11:43 AM
To: Manger, James <[email protected]>
Cc: <[email protected]> <[email protected]>
Subject: Re: [pkix] About RFC4985, SRVName

 

Almost. Anyway, it's not a nice solution. This is the equivalent of allowing a CA to produce bogus certificates in the hope that they will be rejected by another validation layer.

 

The "invalid" TLD seems to not be requested anymore at the root DNS servers; this wasn't the case a few years ago.

That doesn't mean this TLD isn't requested at all (on delegating or caching name servers), as we see that another TLD listed in RFC6761 is still requested up to root DNS servers (localhost), and that the reserved "local" TLD (RFC6762) is also requested at the root level.

 

And the "invalid" service name, while not registered at IANA, is also not reserved, and can then still be defined and used at a local level.

 

2016-07-19 3:24 GMT+02:00 Manger, James <[email protected] <mailto:[email protected]> >:

Permitting only a non-existent service name (eg “_invalid”) almost gives you what you need. Include the “invalid” domain name for good measure [RFC 6761 Special-Use Domain Names].

 

NameConstraintsSyntax:{

  permittedSubtrees {

    {

      base otherName:{

        type-id id-on-dnsSRV,

        value SRVName:"_invalid.invalid"

      }

    }

  }

}

 

--

James Manger

 

 

From: pkix [mailto:[email protected] <mailto:[email protected]> ] On Behalf Of Erwann Abalea
Sent: Tuesday, 19 July 2016 1:33 AM
To: <[email protected] <mailto:[email protected]> > <[email protected] <mailto:[email protected]> >
Subject: [pkix] About RFC4985, SRVName

 

Bonjour,

 

I think it's the right list for this topic.

 

There is an attempt to allow SRVNames in public X.509 certificates as defined by CABForum. This would follow RFC4985.

However, the NameConstraints matching rules as written in section 4 doesn't allow for an empty SRVName restriction; the SRVName has a SIZE(1..MAX) constraint, and the text doesn't deal with both service name and DNS name missing. Having this "fully permitted" constraint may seem stupid, but it's the only way to completely forbid SRVNames, by using such constraint in the excludedSubtrees portion of the NC extension.

 

What is the proper way to solve this issue? Suppress the size constraint on the SRVName element in section 2? Modify section 4 to allow the single '.' character (U+002E) to represent both service and DNS names missing?


 

-- 

Erwann.





 

-- 

Erwann.

_______________________________________________
pkix mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pkix