<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Thank you, Kelvin, IMO this is a very constructive approach.<br>
<br>
With this sense in mind I'd suggest the Forum to take a step forward
and recognize/accept following policy applicability framework.<br>
<br>
Today European policy framework defines following models:<br>
<br>
1. LCP - Lightweihgt Certificate Policy;<br>
2. NCP - Normalized Certificate Policy (also NCP+);<br>
3. QCP - Qualified Certificate Policy (also QCP+);<br>
4. EVCP - Extended Validation Certificate Policy (EVCP+).<br>
<br>
Each model above has a ~formal set of requirements that might have
been summarized by a formally accepted Profile or Certificate
Template.<br>
<br>
As we know the QCP Profile already exists (ETSI).<br>
The EVCP Profile is more or less clear however has no formally
approved form (to my best knowledge). But EVCP is de facto based on
Forum's EVG.<br>
If we agree/accept that NCP is a BR like model, then here comes
Kelvin's approach and we end up with a NCP profile. As NCP is not
just SSL we an call it e.g. NCP SSL Profile (BR Profile). <br>
<br>
So the proposal is to accept the above model as a basis in further
developing BR and EVG. Opinions?<br>
<br>
Thanks,<br>
M.D. <br>
<br>
On 8/8/2013 8:10 PM, Kelvin Yiu wrote:<br>
<span style="white-space: pre;">> One way to make progress is
perhaps for browsers to summarize the<br>
> certificate profile (e.g. required fields and extensions)
that their<br>
> browsers accept as SSL, code signing, or any other public<br>
> certificates they accept. For example, I believe IE expects
SSL<br>
> certificates require at least the following: (I will need to
do some<br>
> research to confirm)<br>
> <br>
> 1. Either no EKU extension, anyEKU, or the server auth EKU in
all<br>
> certificates in the chain. IE may still accept the old SGC
olds as<br>
> well 2. Valid DNS name in either the CN field in the subject
name, or<br>
> one or more dNSNames or IPv4 address in the SubjectAltName
extension <br>
> 3. Root CA must be enabled for server auth<br>
> <br>
> For code signing certificates:<br>
> <br>
> 1. Either no EKU extension, anyEKU, or the code signing auth
EKU in<br>
> all certificates in the chain. 2. Root CA must be enabled for
code<br>
> signing 3. Subject name must have either CN, or O, (and maybe
OU)<br>
> field.<br>
> <br>
> Hence, OV SSL certificates that do not have an EKU extension
(or<br>
> include the anyEKU OID) are valid for both SSL and code
signing.<br>
> Arguably it is probably not the intention of the CA to issue
SSL<br>
> certificates that can be also used for code signing.<br>
> <br>
> At a high level from the MS perspective, I want all CAs that
issue<br>
> certificates that would be interpreted as SSL, code signing,
or<br>
> whatever other usages allowed by the root program) to be in
scope of<br>
> the discussion. The high level principle here is to prevent
or at<br>
> least minimize unintended certificate usages that opens up
security<br>
> vulnerabilities.<br>
> <br>
> So if while PIV certificates may include the anyEKU but do
not<br>
> contain any valid DNS name, browsers may reject it for SSL so
they<br>
> can be considered out of scope.<br>
> <br>
> I agree the much harder problem to resolve is whether to
include CAs<br>
> with no EKUs that are capable of issuing SSL certificates,
but I<br>
> don't have a good answer yet.<br>
> <br>
> Kelvin<br>
> <br>
> <br>
> <br>
> -----Original Message----- From: <a class="moz-txt-link-abbreviated" href="mailto:public-bounces@cabforum.org">public-bounces@cabforum.org</a><br>
> [<a class="moz-txt-link-freetext" href="mailto:public-bounces@cabforum.org">mailto:public-bounces@cabforum.org</a>] On Behalf Of Jeremy
Rowley Sent:<br>
> Thursday, August 8, 2013 9:04 AM To: 'Gervase Markham' Cc:
'CABFPub' <br>
> Subject: Re: [cabfpub] Ballot 108: Clarifying the scope of
the<br>
> baseline requirements<br>
> <br>
> Yes - I am officially withdrawing the ballot pending further<br>
> consideration.<br>
> <br>
> I'm not sure how to overcome these obstacles since: 1) PIV-I
in the<br>
> US space requires the anyEKU 2) Qualified Certs may require
no EKU 3)<br>
> Certificates without an EKU or the anyEKU may be used as SSL<br>
> certificates 4) All SSL certificates should be covered by the
BRs 5)<br>
> Qualified and PIV-I Certs cannot be covered by the BRs since
they<br>
> lack a FQDN 6) SSL Certificates without an FQDN are
considered local<br>
> host and explicitly covered by the BRs<br>
> <br>
> I think the best option might be to simply acknowledge the<br>
> inconsistency and change the definition as follows:<br>
> <br>
> "All root certificates included in a browser's trust store,
all<br>
> subordinate CA certificates signed by one of these root
certificates,<br>
> and all end-entity certificates that either lack any Extended
Key<br>
> Usage extension or contain an Extended Key Usage extension
that<br>
> contain (i) either an Internal Server Name or a FQDN and (ii)
one of<br>
> the following: - Server Authentication (1.3.6.1.5.5.7.3.1) -<br>
> anyExtendedKeyUsage (2.5.29.37.0) - Netscape Server Gated<br>
> Cryptography (2.16.840.1.113730.4.1) - Microsoft Server Gated<br>
> Cryptography (1.3.6.1.4.1.311.10.3.3) are expressly covered
by these<br>
> requirements."<br>
> <br>
> <br>
> Jeremy<br>
> <br>
> -----Original Message----- From: Gervase Markham<br>
> [<a class="moz-txt-link-freetext" href="mailto:gerv@mozilla.org">mailto:gerv@mozilla.org</a>] Sent: Thursday, August 08, 2013
9:20 AM To:<br>
> <a class="moz-txt-link-abbreviated" href="mailto:jeremy.rowley@digicert.com">jeremy.rowley@digicert.com</a> Cc: 'CABFPub' Subject: Re:
[cabfpub]<br>
> Ballot 108: Clarifying the scope of the baseline requirements<br>
> <br>
> On 02/08/13 12:19, Jeremy Rowley wrote:<br>
>> There is a potential conflict that I think needs more
data and<br>
>> discussion:<br>
> <br>
> We agree; hence Mozilla votes NO on the ballot in its current
form.<br>
> <br>
> We would like to see it withdrawn until further information
can be<br>
> gathered. We very much support the goal of this ballot; we
want the<br>
> BRs to cover all certs capable of being used by SSL servers.
But we<br>
> need to figure out whether this requires a change in the
definition<br>
> of what the BRs cover, or a change (e.g. on clients) in the<br>
> definition of "capable of being used by SSL servers". Or
something<br>
> else.<br>
> <br>
> Gerv<br>
> <br>
> _______________________________________________ Public
mailing list <br>
> <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> <br>
> _______________________________________________ Public
mailing list <br>
> <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></span><br>
<br>
</body>
</html>