<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
...of course will go on :)<br>
<br>
First of all, on behalf of the people who participated in the Policy
Review WG and others who contributed with ideas and comments for
this ballot, I'd like to thank everyone for acknowledging the effort
we put into this. The Forum has been debating about ambiguities and
loopholes in the Baseline Requirements and the Network Security
Requirements for a long time. We have a chance to organize the
useful feedback and experience from this ballot and move on
correcting and addressing all concerns raised.<br>
<br>
Secondly, I would like to repeat to everyone that the WG's intent
for the work that culminated in this ballot was
<u>not to change any policy decisions</u> already incorporated in
the current BRs. That was a very challenging and difficult task,
considering the links between sections. For every change, we had to
go through the entire BRs and see if the policy decisions remain the
same. That said, the WG has heard the feedback that the ballot
introduced policy changes. The items that were identified as policy
changes are listed below:<br>
<ul>
<li>the fact that Technically Constrained SubCAs that can respond
"good" for unknown certificates, comes from 4.9.10. I think
Mozilla and Google suggested that the ballot proposed a more
relaxed language than the current BRs.<br>
</li>
<li>the exceptions for Affiliates to the Issuing CA, also come
from various places of the BRs. Google suggested that Affiliates
should be handled as externally operated Subordinate CAs. (I am
not 100% if I am describing this correctly, but we will discuss
it at the WG and the F2F and hopefully Ryan will make it clear).<br>
</li>
<li>For 6.1.1.1, Google suggested that we should always require
the auditor to attest that any Key Pairs, for any CA
Certificate, be accompanied with a Qualified Auditor attesting
that the CA followed its Key Generation Script. <br>
</li>
</ul>
<br>
Here is a list I was able to compile with concerns and improvements.
Please forgive me if I haven't captured exactly all of the issues
raised. This list will most certainly be updated.<br>
<ul>
<li>Do Certificates sign other Certificates or only private keys
sign Certificates? RFC6960 uses some language to suggest
"Certificate signing". RFC 5280 uses the term "signing keys".
The current BRs align with both RFCs so we must choose a path.</li>
<li>Does the ballot introduce loopholes related to the audit
requirements? There are concerns that the introduction of
Internally Operated Subordinate CAs and the combination of
"Affiliates" might create audit scope problems in section 8.7
and possibly other places.</li>
<li>The definition of a "Root CA Certificate" as a self-signed
certificate without correlation to Application Software
Suppliers and trust anchors, raises concerns when a Key-Pair
associated with Subordinate CA Certificate is also used in a
self-signed certificate. This might raise issues for 6.1.1.1
requiring an external auditor to witness that key generation in
the first place.</li>
<li>Some improvements for consistency are noted but will follow
after we clear out some of the other more important concerns
raised.<br>
</li>
</ul>
<div class="moz-forward-container">Finally, Mozilla suggested that
the full Forum should try to get agreement on a sane and
consistent set of definitions before making the document use them
consistently. I can't speak for others but I would certainly
welcome more participation from the full forum. The reason the
Policy WG took the initiative to proceed with this ballot was
because previous efforts to engage the full forum didn't go that
well. Perhaps now that we have clearer issues to discuss, the full
forum could produce good results.<br>
<br>
During the last CA/B Forum teleconference, we didn't want to take
up a lot of time and discuss some key decisions for ballot 188 and
invited members interested in this topic, to join this week's
Policy Review WG meeting (Thursday March 9th) which is 2 hours
before the regular Forum Teleconference at 14:00 UTC (6:00 am
Pacific, 9:00 am Eastern).<br>
<br>
<br>
Dimitris.<br>
<br>
PS: Thanks Peter and Tim H for reviewing this message.<br>
</div>
</body>
</html>