[cabfpub] Which CAs must be audited

[Peter Bowen]

> On May 1, 2017, at 11:41 AM, Doug Beattie <doug.beattie at globalsign.com> wrote:
> 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)
>  <>
Doug,

To be honest, I don’t really know.  I was trying to follow the Mozilla and Microsoft policies (and the implied Chrome policy) when building the flow chart.  That is why the EKU split; Chrome only seems to care about serverAuth, so that is one path.  Mozilla also cares about emailProtection, so that is another path.  And then Microsoft’s requirements list a number of EKUs as requiring audits, so that is the last path.

Microsoft’s definitions say constrained has "EKU, geographic, or other technical restrictions”.  The EKU part is relatively easy — but I did forget to include that bit in the flow chart.  If you take it literally, then you are right, you could have a constraint on OU and call it good. Maybe Jody or Keri can clarify their intent for these EKUs.

I suspect that many applications enforce name constraints because they use the Microsoft library when running on Windows.  

Thanks,
Peter


>   <>
> From: Public [mailto:public-bounces at cabforum.org <mailto:public-bounces at cabforum.org>] On Behalf Of Peter Bowen via Public
> Sent: Sunday, April 30, 2017 1:26 PM
> To: Jeremy Rowley <jeremy.rowley at digicert.com <mailto:jeremy.rowley at digicert.com>>; CA/Browser Forum Public Discussion List <public at cabforum.org <mailto:public at cabforum.org>>
> Cc: Peter Bowen <pzb at amzn.com <mailto:pzb at amzn.com>>
> 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 <jeremy.rowley at digicert.com <mailto:jeremy.rowley at digicert.com>> wrote:
>  
> Lol at the IPv4 and IPv6 part.
>  
> From: Public [mailto:public-bounces at cabforum.org <mailto:public-bounces at cabforum.org>] On Behalf Of Peter Bowen via Public
> Sent: Sunday, April 30, 2017 8:53 AM
> To: CA/Browser Forum Public Discussion List <public at cabforum.org <mailto:public at cabforum.org>>
> Cc: Peter Bowen <pzb at amzn.com <mailto:pzb at amzn.com>>
> 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>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170502/117e9ead/attachment-0002.html>