On 03/01/17 20:32, Jeremy Rowley via Public wrote:
_If a name constrained CA has a dNSNAme constrain but does not have a
constraint for SRVNames, the CA MUST NOT issue certificates containing
SRVNames._
Jeremy, ISTM that this sentence really doesn't work.
Firstly, I think "name constrained CA" should be changed to "Technically
Constrained Subordinate CA Certificate". (A "CA" is a "Certification
Authority", which the BRs define to be an organization; organizations
don't have X.509v3 extensions!)
Secondly, when you say "has a...constrain(t)" and "does not have a
constraint", are you talking about Permitted Subtrees, or Excluded
Subtrees, or either?
Thirdly, what happens if there are multiple Subordinate CA Certificates
that have the same Subject and Subject Public Key, but only some of them
have a "dNSNAme (sic) constrain (sic)" and/or a "constraint for SRVNames"?
Consider https://crt.sh/?caid=7395. https://crt.sh/?id=10185996 has a
Name Constraints extension but no dNSName constraint;
https://crt.sh/?id=10235198 has a Name Constraints extension that
Excludes dNSName=.mil; https://crt.sh/?id=9314792 has no Name
Constraints extension.
For any publicly-trusted Subordinate CA Certificate that contains the
Name Constraints extension, it is possible to issue a self-signed CA
Certificate (with the same Subject and Subject Public Key) that doesn't
include the Name Constraints extension.
What exactly is this sentence trying to achieve?
--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
_______________________________________________
Public mailing list
[email protected]
https://cabforum.org/mailman/listinfo/public
