[cabfpub] Ballot 108: Clarifying the scope of the baselinerequirements
Kelvin Yiu
kelviny at exchange.microsoft.com
Fri Aug 16 18:58:32 UTC 2013
What is ETSI's position on CAs following LCP or NCP who issues certificates that can technically be used for SSL or code signing? Are they not allowed to be subordinates of publicly trusted root CAs?
Kelvin
From: i-barreira at izenpe.net [mailto:i-barreira at izenpe.net]
Sent: Thursday, August 8, 2013 12:12 PM
To: md at ssc.lt; Kelvin Yiu
Cc: public at cabforum.org
Subject: RE: [cabfpub] Ballot 108: Clarifying the scope of the baselinerequirements
Hi,
Something to add to what Mou´s pointing out and that has been mentioned several times at different F2F meetings.
Regarding the BRs the current TS 102 042 and the next to come, EN 319 411-4, have 2 new policies:
OVCP: Organization Validation Certificate Policy
DVCP: Domain Validation Certificate Policy
(There´s a new one coming up called QWSCP: Qualified Web Site Certificate Policy in the EN regarding the EU regulation draft but we don´t know how this will end up)
These 2 new policies are based on the BRs, and created because of these requirements, and are intended only for SSL certs. That´s it.
The problem is what Mark has mentioned and Kelvin has re-organized, is what to do with those that are "kind of" SSL certs but have (or have not) the same profile.
I think the BRs are just for server authentication and I like the new definition Mark proposed, very similar to what Jeremy stated.
The CABF only dedicates to SSL certificates basically (up to now EV, OV, DV) and some others like code signing, s/mime are yet to come. (Well, EV code signing exists and it used EVCP+ policy, which is the one for those issued in SSCDs)
These certs are not related IMO to qualified certs that we issue in Europe (QCP) but can fall into the NCP and they deviations, but that´s why these new policies were created, just to fit the CABF guidelines, EV and BR but only for SSL certificates. Other type of certificates, for example, non qualified certificates for legal entities, or natural persons use these other policies, LCP, NCP.
Hope this clarifies ETSI position.
Regards
Iñigo Barreira
Responsable del Área técnica
i-barreira at izenpe.net<mailto:i-barreira at izenpe.net>
945067705
[Descripción: cid:image001.png at 01CE3152.B4804EB0]
ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada (helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari, korreo honi erantzuna. KONTUZ!
ATENCION! Este mensaje contiene informacion privilegiada o confidencial a la que solo tiene derecho a acceder el destinatario. Si usted lo recibe por error le agradeceriamos que no hiciera uso de la informacion y que se pusiese en contacto con el remitente.
De: public-bounces at cabforum.org<mailto:public-bounces at cabforum.org> [mailto:public-bounces at cabforum.org] En nombre de Moudrick M. Dadashov
Enviado el: jueves, 08 de agosto de 2013 20:12
Para: Kelvin Yiu
CC: 'CABFPub'
Asunto: Re: [cabfpub] Ballot 108: Clarifying the scope of the baselinerequirements
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>
> [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<mailto: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<mailto:Public at cabforum.org>
https://cabforum.org/mailman/listinfo/public
> _______________________________________________ Public
mailing list
> Public at cabforum.org<mailto: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/20130816/8433b6f7/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 19121 bytes
Desc: image001.png
URL: <http://lists.cabforum.org/pipermail/public/attachments/20130816/8433b6f7/attachment-0003.png>
More information about the Public
mailing list