[cabfpub] Ballot 108: Clarifying the scope of the baselinerequirements

i-barreira at izenpe.net i-barreira at izenpe.net
Thu Aug 8 19:12:24 UTC 2013


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

945067705

 

 

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] 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] 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: <http://lists.cabforum.org/pipermail/public/attachments/20130808/d81938a8/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/20130808/d81938a8/attachment-0003.png>


More information about the Public mailing list