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]>
Reply-To: CA/Browser Forum Public Discussion List <[email protected]>
To: CABFPub <[email protected]>
CC: Ben Wilson <[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.
_______________________________________________
Public mailing list
[email protected]
https://cabforum.org/mailman/listinfo/public
