[cabfpub] Ballot 188 - Clarify use of term "CA" in Baseline Requirements
Dimitris Zacharopoulos
jimmy at it.auth.gr
Wed Mar 1 07:02:55 UTC 2017
On 1/3/2017 12:47 πμ, Ryan Sleevi wrote:
> Hi Dimitris,
>
> Unfortunately, it doesn't sound like we're on the same page. While I
> appreciate the effort you and Ben and others have worked on this, I
> think this proposal creates new security vulnerabilities in both
> ambiguity and loopholes.
Nobody can claim that we didn't try to get on the same page :) I also
(and surely other members) appreciate your efforts to make sure the
policies and standards are secure and unambiguous and your opinion is
always important and respected.
>
> My request would be that you consider withdrawing the ballot or that
> members who support this change to No, so that it can be worked on in
> the policy group to resolve these issues. I would suggest that given
> the issues are, in part I suspect, due to misunderstandings about the
> concerns/threats, it might be best to table this until after the F2F.
>
I can't imagine that Mozilla, Entrust, Globalsign, Digicert (that
already voted "Yes") didn't read through the ballot and didn't consider
these misunderstandings. As I've heard people say in this Forum, perfect
is the enemy of good. In my previous replies, I tried to engage more
members who feel that the current language of the ballot creates more
ambiguities than it fixes. Judging from the silence from other members,
I believe that the benefits outweigh the downsides creating an
"acceptable" ballot, which could very well be improved very soon. In
fact, it would be great if you could offer some edits to the ballot to
make it even clearer. The intentions of the changes introduced by the WG
have been clear and the main concern you raised (audits for all
Subordinate CAs) are covered by a BRs part which remains untouched (the
first paragraph of Section 8.1). If we could proceed with an updated
ballot (with fewer changes so we can address the specific concerns you
still believe to exist) right after the F2F, there is no risk.
Even though HARICA proposed the ballot, it was a WG effort so I cannot
take full responsibility of withdrawing the ballot or suggesting members
to vote "No" without any feedback from other endorsers or other members
who I would like to reply to this, and offer their opinion, especially
if they feel that the ballot must be withdrawn. As this is a public
discussion, every voting member can judge on their own for what's best,
after reading this thread.
You also referred to Peter's email
(https://cabforum.org/pipermail/policyreview/2016-November/000358.html).
Peter participated in some WG meetings after this e-mail and we
discussed this and so many other variations. They all had some pros and
cons, so we ended up with the proposed language on this ballot.
Best regards,
Dimitris.
> 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
> <jimmy at it.auth.gr <mailto:jimmy at it.auth.gr>> wrote:
>
> On 27/2/2017 9:21 μμ, Ryan Sleevi wrote:
>>
>>
>> On Mon, Feb 27, 2017 at 10:52 AM, Dimitris Zacharopoulos
>> <jimmy at it.auth.gr <mailto:jimmy at it.auth.gr>> 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/public@cabforum.org/msg02652.html
>> <https://www.mail-archive.com/public@cabforum.org/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 <public at cabforum.org>
> <mailto:public at cabforum.org>
> Reply-To: CA/Browser Forum Public Discussion List
> <public at cabforum.org> <mailto:public at cabforum.org>
> To: CABFPub <public at cabforum.org> <mailto:public at cabforum.org>
> CC: Ben Wilson <ben.wilson at digicert.com>
> <mailto:ben.wilson at digicert.com>
>
>
> 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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170301/29562423/attachment-0003.html>
More information about the Public
mailing list