Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Updating Mozilla's CA Certificate Policy in regards to CABForum BRs

88 views
Skip to first unread message

Kathleen Wilson

unread,
Jan 5, 2012, 5:17:39 PM1/5/12
to mozilla-dev-s...@lists.mozilla.org
All,

As you know, the CA/Browser Forum has published version 1.0 of the
baseline requirements for SSL/TLS certificates: “Baseline Requirements
for the Issuance and Management of Publicly-Trusted Certificates, v.1.0”.

To download the document and read the announcement, see
https://www.cabforum.org/

Now I would like to start the discussion about how to update Mozilla’s
CA Certificate Policy,
http://www.mozilla.org/projects/security/certs/policy/, to take these
baseline requirements into account.

First, I propose that we add a requirement to
http://www.mozilla.org/projects/security/certs/policy/InclusionPolicy.html
in either item #6 or item #9 to require CAs to comply with the baseline
requirements. Does anyone have particular preference or concern about
doing so?

Second, are any of the baseline requirements still contentious enough to
justify calling out a specific exception in Mozilla’s CA Certificate Policy?

Third, if we add a statement requiring CAs to comply with the baseline
requirements, should we remove certain (duplicate) items from Mozilla’s
CA Certificate Policy?

For example :
http://www.mozilla.org/projects/security/certs/policy/InclusionPolicy.html
Item #8 could be removed, since it is included in BR 11.1.
Item #9 could be modified to remove duplicate requirements in BR 17.1.

http://www.mozilla.org/projects/security/certs/policy/MaintenancePolicy.html
Item #2 could be removed, because it directly corresponds to BR 13.1.5.


Fourth, there are some updates to the Mozilla CA Certificate Policy that
are in progress that may not be needed anymore, because they are covered
in the baseline requirements.

For example:
http://www.mozilla.org/projects/security/certs/policy/WorkInProgress/InclusionPolicy.html
The currently proposed new bullets under item #6 are covered by BR 12
and BR 16.5.
The currently proposed new items #9 and #10 are covered by BR 14.2 and
BR 17.5.

I will greatly appreciate thoughtful and constructive input into this
discussion.

Kathleen

Gervase Markham

unread,
Jan 11, 2012, 12:45:20 PM1/11/12
to Kathleen Wilson
On 05/01/12 22:17, Kathleen Wilson wrote:
> I will greatly appreciate thoughtful and constructive input into this
> discussion.

I'm somewhat surprised to see no comments on this post. I would suggest
that Kathleen make whatever changes are necessary to the Mozilla policy
to add the BRs as a requirement (and remove any duplicate requirements
that we have).

We will need to take at least one exception to the BRs; Mozilla's
current policy on who is permitted to do an audit is more accommodating
than that of the BRs, and so our policy will need to stand. My
suggestion is that we need to say that BRs 17.6.4 and 17.6.6 do not
apply (and the definition of Qualified Auditor is modified accordingly);
if anyone thinks this form of putting the exclusion is insufficient,
please say.

Gerv

Gervase Markham

unread,
Jan 11, 2012, 12:47:56 PM1/11/12
to mozilla-dev-s...@lists.mozilla.org
On 05/01/12 22:17, Kathleen Wilson wrote:
> As you know, the CA/Browser Forum has published version 1.0 of the
> baseline requirements for SSL/TLS certificates: “Baseline Requirements
> for the Issuance and Management of Publicly-Trusted Certificates, v.1.0”.

Further to this, the CA/Browser Forum is gathering a list of issues that
will be addressed in version 1.1. Mozilla has the opportunity to add to
that list; if there are things you would like to see improved, fixed or
changed, now is the time to say.

Please phrase any responses as specific proposals for change rather than
long screeds of frustratedness and complaint ;-) Suggestions which turn
the entirety of PKI inside out are also unlikely to come to fruition.

Gerv

Policy Authority PKIoverheid

unread,
Jan 11, 2012, 3:14:05 PM1/11/12
to mozilla-dev-s...@lists.mozilla.org
On 5 jan, 23:17, Kathleen Wilson <kwil...@mozilla.com> wrote:

Hi Kathleen,

> First, I propose that we add a requirement tohttp://www.mozilla.org/projects/security/certs/policy/InclusionPolicy...
> in either item #6 or item #9 to require CAs to comply with the baseline
> requirements. Does anyone have particular preference or concern about
> doing so?

My suggestion would be that Mozilla will require adherence by member
CAs as soon as the requirements make it into the audit regimes
(WebTrust and ETSI). Once they can be audited, then Mozilla can ask
the CAs to comply with the baseline requirements at their next annual
audit (e.g. when the auditors come around, and are trained and
auditing against criteria that reflect the minimum guidelines). So IMO
the actual time frame for compliance with the minimum guidelines
depends on whether and when the major audit regimes can amend their
criteria, notify and train their auditors, and audit against the
guidelines. Assuming that the minimum guidelines will be adopted by
WebTrust and ETSI at some point in 2012 than by the end of 2013 all
CAs should be able to provide Mozilla with an audit statement that
they comply with the guidelines. (The latest published draft of the
ETSI "Policy requirements for Certification Authorities issuing
public key certificates" (2/12/2011) doesn't show an adoption of the
minimum guidelines yet: http://docbox.etsi.org/ESI/Open/Latest_Drafts/)

> Second, are any of the baseline requirements still contentious enough to
> justify calling out a specific exception in Mozilla’s CA Certificate Policy?

In addition to my above suggestion: until the minimum guidelines are
fully adopted in WebTrust and ETSI and CAs are auditted against the
guidelines, the Mozilla CA Certificate Policy should continue to
apply.

> Third, if we add a statement requiring CAs to comply with the baseline
> requirements, should we remove certain (duplicate) items from Mozilla’s
> CA Certificate Policy?

In addition to my above suggestions: when the minimum guidelines are
adopted in WebTrust and ETSI AND the Mozilla CA Certificate Policy
(and the policies from other browser vendors) is fully adopted in for
example v1.1 of the minimum guidelines then the Mozilla CA Certificate
Policy should cease to excist (as should the policies from the other
browser vendors). Idealistically only WebTrust and ETSI should remain
(including the guidelines).

> Fourth, there are some updates to the Mozilla CA Certificate Policy that
> are in progress that may not be needed anymore, because they are covered
> in the baseline requirements.

In addition to my above suggestions: that depends on the adoption of
the guidelines etc. and the desire of Mozilla to quickly mitigate
certain risks.

Thanks.

Regards,
Mark

Gervase Markham

unread,
Jan 13, 2012, 6:24:07 AM1/13/12
to Policy Authority PKIoverheid
Hi Mark,

On 11/01/12 20:14, Policy Authority PKIoverheid wrote:
> My suggestion would be that Mozilla will require adherence by member
> CAs as soon as the requirements make it into the audit regimes
> (WebTrust and ETSI).

Mozilla already requires compliance with requirements which are not
mandated by WebTrust or ETSI. Now that a group of those requirements
have been bundled up into a single document, why can't we keep doing the
same thing?

I agree that compliance with some of the requirements in the BRs cannot
be observed externally, and so must be audited. So, in a sense, Mozilla
has no way of verifying compliance with the entire document until
auditors get involved. But, to my mind, there is no reason why we should
not require compliance with the "visible" things.

The CA/Browser Forum has requested that browsers incorporate the BRs
into their root program requirements (albeit not before the Effective
Date in June). So the CAs are expecting this - as in, it would not come
as a shock to them if we did it.

Gerv

Policy Authority PKIoverheid

unread,
Jan 13, 2012, 9:40:29 AM1/13/12
to mozilla-dev-s...@lists.mozilla.org
Hi Gerv,

I'll hope you're doing well.

On 13 jan, 12:24, Gervase Markham <g...@mozilla.org> wrote:
> Mozilla already requires compliance with requirements which are not
> mandated by WebTrust or ETSI. Now that a group of those requirements
> have been bundled up into a single document, why can't we keep doing the
> same thing?

True. Although the basis guidelines IMO are far more than a bundling
of the current browser vendor policies. Second I noticed that other
major browser vendors will require adherence by member CAs as soon as
the requirements make it into the audit regimes (WebTrust and ETSI)
etc. etc. It would be nice if all browser vendors would be consistent
on this matter.

> I agree that compliance with some of the requirements in the BRs cannot
> be observed externally, and so must be audited. So, in a sense, Mozilla
> has no way of verifying compliance with the entire document until
> auditors get involved. But, to my mind, there is no reason why we should
> not require compliance with the "visible" things.

Okay. What does Mozilla consider "visible things" regarding the BRs?

> The CA/Browser Forum has requested that browsers incorporate the BRs
> into their root program requirements (albeit not before the Effective
> Date in June). So the CAs are expecting this - as in, it would not come
> as a shock to them if we did it.

Okay. It is not a question if the BRs should be included but when and
how. See my above comments.

Regards,
Mark

Peter Kurrasch

unread,
Jan 13, 2012, 7:16:25 PM1/13/12
to mozilla-dev-s...@lists.mozilla.org
Question: so is the expectation that Mozilla's cert-acceptance policy
will go away once auditing begins? that adherence to the BR (as audited
by whomever) is sufficient to include certs in an end product?

Regarding the "visible" question, I'm assuming we're talking about
things like fields within the certificate itself?

Thanks.


On 01.13.2012 8:40 AM, Policy Authority PKIoverheid wrote:
> Hi Gerv,
>
> I'll hope you're doing well.
>
> On 13 jan, 12:24, Gervase Markham<g...@mozilla.org> wrote:
>> Mozilla already requires compliance with requirements which are not
>> mandated by WebTrust or ETSI. Now that a group of those requirements
>> have been bundled up into a single document, why can't we keep doing the
>> same thing?
> True. Although the basis guidelines IMO are far more than a bundling
> of the current browser vendor policies. Second I noticed that other
> major browser vendors will require adherence by member CAs as soon as
> the requirements make it into the audit regimes (WebTrust and ETSI)
> etc. etc. It would be nice if all browser vendors would be consistent
> on this matter.
>
>> I agree that compliance with some of the requirements in the BRs cannot
>> be observed externally, and so must be audited. So, in a sense, Mozilla
>> has no way of verifying compliance with the entire document until
>> auditors get involved. But, to my mind, there is no reason why we should
>> not require compliance with the "visible" things.
> Okay. What does Mozilla consider "visible things" regarding the BRs?
>
>> The CA/Browser Forum has requested that browsers incorporate the BRs
>> into their root program requirements (albeit not before the Effective
>> Date in June). So the CAs are expecting this - as in, it would not come
>> as a shock to them if we did it.
> Okay. It is not a question if the BRs should be included but when and
> how. See my above comments.
>
> Regards,
> Mark
>
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy

ianG

unread,
Jan 13, 2012, 7:24:06 PM1/13/12
to dev-secur...@lists.mozilla.org
On 14/01/12 11:16 AM, Peter Kurrasch wrote:
> Question: so is the expectation that Mozilla's cert-acceptance policy
> will go away once auditing begins? that adherence to the BR (as
> audited by whomever) is sufficient to include certs in an end product?

That is my expectation, yes.

iang

Kathleen Wilson

unread,
Jan 13, 2012, 9:20:33 PM1/13/12
to mozilla-dev-s...@lists.mozilla.org
I think that Mozilla's CA Certificate Policy will become smaller as
duplicate requirements are removed.

I expect that the cert inclusion process (https://wiki.mozilla.org/CA)
will be updated/simplified too.

I don't think either will entirely go away.

Kathleen

Gervase Markham

unread,
Jan 16, 2012, 11:50:51 AM1/16/12
to Peter Kurrasch
On 14/01/12 00:16, Peter Kurrasch wrote:
> Question: so is the expectation that Mozilla's cert-acceptance policy
> will go away once auditing begins? that adherence to the BR (as audited
> by whomever) is sufficient to include certs in an end product?

That would be up to Kathleen but I suspect there will be some things we
want to specify which are not covered by the BRs, and so we will need to
maintain a policy of our own.

> Regarding the "visible" question, I'm assuming we're talking about
> things like fields within the certificate itself?

Any externally observable behaviour. If e.g. one of the BR requirements
was "when a website owner buys a cert, they must type in the word
'PURPLEPANDAS' into the web interface", then we could receive reports
from internet users, who had used a CA we include, that the requirement
was not being met, and act accordingly.

Gerv

Stephen Schultze

unread,
Jan 17, 2012, 9:39:42 AM1/17/12
to mozilla-dev-s...@lists.mozilla.org
On 1/11/12 12:45 PM, Gervase Markham wrote:
> On 05/01/12 22:17, Kathleen Wilson wrote:
>> I will greatly appreciate thoughtful and constructive input into this
>> discussion.
>
> I'm somewhat surprised to see no comments on this post. I would suggest
> that Kathleen make whatever changes are necessary to the Mozilla policy
> to add the BRs as a requirement (and remove any duplicate requirements
> that we have).

Have you gone back to the comment tracking spreadsheet? There are
several issues that were marked "currently under discussion" or the
like, which I do not believe were addressed. See, for example, issues
18, 22, 47, and 49.

The same fundamental set of issues well known to this list still exist
in BR, and this we remain as clueless as ever about what justifications,
if any, exist for the CABForum's decision (given the closed nature of
CABForum discussions). I'm not sure what value there is in continuing
to tilt at windmills, but in short:

1. Delegated Third Parties are not audited by a Qualified Auditor
2. Delegated Third Parties are not disclosed to end-users such that
users could make an informed decision about whether to trust a given root
3. The BR exacerbate the confusion about liability by saying that the CA
and the Delegated Third Party "MAY allocate liability between themselves
contractually as they determine", but also that "the CA SHALL remain
fully responsible for the performance of all parties". I can't parse
this in a way that makes sense, as the two things seem mutually exclusive.

Don't take the relative lack of response on this topic as approval.
It's more like burnout. Particularly when the discussion and
decisionmaking goes on behind closed doors, your public participants are
likely to fade away.

Steve

Stephen Schultze

unread,
Jan 17, 2012, 9:49:52 AM1/17/12
to mozilla-dev-s...@lists.mozilla.org
On 1/5/12 5:17 PM, Kathleen Wilson wrote:
> http://www.mozilla.org/projects/security/certs/policy/InclusionPolicy.html

> Item #9 could be modified to remove duplicate requirements in BR 17.1.

What text specifically could be removed? I don't see anything in 17.1
(or 17 as a whole, or 14.2) that duplicates text in #9.

Eddy Nigg

unread,
Jan 17, 2012, 10:10:25 AM1/17/12
to mozilla-dev-s...@lists.mozilla.org
On 01/17/2012 04:39 PM, From Stephen Schultze:
> Don't take the relative lack of response on this topic as approval.
> It's more like burnout. Particularly when the discussion and
> decisionmaking goes on behind closed doors, your public participants
> are likely to fade away.
>

But perhaps you also have to set the expectations right - the BR
addresses many issues that never were defined, but that were considered
"problematic practices". Finally it has been decided what flies and what
not.

The BR isn't and probably can't be perfect in its current form, but it's
also not the last version either. I think it's a significant step
forward (and not standstill or step backwards), you may be wishing for
perfect, but it wont happen in this round.

Issues that couldn't be addressed this time have a good chance to be
looked upon in the upcoming revisions - and don't think you are the only
one that sees possible improvements. Many CAB Forum members see it the
same way, but it was more important to first of all start somewhere and
get it of the ground instead of investing another year of discussions
and have nothing.

--
Regards

Signer: Eddy Nigg, StartCom Ltd.
XMPP: star...@startcom.org
Blog: http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg

Stephen Schultze

unread,
Jan 17, 2012, 3:36:49 PM1/17/12
to mozilla-dev-s...@lists.mozilla.org
On 1/17/12 10:10 AM, Eddy Nigg wrote:
> On 01/17/2012 04:39 PM, From Stephen Schultze:
>> Don't take the relative lack of response on this topic as approval.
>> It's more like burnout. Particularly when the discussion and
>> decisionmaking goes on behind closed doors, your public participants
>> are likely to fade away.
>
> But perhaps you also have to set the expectations right - the BR
> addresses many issues that never were defined, but that were considered
> "problematic practices". Finally it has been decided what flies and what
> not.
>
> The BR isn't and probably can't be perfect in its current form, but it's
> also not the last version either. I think it's a significant step
> forward (and not standstill or step backwards), you may be wishing for
> perfect, but it wont happen in this round.
>
> Issues that couldn't be addressed this time have a good chance to be
> looked upon in the upcoming revisions - and don't think you are the only
> one that sees possible improvements. Many CAB Forum members see it the
> same way, but it was more important to first of all start somewhere and
> get it of the ground instead of investing another year of discussions
> and have nothing.

The problems I identified have been long defined... so long in fact that
many security folks have abandoned these conversations because they
believed that they were not being heard. You may have hope that some of
them will be addressed, but you of course are an actual participant in
the discussions.

CAB Forum is a closed group that fails to adequately include users in
its decision-making process... by design.

However, we're not going to see eye-to-eye on that, so I'll settle for
some evidence of movement on the topics I've identified. If Mozilla can
start by actually implementing its proposed language, that would be a
step forward, and I imagine that it would also encourage CAB Forum to
take the issues seriously for future BR revisions.

Steve

Peter Kurrasch

unread,
Jan 17, 2012, 5:50:53 PM1/17/12
to mozilla-dev-s...@lists.mozilla.org
Totally agree that silence does not equal approval. Speaking for myself,
silence means "I don't think it matters" but to better explain that, let me
suggest that there are 2 conflicting goals at play:

1. How CA certs are "uniformly" incorporated into Mozilla products and
other browsers (just browsers--not other clients).
2. How to advocate for end users and improve the security they observe and
experience.

My impression from recent conversations in this forum is that CABF and the
BR 1.0 is only really expected to address #1. That being the case, I would
say the BR is just fine and probably helps with uniformity.

Where I start to criticize the BR is when it comes to goal #2. I think the
BR falls far short of positively affecting the security experience for end
users--if for no other reason than there is so much space between the user
and the issuing CA that the root cert is the least of our concerns.

So, when it comes to improving the BR I'm not overly interested because I
don't think it matters. Sure, there might be improvements and
clarifications to help the cert adoption process--and for those I don't
have much of an opinion. If somebody takes it the next step and tries to
say "this improves user security" I will have to disagree.


So this is my opinion but I'd like to know how other people feel about
this. I'd also like to hear some perspective on how people view Mozilla's
role as "user advocate". If Mozilla is supposed to fill that role to some
degree is there a forum apart from CAB where suggestions/proposals might be
made? Maybe this email list is it? Maybe we need a user-advocate forum,
with CA support? (UAFWCAS???)

Well, just thoughts....


On Tue, Jan 17, 2012 at 2:36 PM, Stephen Schultze <
sjschult...@gmail.com> wrote:

> On 1/17/12 10:10 AM, Eddy Nigg wrote:
>
>> On 01/17/2012 04:39 PM, From Stephen Schultze:
>>
>>> Don't take the relative lack of response on this topic as approval.
>>> It's more like burnout. Particularly when the discussion and
>>> decisionmaking goes on behind closed doors, your public participants
>>> are likely to fade away.
>>>
>>
>> But perhaps you also have to set the expectations right - the BR
>> addresses many issues that never were defined, but that were considered
>> "problematic practices". Finally it has been decided what flies and what
>> not.
>>
>> The BR isn't and probably can't be perfect in its current form, but it's
>> also not the last version either. I think it's a significant step
>> forward (and not standstill or step backwards), you may be wishing for
>> perfect, but it wont happen in this round.
>>
>> Issues that couldn't be addressed this time have a good chance to be
>> looked upon in the upcoming revisions - and don't think you are the only
>> one that sees possible improvements. Many CAB Forum members see it the
>> same way, but it was more important to first of all start somewhere and
>> get it of the ground instead of investing another year of discussions
>> and have nothing.
>>
>

Eddy Nigg

unread,
Jan 17, 2012, 6:20:28 PM1/17/12
to mozilla-dev-s...@lists.mozilla.org
On 01/17/2012 10:36 PM, From Stephen Schultze:
> However, we're not going to see eye-to-eye on that, so I'll settle for
> some evidence of movement on the topics I've identified. If Mozilla
> can start by actually implementing its proposed language, that would
> be a step forward, and I imagine that it would also encourage CAB
> Forum to take the issues seriously for future BR revisions.
>

Mozilla's contribution at the CAB Forum was significant to get to its
current form and out the door. I believe that reasonable and important
issues will be driven further by Mozilla also in the future. Your input
to that is probably important and also considered accordingly.

Kyle Hamilton

unread,
Jan 17, 2012, 8:40:12 PM1/17/12
to Stephen Schultze, mozilla-dev-s...@lists.mozilla.org
> 3. The BR exacerbate the confusion about liability by saying that the CA and
> the Delegated Third Party "MAY allocate liability between themselves
> contractually as they determine", but also that "the CA SHALL remain fully
> responsible for the performance of all parties".  I can't parse this in a
> way that makes sense, as the two things seem mutually exclusive.

I read this to mean, the CA and the D3P -may- indemnify each other as
they choose, but ultimately it's the CA's responsibility to ensure
that its issuance controls perform correctly. If the D3P screws up,
it's the CA's reputation (public perception of fitness for inclusion
in root programs and trustworthiness) on the line.

This also suggests that if a CA is cross-certified by a trusted CA, is
separately added to the trust list, and only then screws up, then both
the CA in question and the cross-certifier need to be pulled unless
the cross-certifier revokes or has revoked its cross-certificate. (If
we could get deny bits implemented, this wouldn't be as technically
necessary. If we could get revocation working in a manner that
Mozilla considers effective, this not only wouldn't be as technically
necessary but would provide a lot of wiggle room for CA corporate
governance to catch and correct accidental and externally-generated
control failures, before being delisted as malicious.)

-Kyle H

ianG

unread,
Jan 20, 2012, 4:09:12 AM1/20/12
to dev-secur...@lists.mozilla.org
Hi Peter,

On 18/01/12 09:50 AM, Peter Kurrasch wrote:
> Totally agree that silence does not equal approval. Speaking for myself,
> silence means "I don't think it matters" but to better explain that, let me
> suggest that there are 2 conflicting goals at play:
>
> 1. How CA certs are "uniformly" incorporated into Mozilla products and
> other browsers (just browsers--not other clients).
> 2. How to advocate for end users and improve the security they observe and
> experience.

Yes, or words to effect.

> My impression from recent conversations in this forum is that CABF and the
> BR 1.0 is only really expected to address #1. That being the case, I would
> say the BR is just fine and probably helps with uniformity.

This is the same comment made about EV by Frank when it was adopted, in
that it documents a standard for high-end SSL web certs. Fine. But,
same comment made then -- but what about the users?

BR documents a standard for low-end SSL web certs. BR does some good,
it solves a massive headache for vendors because it solves their
contract woes with CAs. It also avoids a few of the minefields in EV.

The problem is if you look at the title and the purpose, BR claims to
address your 2. It should go on to deal with user interests, but does not.

Obviously CAs will claim loudly that it does, but they are biased and
lack references, if not words. So, Steve's words, we don't see eye-to-eye.

> Where I start to criticize the BR is when it comes to goal #2. I think the
> BR falls far short of positively affecting the security experience for end
> users--if for no other reason than there is so much space between the user
> and the issuing CA that the root cert is the least of our concerns.
>
> So, when it comes to improving the BR I'm not overly interested because I
> don't think it matters. Sure, there might be improvements and
> clarifications to help the cert adoption process--and for those I don't
> have much of an opinion. If somebody takes it the next step and tries to
> say "this improves user security" I will have to disagree.

The problem is that they have successfully filled the spot available.
Now if anyone comes along and says we need to address users, they will
say, look, we have BR. And then the arguments will start. Which will
never end. See thread below. It's endless....

So, nothing new will be accepted by vendors. Essentially, unless the
CAs agree, the vendors will not accept anything from the users.

So, for different logic, I reach the same conclusion: it doesn't
matter. The user loses. Game over.

> So this is my opinion but I'd like to know how other people feel about
> this. I'd also like to hear some perspective on how people view Mozilla's
> role as "user advocate".

Epic Fail. But that was the point of CABForum - the elimination of the
user voice was clearly an or even the objective. The techniques are old
and hallowed: gate-keeping, funneling, exclusion, human shield,
confidentiality, alliances, tag,...

> If Mozilla is supposed to fill that role to some
> degree is there a forum apart from CAB where suggestions/proposals might be
> made? Maybe this email list is it? Maybe we need a user-advocate forum,
> with CA support? (UAFWCAS???)

No chance. CAs put together CABForum for CA purposes. Although not
pre-ordained, it quickly found purpose to block the user voice that
Mozilla had successfully created to some small extent, and had taken
some small root in the vendor meetings way back when. I forget when /
where, but started by the Konqueror SSL guy in Montreal or similar.

Anyway, the point is that any forum that is created will be subject to
the same (winning) forces.

> Well, just thoughts....

The Mozilla experiment was nice while it lasted, sure.

iang


>
> On Tue, Jan 17, 2012 at 2:36 PM, Stephen Schultze<
> sjschult...@gmail.com> wrote:
>
>> On 1/17/12 10:10 AM, Eddy Nigg wrote:
>>
>>> On 01/17/2012 04:39 PM, From Stephen Schultze:
>>>
>>>> Don't take the relative lack of response on this topic as approval.
>>>> It's more like burnout. Particularly when the discussion and
>>>> decisionmaking goes on behind closed doors, your public participants
>>>> are likely to fade away.
>>>>
>>> But perhaps you also have to set the expectations right - the BR
>>> addresses many issues that never were defined, but that were considered
>>> "problematic practices". Finally it has been decided what flies and what
>>> not.
>>>
>>> The BR isn't and probably can't be perfect in its current form, but it's
>>> also not the last version either. I think it's a significant step
>>> forward (and not standstill or step backwards), you may be wishing for
>>> perfect, but it wont happen in this round.
>>>
>>> Issues that couldn't be addressed this time have a good chance to be
>>> looked upon in the upcoming revisions - and don't think you are the only
>>> one that sees possible improvements. Many CAB Forum members see it the
>>> same way, but it was more important to first of all start somewhere and
>>> get it of the ground instead of investing another year of discussions
>>> and have nothing.
>>>
>> The problems I identified have been long defined... so long in fact that
>> many security folks have abandoned these conversations because they
>> believed that they were not being heard. You may have hope that some of
>> them will be addressed, but you of course are an actual participant in the
>> discussions.
>>
>> CAB Forum is a closed group that fails to adequately include users in its
>> decision-making process... by design.
>>
>> However, we're not going to see eye-to-eye on that, so I'll settle for
>> some evidence of movement on the topics I've identified. If Mozilla can
>> start by actually implementing its proposed language, that would be a step
>> forward, and I imagine that it would also encourage CAB Forum to take the
>> issues seriously for future BR revisions.
>>
>> Steve

Gervase Markham

unread,
Jan 23, 2012, 8:40:20 AM1/23/12
to Policy Authority PKIoverheid
On 13/01/12 14:40, Policy Authority PKIoverheid wrote:
> True. Although the basis guidelines IMO are far more than a bundling
> of the current browser vendor policies. Second I noticed that other
> major browser vendors will require adherence by member CAs as soon as
> the requirements make it into the audit regimes (WebTrust and ETSI)
> etc. etc. It would be nice if all browser vendors would be consistent
> on this matter.

What other vendors do is a matter for them, but if the CAB Forum's
official adoption motion said "please adopt ASAP, but not before the
Effective Date", then IMO we should do as they ask. Here's the text from
the motion which passed:

"The members expect all SSL CAs and (in particular) all member CAs to
implement the resulting Forum Guideline in their operating procedures by
the Effective Date.

The members request that the member browser suppliers incorporate the
resulting Forum Guideline into their root-embedding program requirements
as soon as is practical (but not before the Effective Date).

The members further request that the WebTrust Task Force and ETSI adapt
their SSL CA audit criteria to include the resulting Forum Guidelines as
soon as is practical (but not before the Effective Date)."

It seems pretty clear to me that CAs should be doing this, and we should
be requiring it, by the Effective Date (1 July 2012).

>> I agree that compliance with some of the requirements in the BRs cannot
>> be observed externally, and so must be audited. So, in a sense, Mozilla
>> has no way of verifying compliance with the entire document until
>> auditors get involved. But, to my mind, there is no reason why we should
>> not require compliance with the "visible" things.
>
> Okay. What does Mozilla consider "visible things" regarding the BRs?

Well, you should be adopting all of them. :-) You can decide if you want
to run the risk of not adopting some because you think we can't find out!

Gerv

Gervase Markham

unread,
Jan 23, 2012, 11:54:38 AM1/23/12
to mozilla-dev-s...@lists.mozilla.org
On 17/01/12 14:39, Stephen Schultze wrote:
> Have you gone back to the comment tracking spreadsheet? There are
> several issues that were marked "currently under discussion" or the
> like, which I do not believe were addressed. See, for example, issues
> 18, 22, 47, and 49.

Remind me of the URL? It's not in my Google Docs history...

> CABForum discussions). I'm not sure what value there is in continuing to
> tilt at windmills, but in short:
>
> 1. Delegated Third Parties are not audited by a Qualified Auditor

The issues list currently has, as issue 1:

"Better audit criteria are needed for sub CAs and RAs that are not
operated directly by the CA."

There is also a task to:

"Describe a model of the certificate management eco-system, identifying
the various components, then rewrite the document in terms of which
component is responsible for satisfying each requirement, and identify
which components fall within the scope of the various audits."

Does that cover it?

> 2. Delegated Third Parties are not disclosed to end-users such that
> users could make an informed decision about whether to trust a given root

Your request is that the CAs publish a list of Delegated Third Parties?
What would be done with such a list?

> 3. The BR exacerbate the confusion about liability by saying that the CA
> and the Delegated Third Party "MAY allocate liability between themselves
> contractually as they determine", but also that "the CA SHALL remain
> fully responsible for the performance of all parties". I can't parse
> this in a way that makes sense, as the two things seem mutually exclusive.

You are talking about:

14.2.3 Allocation of Liability

For delegated tasks, the CA and any Delegated Third Party MAY allocate
liability between themselves contractually as they determine, but the CA
SHALL remain fully responsible for the performance of all parties in
accordance with these Requirements, as if the tasks had not been delegated.

?

I agree that this is not entirely clear; I will raise an issue about
fixing it. Do you have a preferred resolution?

> Don't take the relative lack of response on this topic as approval.

Don't worry; I wouldn't take anything you say or don't say as approval
of anything I'm doing without very clear indications of such.

;-)

Gerv

Stephen Schultze

unread,
Jan 24, 2012, 9:53:50 AM1/24/12
to mozilla-dev-s...@lists.mozilla.org
On 1/23/12 11:54 AM, Gervase Markham wrote:
> On 17/01/12 14:39, Stephen Schultze wrote:
>> Have you gone back to the comment tracking spreadsheet? There are
>> several issues that were marked "currently under discussion" or the
>> like, which I do not believe were addressed. See, for example, issues
>> 18, 22, 47, and 49.
>
> Remind me of the URL? It's not in my Google Docs history...

You can find it in the list history. I'm troubled that you haven't
consulted it recently enough to know the URL, given that you are
purportedly relaying the concerns of this list to the CAB Forum.

>> CABForum discussions). I'm not sure what value there is in continuing to
>> tilt at windmills, but in short:
>>
>> 1. Delegated Third Parties are not audited by a Qualified Auditor
>
> The issues list currently has, as issue 1:
>
> "Better audit criteria are needed for sub CAs and RAs that are not
> operated directly by the CA."
>
> There is also a task to:
>
> "Describe a model of the certificate management eco-system, identifying
> the various components, then rewrite the document in terms of which
> component is responsible for satisfying each requirement, and identify
> which components fall within the scope of the various audits."
>
> Does that cover it?

It entirely depends on the results of that discussion (which most of us
are of course not part of). The task as described could cover it or
not. What components? What counts as one of the "various audits"?

It's fairly simple: all trusted entities should be audited by a
qualified independent auditor. What you quoted muddies the waters.

Would you be willing to share the current issues list with us?

>> 2. Delegated Third Parties are not disclosed to end-users such that
>> users could make an informed decision about whether to trust a given root
>
> Your request is that the CAs publish a list of Delegated Third Parties?
> What would be done with such a list?

There has been extensive discussion on the list, and a great deal of
support, which (among other things) led to additions to the draft
changes to the Mozilla requirements:

https://groups.google.com/group/mozilla.dev.security.policy/search?q=disclose+sub

>> 3. The BR exacerbate the confusion about liability by saying that the CA
>> and the Delegated Third Party "MAY allocate liability between themselves
>> contractually as they determine", but also that "the CA SHALL remain
>> fully responsible for the performance of all parties". I can't parse
>> this in a way that makes sense, as the two things seem mutually
>> exclusive.
>
> You are talking about:
>
> 14.2.3 Allocation of Liability
>
> For delegated tasks, the CA and any Delegated Third Party MAY allocate
> liability between themselves contractually as they determine, but the CA
> SHALL remain fully responsible for the performance of all parties in
> accordance with these Requirements, as if the tasks had not been delegated.
>
> ?
>
> I agree that this is not entirely clear; I will raise an issue about
> fixing it. Do you have a preferred resolution?
>
>> Don't take the relative lack of response on this topic as approval.
>
> Don't worry; I wouldn't take anything you say or don't say as approval
> of anything I'm doing without very clear indications of such.

CAs and Delegated Third Parties bear strict liability for any harm
resulting from their failure, or the failure of any delegated entities,
to conform to the BR, promises to users, or industry best practices.

ianG

unread,
Jan 24, 2012, 4:57:21 PM1/24/12
to dev-secur...@lists.mozilla.org
On 25/01/12 01:53 AM, Stephen Schultze wrote:
> On 1/23/12 11:54 AM, Gervase Markham wrote:
>> On 17/01/12 14:39, Stephen Schultze wrote:
...
>>> 3. The BR exacerbate the confusion about liability by saying that the CA
>>> and the Delegated Third Party "MAY allocate liability between themselves
>>> contractually as they determine", but also that "the CA SHALL remain
>>> fully responsible for the performance of all parties". I can't parse
>>> this in a way that makes sense, as the two things seem mutually
>>> exclusive.
>>
>> You are talking about:
>>
>> 14.2.3 Allocation of Liability
>>
>> For delegated tasks, the CA and any Delegated Third Party MAY allocate
>> liability between themselves contractually as they determine, but the CA
>> SHALL remain fully responsible for the performance of all parties in
>> accordance with these Requirements, as if the tasks had not been
>> delegated.
>>
>> ?
>>
>> I agree that this is not entirely clear; I will raise an issue about
>> fixing it. Do you have a preferred resolution?
>>
>>> Don't take the relative lack of response on this topic as approval.
>>
>> Don't worry; I wouldn't take anything you say or don't say as approval
>> of anything I'm doing without very clear indications of such.
>
> CAs and Delegated Third Parties bear strict liability for any harm
> resulting from their failure, or the failure of any delegated entities,
> to conform to the BR, promises to users, or industry best practices.


In simple terms: The problem of liability is only relevant in a court
setting. So it depends initially on who the parties are. Jurisdiction
and standing - whether a party has a right to sue - have a lot to do
with it all.

The Delegated Third Parties (whoever or whatever that means) can only be
sued by those with a contract (unless we are going on for some exotic
and path breaking public tort cases). Vendors only have a contract with
the CA, and potentially a subscriber.

So what the vendor is trying to do is make the CA responsible completely
for the 3rd parties because it already knows that we cannot sue the
latter, the 3rd party delegatee, without a contract.

Which makes sense. What might be helpful is if more legally appropriate
terms are included. I'm thinking here of the effect of "jointly and
severally" but I don't know enough legal talk to do it off the top of my
head.

This is all part of the persistent & irreversible trend towards vendor
as relying party and being therefore totally responsible on the users'
side. Hence, the need for language to balance that and make CA totally
responsible on the CA side.




iang

Kyle Hamilton

unread,
Jan 24, 2012, 8:00:31 PM1/24/12
to ianG, dev-secur...@lists.mozilla.org
Ian (and all),

I agree entirely with this assessment.

Here's an effective model under which all of the observed problems can be resolved.

On Tue, Jan 24, 2012 at 1:57 PM, ianG <ia...@iang.org> wrote:
> In simple terms: The problem of liability is only relevant in a court
> setting.  So it depends initially on who the parties are.  Jurisdiction and
> standing - whether a party has a right to sue - have a lot to do with it
> all.

This is why a (but more than one) strong central cross-certifier needs to exist, which forms contracts with the CAs it cross-certifies so as to create standing and resolve jurisdiction. The cross-certifier's contracts should specify the monetary penalties for failure to live up to the contract.

If we had such a central cross-certifier, none of the revocation scenarios which have required Firefox to push updates would have required the updates to be pushed.

> The Delegated Third Parties (whoever or whatever that means) can only be
> sued by those with a contract (unless we are going on for some exotic and
> path breaking public tort cases).  Vendors only have a contract with the CA,
> and potentially a subscriber.

A Delegated Third Party has a contract with a CA, under which the CA agrees to take responsibility and accept liability for certain actions of that DTP. The CA has a contract with the central cross-certifier, which establishes that CA's liability for the actions of its entire enrollment structure. The Vendor has a contract with the cross-certifier, under which it may claim monetary relief if it determines that the CA's controls failed. This Vendor-CC contract would also specify the processing requirements before the Vendor's software had the right to display anything about the certificate (including its existence) to the Vendor's software users.

Because these contracts would specify enforceable monetary penalties, publicly-held companies would be required (under securities law) to ensure that they are not accepting liability for someone who's going to do nothing but expose them to liability. This means that they actually have a reason to stay on top of DTP audits.

And, needless to say, the central cross-certifier would keep up on the audit reports and simply not renew the cross-certification of any deficient CAs. Think of cross-certificate policy mapping in libpkix, and imagine simplifying the code so that no special-cases for individual imagine the simple, easy mapping of "OV", "DV", and "EV".

These contracts could also contain language specifying binding arbitration by the central cross-certifier.

I think the reason nobody's been interested in doing this is because it radically shifts the liability from where it doesn't exist in the current system.

-Kyle H

Gervase Markham

unread,
Jan 27, 2012, 11:09:49 AM1/27/12
to mozilla-dev-s...@lists.mozilla.org
On 24/01/12 14:53, Stephen Schultze wrote:
> You can find it in the list history. I'm troubled that you haven't
> consulted it recently enough to know the URL, given that you are
> purportedly relaying the concerns of this list to the CAB Forum.

(Comment in passing: I will try and reply to this later, but I would
point out that currently opening one of your messages in this group has
the effect of causing me heave a deep sigh, think 'I don't have the
energy for this; maybe another day', mark it unread and move on. Which
is why conversations with you tend to proceed at a pretty slow pace. You
may wonder whether this effect has a negative impact on your ability to
effect change.)

Gerv

Kyle Hamilton

unread,
Jan 27, 2012, 3:33:13 PM1/27/12
to Gervase Markham, mozilla-dev-s...@lists.mozilla.org, Dan Veditz
Gerv,

On Fri, Jan 27, 2012 at 8:09 AM, Gervase Markham <ge...@mozilla.org> wrote:
> (Comment in passing: I will try and reply to this later, but I would point
> out that currently opening one of your messages in this group has the effect
> of causing me heave a deep sigh, think 'I don't have the energy for this;
> maybe another day', mark it unread and move on. Which is why conversations
> with you tend to proceed at a pretty slow pace. You may wonder whether this
> effect has a negative impact on your ability to effect change.)

You may perhaps wonder why you get nothing but hostility in this group. You sowed the seeds of it, and now you blame the harvest.

If you were to listen and participate and show that our participation actually meant something, instead of holding stubbornly to your belief that your vision of Internet or Web security is adequate, correct, or even remotely useful, perhaps you would find that the participants here wouldn't be so tiresome to deal with.

If you would provide us some means of working with the developers on a strategy for Internet and Web security that can work given what we've learned this past decade and more, perhaps you'd find that many of us in the group tend to be rancorous because there's no way to penetrate (much less burst) your bubble or demolish your ivory tower to see that your assumptions about security are hurting your users. There's no way to get you to see that your long-term callous attitude toward us has earned the response that you receive.

Hint: People don't use client authentication because you've made it impossible for them to do so across their swath of devices in any manner that doesn't rely on a single key being exportable, or in any way which allows them to have inconspicuous communication (every stream is visibly tagged with the certificate content). Compounded with the facts that most CA implementations I've interacted with refuse to certify multiple keys for the same email address, and some of our devices could possibly use USB tokens to utilize keys but others can't, this overall effect is to make cryptographic messaging and authentication unreliable and thus unusable.

People don't use web or email authentication because you've made it impossible for Firefox and Thunderbird to share the same user profile with the same keys even on the same system. And heaven forbid you create PKCS#11 modules for access to the platform certificate stores. People can't use a single location, nothing you write allows for it. This makes cryptographic messaging and authentication thus unusable.

But somehow this has managed to translate into "the market doesn't want cryptographic security". This view is completely wrong. The market doesn't want what you've been trying to force-feed them with mandatory buy-in to the CA model. The market doesn't want to expose its privacy due to your institutional inability to perceive what it and your users actually need, beyond your institutional ability to see what you think you offer.

I hate having to present it this way, but it's the truth. Mozilla is so misguided that it's institutionally working in a psychotic delusion.

Instead of focusing so much on security to the extent that you refuse to make a better UI, why don't you focus on creating a better UI for security and only after it's created figure out how to leverage the cryptographic technology that Netscape=>AOL=>Mozilla pioneered? Why continue the insanity of beating your head against the brick wall that is being so caught up in security you forget usability?

Why not get someone who knows how to manipulate the UI (not necessarily one of Mozilla's UI folk, unless they'd be willing to have a VERY open mind as we begin, and only after we figure out what we want in it start to simplify it) involved over here to help us figure out how to present our interface ideas? Dan Veditz appeared to be rather taken aback that the folk in dev.security.policy didn't seem to have any control or input into how the software interacted with the root store.

Can we at least agree that PKIX client certificate authentication is so broken that very few sites are willing to take on the task of educating their users on how to use it? (Even Microsoft's Live doesn't use certificate authentication, and they write one of the main consuming platforms.)

Can we at least agree that server certificate authentication is so broken that the delisting of a CA is a burden on every site owner which uses that CA, every other CA which must deal with their customer load as well, and every user who must deal with the fact that the key or certificate changed? (Providing multiple certificate chains in a single structure would permit all of those leaf certificate keys to be
associated with the site, in a key-continuity/key-pinning sense. Even if one of the keys in that structure becomes untrustworthy, the others stay trustworthy, and the user would still have reasonable assurance that he's still dealing with the right system. The problem shouldn't be "The Right Key", it should be "A Correct Key".)

Can we at least agree that the current practice of mandating certification operates as an extortion racket? (There is no law which says I have to take part in it, custom only demands it for business transactions, and TLS itself offers an unauthenticated mode which Mozilla's software refuses to permit. Even if Mozilla doesn't benefit from it, it's still an enforced commercial transaction which involves the transfer of the site owner's personally identifying information. If Mozilla doesn't benefit from it, why does it punish its users for using sites that very rightly don't want to be forced to pay the UI protection racket which it so well-meaningly created?)

Short form of the above: Clue, meet Gerv. Mr Markham, meet Mr byFour. I'm sorry I have to introduce you.

-Kyle H

Eddy Nigg

unread,
Jan 27, 2012, 4:08:27 PM1/27/12
to mozilla-dev-s...@lists.mozilla.org
On 01/27/2012 10:33 PM, From Kyle Hamilton:
>
> You may perhaps wonder why you get nothing but hostility in this
> group. You sowed the seeds of it, and now you blame the harvest.
>

It seems you erred in the forum because this forum isn't really about
X.509, PKIX, RFC XXX or how the Mozilla software is built and most of
what you mentioned has nothing to do with the Mozilla CA policy and its
implementation. Gerv might be around in other forums too, but we
basically don't deal here with the technical aspects of how certs are
used on the web and elsewhere.

But some heads up nevertheless....it took over one decade to reach the
first million SSL secured web sites, but it took only 3 years to reach
the second million and we are already on the way to the third. Adoption
seems to be really flying high these days, so it can't be that wrong
after all? Not speaking about all those certs that aren't equally
visible and measurable like those for web sites.

:-)

Stephen Schultze

unread,
Jan 27, 2012, 8:36:02 PM1/27/12
to mozilla-dev-s...@lists.mozilla.org
I'm sorry that you're frustrated. I hope that you can at least
understand why it was likewise frustrating to donate considerable time
and energy to something that wasn't thoroughly kept track of.

That being said, it is certainly more productive to talk about the the
actual issues than to spend more time sighing at each other.

The spreadsheet is here:
https://spreadsheets.google.com/ccc?key=0AtEE6hwRJw5cdGNudVN0M1hlSDE2dEs5OG1zVUE5VHc

Stephen Schultze

unread,
Jan 27, 2012, 8:39:50 PM1/27/12
to mozilla-dev-s...@lists.mozilla.org
Kathleen, do you have a proposal for what text (if any) could be removed
so that we can move forward on adopting the changes?

ianG

unread,
Jan 27, 2012, 9:34:13 PM1/27/12
to dev-secur...@lists.mozilla.org
On 28/01/12 03:09 AM, Gervase Markham wrote:
> On 24/01/12 14:53, Stephen Schultze wrote:
>> You can find it in the list history. I'm troubled that you haven't
>> consulted it recently enough to know the URL, given that you are
>> purportedly relaying the concerns of this list to the CAB Forum.
>
> (Comment in passing: I will try and reply to this later, but I would
> point out that currently opening one of your messages in this group has
> the effect of causing me heave a deep sigh, think 'I don't have the
> energy for this; maybe another day', mark it unread and move on. Which
> is why conversations with you tend to proceed at a pretty slow pace. You
> may wonder whether this effect has a negative impact on your ability to
> effect change.)
>
> Gerv


I have empathy with Stephen on this.

This is the gatekeeper in action. Unfortunately, the gatekeeper will
always be busy, and will always have good reasons why not to attend to
any particular issue or post or hobby horse. This being the point, all
the hundred issues are filtered through only one person, who "doesn't
have the energy" and thus ... 95 go nowhere. The 5 that might benefit
the insiders are of course somehow allowed to slip through.

This is seen by all, if not understood. This is why for the most part
we recognise that the CABForum approach of no user-representation and no
openness is bad, and in direct conflict of Mozilla's principles and
antithetical to the spirit of the open net.

I don't mean this personally. I don't think Gerv has done a
particularly bad job at it. I'm mostly pointing out that the gatekeeper
is *always put in position to block the outsiders*. Always, every time.
Whether you do a great job or not, whether you believe in the "user
cause", you cannot avoid blocking the outsiders, you cannot avoid doing
the job of the gatekeeper, as appointed. The cards are stacked, the
dice are weighted.

The gatekeeper is studied mostly in marketing, where the emphasis is on
how to bypass and get control of the real buyers for influence in sales.
Unfortunately for Mozilla, users are not sellers, and CABForum isn't
buying. It's the other way around. So we can't use any studied
techniques to break the pattern.

iang

Kathleen Wilson

unread,
Jan 30, 2012, 3:03:49 PM1/30/12
to mozilla-dev-s...@lists.mozilla.org
On 1/5/12 2:17 PM, Kathleen Wilson wrote:
> All,
>
> As you know, the CA/Browser Forum has published version 1.0 of the
> baseline requirements for SSL/TLS certificates: “Baseline Requirements
> for the Issuance and Management of Publicly-Trusted Certificates, v.1.0”.
>
> To download the document and read the announcement, see
> https://www.cabforum.org/
>
> Now I would like to start the discussion about how to update Mozilla’s
> CA Certificate Policy,
> http://www.mozilla.org/projects/security/certs/policy/, to take these
> baseline requirements into account.
>

All,

I greatly appreciate your thoughtful feedback regarding updating
Mozilla’s CA Certificate Policy to take into account the CA/Browser
Forum’s Baseline Requirements.

Based on your feedback I have made the following changes to the DRAFT of
version 2.1 of Mozilla’s CA Certificate Policy.

http://www.mozilla.org/projects/security/certs/policy/WorkInProgress/InclusionPolicy.html

Indicated in bold the items that I propose removing because they are
covered by the BRs. In parentheses I noted the BR that covers the item.
#6, bullet 3: “DELETE (BR16.5): …”
#6, bullet 4: “DELETE (BR12): …”
#8: “DELETE (BR11.1): …”

I left the currently proposed #9 and #10 as is. These are in red text,
because they are still proposed new text to add to the policy. Feedback
indicates that the concern that these items address is not sufficiently
covered by the current BRs.

I left #11 alone, because I think we need to keep this information in
Mozilla’s CA Certificate Policy for clarity, even though some of it is
in the BRs.

Added #12: “CA operations 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.

Note: I am open to suggestions here, but it seemed best to add this as a
separate item #. Also, I think that the second sentence handles the
exceptions that we currently need (such as the concerns with BR 17.6).
Let me know if you disagree, and think we need to call out specific
exceptions.

I also propose deleting a couple items in
file:///Users/kathleenwilson/Documents/Mozilla/mozilla.org/projects/security/certs/policy/WorkInProgress/MaintenancePolicy.html
#2: “DELETE (BR13.1.5): … “
#3: “DELETE (BR13.2.2): … “


I will appreciate your feedback on these proposed changes.

Kathleen

Kathleen Wilson

unread,
Jan 30, 2012, 3:09:57 PM1/30/12
to mozilla-dev-s...@lists.mozilla.org
On 1/30/12 12:03 PM, Kathleen Wilson wrote:
>
> I also propose deleting a couple items in
> file:///Users/kathleenwilson/Documents/Mozilla/mozilla.org/projects/security/certs/policy/WorkInProgress/MaintenancePolicy.html
>
> #2: “DELETE (BR13.1.5): … “
> #3: “DELETE (BR13.2.2): … “
>

Correct link:
http://www.mozilla.org/projects/security/certs/policy/WorkInProgress/MaintenancePolicy.html


Gervase Markham

unread,
Jan 31, 2012, 11:04:47 AM1/31/12
to mozilla-dev-s...@lists.mozilla.org
On 11/01/12 17:47, Gervase Markham wrote:
> Further to this, the CA/Browser Forum is gathering a list of issues that
> will be addressed in version 1.1. Mozilla has the opportunity to add to
> that list; if there are things you would like to see improved, fixed or
> changed, now is the time to say.
>
> Please phrase any responses as specific proposals for change rather than
> long screeds of frustratedness and complaint ;-) Suggestions which turn
> the entirety of PKI inside out are also unlikely to come to fruition.

The deadline for this is 5th February and my wife is currently in
labour. I would again suggest to this group that if they are interested
in seeing improvements to the BRs (as opposed to grandstanding about how
evil they are, how evil Mozilla is, how evil the CAB Forum is, how evil
the CAB Forum process is, or how evil I am), they (within the
constraints of the process, yes) provide some concrete suggestions for
issues I can get on the list.

E.g.:

"Section 14.5.76.3245 has problem X. It's not clear whether Y or Z is
meant. It should be clarified."

"There is nothing in the BRs about issue Q. Section 12 would be a good
place to insert something. Here is some suggested text that I have some
confidence the Forum might agree to: ..."

and so on.

In haste,

Gerv

Kathleen Wilson

unread,
Feb 1, 2012, 1:11:22 PM2/1/12
to mozilla-dev-s...@lists.mozilla.org
Another clarification...

>> #2: “DELETE (BR13.1.5):

Means that I am proposing deleting the text in bold (see the link) from
Mozilla's CA Certificate Policy because the same requirement is included
in the CAB Forum's BR 13.1.5. So I don't think we need to repeat it.

Kathleen


Stephen Schultze

unread,
Feb 2, 2012, 11:18:41 AM2/2/12
to mozilla-dev-s...@lists.mozilla.org
I propose the same concrete suggestions I made a week ago on this list.

I propose the full text of our current proposed update #9.

Gervase Markham

unread,
Feb 3, 2012, 12:55:12 PM2/3/12
to Stephen Schultze
On 02/02/12 16:18, Stephen Schultze wrote:
> I propose the same concrete suggestions I made a week ago on this list.

You really are determined not to help me at all, even the tiniest bit,
are you?

My 2-day-old son is downstairs and I have very limited time for this.
Where is the thing I wanted, which was a reply to my message which I
could cut and paste into an email to the CAB Forum? The deadline is
Monday and it's very unlikely I will have any more time to get this done.

I don't know how I could be more clear about what I wanted. I can only
conclude that you are not particularly interested in getting the BRs
changed. (That's fine, BTW - that's entirely your right.)

<sigh>

2 weeks ago, you said:

"1. Delegated Third Parties are not audited by a Qualified Auditor

2. Delegated Third Parties are not disclosed to end-users such that
users could make an informed decision about whether to trust a given root

3. The BR exacerbate the confusion about liability by saying that the CA
and the Delegated Third Party "MAY allocate liability between themselves
contractually as they determine", but also that "the CA SHALL remain
fully responsible for the performance of all parties". I can't parse
this in a way that makes sense, as the two things seem mutually exclusive."

Is that what you meant? If so, please can you reformat them into the
form I requested, along with suggested alternative text.

> I propose the full text of our current proposed update #9.

Er, what? You've totally lost me.

Gerv

Peter Kurrasch

unread,
Feb 3, 2012, 2:17:38 PM2/3/12
to Gervase Markham, mozilla-dev-s...@lists.mozilla.org
First let me congratulate you and your family on the birth of your son!
Frankly that has got to be far more important that this silly mail list or
the CAB forum. That said...

What I'm looking for are concrete steps that I (both as a user and software
developer) can take to distinguish between fraudulent certificates and
"probably good" certs. I'm not looking for something black-or-white but if
I can see that a cert is "obviously bad" I want to weed it out as soon as
possible.

To that end, this is what I expect to see:

1) All certs have an O= field in both subject and issuer names. A user
should be able to clearly see who or what agency is issuing the cert.

2) No certs have an OU= field in either subject or issuer names since it
doesn't help anyone and frequently obfuscates what's going on. I
understand why it has been used in the past, but we should stop the
practice going forward.

3) Once a cert is issued the "not before" date does not get changed on
subsequent re-issues. If I reissue a cert to extend out the expiration
date, the "not before" date doesn't change. If I add or modify an
extension, the "not before" date does not change.

4) Once a cert is issued the subject name is forever bound to the public
key on that cert. On the flip side, however, a public key is expected to
be associated with multiple subject names. The motivation here is that if
at some point in the future I encounter a cert with a subject name I
recognize but it has a different public key I want to be able to say "a ha,
this new cert is obviously a forgery!" Maybe there's a doc somewhere that
stipulates this already--I haven't been able to find it yet.

5) As I've mentioned before in this group, I have different expectations
on the serial number field which I won't bother to bring up again right
here and now. Still, I would like to see something different that what's
currently in the BR.

6) All certs to be submitted for inclusion in a product will be judged by
the current standards. The "this is what we had before" argument will not
be accepted. For example, if a root cert is re-submitted because it has an
later expiration date, the entire cert will be evaluated according to the
current practices and no special considerations will be granted to what was
used in the past.

7) All root certs must have at least 1 intermediary between the root and
end-point certificate. This is more a pragmatic issue to help mitigate
backward-compatibility issues. Also, it's another way to help exclude
"obviously fraudulent" situations.

8) I'd also like to see tighter rules and restrictions placed on the actual
ASN.1 syntax for the distinguished names, but I'll leave that for another
discussion.


Finally, I suggest splitting the liability requirements/issues/whatever
into a separate doc from the BR. Obviously that's a complicated issue and
far more thought needs to go into it and I expect that whatever is worked
out will require a combination of legalese documents plus user interface
improvements. While those issues are worked and re-worked I think we can
settle the other stuff and have a stable document.



On Fri, Feb 3, 2012 at 11:55 AM, Gervase Markham <ge...@mozilla.org> wrote:

> On 02/02/12 16:18, Stephen Schultze wrote:
>
>> I propose the same concrete suggestions I made a week ago on this list.
>>
>

Stephen Schultze

unread,
Feb 3, 2012, 4:56:30 PM2/3/12
to mozilla-dev-s...@lists.mozilla.org
On 2/3/12 12:55 PM, Gervase Markham wrote:
> On 02/02/12 16:18, Stephen Schultze wrote:
>> I propose the same concrete suggestions I made a week ago on this list.
>
> You really are determined not to help me at all, even the tiniest bit,
> are you?
>
> My 2-day-old son is downstairs and I have very limited time for this.
> Where is the thing I wanted, which was a reply to my message which I
> could cut and paste into an email to the CAB Forum? The deadline is
> Monday and it's very unlikely I will have any more time to get this done.

Gerv, congratulations. I certainly didn't mean to exasperate you.
Perhaps someone else should help you out by taking over CAB Forum
responsibilities for a little while. You deserve a break.

I was referring to my email from 1/24:

> It's fairly simple: all trusted entities should be audited by a
> qualified independent auditor.

(ie, CAB Forum should add a qualified independent audit requirement to
SubCAs and cross-signed CAs)

....and...

> CAs and Delegated Third Parties bear strict liability for any harm
> resulting from their failure, or the failure of any delegated entities,
> to conform to the BR, promises to users, or industry best practices.

>> I propose the full text of our current proposed update #9.
>
> Er, what? You've totally lost me.

Item #9 of the proposed updates to the Mozilla Cert Policy. The one
that deals with SubCA disclosure, that Kathleen and I have been
discussing on the list over this past week. Listed here:

https://www.mozilla.org/projects/security/certs/policy/WorkInProgress/InclusionPolicy.html


9. The CA must do one of the following for each external third party
that issues certificates. (Any external third party that can directly
cause the issuance of a certificate must be treated as a subordinate CA,
meeting one of the following two requirements.)

- Implement technical controls to restrict the subordinate CA to only
issue certificates within a specific set of domain names which the CA
has confirmed that the subordinate CA has registered or has been
authorized by the domain registrant to act on the registrant's behalf.
Such technical controls must be documented in the CA's Certificate
Policy or Certification Practice Statement, and reviewed by a competent
independent party as part of the CA's annual audit. Acceptable technical
controls include but are not limited to X.509 dNSName Name Constraints
as specified in RFC 5280, which are marked as critical.

- Publicly disclose the subordinate CA along with the subordinate CA's
corresponding Certificate Policy and/or Certification Practice Statement
and provide public attestation of the subordinate CA's conformance to
the stated verification requirements and other operational criteria by a
competent independent party or parties with access to details of the
subordinate CA's internal operations. The subordinate CA's verification
requirements and operational criteria must satisfy the requirements of
the Mozilla CA Certificate Policy. The CA's Certificate Policy or
Certification Practice Statement must indicate where the list of
publicly disclosed subordinate CAs may be found on the CA's website.



Gervase Markham

unread,
Feb 4, 2012, 11:15:52 AM2/4/12
to mozilla-dev-s...@lists.mozilla.org
On 03/02/12 19:17, Peter Kurrasch wrote:
> 1) All certs have an O= field in both subject and issuer names. A user
> should be able to clearly see who or what agency is issuing the cert.

Isn't this true already?

What would be in the Subject O field for individuals?

> 2) No certs have an OU= field in either subject or issuer names since it
> doesn't help anyone and frequently obfuscates what's going on. I
> understand why it has been used in the past, but we should stop the
> practice going forward.

If you are uninterested in the contents of that field, surely you can
ignore it?

> 3) Once a cert is issued the "not before" date does not get changed on
> subsequent re-issues. If I reissue a cert to extend out the expiration
> date, the "not before" date doesn't change. If I add or modify an
> extension, the "not before" date does not change.

What benefit does this provide?

> 4) Once a cert is issued the subject name is forever bound to the public
> key on that cert. On the flip side, however, a public key is expected to
> be associated with multiple subject names. The motivation here is that if
> at some point in the future I encounter a cert with a subject name I
> recognize but it has a different public key I want to be able to say "a ha,
> this new cert is obviously a forgery!"

Surely one big feature of PKI is that a subject name can be bound to
multiple keys (e.g. during cert rollover)?

> 6) All certs to be submitted for inclusion in a product will be judged by
> the current standards. The "this is what we had before" argument will not
> be accepted. For example, if a root cert is re-submitted because it has an
> later expiration date, the entire cert will be evaluated according to the
> current practices and no special considerations will be granted to what was
> used in the past.

This doesn't sound like something for the BRs... is this a suggestion
for Mozilla practice?

> 7) All root certs must have at least 1 intermediary between the root and
> end-point certificate. This is more a pragmatic issue to help mitigate
> backward-compatibility issues. Also, it's another way to help exclude
> "obviously fraudulent" situations.

This is basically true already; IIRC, the BRs have a tightly-limited
exception to this for legacy systems which can't process chains, but
otherwise it's true.

Gerv

Gary Gapinski

unread,
Feb 6, 2012, 1:52:52 PM2/6/12
to mozilla-dev-s...@lists.mozilla.org
On 01/11/2012 12:47 PM, Gervase Markham wrote:
> Please phrase any responses as specific proposals for change rather than
> long screeds of frustratedness and complaint ;-) Suggestions which turn
> the entirety of PKI inside out are also unlikely to come to fruition.


Regarding

/Baseline Requirements for the Issuance and Management of
Publicly-Trusted Certificates, v.1.0/

(https://www.cabforum.org/Baseline_Requirements_V1.pdf)


In section 13.2.5 "OCSP Signing", the statement

"OCSP responses MUST either:

1. Be signed by the CA that issued the Certificates whose revocation
status is being checked, or

2. Be signed by an OCSP Responder whose Certificate is signed by the CA
that issued the Certificate whose revocation status is being checked"

should be changed to

"OCSP responses MUST either:

1. Be signed by the private key that was used to sign the Certificate(s)
whose revocation status is being checked, or

2. Be signed by an OCSP Responder whose Certificate is signed using the
same private key that was used to sign the Certificate(s) whose
revocation status is being checked"

Erwann Abalea

unread,
Feb 7, 2012, 8:50:51 AM2/7/12
to mozilla-dev-s...@lists.mozilla.org
Le lundi 6 février 2012 19:52:52 UTC+1, Gary Gapinski a écrit :
[...]
> In section 13.2.5 "OCSP Signing", the statement
>
> "OCSP responses MUST either:
>
> 1. Be signed by the CA that issued the Certificates whose revocation
> status is being checked, or
>
> 2. Be signed by an OCSP Responder whose Certificate is signed by the CA
> that issued the Certificate whose revocation status is being checked"
>
> should be changed to
>
> "OCSP responses MUST either:
>
> 1. Be signed by the private key that was used to sign the Certificate(s)
> whose revocation status is being checked, or
>
> 2. Be signed by an OCSP Responder whose Certificate is signed using the
> same private key that was used to sign the Certificate(s) whose
> revocation status is being checked"

No. Look into RFC2560 to get the original phrasing, which is what is included in the BR. Changing "CA" into "private key" doesn't follow X.509.

Gervase Markham

unread,
Feb 7, 2012, 10:01:27 AM2/7/12
to Kyle Hamilton, Dan Veditz
On 27/01/12 20:33, Kyle Hamilton wrote:
> If you were to listen and participate and show that our participation
> actually meant something, instead of holding stubbornly to your belief
> that your vision of Internet or Web security is adequate, correct, or
> even remotely useful, perhaps you would find that the participants here
> wouldn't be so tiresome to deal with.

I do think the current Internet security we have is more than "remotely
useful", given the amount of unmolested business carried on using it
every single day.

Note that "remotely useful" in the above sentence is not the same as
"ideal", or even "well-designed" or various other complementary adjectives.

> assumptions about security are hurting your users. There's no way to get
> you to see that your long-term callous attitude toward us has earned the
> response that you receive.

Yes, Kyle, that's it. It's because I hate you. Surely, there can be no
other explanation for my pig-headedness in refusing to accept that you
are right.

I thought about preparing a response to the rest, but I felt myself
losing the will to live. Sorry. It's hard to have a discussion when
being bombarded with "you're an idiot". Particularly when it's over
things which are mostly not under my control; I'm just the convenient
whipping boy.

Gerv

Gervase Markham

unread,
Feb 7, 2012, 10:01:36 AM2/7/12
to ianG, dev-secur...@lists.mozilla.org
On 28/01/12 02:34, ianG wrote:
> This is the gatekeeper in action. Unfortunately, the gatekeeper will
> always be busy, and will always have good reasons why not to attend to
> any particular issue or post or hobby horse. This being the point, all
> the hundred issues are filtered through only one person, who "doesn't
> have the energy" and thus ... 95 go nowhere. The 5 that might benefit
> the insiders are of course somehow allowed to slip through.

If you had clearly presented 100 issues, I might have some sympathy with
this view. But every time I read this forum (increasingly seldom,
because it's such a mental effort) I have to plough through pages and
pages of soapboxing, entire system redesigns, deep incentives analysis,
and so on.

It's your right not to want to engage with this system, and to desire to
replace it with something else entirely. There are even times when
Mozilla, or individual Mozillians, are interested in hearing about such
things. But all day, every day is just not helpful.

Gerv

Gervase Markham

unread,
Feb 7, 2012, 10:01:36 AM2/7/12
to ianG, dev-secur...@lists.mozilla.org
On 28/01/12 02:34, ianG wrote:
> This is the gatekeeper in action. Unfortunately, the gatekeeper will
> always be busy, and will always have good reasons why not to attend to
> any particular issue or post or hobby horse. This being the point, all
> the hundred issues are filtered through only one person, who "doesn't
> have the energy" and thus ... 95 go nowhere. The 5 that might benefit
> the insiders are of course somehow allowed to slip through.

Gervase Markham

unread,
Feb 7, 2012, 10:01:36 AM2/7/12
to ianG, dev-secur...@lists.mozilla.org
On 28/01/12 02:34, ianG wrote:
> This is the gatekeeper in action. Unfortunately, the gatekeeper will
> always be busy, and will always have good reasons why not to attend to
> any particular issue or post or hobby horse. This being the point, all
> the hundred issues are filtered through only one person, who "doesn't
> have the energy" and thus ... 95 go nowhere. The 5 that might benefit
> the insiders are of course somehow allowed to slip through.

Eddy Nigg

unread,
Feb 7, 2012, 10:06:27 AM2/7/12
to mozilla-dev-s...@lists.mozilla.org
On 02/07/2012 05:00 PM, From Gary Gapinski:
> Unfortunately, Mozilla NSS and several other PKI stacks appear to
> enforce the "same key" constraint, at least for OCSP signing
> certificates that are not the CA certificate but are from the "same CA".

Of course, otherwise anybody can sign just any OCSP response, also an
attacker.

Gary Gapinski

unread,
Feb 7, 2012, 10:20:39 AM2/7/12
to mozilla-dev-s...@lists.mozilla.org, Eddy Nigg
On 02/07/2012 10:06 AM, Eddy Nigg wrote:
> On 02/07/2012 05:00 PM, From Gary Gapinski:
>> Unfortunately, Mozilla NSS and several other PKI stacks appear to
>> enforce the "same key" constraint, at least for OCSP signing
>> certificates that are not the CA certificate but are from the "same CA".
>
> Of course, otherwise anybody can sign just any OCSP response, also an
> attacker.
>

Indeed.

I should have written that as «Despite conflicting guidance in normative
and informative standards, such as RFC 2560, Mozilla NSS and several
other PKI stacks fortuitously appear to enforce the "same key" constraint».

Erwann Abalea

unread,
Feb 7, 2012, 10:37:32 AM2/7/12
to mozilla-dev-s...@lists.mozilla.org
Le mardi 7 février 2012 16:06:27 UTC+1, Eddy Nigg a écrit :
> On 02/07/2012 05:00 PM, From Gary Gapinski:
> > Unfortunately, Mozilla NSS and several other PKI stacks appear to
> > enforce the "same key" constraint, at least for OCSP signing
> > certificates that are not the CA certificate but are from the "same CA".
>
> Of course, otherwise anybody can sign just any OCSP response, also an
> attacker.

How could it?

RFC2560, in its current phrasing, allows the CA to self-issue a certificate used exclusively for OCSP signing. It also allows the CA to renew its key and sign OCSP responses with the new key.

The proposed phrasing forbids that. This tends to propose a less agile world.

Peter Kurrasch

unread,
Feb 7, 2012, 1:38:07 PM2/7/12
to Gervase Markham, mozilla-dev-s...@lists.mozilla.org, Dan Veditz, Kyle Hamilton
Gerv--

Without trying to continue the broad strokes, evil-vs-less-evil debate, I
would like to know where you set the bar for what is considered
"acceptable"--both for you personally as well as a representative of
mozilla.org. I know there are differences between what is realistically
possible and what each of us would like to see, but I would just like to
understand better where you're coming from.

And to be clear, I do not mean this as any sort of attack or an attempt to
cast aspersions, etc. I really am trying to understand better.

Thanks.


On Tue, Feb 7, 2012 at 9:01 AM, Gervase Markham <ge...@mozilla.org> wrote:

> On 27/01/12 20:33, Kyle Hamilton wrote:
>
>> If you were to listen and participate and show that our participation
>> actually meant something, instead of holding stubbornly to your belief
>> that your vision of Internet or Web security is adequate, correct, or
>> even remotely useful, perhaps you would find that the participants here
>> wouldn't be so tiresome to deal with.
>>
>

Gervase Markham

unread,
Feb 8, 2012, 10:03:40 AM2/8/12
to Peter Kurrasch, Kyle Hamilton, Dan Veditz
On 07/02/12 18:38, Peter Kurrasch wrote:
> Without trying to continue the broad strokes, evil-vs-less-evil debate, I
> would like to know where you set the bar for what is considered
> "acceptable"--both for you personally as well as a representative of
> mozilla.org. I know there are differences between what is realistically
> possible and what each of us would like to see, but I would just like to
> understand better where you're coming from.
>
> And to be clear, I do not mean this as any sort of attack or an attempt to
> cast aspersions, etc. I really am trying to understand better.

That's fine :-) There is a spectrum of opinions on, well, almost any
security-related topic within mozilla.org and the final decision-maker
for a particular thing is sometimes not entirely clear. So perhaps it's
best if I just speak for myself.

Limiting us to the small subset of the security landscape that is the CA
and SSL ecosystem, I would say that currently we're at "could do
better", but some form of widely-deployed and understood CA pinning,
available to all sites who want it, would plug what is clearly the
biggest potential hole (any CA can sign for any site) and turn things
into "acceptable".

I think Firefox should have the ability to "shut off a root from date
X", so we can disable compromised roots without breaking large chunks of
the web.

"Doing really well", would be a system which allows people to protect
themselves effectively from their own or other hostile governments. I'm
not sure we're there yet, and it's an open question as to whether it
should really be in the threat model. But it would be awesome if we
could fix that someday.

Gerv

Kathleen Wilson

unread,
Feb 25, 2012, 1:40:22 PM2/25/12
to mozilla-dev-s...@lists.mozilla.org
On 2/1/12 10:11 AM, Kathleen Wilson wrote:
> Another clarification...
>
> >> #2: “DELETE (BR13.1.5):
>
> Means that I am proposing deleting the text in bold (see the link) from
> Mozilla's CA Certificate Policy because the same requirement is included
> in the CAB Forum's BR 13.1.5. So I don't think we need to repeat it.
>


From Section 1 of the Baseline Requirements:
"This version of the Requirements only addresses Certificates intended
to be used for authenticating servers accessible through the Internet.
Similar requirements for code signing, S/MIME, time-stamping, VoIP, IM,
Web services, etc. may be covered in future versions."

However, Mozilla's CA Certificate Policy addresses certificates to be
used for S/MIME and code signing, as well as SSL. Therefore, I propose
the following changes to the DRAFT policy.

http://www.mozilla.org/projects/security/certs/policy/WorkInProgress/InclusionPolicy.html

The two bullet points that we were considering deleting from item #6
should not be deleted, because they also apply to non-SSL cert issuance.
- "DELETE (BR16.5): enforce multi-factor authentication for all accounts
capable of directly causing certificate issuance;"
- "DELETE (BR12): maintain a certificate hierarchy such that the
included certificate signs intermediate certificates for the issuance of
end-entity certificates to customers;"

The proposed item #12 should clarify that the requirement is for SSL
cert issuance. How about the following?
"12. CA operations and issuance of certificates to be used for
SSL-enabled servers must 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."



http://www.mozilla.org/projects/security/certs/policy/WorkInProgress/MaintenancePolicy.html

Both item #2 and item #3 should not be deleted, because they also apply
to non-SSL certificates.


Kathleen
0 new messages