[cabfcert_policy] CA vs. CA draft proposal
陳立群
realsky at cht.com.tw
Thu Sep 8 05:03:05 MST 2016
Hi, Dimitris,
OK. I will start a new thread about some definitions and terms.
Li-Chun CHEN
-----Original Message-----
From: Dimitris Zacharopoulos [mailto:jimmy at it.auth.gr]
Sent: Thursday, September 08, 2016 7:28 PM
To: 陳立群
Cc: 'Ben Wilson'; policyreview at cabforum.org
Subject: Re: [cabfcert_policy] CA vs. CA draft proposal
Hi Li-Chun,
These are very interesting observations but let's try to focus this
thread on the "CA" definition only. Feel free to start a new thread if
you would like to discuss other definitions and terms.
Best regards,
Dimitris.
On 8/9/2016 2:11 μμ, 陳立群 wrote:
> Dear All,
>
> Do we have to define self-signed certificate and self-issued certificate in 1.6.1 Definitions?
>
> Self-signed certificates: Self-signed certificates are CA certificates in which the issuer and subject are the same entity. Self-signed certificates are used to convey a public
> key for use to begin certification paths.
>
> Self-issued certificates: Self-issued certificates are generated to support key rollover or changes in certificate policies. These self-issued certificates are not counted when evaluating path length or name constraints.
>
> Above definition most are from RFC 5280 Page 12.
>
> Why we need to define Self-issued certificates? 1. Because CA/B Forum define DV/OV/IV/EV/TEST OID, then CA must update their self-issued certificates, Subordinate CA certificates and SSL certificates for inserting these new OIDs.
>
> 2. Also, if an example Root CA certificate is built in Browsers' root certificate program, but when they generate a second generation example Root CA key pairs, but the example Root CA is applying for 2nd generation example Root CA built in Browsers' root certificate program, then they need self-issued certificate to construct a certificate path.
>
> In RFC 4110, there are below sentences
>
> 4.4. Root CA Key Update
>
> This discussion only applies to CAs that are directly trusted by some end entities. Self-signed CAs SHALL be considered as directly trusted CAs. Recognizing whether a non-self-signed CA is supposed to be directly trusted for some end entities is a matter of CA policy and is thus beyond the scope of this document.
>
> The basis of the procedure described here is that the CA protects its new public key using its previous private key and vice versa. Thus, when a CA updates its key pair it must generate two extra cACertificate attribute values if certificates are made available using an X.500 directory (for a total of four: OldWithOld, OldWithNew, NewWithOld, and NewWithNew).
>
> When a CA changes its key pair, those entities who have acquired the old CA public key via "out-of-band" means are most affected. It is these end entities who will need access to the new CA public key protected with the old CA private key. However, they will only require this for a limited period (until they have acquired the new CA public key via the "out-of-band" mechanism). This will typically be easily achieved when these end entities' certificates expire.
>
> The data structure used to protect the new and old CA public keys is a standard certificate (which may also contain extensions). There are no new data structures required.
>
> Note 1. This scheme does not make use of any of the X.509 v3 extensions as it must be able to work even for version 1 certificates. The presence of the KeyIdentifier extension would make for efficiency improvements.
>
> Note 2. While the scheme could be generalized to cover cases where the CA updates its key pair more than once during the validity period of one of its end entities' certificates, this generalization seems of dubious value. Not having this generalization simply means that the validity periods of certificates issued with the old CA key pair cannot exceed the end of the OldWithNew validity period.
>
> Note 3. This scheme ensures that end entities will acquire the new CA public key, at the latest by the expiry of the last certificate they owned that was signed with the old CA private key (via the "out-of-band" means). Certificate and/or key update operations occurring at other times do not necessarily require this (depending
> on the end entity's equipment).
>
> 4.4.1. CA Operator Actions
>
> To change the key of the CA, the CA operator does the following:
>
> 1. Generate a new key pair;
>
> 2. Create a certificate containing the old CA public key signed with the new private key (the "old with new" certificate);
>
> 3. Create a certificate containing the new CA public key signed with the old private key (the "new with old" certificate);
>
> 4. Create a certificate containing the new CA public key signed with the new private key (the "new with new" certificate);
>
> 5. Publish these new certificates via the repository and/or other means (perhaps using a CAKeyUpdAnn message);
>
> 6. Export the new CA public key so that end entities may acquire it using the "out-of-band" mechanism (if required).
>
> The old CA private key is then no longer required. However, the old CA public key will remain in use for some time. The old CA public key is no longer required (other than for non-repudiation) when all end entities of this CA have securely acquired the new CA public key.
>
> I found there is no stupulation for
>
> 4.7 Certificate re-key
> 4.8 Certificate modification
>
> section. Otherwise maybe we can add about the rule for key roll-over or update CP polices exteision of Sub CA certificates.
>
> Sincerely Yours,
>
>
> Li-Chun CHEN
> Chunghwa Telecom Co. Ltd.
>
>
> From: policyreview-bounces at cabforum.org [mailto:policyreview-bounces at cabforum.org] On Behalf Of Dimitris Zacharopoulos
> Sent: Monday, September 05, 2016 4:06 PM
> To: Ben Wilson; policyreview at cabforum.org
> Subject: Re: [cabfcert_policy] CA vs. CA draft proposal
>
>
> After our discussion during the last WG call, here is an updated version of the BRs (re-used version 1.3.7) with comments, proposed text changes that we could discuss on our next call this week. Of course, feel free to comment on the list as well.
>
> I chose to propose text changes within comments but if you feel it would be more helpful it they were directly changed (in review mode), I could apply them.
>
> Basically, this currently looks like a candidate for a "Clarification of the usage of the term CA" ballot.
>
>
> Best regards,
> Dimitris.
>
>
>
> On 11/8/2016 5:26 μμ, Ben Wilson wrote:
> Here is what I mentioned on the call:
>
> https://wiki.mozilla.org/CA:SubordinateCA_checklist#Terminology
>
> From: policyreview-bounces at cabforum.org [mailto:policyreview-bounces at cabforum.org] On Behalf Of Dimitris Zacharopoulos
> Sent: Thursday, August 11, 2016 3:45 AM
> To: policyreview at cabforum.org
> Subject: Re: [cabfcert_policy] CA vs. CA draft proposal
>
>
> 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 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
>
>
>
>
>
>
> 本信件可能包含中華電信股份有限公司機密資訊,非指定之收件者,請勿蒐集、處理或利用本信件內容,並請銷毀此信件. 如為指定收件者,應確實保護郵件中本公司之營業機密及個人資料,不得任意傳佈或揭露,並應自行確認本郵件之附檔與超連結之安全性,以共同善盡資訊安全與個資保護責任.
> Please be advised that this email message (including any attachments) contains confidential information and may be legally privileged. If you are not the intended recipient, please destroy this message and all attachments from your system and do not further collect, process, or use them. Chunghwa Telecom and all its subsidiaries and associated companies shall not be liable for the improper or incomplete transmission of the information contained in this email nor for any delay in its receipt or damage to your system. If you are the intended recipient, please protect the confidential and/or personal information contained in this email with due care. Any unauthorized use, disclosure or distribution of this message in whole or in part is strictly prohibited. Also, please self-inspect attachments and hyperlinks contained in this email to ensure the information security and to protect personal information.
>
>
>
本信件可能包含中華電信股份有限公司機密資訊,非指定之收件者,請勿蒐集、處理或利用本信件內容,並請銷毀此信件. 如為指定收件者,應確實保護郵件中本公司之營業機密及個人資料,不得任意傳佈或揭露,並應自行確認本郵件之附檔與超連結之安全性,以共同善盡資訊安全與個資保護責任.
Please be advised that this email message (including any attachments) contains confidential information and may be legally privileged. If you are not the intended recipient, please destroy this message and all attachments from your system and do not further collect, process, or use them. Chunghwa Telecom and all its subsidiaries and associated companies shall not be liable for the improper or incomplete transmission of the information contained in this email nor for any delay in its receipt or damage to your system. If you are the intended recipient, please protect the confidential and/or personal information contained in this email with due care. Any unauthorized use, disclosure or distribution of this message in whole or in part is strictly prohibited. Also, please self-inspect attachments and hyperlinks contained in this email to ensure the information security and to protect personal information.
More information about the Policyreview
mailing list