[cabfpub] Issuers in BR/EV/EVCS Guideline Scope

["Barreira Iglesias, Iñigo"]

Adding more salt, the term CSP (used in the old directive of 2003) is not used in the new eIDAS regulation but TSP (Trust Service Provider), and there can be TSP that provides certification services and have several CAs under the TSP among their services.


Iñigo Barreira
Responsable del Área técnica
i-barreira at izenpe.eus 
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.

-----Mensaje original-----
De: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] En nombre de Peter Bowen
Enviado el: lunes, 18 de abril de 2016 20:18
Para: Ryan Sleevi; kirk_hall at trendmicro.com; CABFPub
Asunto: Re: [cabfpub] Issuers in BR/EV/EVCS Guideline Scope

On Apr 18, 2016, at 10:36 AM, Ryan Sleevi <sleevi at google.com> wrote:
> 
> Member CAs are already running into this with respect to root programs. This isn't a "pro/con" sort of thing. This is: "Is there a common enough understanding so that we can avoid root programs doing what they're doing today, and to make it clear to auditors and CAs the expectations already set forth"
>  
> While it is unquestionably certain that this conversation will continue at least to the F2F, due to the pace at which the Forum moves, perhaps it would be more useful if you might contribute insight to the questions Peter has proposed, with your perspective as a CA and its operations.
> 
> Rather than attempt to redefine what things mean, the first order is simply to understand what you, as a CA, see the scope as. That's what these questions set forth to understand, since it's clear some members have divergent views. The approach you propose presupposes there is a common understanding, where clearly there isn't, and thus would not lead to a fruitful or productive discussion. 

I think Ryan hit my interest in the head perfectly — I would prefer to have a common understanding and baseline that all root programs can use rather than negotiate with each root program about what is in scope or not.

An example, which I’m sure can be seen as the extreme case, is:

- The term “CA” means a specific issuer distinguished name and subject key identifier
- The term “CSP” means the operator of one or more CAs and is the entity making the management assertion (for WebTrust) or identified company/provider (for ETSI)
- The term “CA Certificate” means a Certificate that has at least one of Basic Constraints with CA:TRUE, keyCertSign key usage, cRLSign key usage

- All CAs designed by the CSP as a “Root CA” and requested for inclusion in one or more Browser trust stores when the Browser has adopted the BRs as require are in scope starting when they request inclusion
- Any CA that is the subject of a CA certificate issued by an in-scope CA is in scope, unless such certificate contains an Extended Key Usage extension and does not contain any of {anyExtendedKeyUsage, id-kp-serverAuth, id-kp-codeSigning} key purposes
- Once a CA becomes in scope, the CSP must report on it as long as the CSP has audits.  Once the CA stops issuing certificates, the CSP should implement controls to ensure that no future certificates will be issued from the CA, but the CA should continue to be included in the reporting (possibly with an audited statement that it is no longer issuing certificates).
- Each CA must publicly disclose all CA certificates it signs in order to provide assurance that the audit scope includes all in-scope CAs

Thanks,
Peter
_______________________________________________
Public mailing list
Public at cabforum.org
https://cabforum.org/mailman/listinfo/public