Re: About RFC4985, SRVName

"Manger, James" <[email protected]>
Newsgroups gmane.ietf.x509
Message-ID <255B9BB34FB7D647A506DC292726F6E13BD6D8F7E0@WSMSG3153V.srv.dir.telstra.com>
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.

_______________________________________________
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.