Re: About RFC4985, SRVName

Erwann Abalea <[email protected]>
Newsgroups gmane.ietf.x509
Message-ID <CA+i=0E4dQf2EZw_esj3ngvOaSSzYSaH3MJ4f3cf2ZXeQSJ5mHA@mail.gmail.com>
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]>:

> 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]] *On Behalf Of *Erwann Abalea
> *Sent:* Tuesday, 19 July 2016 1:33 AM
> *To:* <[email protected]> <[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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.