[cabfpub] SRV Ballot
Erwann.Abalea at docusign.com
Fri Jun 10 19:02:16 UTC 2016
I’m opposed to the underscore character for DNS host names, either in SAN:dNSName or in this SAN:otherName(SRVName):Name. The underscore set in SRVName has precisely been added to avoid collisions with DNS host names. This non collision is extremely important for NameConstraints to work with SRVName.
Since this ballot adds another name type, it has an impact on the definition of a technically constrained CA (section 7.1.5), not reflected here.
At a minimum, add an item (d) in section 7.1.5:
(d) For each otherName of type SRVName in permittedSubtrees, , the CA MUST confirm that the Applicant has registered the Name or has been authorized by the domain registrant to act on the registrant’s behalf in line with the verification practices of section 22.214.171.124.
and change the phrase
If the Subordinate CA Certificate includes the id‐kp‐serverAuth extended key usage, then the Subordinate CA Certificate MUST include the Name Constraints X.509v3 extension with constraints on dNSName, iPAddress and DirectoryName as follows:‐
If the Subordinate CA Certificate includes the id‐kp‐serverAuth extended key usage, then the Subordinate CA Certificate MUST include the Name Constraints X.509v3 extension with constraints on dNSName, iPAddress, DirectoryName, and otherName of type SRVName as follows:‐
Should we also add specific requirements when such a CA is not allowed to issue certificates with an otherName of type SRVName, as it was defined for iPAddress and dNSName (setting these types in the excludedSubtrees portion of NC)?
Reading RFC4985, it’s impossible to have an empty SRVName (the ASN.1 definition forbids it). The logic described in section 4 doesn’t consider the case where both Name and Service are absent. We could specify that a CA not allowed to issue otherName:SRVName certificates must have a single « . » in this entry, but I’m not sure the logic described in section 4 is ok with this.
Le 10 juin 2016 à 19:28, Jeremy Rowley <jeremy.rowley at digicert.com<mailto:jeremy.rowley at digicert.com>> a écrit :
Looking for two endorsers for the following ballot:
The following motion has been proposed by Jeremy Rowley, from DigiCert, and endorsed by ____________________:
-- MOTION BEGINS –
Effective immediately, the follow changes are made to the Baseline Requirements:
A) Section 4.2.2 of the Baseline Requirements is replaced with “No Stipulation”
B) Add the following definition to Section 1.6.1:
Wildcard Domain Name: A Domain Name formed by prepending '*.' to a FQDN.
C) Section 126.96.36.199.1 is amended as follows:
Certificate Field: extensions:subjectAltName
Contents: This extension MUST contain at least one entry. Each entry MUST be either a dNSName containing the Fully‐Qualified Domain Name, Wildcard Domain Name, or an iPAddress containing the IP address of a server, or an otherName of type SRVName as defined in RFC4985. An entry MUST NOT be an Internal name or Reserved IP Address. The CA MUST confirm the entry as follows:
a) For a Fully‐Qualified Domain Name or Wildcard Domain Name entry, the CA MUST verify the entry in accordance with Section 188.8.131.52;
b) For a SRVName entry, the CA MUST verify the Name portion of the entry in accordance with Section 184.108.40.206; and
c) For an IP address entry, the CA MUST verify the entry in accordance with Section 220.127.116.11 or has been granted the right to use it by the Domain Name Registrant or IP address assignee, as appropriate. Wildcard FQDNs are permitted.
As exceptions to RFC5280 and X.509, dNSName entries MAY contain Wildcard Domain Names, and FQDNs and Wildcard Domain Names MAY contain the underscore character ("_") in any location where the hyphen character ("-") is allowed. SRVName entries MUST NOT contain Wildcard Domain Names.
If a name constrained CA has a dNSName constraint but does not have a constraint for SRVNames, the CA MUST NOT issue certificates containing SRVNames.
As of the Effective Date of these Requirements, prior to the issuance of a Certificate with a subjectAlternativeName extension or Subject commonName field containing a Reserved IP Address or Internal Name, the CA SHALL notify the Applicant that the use of such Certificates has been deprecated by the CA / Browser Forum and that the practice will be eliminated by October 2016. Also as of the Effective Date, the CAs SHALL NOT issue a certificate with an Expiry Date later than 1 November 2015 with a subjectAlternativeName extension or Subject commonName field containing a Reserved IP Address or Internal Name. Effective 1 October 2016, CAs SHALL revoke all unexpired Certificates whose subjectAlternativeName extension or Subject commonName field contains a Reserved IP Address or Internal Name. Effective May 1, 2015, each CA SHALL revoke all unexpired Certificates with an Internal Name using onion as the right‐most label in an entry in the subjectAltName Extension or commonName field unless such Certificate was issued in accordance with Appendix F of the EV Guidelines.
---- END BALLOT ----
Public mailing list
Public at cabforum.org<mailto:Public at cabforum.org>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Public