[cabfpub] Life after Ballot 188 - Clarify use of term "CA" in Baseline Requirements
Dimitris Zacharopoulos
jimmy at it.auth.gr
Mon Mar 6 22:21:41 UTC 2017
...of course will go on :)
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.
Secondly, I would like to repeat to everyone that the WG's intent for
the work that culminated in this ballot was _not to change any policy
decisions_ 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:
* 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.
* 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).
* 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.
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.
* 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.
* 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.
* 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.
* Some improvements for consistency are noted but will follow after we
clear out some of the other more important concerns raised.
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.
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).
Dimitris.
PS: Thanks Peter and Tim H for reviewing this message.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170307/81fd1fcd/attachment-0002.html>
More information about the Public
mailing list