[cabfcert_policy] CA vs. CA draft proposal

Thu Aug 11 02:44:59 MST 2016

On 14/7/2016 9:23 μμ, Ben Wilson wrote:
> On the next call we’ll have some sections to discuss with the Baseline 
> Requirements, but are there any other topics we’d like to address?  
> There are two new topics that we’d like to address at the next 
> face-to-face meeting.  One is an action item to address  the use of 
> the  terms “CA,” “subordinate CA,” “intermediate CA”, etc. and the 
> other is somewhat related and that  is CA annual audits and whether 
> subordinate/intermediate CAs generated by CAs during the audit period 
> (after the audit letter)  require point-in-time audits.  CAs have 
> yearly audit cycles, and it seems onerous to require a point-in-time 
> readiness assessment for every new issuing CA.  Some CAs create many 
> issuing CAs during the year as a means for distributing risk, and 
> requiring additional audits would discourage that.  We need to gather 
> input from auditors and browsers on this issue.  For example, 
> Microsoft and Mozilla are expecting to be able to correlate an audit 
> report with each CA, but what  about new ones under the same  root? 

Following-up on the last F2F Policy WG action 
<https://cabforum.org/2016/05/25/2016-05/> and the July 14th call, I 
have prepared a version of the BR version 1.3.7 highlighting in Green 
and Yellow whether the term CA is used to refer to an Organization or an 
X.509 Certificate with basicConstraints:CA=True, respectively.

Tim, I know we said that we'll work independently on this but I'm sure 
you will find this helpful :)

During this review, I came across several sections that could be 
improved. I added comments to indicate my suggestions. Please feel free 
to comment and we can discuss this further.

Best regards,
Dimitris.

On 1/6/2016 1:23 πμ, Peter Bowen wrote:
> 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
> _______________________________________________
> Policyreview mailing list
> Policyreview at cabforum.org
> https://cabforum.org/mailman/listinfo/policyreview
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/policyreview/attachments/20160811/af657bec/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: BR 1.3.7-with-comments-regarding-CA-subCA-intermediateCA.docx
Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document
Size: 112738 bytes
Desc: not available
Url : https://cabforum.org/pipermail/policyreview/attachments/20160811/af657bec/attachment-0001.bin 