is insufficient, and that we need to explicitly list where Mozilla's CA Certificate Policy overrides the CAB Forum BRs.
How about the following instead?
"11. CA operations and issuance of certificates to be used for SSL-enabled servers must also conform to the current version of the CA/Browser Forum Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates. In the event of inconsistency between Mozilla's CA Certificate Policy requirements and the Baseline Requirements, Mozilla's CA Certificate Policy takes precedence. The items listed below will be accepted as reason for not following the Baseline Requirements. If you find an inconsistency that is not listed here, notify Mozilla by sending email to certifica...@mozilla.org so the item can be considered.
- Mozilla's CA Certificate Policy defining a competent and independent auditor takes precedence over BR 17.6, Auditor Qualifications.
- Name Constraints does not need to be marked as critical.
- <Other?>”
Is this new text clear?
Are there other inconsistencies between the CAB Forum BRs and Mozilla's CA Certificate Policy that we should include in this list?
> is insufficient, and that we need to explicitly list where Mozilla's CA > Certificate Policy overrides the CAB Forum BRs.
> How about the following instead?
> "11. CA operations and issuance of certificates to be used for > SSL-enabled servers must also conform to the current version of the > CA/Browser Forum Baseline Requirements for the Issuance and Management > of Publicly-Trusted Certificates. In the event of inconsistency between > Mozilla's CA Certificate Policy requirements and the Baseline > Requirements, Mozilla's CA Certificate Policy takes precedence. The > items listed below will be accepted as reason for not following the > Baseline Requirements. If you find an inconsistency that is not listed > here, notify Mozilla by sending email to certifica...@mozilla.org so the > item can be considered.
> - Mozilla's CA Certificate Policy defining a competent and independent > auditor takes precedence over BR 17.6, Auditor Qualifications.
> - Name Constraints does not need to be marked as critical.
> - <Other?>�
> Is this new text clear?
> Are there other inconsistencies between the CAB Forum BRs and Mozilla's > CA Certificate Policy that we should include in this list?
> Thanks,
> Kathleen
Why not make the more restrictive (more rigorous?) statement between
Mozilla's policy and the CA/Browser Forum Baseline Requirements be the
requirement? Then, if the Baseline Requirements are modified to be more
restrictive, Mozilla does not have to rush a policy change to keep up.
Anyone who thinks government owns a monopoly on inefficient, obstructive
bureaucracy has obviously never worked for a large corporation.
� 1997 by David E. Ross
On Thu, May 17, 2012 at 5:37 PM, David E. Ross <nob...@nowhere.invalid> wrote:
> On 5/17/12 4:27 PM, Kathleen Wilson wrote:
> Why not make the more restrictive (more rigorous?) statement between
> Mozilla's policy and the CA/Browser Forum Baseline Requirements be the
> requirement? Then, if the Baseline Requirements are modified to be more
> restrictive, Mozilla does not have to rush a policy change to keep up.
Because the BR is already more restrictive in the two cases Kathleen cites, and if CABF decides to do something that breaks Mozilla's certificate verification in any manner Mozilla must be able to say "no, we're not enforcing that rule". Under your proposal, if CABF down the line votes that sAN MUST be critical, it would override Mozilla's explicit policy decision to permit non-critical sAN. This would remove the capacity to make policy decisions that stick.
Anything that Mozilla edits BR with must be Mozilla's edit, not CABF's. If CABF is not where power should be consolidated, CABF then 'MUST NOT' [RFC2119] have the ability to overrule or override Mozilla's impositions. To grant that capability would severely compromise Mozilla's long-term interest in ensuring interoperability in and with its own platform.
(as much as I hate being a political wonk, this is the situation as I see it.)
I like this change. It marks the first time that there will be any potential solid foothold for alternative regimes which still provide value to Mozilla's customers.
On Thu, May 17, 2012 at 4:27 PM, Kathleen Wilson <kwil...@mozilla.com> wrote:
> It has been brought to my attention that the proposed item #11 in
> http://www.mozilla.org/projects/security/certs/policy/WorkInProgress/... > is insufficient, and that we need to explicitly list where Mozilla's CA
> Certificate Policy overrides the CAB Forum BRs.
> How about the following instead?
> "11. CA operations and issuance of certificates to be used for SSL-enabled
> servers must also conform to the current version of the CA/Browser Forum
> Baseline Requirements for the Issuance and Management of Publicly-Trusted
> Certificates. In the event of inconsistency between Mozilla's CA Certificate
> Policy requirements and the Baseline Requirements, Mozilla's CA Certificate
> Policy takes precedence. The items listed below will be accepted as reason
> for not following the Baseline Requirements. If you find an inconsistency
> that is not listed here, notify Mozilla by sending email to
> certifica...@mozilla.org so the item can be considered.
> - Mozilla's CA Certificate Policy defining a competent and independent
> auditor takes precedence over BR 17.6, Auditor Qualifications.
> - Name Constraints does not need to be marked as critical.
> - <Other?>”
> Is this new text clear?
> Are there other inconsistencies between the CAB Forum BRs and Mozilla's CA
> Certificate Policy that we should include in this list?
> Why not make the more restrictive (more rigorous?) statement between
> Mozilla's policy and the CA/Browser Forum Baseline Requirements be the
> requirement?
Because in the case of auditor qualifications, our requirements (which
overrule) are _less_ restrictive than those of the BRs.
Yes, this means the BRs are not really Baseline. Yes, I pointed this out
at the time. No, I was not successful in getting the more lax Mozilla
requirements into the document.
> Because in the case of auditor qualifications, our requirements (which > overrule) are _less_ restrictive than those of the BRs. Yes, this > means the BRs are not really Baseline. Yes, I pointed this out at the > time. No, I was not successful in getting the more lax Mozilla > requirements into the document.
Which might be a good opportunity to have a discussion about it here too, what do you think?
We were discussing this subject at the CAB Forum, but here this hasn't been reviewed for a while, it could be that the contributors and audience have a different opinion than what Mozilla currently states?
IIRC the decision regarding auditor requirements has been made some 7+ years ago, a lot happened since then, some experienced was gained (to which I'm glad to contribute) and it might be beneficial to review the policy in this respect. In my opinion, specially in order to not undermine the BR (if every browser would do that where it serves it, the BR would become pretty useless at some point).
> I haven't heard anyone objecting to our current policy. Do you have an > objection to it? If so, on what grounds?
I think that the BR (and EV guidelines if they'd be affected too) might/would be undermined if software vendors simply apply different criterion and lower requirements than the actual requirements set forth.
I'm not entering the discussion on the subject itself, rather I'm answering your question on which grounds I believe this should be reviewed first and foremost. And it this respect, we might discuss what are the benefits versus the costs for the current policy that stands in contradiction of the BR (since Mozilla wasn't able to convince the forum after all).
> On 05/22/2012 12:52 PM, From Gervase Markham:
>> I haven't heard anyone objecting to our current policy. Do you have an
>> objection to it? If so, on what grounds?
> I think that the BR (and EV guidelines if they'd be affected too)
> might/would be undermined if software vendors simply apply different
> criterion and lower requirements than the actual requirements set forth.
We've heard plenty of argument that CABForum is voluntary and there is no transfer of power over to them. It's also an open question as to whether their interests are aligned with Mozilla's (c.f. users).
Adopting the document for the benefit of users and modifying it where necessary seems to be a reasonable approach. Especially given that the change in question does not effect them negatively.
> I'm not entering the discussion on the subject itself, rather I'm
> answering your question on which grounds I believe this should be
> reviewed first and foremost. And it this respect, we might discuss what
> are the benefits versus the costs for the current policy that stands in
> contradiction of the BR (since Mozilla wasn't able to convince the forum
> after all).
It's certainly the intent of CABForum to pass the power of binding document creation across to its forum. I for one do not understand how Mozilla can subscribe to that given its current manifesto.
> Adopting the document for the benefit of users and modifying it where > necessary seems to be a reasonable approach. Especially given that > the change in question does not effect them negatively.
Of course one can argue that it can affect it negatively. This of course would have to be determined and if that outweighs the benefits and this is exactly the discussion we should probably have here.
If the requirements are lowered or not enforced I believe that it negatively affects the BR. If every software vendor does that, the BR becomes pretty useless. But the very software vendors have the right to submit ballots and request changes to the requirements. IMO, this is the way to go...
> On 05/22/2012 08:30 PM, From ianG:
>> Adopting the document for the benefit of users and modifying it where
>> necessary seems to be a reasonable approach. Especially given that the
>> change in question does not effect them negatively.
> Of course one can argue that it can affect it negatively. This of course
> would have to be determined and if that outweighs the benefits and this
> is exactly the discussion we should probably have here.
Well, there is little data on this.
Also, the data we have on the alternate - the Accountants - leaves a lot to be desired. Let's open that can of worms - would CABForum please explain to us why they are granting a monopoly to a group that has the stellar record of being totally wrong on every failed FI since 2007?
I really don't see it is likely you can argue that there is a negative impact. Sure we can all throw wild unfounded claims around, but that's not the same thing.
> If the requirements are lowered or not enforced I believe that it
> negatively affects the BR.
Not part of our mission to support BR.
> If every software vendor does that, the BR
> becomes pretty useless. But the very software vendors have the right to
> submit ballots and request changes to the requirements. IMO, this is the
> way to go...
Any substantial, material complaints? Repetitions less desirable....
iang
PS: oh wait - I think they got one in the last few months, ending their near perfect record.
> On 05/22/2012 08:30 PM, From ianG:
>> Adopting the document for the benefit of users and modifying it where
>> necessary seems to be a reasonable approach. Especially given that the
>> change in question does not effect them negatively.
> Of course one can argue that it can affect it negatively. This of course
> would have to be determined and if that outweighs the benefits and this
> is exactly the discussion we should probably have here.
> If the requirements are lowered or not enforced I believe that it
> negatively affects the BR. If every software vendor does that, the BR
> becomes pretty useless. But the very software vendors have the right to
> submit ballots and request changes to the requirements. IMO, this is the
> way to go...
I think we're only talking about two exceptions to the BRs, and one of those exceptions is simply because critical name constraints are not yet widely enough supported (hopefully that will change soon). Since we are planning to require name constraints in certain situations, we need to allow a use of them that will work in practice.
The reason for taking this new approach and explicitly listing the exceptions is so that someone who interprets the Mozilla CA Certificate Policy in a different way cannot use that as an explanation for not meeting the BRs.
> I think we're only talking about two exceptions to the BRs, and one of
> those exceptions is simply because critical name constraints are not yet
> widely enough supported (hopefully that will change soon). Since we are
> planning to require name constraints in certain situations, we need to
> allow a use of them that will work in practice.
Kathleen,
I don't see how allowing non-critical Name Constraints in just the Mozilla policy "will work in practice".
RFC5280 says that Name Constraints MUST be critical.
The Baseline Requirements v1.0 says "All other fields and extensions MUST be set in accordance to RFC 5280", meaning Name Constraints MUST be critical.
Mozilla plans to allow non-critical Name Constraints and maybe some other browser/software vendors will follow suit, but I think we have to assume that at least some browser/software vendors will choose to require strict adherence to the BRs.
So it's likely that using non-critical Name Constraints would violate at least one browser/software vendor's policy, which in practice would mean that most CAs would _not_ be able to use non-critical Name Constraints. (Very few CAs need to follow _only_ Mozilla's policy!)
The consensus on the PKIX list seemed to be against updating RFC5280 to allow non-critical Name Constraints, but several folks suggested that it would be reasonable for the Baseline Requirements to be modified to allow non-critical Name Constraints.
Therefore, I think that Mozilla should propose a change to the Baseline Requirements to allow non-critical Name Constraints. I'd be happy to endorse it. I'd be surprised if anybody voted against it!
After that, there would be no need to have an exception in the Mozilla policy, and we would be able to say that non-critical Name Constraints "will work in practice".
(Cross-posting to the new CABForum public list, 'cos that's probably where we should continue this discussion!)
> The reason for taking this new approach and explicitly listing the
> exceptions is so that someone who interprets the Mozilla CA Certificate
> Policy in a different way cannot use that as an explanation for not
> meeting the BRs.
> Therefore, I think that Mozilla should propose a change to the Baseline
> Requirements to allow non-critical Name Constraints. I'd be happy to
> endorse it. I'd be surprised if anybody voted against it!
> After that, there would be no need to have an exception in the Mozilla
> policy, and we would be able to say that non-critical Name Constraints
> "will work in practice".
I will make that proposal to the CAB Forum.
In the meantime, I will leave the exception in the Mozilla Policy, and we can remove it if/when the exception is added to the BRs.
I've updated the WorkInProgress text for #11 as follows.
"11. CA operations and issuance of certificates to be used for SSL-enabled servers must also conform to the current version of the CA/Browser Forum Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates. In the event of inconsistency between Mozilla's CA Certificate Policy requirements and the Baseline Requirements, Mozilla's CA Certificate Policy takes precedence. The items listed below will be accepted as reason for not following the Baseline Requirements. If you find an inconsistency that is not listed here, notify Mozilla by sending email to certifica...@mozilla.org so the item can be considered.
- Mozilla's CA Certificate Policy defining a competent and independent auditor takes precedence over Baseline Requirement #17.6, Auditor Qualifications.
- Name Constraints do not need to be marked as critical at this time."
