<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
Hi Peter,<br>
<br>
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.<br>
<br>
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:<br>
<br>
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<br>
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.<br>
<br>
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.<br>
<br>
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".<br>
<br>
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.<br>
<br>
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 :)<br>
<br>
<br>
Best regards,<br>
Dimitris.<br>
<br>
<br>
<br>
<br>
<div class="moz-cite-prefix">On 24/10/2016 8:30 μμ, Peter Bowen
wrote:<br>
</div>
<blockquote cite="mid:E9743A6F-962A-4310-8E12-3DC9B069006B@amzn.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode:
space; -webkit-line-break: after-white-space;" class="">
<div class="">Dimitris,</div>
<div class=""><br class="">
</div>
<div class="">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.</div>
<div class=""><br class="">
</div>
<div class="">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.</div>
<div class=""><br class="">
</div>
<div class="">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.</div>
<div class=""><br class="">
</div>
<div class="">Thanks,</div>
<div class="">Peter</div>
<br class="">
<div>
<blockquote type="cite" class="">
<div class="">On Oct 19, 2016, at 5:20 AM, Dimitris
Zacharopoulos via Public <<a moz-do-not-send="true"
href="mailto:public@cabforum.org" class="">public@cabforum.org</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<meta http-equiv="Content-Type" content="text/html;
charset=utf-8" class="">
<div bgcolor="#FFFFFF" text="#000000" class=""> <br
class="">
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:<br class="">
<ol class="">
<li class="">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.</li>
<li class="">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.</li>
<li class="">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.<br class="">
</li>
<li class="">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.<br class="">
<div class="moz-forward-container"> </div>
</li>
</ol>
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.<br
class="">
<br class="">
You may find for more information and comments on the
Policy Review WG mailing <a moz-do-not-send="true"
href="https://cabforum.org/pipermail/policyreview/"
class="">archive</a>. <a moz-do-not-send="true"
href="https://cabforum.org/pipermail/policyreview/2016-October/000341html"
class="">Here </a>is the latest message on this
topic. You are also welcome to comment during slot #6
(Working Group reports) at the F2F.<br class="">
<div class="moz-forward-container"> <br class="">
<br class="">
Best regards,<br class="">
Dimitris Zacharopoulos.</div>
</div>
<span
id="cid:102627A0-1D34-43D7-9F57-AD86BDDAAB76@amazon.com"><BR
1.3.7-with-comments-regarding-CA-subCA-intermediateCA
v5.docx></span>_______________________________________________<br
class="">
Public mailing list<br class="">
<a moz-do-not-send="true"
href="mailto:Public@cabforum.org" class="">Public@cabforum.org</a><br
class="">
<a class="moz-txt-link-freetext"
href="https://cabforum.org/mailman/listinfo/public">https://cabforum.org/mailman/listinfo/public</a><br
class="">
</div>
</blockquote>
</div>
<br class="">
</div>
</blockquote>
<br>
</body>
</html>