<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix"><br>
<pre class="moz-signature" cols="72">--
Erwann ABALEA
</pre>
Le 23/04/2013 19:28, Piyush Jain a écrit :<br>
</div>
<blockquote cite="mid:009001ce4047$f32e8150$d98b83f0$@ditenity.com"
type="cite">
<pre wrap="">Wendy,
I don't think that these CAB forum requirements are applicable to FPKI (or
for that matter any enterprise PKI) at all.</pre>
</blockquote>
<br>
Or you can say that the BR are applicable to anything that gets
audited according to it.<br>
<br>
<blockquote cite="mid:009001ce4047$f32e8150$d98b83f0$@ditenity.com"
type="cite">
<pre wrap="">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.</pre>
</blockquote>
<br>
Public CAs, yes. But with a strong consumer point of view.<br>
<br>
<blockquote cite="mid:009001ce4047$f32e8150$d98b83f0$@ditenity.com"
type="cite">
<pre wrap="">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.</pre>
</blockquote>
<br>
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.<br>
<br>
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?)<br>
<br>
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).<br>
<br>
<blockquote cite="mid:009001ce4047$f32e8150$d98b83f0$@ditenity.com"
type="cite">
<pre wrap="">Now if there are talks of embedding FPKI root in the browsers, it would be a
completely different discussion.</pre>
</blockquote>
<br>
Haven't you heard of
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
<a
href="https://groups.google.com/forum/?fromgroups=#%21topic/mozilla.dev.security.policy/hCxohNynd_0">https://groups.google.com/forum/?fromgroups=#!topic/mozilla.dev.security.policy/hCxohNynd_0</a>
?<br>
<br>
<blockquote cite="mid:009001ce4047$f32e8150$d98b83f0$@ditenity.com"
type="cite">
<pre wrap="">-Piyush
</pre>
<blockquote type="cite">
<pre wrap="">-----Original Message-----
From: <a class="moz-txt-link-abbreviated" href="mailto:public-bounces@cabforum.org">public-bounces@cabforum.org</a> [<a class="moz-txt-link-freetext" href="mailto:public">mailto:public</a>-
<a class="moz-txt-link-abbreviated" href="mailto:bounces@cabforum.org">bounces@cabforum.org</a>] On Behalf Of Brown, Wendy (10421)
Sent: Monday, April 22, 2013 12:50 PM
To: Rob Stradling; Erwann Abalea
Cc: <a class="moz-txt-link-abbreviated" href="mailto:public@cabforum.org">public@cabforum.org</a>
Subject: Re: [cabfpub] Name Constraints, Auditing and EKU
I disagree with the statement it is too late to try to stop the
</pre>
</blockquote>
<pre wrap="">proliferation of
</pre>
<blockquote type="cite">
<pre wrap="">trying to do technical constraints on CAs using EKU in violation of the
</pre>
</blockquote>
<pre wrap="">intent of
</pre>
<blockquote type="cite">
<pre wrap="">RFC 5280.
The FPKI is one large community of PKIs that will opt for publicly
</pre>
</blockquote>
<pre wrap="">disclosed
</pre>
<blockquote type="cite">
<pre wrap="">and audited rather than the technical constraints Mozilla is trying to
</pre>
</blockquote>
<pre wrap="">impose
</pre>
<blockquote type="cite">
<pre wrap="">because that model doesn't really work with our community and we already
require audit of all subordinate CAs.
wendy
-----Original Message-----
From: <a class="moz-txt-link-abbreviated" href="mailto:public-bounces@cabforum.org">public-bounces@cabforum.org</a> [<a class="moz-txt-link-freetext" href="mailto:public">mailto:public</a>-
<a class="moz-txt-link-abbreviated" href="mailto:bounces@cabforum.org">bounces@cabforum.org</a>] On Behalf Of Rob Stradling
Sent: Monday, April 22, 2013 3:38 PM
To: Erwann Abalea
Cc: <a class="moz-txt-link-abbreviated" href="mailto:public@cabforum.org">public@cabforum.org</a>
Subject: Re: [cabfpub] Name Constraints, Auditing and EKU
On 22/04/13 15:08, Erwann Abalea wrote:
<snip>
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">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).
</pre>
</blockquote>
<pre wrap="">
I think the requirement is really a "id-kp-OCSPSigning MUST NOT be
</pre>
</blockquote>
<pre wrap="">present".
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">
+1
</pre>
<blockquote type="cite">
<pre wrap="">There are limits to using an extension for something it wasn't
designed for... I'm not a fan of "EKU constraints".
</pre>
</blockquote>
<pre wrap="">
I agree that it would be preferable for the PKIX specs to match the
</pre>
</blockquote>
<pre wrap="">reality,
</pre>
<blockquote type="cite">
<pre wrap="">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,
</pre>
</blockquote>
<pre wrap="">but
</pre>
<blockquote type="cite">
<pre wrap="">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
<a class="moz-txt-link-abbreviated" href="mailto:Public@cabforum.org">Public@cabforum.org</a>
<a class="moz-txt-link-freetext" href="https://cabforum.org/mailman/listinfo/public">https://cabforum.org/mailman/listinfo/public</a>
_______________________________________________
Public mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Public@cabforum.org">Public@cabforum.org</a>
<a class="moz-txt-link-freetext" href="https://cabforum.org/mailman/listinfo/public">https://cabforum.org/mailman/listinfo/public</a>
</pre>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
<br>
</body>
</html>