[cabfpub] Name Constraints, Auditing and EKU

[Erwann Abalea]

-- 
Erwann ABALEA

Le 23/04/2013 19:28, Piyush Jain a écrit :
> Wendy,
>
> I don't think that these CAB forum requirements are applicable to FPKI (or
> for that matter any enterprise PKI) at all.

Or you can say that the BR are applicable to anything that gets audited 
according to it.

> The fact that the BR document lists only browser vendors as the relying
> party software providers is a good indication of the scope of these
> requirements.

Public CAs, yes. But with a strong consumer point of view.

> However, your point about using EKU in sub CAs as a constraint is well
> taken. Even from CAB requirements perspective it is a little crazy.
> Think of OCSP signing EKU as an example. The root might think it is
> constraining the sub CA, but it has essentially granted sub CA the right to
> provide revocation status on its behalf.

This text is a proposal that is discussed about publicly. It's not part 
of the BR, no ballot has been voted to include it in the BR, no vote has 
been engaged to adopt this proposal, no endorsement has been asked to 
engage a vote. We're far.

It's clear to anyone fluent in technical aspects of PKI that this point 
of the proposal isn't acceptable. But it wasn't evident at first read. 
That's why proposals are discussed, corrected, polished, then formaly 
presented, and voted. I don't think the current discussion around 
RFC2560bis is a model of how-things-must-be-done (seriously, declaring a 
non-existent certificate as suspended with a revocation date set to 
01/01/1970, isn't this crazy?)

Apparently, the lack of OCSPSigning in a subordinate CA's EKU extension 
blocks MSCA from creating its own designated OCSP responders. I'm 
waiting for results from someone more versed in MSCA than I am (Ryan 
Hurst comes to mind). If it's true, then MSCA will have to evolve, and 
it shows that EKU constraints isn't as smooth as it seems (how surprising).

> Now if there are talks of embedding FPKI root in the browsers, it would be a
> completely different discussion.

Haven't you heard of 
https://groups.google.com/forum/?fromgroups=#!topic/mozilla.dev.security.policy/hCxohNynd_0 
<https://groups.google.com/forum/?fromgroups=#%21topic/mozilla.dev.security.policy/hCxohNynd_0> 
?

> -Piyush
>
>> -----Original Message-----
>> From: public-bounces at cabforum.org [mailto:public-
>> bounces at cabforum.org] On Behalf Of Brown, Wendy (10421)
>> Sent: Monday, April 22, 2013 12:50 PM
>> To: Rob Stradling; Erwann Abalea
>> Cc: public at cabforum.org
>> Subject: Re: [cabfpub] Name Constraints, Auditing and EKU
>>
>> I disagree with the statement it is too late to try to stop the
> proliferation of
>> trying to do technical constraints on CAs using EKU in violation of the
> intent of
>> RFC 5280.
>>
>> The FPKI is one large community of PKIs that will opt for publicly
> disclosed
>> and audited rather than the technical constraints Mozilla is trying to
> impose
>> because that model doesn't really work with our community and we already
>> require audit of all subordinate CAs.
>>
>>     wendy
>>
>> -----Original Message-----
>> From: public-bounces at cabforum.org [mailto:public-
>> bounces at cabforum.org] On Behalf Of Rob Stradling
>> Sent: Monday, April 22, 2013 3:38 PM
>> To: Erwann Abalea
>> Cc: public at cabforum.org
>> Subject: Re: [cabfpub] Name Constraints, Auditing and EKU
>>
>> On 22/04/13 15:08, Erwann Abalea wrote:
>> <snip>
>>>> 12. Appendix B(2)G:
>>>>         "id-kp-OCSPSigning MUST be present"
>>>>
>>>> Disagree.  The OCSP Signing trust purpose is not supposed to be
>>>> passed down from the Root, and AFAIK there is no way to prevent a
>>>> Subordinate CA from issuing delegated OCSP Signing Certificates!  (If
>>>> you have evidence to the contrary, please say).
>>> I think the requirement is really a "id-kp-OCSPSigning MUST NOT be
>> present".
>>> If CA A issues a certificate to CA B with id-kp-OCSPSigning in the
>>> EKU, then CA B has now a valid OCSP responder for certificates issued
>>> by CA A; which is certainly NOT something wanted by CA A.
>> +1
>>
>>> There are limits to using an extension for something it wasn't
>>> designed for... I'm not a fan of "EKU constraints".
>> I agree that it would be preferable for the PKIX specs to match the
> reality,
>> but unfortunately that isn't the case here.
>>
>> Mozilla could've achieved the same "technically constrained" goal by
>> requiring the use of the Netscape Certificate Type extension instead of
>> Extended Key Usage, but they chose EKU because "EKU constraints" are
>> already supported more widely.  Yes, it's arguably a violation of RFC5280,
> but
>> the momentum behind "EKU constraints" is already too great for that to
>> make any difference IMHO.
>>
>> --
>> Rob Stradling
>> Senior Research & Development Scientist
>> COMODO - Creating Trust Online
>> _______________________________________________
>> Public mailing list
>> Public at cabforum.org
>> https://cabforum.org/mailman/listinfo/public
>>
>>
>> _______________________________________________
>> Public mailing list
>> Public at cabforum.org
>> https://cabforum.org/mailman/listinfo/public

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20130423/8ebef37b/attachment-0003.html>