[cabfpub] Clarification of the "CA" term in the BRs
Dimitris Zacharopoulos
jimmy at it.auth.gr
Mon Oct 24 20:01:24 UTC 2016
Hi Peter,
Things can be very complicated if we only decide to introduce every type
of combination (keys, subject information, policy identifiers,
extensions) :) The current BR language is ambiguous, but for a person
who has enough knowledge and has been around the CA business for a
while, things are quite clear. In fact, audits have been taking place
all these years and seem to find answers (hopefully the right ones) to
these "ambiguities". Having said that, I think we've made a lot of
progress to clarify the current language without causing too much
headache. Bringing and analyzing every scenario which is not described
in the current BRs, is a big challenge.
After reading the BRs several times, I believe that the majority of the
cases where a Subordinate CA Certificate is mentioned, it takes for
granted that one key pair is associated with a Subordinate CA
Certificate and this Subordinate CA Certificate is either:
a) directly controlled by the Issuing CA (an organization) or an
Affiliate, and includes the anyPolicy identifier (MAY) or a more
specific one (SHOULD) or is
b) externally operated by a different organization (that is not an
Affiliate) and cannot use the anyPolicy identifier and must include a
policy identifier for a specific CP/CPS.
This covers the majority of cases that bind a keypair, to a specific
Intermediate CA certificate under a specific policy which is included as
an identifier in the end-entity certificates.
Are there cases where the same key is associated with two Subordinate CA
Certificates for issuing different type of end-entity certificates under
a different policy? Maybe yes but I don't think this corresponds to the
majority. Is this scenario covered under the current BR language?
Possibly, and probably by using the uncertainty that the current BRs
leave for some uses of the term "CA".
Are the same key pairs used to be signed by different issuers with the
same subject DN? In the case of cross-signing, yes, but this is defined
in the current BRs. Perhaps we could try enumerating the different
possible cases but I'm not sure if we would catch all of them. I'm also
afraid that the language would get very complex, moving away from the
principles of a "policy" document.
In any case, we need a way forward to improve the current language and
help CAs, Browsers and Auditors have clear guidelines in their hands.
Suggestions are always welcome :)
Best regards,
Dimitris.
On 24/10/2016 8:30 μμ, Peter Bowen wrote:
> Dimitris,
>
> Thank you for working on this. The lack of clarity with regards to
> “Root CA” and “Subordinate CA” is one that needs resolving to ensure
> all have a common understanding of what it expected of them.
>
> I also appreciate the objective to change as little as possible to get
> this clarity. As Ryan Sleevi pointed out yesterday, this is a complex
> issue as a single organization can have multiple CPSes and a single
> key pair can be used for multiple DNs and there can be multiple CA
> certificate with the same subject.
>
> I think we may need to reconsider whether the majority of cases can be
> considered to be the Key Pair + Distinguished Name case and make the
> organization case the outlier.
>
> Thanks,
> Peter
>
>> On Oct 19, 2016, at 5:20 AM, Dimitris Zacharopoulos via Public
>> <public at cabforum.org <mailto:public at cabforum.org>> wrote:
>>
>>
>> After working this topic for quite some time in the Policy Review WG,
>> we consider it ready to be discussed on the public list and we
>> encourage members to provide feedback and comments. Here is some
>> information about the attached document:
>>
>> 1. It is based on the BRs version 1.3.7. We didn't always update to
>> the latest version because these changes are quite basic and
>> could be implemented on any latest version of the BRs.
>> 2. At first (almost 6 months back), it was decided that minimal
>> changes should take place which would make a revision ballot more
>> easily adopted by the forum. Now, with the new process that
>> requires longer time for review/adoption than before (for IPR
>> issues), we decided that we should also provide clarity on the
>> "signing" operations. So, you will see a more technically
>> accurate language that replaces the concept of a Certificate
>> being "signed by a CA Certificate". The language now includes
>> Keys associated with specific Certification Authority Certificates.
>> 3. This red-lined document does not attempt to solve all problematic
>> language in the BRs but only the usage of the term "CA" and Keys
>> associated with CA Certificates. Other clarifications for other
>> terms will be addressed in the future.
>> 4. We believe that this version, to the best of our knowledge, uses
>> the term "CA", "Root CA", "Root Certificate" and "Subordinate CA
>> Certificate" consistently. If you spot an ambiguity we missed,
>> please let us know.
>>
>> We don't need to wait for the re-adoption process of the BRs and EV
>> guidelines in order to discuss this amendment. We hope to complete
>> this discussion process, prepare a proper ballot and once the
>> re-adoption is complete, we can officially submit it for review.
>>
>> You may find for more information and comments on the Policy Review
>> WG mailing archive <https://cabforum.org/pipermail/policyreview/>.
>> Here
>> <https://cabforum.org/pipermail/policyreview/2016-October/000341html>is
>> the latest message on this topic. You are also welcome to comment
>> during slot #6 (Working Group reports) at the F2F.
>>
>>
>> Best regards,
>> Dimitris Zacharopoulos.
>> <BR 1.3.7-with-comments-regarding-CA-subCA-intermediateCA
>> v5.docx>_______________________________________________
>> Public mailing list
>> Public at cabforum.org <mailto: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/20161024/b8ebe532/attachment-0003.html>
More information about the Public
mailing list