Hi Peter, I understand how NC values for domain names relate to CA certificates that have ServerAuth or Secure email, but I’m not sure about Code Signing, client auth, document signing and time stamping.
- Is the list of required DN fields listed anywhere for these types to be considered to be Name Constrained? Could I NC an OU field and call it name constrained if that is all I wanted in the subject of the issued certificates? o NC in RFC5280 decomposes to: § GeneralSubtrees, then to § GeneralName then to § a choice of rfc822Name, dNSName, directoryName (Name), and more o If we NC by Name (decomposes to RelativeDistinguishedName), what specific AttributeTypes are needed? Perhaps some of the cert types have rules about what MUST go into their DN, but that’s not the case for all of them (e.g., client auth). o So, what constitutes NC in those cases? Is NC meaningful? - Side question: Do any of “these” applications enforce name constraints? If not, what’s the point (other than not being required to perform WT audits, which doesn’t bother me a bit…just asking) Gerv: Your last Policy update added a requirement that even NC CAs needed to be audited (discussed previously in a different thread). Does this conflict with anything in Peters flow chart? Doug From: Public [mailto:[email protected]] On Behalf Of Peter Bowen via Public Sent: Sunday, April 30, 2017 1:26 PM To: Jeremy Rowley <[email protected]>; CA/Browser Forum Public Discussion List <[email protected]> Cc: Peter Bowen <[email protected]> Subject: Re: [cabfpub] Which CAs must be audited Of course I missed a key step. If there is an EKU extension, check to see if it contains the anyEKU KP. If so, then go to the pathLen check. Otherwise check for specific KPs. On Apr 30, 2017, at 9:27 AM, Jeremy Rowley <[email protected]<mailto:[email protected]>> wrote: Lol at the IPv4 and IPv6 part. From: Public [mailto:[email protected]] On Behalf Of Peter Bowen via Public Sent: Sunday, April 30, 2017 8:53 AM To: CA/Browser Forum Public Discussion List <[email protected]<mailto:[email protected]>> Cc: Peter Bowen <[email protected]<mailto:[email protected]>> Subject: [cabfpub] Which CAs must be audited Over on the mozilla.dev.security.policy list, there was some confusion about which subordinate CAs need to have audits. I’ve put together two flow charts to help document what I think has been said on that list. I tried to merge info from both the Mozilla and Microsoft policies, so I might be a little off. The one place where this does differ from current Mozilla policy is that it has disclosure of technically constrained CA certificates themselves. This is proposed for Mozilla but not yet required. Anyone see errors? Thanks, Peter <image001.png> <image002.jpg>
_______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
