For example, your response regarding audits is demonstrably incorrect
- and though I believe it emerges from a misunderstanding of effect,
even though we share the common goal - and that alone is reason for
serious concern.
On Tue, Feb 28, 2017 at 2:09 AM, Dimitris Zacharopoulos
<[email protected] <mailto:[email protected]>> wrote:
On 27/2/2017 9:21 μμ, Ryan Sleevi wrote:
On Mon, Feb 27, 2017 at 10:52 AM, Dimitris Zacharopoulos
<[email protected] <mailto:[email protected]>> wrote:
I think this is a potentially problematic definition, in
that it relates to the scope of the operations of the audit,
as well as matters below that I highlight. I'm hoping the
proposers and drafters can clarify (or link to previous
discussions) as to the reason in which "or its Affiliate"
was introduced into these definitions, or to highlight where
it was already a natural and existing part of these definitions.
Peter already provided some clarity for this. The "Affiliate"
language was not introduced by this ballot. It was already
mentioned in several sections of the BRs (6.1.1.1 "CA Key
Pair Generation", 6.1.2 "Private Key Delivery to Subscriber",
6.2.6 "Private Key Transfer into or from a Cryptographic
Module", 7.1.2.2 "Subordinate CA Certificate" and 7.1.6.3
"Subordinate CA Certificates").
Unfortunately, I think the concern still remains that this is a
subtle introduction that goes from being scoped to specific
sections (as you've noted) to now being a foundational concept,
which unfortunately 'weakens' the BRs, I believe.
I totally understand and appreciate the intent to align here,
especially for the cases Peter noted, but I want to especially
make sure to highlight the issue that "or the Affiliate" can be
problematic from a set of scope of audits.
Basically, what's being asked for on this ballot is a trade-off
from being logically bugged (and I agree, this is an issue we
should fix) to something that is procedurally weaker, and I'm
trying to figure out what the plan is to align. From both you and
Peter's response, it sounds like you don't believe further
changes are needed, and this is concerning.
As far as this ballot is concerned, which is only to clarify the
use of the term "CA", it does not "weaken" the BRs in any way. The
use of the term "Affiliate" and policy around it, is already
there. I personally (and maybe others) feel that the "Affiliate"
issue needs to be further discussed and even be removed as a way
of providing better conditions but this is something outside the
scope of this ballot.
Peter's answer should cover this. Your follow-up questions
challenge the fact that the current BRs treat Root Operator's
"Affiliates" in a different way than the non-Affiliates but
this is a policy matter and should be discussed separately.
In any case, I don't think it changes the fact that all
Subordinate CAs (whether internally or externally operated)
need to be audited. In the case of Internally Operated
Subordinate CAs, the audit might be covered in the Root
Operator audit, and this information should be included in
the audit scope.
That's the intent - but my question is, where is it specified? I
may have missed that, and that was the point of raising these
concerns: if I'm misreading, and it's already addressed,
fantastic. But I don't believe it is, hence the concern :)
8.1: "Certificates that are capable of being used to issue new
certificates MUST either be Technically Constrained in line with
section 7.1.5 and audited in line with section 8.7 only, or
Unconstrained and fully audited in line with all remaining
requirements from this section". IMO, from this reading, it is
clear that all Subordinate CAs MUST be fully audited or
self-audited (per 8.7) if they use Technically Constrained
Subordinate CA Certificates. There is no distinction about whether
the Subordinate CA is "Internal" or "External".
"Affiliates" in the current BRs have different policy in the
following:
* The key generation ceremony SHOULD (instead of MUST) be
witnessed by an external auditor (6.1.1.1)
* The Policy Identifier MAY (instead of MUST) be present in the
Subordinate CA Certificate and the "anyPolicy" identifier MAY
(instead of MUST NOT) be used. (7.1.6.3).
I believe that's all there is to it.
After several discussions within the WG, it was agreed that
the most accurate technical language is that "Private Keys
sign Certificates". Certificates, don't sign Certificates.
I understand the "why". I'm more specifically asking three questions:
1) Is my interpretation correct?
2) Is this desired?
3) Is there a plan to fix it?
From the rest of this section, I can interpret your response as
"1) Yes 2) No, not necessarily 3) Not really, but we could come
up with one". I'm not sure if that really provides the level of
assurance when considering whether to vote on this ballot, even
though I agree and understand the why, and am relieved it isn't
intended.
Your interpretation for 1) is correct regarding the specific OCSP
responder question.
For 2), the WG's desire was to use technically correct language in
the entire BRs to describe the "signing" process. You had a very
specific concern about the OCSP responder where RFC 6960 allows
either the name of the responder of a hash of the responder's
public key as the ResponderID so even that is taken care of.
However, if this concern remains, we will move to fixing it.
For 3), if this concern remains, we will fix it. I would like to
ask if more members have the same concern, to please speak up.
So, according to your example, if the ResponderID was the
hash of the Subordinate CA Certificate's public key, it would
not be prohibited even though that key would be included in
two or more Subordinate CA Certificates. Perhaps the multiple
CA Certificates with the same key-pair scenario is not
entirely addressed. We could update the BRs to specifically
include language for the ResponderID information, if you
think people would be puzzled about what information should
be included in that field.
Whether we address this by specifying language fro the
ResponderID (which seems overly specific) or by addressing the
general concern, I'd like to see a concrete proposal to address
this, ideally before voting concludes.
So far, the WG thought that the phrase "signed by the Private Key
associated with a Root CA Certificate or a Subordinate CA
Certificate" was technically correct and enough to clearly
demonstrate a link between a Private Key and a Specific CA
Certificate. If the corresponding public key to that private key
is included in another Subordinate CA Certificate, it only adds
policy requirements around that private key.
Put differently, if a Private Key is associated with Certificate
"SubCA1" which is operated by "SubCA1 org" and for some reason the
same private key is associated with Certificate "SubCA2" which is
operated by "SubCA2 org", we need to determine what obligations
exist for the handling of that Private Key for its entire
lifecycle and usage, which is the superset of SubCA1 and SubCA2.
If the requirements surrounding SubCA1 and SubCA1 org are
"requirements A" and the requirements surrounding SubCA2 and
SubCA2 org are "requirements B", then the Private Key must meet
requirements A+B.
In Section 4.9.10 (On-line revocation checking requirements)
Was this intentional?
This specific change was addressed during the discussion
phase
(https://www.mail-archive.com/[email protected]/msg02652.html
<https://www.mail-archive.com/[email protected]/msg02652.html>).
Did you link to the right thread? I cannot find a clear answer,
but perhaps I'm just missing it. As it stands, I think this alone
is potentially grounds that we may need to vote against it,
because it's a clear reduction in assurance.
The link is from a thread started by Ben. Unfortunately, I
couldn't find it in the mail-archive so it is pasted here:
--- BEGIN QUOTE---
-------- Forwarded Message --------
Subject: [cabfpub] Policy Review Working Group's Pre-Ballot to
Clarify Use of "CA"
Date: Thu, 19 Jan 2017 16:44:46 +0000
From: Ben Wilson via Public <[email protected]>
<mailto:[email protected]>
Reply-To: CA/Browser Forum Public Discussion List
<[email protected]> <mailto:[email protected]>
To: CABFPub <[email protected]> <mailto:[email protected]>
CC: Ben Wilson <[email protected]>
<mailto:[email protected]>
All,
The Policy Review Working Group has completed its review of the
Baseline Requirements for purposes of clarifying use of the term
"CA" and related terminology. Please review and comment on the
following pre-ballot. A redlined version of the Baseline
Requirements is attached to facilitate your review and comment.
I did want to highlight one of the proposed changes that is not
related to "CA" terminology. That proposed change is in Section
4.9.10. The current language is ambiguous, and it doesn't say
what was originally intended when it was adopted. The current
language says, "Effective 1 August 2013, OCSP responders for CAs
which are not Technically Constrained in line with Section 7.1.5
MUST NOT respond with a "good" status for such certificates."
The proposed change would rephrase this sentence to say what was
originally intended. It would say, "OCSP responders for
Subordinate CA Certificates that are Technically Constrained in
accordance with Section 7.1.5 are exempt from this prohibition on
responding with a "good" to OCSP requests for the status for such
certificates."
I don't know if anyone is relying on this provision, but its
original intent was to address concerns by users of legacy CA
software / OCSP responder software who complained that they could
not meet this requirement because their OCSP responders were built
to rely only on CRLs.
If this proposed change presents a problem for anybody, it will be
removed from this ballot and put into its own separate ballot.
Thanks,
Ben
--- END QUOTE---
Gerv replied on January 25th that he agrees with the proposed
change on 7.1.5 which basically clears the language. It doesn't
reduce the assurance. The assurance is already "reduced" in the
current BRs. Here is the current language in 4.9.10:
"Effective 1 August 2013, OCSP responders for CAs which are not
Technically Constrained in line with Section 7.1.5 MUST NOT
respond with a "good" status for such certificates".
The new proposed language says exactly the same thing but in a
more clear way. So, again, the ballot does not propose policy
changes (although as we said a couple of times, the WG was very
tempted to propose policy changes to make things better).
A typo indeed. It is clear in the red-lined version.
For future reference, we should try to figure out what version is
being voted on, when the e-mailed ballot and Red Line disagree :)
This is a minor issue, but I can easily see more significant
issues creeping in, least of all, because I have not looked at
all at the Red Lined version, because that's not the balloted text :)
Agreed. I guess once we become more familiar with a github
process, we will use one version over another as authoritative for
ballots (most probably the github version).
In Section 8.7 (Self-Audits)
Replace the last paragraph with:
During the period in which a Technically Constrained
Externally Operated Subordinate CA issues Certificates,
the Issuing CA SHALL monitor adherence to the Issuing
CA's Certificate Policy and/or Certification Practice
Statement and the Externally Operated Subordinate CA's
Certificate Policy and/or Certification Practice
Statement. On at least a quarterly basis, against a
randomly selected sample of the greater of one
certificate or at least three percent of the
Certificates issued by the Externally Operated
Subordinate CA, during the period commencing immediately
after the previous audit sample was taken, the CA SHALL
ensure adherence to all applicable Certificate Policies
and/or Certification Practice Statements.
Much like several other changes mentioned above, this limits
the scope of the existing text from "internal or external"
to simply "external". Thus it reduces the scope of
examination for internally operated subordinate CA
certificates, which may be operated by an Afilliate under a
distinct CP/CPS. Is that fair to say?
The rest of the section remains the same. It doesn't remove
the obligation for the CA (this covers ALL CA organizations,
including affiliates) to perform quarterly self-audits.
The reasoning for changing the last paragraph to only
"Externally Operated Subordinate CAs", was that the language
dictates that the "Issuing CA SHALL monitor adherence...". We
thought that it doesn't make sense to have one organization
monitor adherence to it's own organization. It is already
required for the Root CA Operator to adhere to its own CP
and/or CPS (that must cover all Internally Operated
Subordinate CAs), check against a randomly selected sample,
etc, as specified in the first paragraph of section 8.7.
So I think the point you're making is important, and I'm not
cleared where it's technically spelled out or required, and do
hope you can highlight this.
You're asserting that all Internally Operated Subordinate CAs are
operated by the Root Operator AND, if I'm understanding
correctly, audited to the same CP/CPS as the Root CA Certificate
- is this correct?
No. I am saying that it could be, under some circumstances. For
example, if a Root Operator has an internal department (under the
same Management) that handle issuances under a specific
Subordinate CA Certificate, then this Internally Operated
Subordinate CA could be covered in the audit of the Root Operator.
If we're talking about two separate legal entities under different
Management, then a separate audit report is needed according to
Section 8.1.
I haven't found text to normatively require either statement, and
that's the concern: even if it's the same organization as the
Root Operator, the possibility for distinct CP/CPSes to exist
between the Root CA Certificate's policies and the Internally
Operated Subordinate CA's policies (and/or independent audits)
exists, and as much as possible, I want to ensure the same
consistent duty of care with respect to policies and practices. I
fear this introduces a loophole for Affiliates to 'skip' audits
and key protection, even if unintended, so I'm curious if we can
find a resolution for this within the voting period.
The requirement for all Subordinate CAs to be audited comes from
the first paragraph of Section 8.1, as stated above. It leaves no
room for interpretations and includes ALL Subordinate CAs,
Internal or External.
Here are the two definitions introduced:
*Root CA Operator:*The top-level Certification Authority
(i.e. an organization) whose CA Certificate (or associated
Public Key) is distributed by Application Software Suppliers
as a trust anchor
*Internally Operated Subordinate CA:*A Subordinate CA
Operator, operated by a Root CA Operator or its Affiliate
that is in possession or control of the Private Key
associated with the Subordinate CA Certificate
The Root CA Operator is already -by definition- responsible
for all actions related to its Internally Operated
Subordinate CAs and Affiliates.
I disagree, and that's the point of concern. If the Root CA
Operator included the definition of Affiliates - ergo bringing
consistency to the scope of audits and operation - then perhaps
this issue would be resolved (of course, it may introduce new
bugs). But as it stands, an Internally Operated Sub CA having the
"or its Affiliate" creates a loophole in which all the policies
which apply to a Root CA Operator _don't_ apply to the Affiliate,
because IOSCAs clearly distinguish Affiliate as "something other
than the Root CA Operator"
Does this make sense?
I believe it is the opposite. To the best of my knowledge and
understanding (and I hope members can correct me if I'm wrong),
IOSCAs are treated as "something as the Root CA Operator". That's
already captured in the BRs today.
Voting ends on Thursday March 2 at 22:00 UTC but the
remaining issues will be tracked and addressed in a future
ballot.
My hope is something a bit more concrete than future ballot
before then, because I think some of these concerns are enough to
prevent our support
The voting ends tomorrow and I hope to have addressed some or all
your concerns. Ben and Tim (and even Peter who attended several of
the WG meetings) are welcome to add any comments to help
addressing these concerns even further. I also encourage other
members with the same or similar concerns who feel they are not
properly addressed, to speak up so we can decide if we must
proceed with amendments. Unfortunately, at the stage we are at,
the ballot cannot be withdrawn so it can either pass or fail.
Overall, the ballot has significant language improvements -as many
have already stated- and it would be nice to have every member's
support. Policy problems that pre-existed the ballot, still remain
but that was left untouched on purpose, so we could proceed with
policy improvements after we had a consistent language and
definitions throughout the BRs.
Best regards,
Dimitris.
