[cabf_validation] [EXTERNAL] SRVNames in subjectAltNames and nameConstraints

[Paul van Brouwershaven]

Section 7.1.5 of the BR's state:

If the Subordinate CA is not allowed to issue certificates with dNSNames, then the Subordinate CA Certificate MUST include a zero-length dNSName in excludedSubtrees. Otherwise, the Subordinate CA Certificate MUST include at least one dNSName in permittedSubtrees.

Which permits an empty value in the excluded subtrees of the name constraints.



Reading the RFC 5180 this is not clearly stated but it might be interpreted that way as adding something to nothing always results in a match.

DNS name restrictions are expressed as host.example.com.  Any DNS

   name that can be constructed by simply adding zero or more labels to

   the left-hand side of the name satisfies the name constraint.

RFC4985 contains a similar language:

DNS name restrictions are expressed as host.example.com.  Any DNS

   name that can be constructed by simply adding subdomains to the

   left-hand side of the name satisfies the DNS name part of the name

   constraint.  For example, www.host.example.com<http://www.host.example.com/> would satisfy the

   constraint (host.example.com) but 1host.example.com would not.

Does this mean that the SRVNames can/should be blocked by adding an empty value to the excluded subtrees of the name constraints?



The reason for asking is because implementations seem to be slightly different per type of name. An empty DNSName in the excluded subtree is correctly prohibited by OpenSSL and Windows as described in baseline requirements. An URI with an empty value is prohibited in Windows but ignored by OpenSSL, while the RFC describes the logic like the DNSName only with more words and that it MUST contain an FQDN for some reason.



Summary of my understanding:



Restricted using an empty value in the excluded subtrees:

  *   DNSName
  *   SRVName


GeneralName types that may not be restricted using an empty value in the excluded subtrees:

  *   URIs: Must be restricted using a value in the permitted subtrees
  *   RFC822Name: Must be restricted using a value in the permitted subtrees
  *   SmtpUTF8Mailbox: Is restricted using rfc822Name and must not be included in the name constraints


Is the above correct?


Does this mean that there is no way to exclude all URIs, RFC822Name or Othernames without adding them with a value you might also not want to permit in the permitted subtree?


Thanks,


Paul

________________________________
From: Validation <validation-bounces at cabforum.org> on behalf of Ryan Sleevi via Validation <validation at cabforum.org>
Sent: Friday, April 23, 2021 00:18
To: CA/Browser Forum Validation WG List <validation at cabforum.org>
Subject: [EXTERNAL] [cabf_validation] SRVNames in subjectAltNames and nameConstraints

WARNING: This email originated outside of Entrust.
DO NOT CLICK links or attachments unless you trust the sender and know the content is safe.
________________________________
As a follow-up to our call today, I filed https://github.com/cabforum/servercert/issues/268<https://urldefense.com/v3/__https://github.com/cabforum/servercert/issues/268__;!!FJ-Y8qCqXTj2!LdK6Q4WRP9QWdfGzePGS20CdFzVRO-_3ur9uhjLasQTscHbyRv8gy7VOC5IvTfH1XvDMxpbShA$> to capture the discussion we had around SRVNames, so that we can explore steps going forward.

While it is not a priority of Google to add support for SRVNames, relative to the other important work still to be done in the Forum, we're broadly supportive of the goal.

Our proposed sequencing is this:

  1.  A transition path so that existing technically constrained sub-CAs, which are not constrained by SRVNames, are phased out (e.g. revoked and replaced in time)
  2.  Support for SRVNames added to browser clients. This cannot happen before 1, due to the security risk otherwise.
  3.  Support for CAs issuing SRVNames
     *   At a minimum, CAs MUST validate the Domain Portion in a manner consistent with validating a dNSName
     *   It's unclear what policies should be developed for service names, particularly for those using the "host-based" demonstrations of control (e.g. 3.2.2.4.17/.18) - ALPN and .well-known. One path might be mapping the port used for the validation to the IANA well-known port registry (e.g. 80 or 443 becomes "http" SRVName, 465/587 becomes "smtp", etc)

Since there was a desire to keep discussing, I said I'd file a GitHub issue and discuss on list.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20210528/3b555c62/attachment-0001.html>