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