[cabfcert_policy] CA vs. CA draft proposal

Thu Jun 2 23:34:07 MST 2016

Hi Peter, it was discussed but no agreement reached.

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: Peter Bowen [mailto:pzb at amzn.com] 
Enviado el: miércoles, 01 de junio de 2016 0:23
Para: Barreira Iglesias, Iñigo; Ben Wilson
CC: policyreview at cabforum.org
Asunto: Re: [cabfcert_policy] CA vs. CA draft proposal

Did this get discussed at all in Bilbao?  Should we send this to the public list?

> On May 6, 2016, at 3:08 AM, Barreira Iglesias, Iñigo <i-barreira at izenpe.eus> wrote:
> 
> Well, if it can help, the old EU directive was using the term CSP because only refer to entities issuing certificates, public key certificates, and then in the new eIDAS regulation changed to the TSP term because there´re can be different trust services provided by different or the same entity. Since in the CABF documents is also mentioned the timestamp that can be provided by the same entity that is providing certificates or by a different one,  think the right term to use is TSP, and it´s aligned with the EU approach.
> I think the PSP term is more generic on the technical implementation/solutions/standards rather on services and/or products (certificates, timestamps, ...) that use the current "CAs". In fact there´s another term such as WebPKI so is this also another subset within the PSP, which BTW sounds to me to the Sony Playstation Portable gamepad :-).
> I also think that the term TSP allows more room for future/new products/services not tied to PKI.
> 
> Regards
> 
> 
> 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: policyreview-bounces at cabforum.org 
> [mailto:policyreview-bounces at cabforum.org] En nombre de Peter Bowen 
> Enviado el: jueves, 05 de mayo de 2016 16:18
> Para: Ben Wilson
> CC: policyreview at cabforum.org
> Asunto: Re: [cabfcert_policy] CA vs. CA draft proposal
> 
> Sounds good.  I assume c. should be (PSP), right?
> 
>> On May 5, 2016, at 7:14 AM, Ben Wilson <ben.wilson at digicert.com> wrote:
>> 
>> Should we take a straw poll on the public list as to which term we use?  
>> 
>> a.       Trust Service Provider (TSP)
>> b.       Certificate Service Provider (CSP)
>> c.       PKI Service Provider (SP)
>> d.       Certificate Issuer (CI)
>> e.       Service Provider (SP)
>> 
>> From: policyreview-bounces at cabforum.org 
>> [mailto:policyreview-bounces at cabforum.org] On Behalf Of Dimitris 
>> Zacharopoulos
>> Sent: Thursday, May 5, 2016 12:58 AM
>> To: policyreview at cabforum.org
>> Subject: Re: [cabfcert_policy] CA vs. CA draft proposal
>> 
>> On 29/3/2016 7:09 μμ, "Barreira Iglesias, Iñigo" wrote:
>> What about TSP and then merge with the EU approach? 
>> 
>> 
>> Coming back to this topic, I would also agree to changing the "CA" term with "TSP" which is more clearly referred to as an organization. This will also help to make a subordinate CA definition clearer because it is currently being used in the BRs as a non-affiliated organization AND as an Intermediate CA Certificate of the organization in control of the Root CA.
>> 
>> The following definitions would come from a "strict" interpretation of the terms "Certification Authority" and "Subordinate CA" of the current BRs.
>> 
>> Intermediate CA Certificate: A Certificate issued by a Root Certificate or another Intermediate CA Certificate which is deemed as capable of being used to issue new certificates and which contains an X.509v3 basicConstraints extension, with the cA boolean set to true. If an Intermediate CA Certificate is issued to a non-affiliated organization, then this Intermediate CA Certificate is also referred to as an Intermediate CA Certificate of a Subordinate CA.
>> 
>> Subordinate CA: A non-affiliated organization in direct or indirect control of an Intermediate CA Certificate capable of being used to issue new certificates for that organization.
>> 
>> Does this seem any clearer?
>> 
>> 
>> Dimitris.
>> 
>> 
>> 
>> 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: policyreview-bounces at cabforum.org 
>> [mailto:policyreview-bounces at cabforum.org] En nombre de Ben Wilson 
>> Enviado el: jueves, 24 de marzo de 2016 15:43
>> Para: Ben Wilson; Peter Bowen; policyreview at cabforum.org
>> Asunto: Re: [cabfcert_policy] CA vs. CA draft proposal
>> 
>> After discussing this a bit, I'd prefer sticking to "CA" when using it as an adjective.  Also, I still think it might be better to replace "CA," when talking about the entity, with either "CSP" or "CASP"--even if that  means making sweeping changes throughout the  guideline documents.
>> 
>> -----Original Message-----
>> From: policyreview-bounces at cabforum.org 
>> [mailto:policyreview-bounces at cabforum.org] On Behalf Of Ben Wilson
>> Sent: Thursday, March 24, 2016 7:58 AM
>> To: Peter Bowen <pzb at amzn.com>; policyreview at cabforum.org
>> Subject: Re: [cabfcert_policy] CA vs. CA draft proposal
>> 
>> Thanks!  Let's discuss today.
>> 
>> -----Original Message-----
>> From: policyreview-bounces at cabforum.org 
>> [mailto:policyreview-bounces at cabforum.org] On Behalf Of Peter Bowen
>> Sent: Thursday, March 24, 2016 7:43 AM
>> To: policyreview at cabforum.org
>> Subject: [cabfcert_policy] CA vs. CA draft proposal
>> 
>> New Definitions:
>> 
>> Certificate Issuer (CI): An issuer of Certificates defined by a 
>> distinct Distinguished Name and Public Key
>> 
>> CI Certificate: A Certificate for which any of the following are true:
>> - A Basic Constraints extension is present and the cA component is 
>> set to TRUE
>> - A Key Usage extension is present and the keyCertSign bit is set
>> 
>> CI Key Pair: A Key Pair which has its Public Key included in a CI 
>> Certificate
>> 
>> Cross-Certificate: A CI certificate which is not a Self-Issued CI 
>> Certificate
>> 
>> End-entity Certificate: A Certificate which is not a CI Certificate
>> 
>> Root CI: A CI which is distributed by Application Software Suppliers 
>> as a trust anchor
>> 
>> Root CI Key Pair: A CI Key Pair which has its Public Key included in 
>> a Root Certificate
>> 
>> Root CI Certificate:  A CI Certificate which contains the Public Key 
>> from a Root CI Key Pair
>> 
>> Self-Issued CI Certificate: A CI Certificate where the subject and 
>> issuer Distinguished Names match
>> 
>> Technically Constrained CI Certificate: A CI certificate which uses a combination of Extended Key Usage settings and Name Constraint settings to limit the scope within which CI may issue Subscriber or additional CI Certificates.
>> 
>> Modifications:
>> 
>> In section 3.1.5, insert the following text:
>> 
>> Each CI Public Key MUST be associated with a single distinct Distinguished Name.  Each CI Distinguished Name MUST be associated with a single unique Public Key.
>> 
>> In section 4.3.1, append the following text:
>> 
>> A CA shall only issue a Self-Issued CI Certificate when the Private Key used by the CA to sign the Certificate corresponds to the Public Key that is certified within the Certificate.
>> 
>> <more to change CA to CI where appropriate> 
>> _______________________________________________
>> Policyreview mailing list
>> Policyreview at cabforum.org
>> https://cabforum.org/mailman/listinfo/policyreview
>> _______________________________________________
>> Policyreview mailing list
>> Policyreview at cabforum.org
>> https://cabforum.org/mailman/listinfo/policyreview
>> 
>> 
>> 
>> _______________________________________________
>> Policyreview mailing list
>> Policyreview at cabforum.org
>> https://cabforum.org/mailman/listinfo/policyreview
> 
> _______________________________________________
> Policyreview mailing list
> Policyreview at cabforum.org
> https://cabforum.org/mailman/listinfo/policyreview