Subject: [pkix] About RFC4985, SRVName

From: Erwann Abalea <[email-masked]>
Date: Mon, 18 Jul 2016 17:33:19 +0200

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.

---

From: "Manger, James" <[email-masked]>
Date: Tue, 19 Jul 2016 11:24:21 +1000

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-masked]] On Behalf Of Erwann Abalea
Sent: Tuesday, 19 July 2016 1:33 AM
To: <[email-masked]> <[email-masked]>
Subject: [pkix] About RFC4985, SRVName

Bonjour,

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.

---

From: Erwann Abalea <[email-masked]>
Date: Wed, 20 Jul 2016 11:43:25 +0200

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-masked]>:

> 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,
>
> *From:* pkix [mailto:[email-masked]] *On Behalf Of *Erwann Abalea
> *Sent:* Tuesday, 19 July 2016 1:33 AM
> *To:* <[email-masked]> <[email-masked]>
> *Subject:* [pkix] About RFC4985, SRVName
>
>
>
> Bonjour,
>
>
>
> 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.

---

From: Jim Schaad <[email-masked]>
Date: Wed, 20 Jul 2016 12:13:56 +0200

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

Jim

From: pkix [mailto:[email-masked]] On Behalf Of Erwann Abalea
Sent: Wednesday, July 20, 2016 11:43 AM
To: Manger, James <[email-masked]>
Cc: <[email-masked]> <[email-masked]>
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-masked] <mailto:[email-masked]> >:

NameConstraintsSyntax:{

  permittedSubtrees {

    {

      base otherName:{

        type-id id-on-dnsSRV,

      }

    }

  }

}

--

James Manger

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

Bonjour,

 

-- 

Erwann.

-- 

Erwann.