Updating Mozilla CA certificate policy to address EV certificates
Frank Hecker
CA certificate policy to address the issue of "extended validation"
certificates. Part of that process involves public discussion of exactly
what changes need to be made. Here are some quick thoughts of my own;
note that these are somewhat tentative, but I'm putting them out here to
get feedback.
First, just to review: Now that the CAB Forum has published version 1.0
of the EV guidelines:
http://www.cabforum.org/EV_Certificate_Guidelines.pdf
we've had a number of CAs asking for their root CAs to be marked as
capable of issuing EV certificates, so that they can be accorded any
special UI present in Firefox 3 and related products to display identity
information in SSL certs. (See for example bugs 398944 and 383183.)
However just as we have a formal policy for deciding whether to add a
particular root CA certificate for "normal" use, we should also have a
formal policy for marking a root CA's certificate as EV-capable (as
noted by Eddy Nigg and others).
As noted in the bug, I think an EV-enabled root CA cert is simply a
special case of root CA certs in general, so we don't need a whole new
separate policy. At the same time I don't want to revise every section
of the existing policy, and if possible I'd like to avoid changes that
necessitate renumbering and reorganizing the current sections of the
policy. I'm therefore leaning toward having an EV addendum to the
policy, and putting all the EV-related stuff there. Then we could simply
modify section 6 ("We require ...") to add an additional paragraph
pointing to the addendum. This would result in a version 1.1 of the
overall Mozilla CA cert policy.
In terms of the addendum itself, obviously we can reference the CAB
Forum guidelines document (formally, "Guidelines for the Issuance and
Management of Extended Validation Certificates, Version 1.0") as the
governing criteria. There's a broader question of whether in theory we
could or should accord "EV-style" treatment to CAs that don't strictly
speaking conform to the guidelines, but conform to other guidelines
deemed to be equivalent. I'd like to declare that question out of scope
for now, as there's no obvious candidates today for alternative
guidelines (at least AFAIK).
In terms of audits associated with "EV-ness", I'm a little unclear on
what other documents need to be referenced. Section J of the EV
guidelines spells out the high-level audit requirements: basically
either go through the WebTrust EV process or a process deemed as
equivalent by the CAB Forum. There's a document "WebTrust for
Certification Authorities - WebTrust Extended Validation Audit Criteria"
on the CAB Forum web site; however it's marked as draft and the
guidelines themselves don't mention it by name AFAICT. (The guidelines
instead use the term "WebTrust EV Program".) My initial conclusion is
that we don't need to reference the WebTrust draft document, but can
confine ourselves to referencing the relevant section(s) of the guidelines.
Finally, I'm open to suggestions on other possible changes to the
Mozilla CA certificate policy unrelated to EV certs. However I reserve
the right to postpone such consideration of such changes to a future
version of the policy (e.g., 1.2) if there's no immediate strong
consensus on the need for any such change and the associated "patch" to
the policy itself. My primary goal is to address the EV-related policy
changes, and to do so as expeditiously as possible.
Anyway, if you have comments on this general topic please feel free to
post them here. In the meantime I'll work to come up with an initial
draft of proposed changes to the policy text, and will post that to the
bug when done.
Frank
--
Frank Hecker
hec...@mozillafoundation.org
Gervase Markham
> In terms of audits associated with "EV-ness", I'm a little unclear on
> what other documents need to be referenced. Section J of the EV
> guidelines spells out the high-level audit requirements: basically
> either go through the WebTrust EV process or a process deemed as
> equivalent by the CAB Forum. There's a document "WebTrust for
> Certification Authorities - WebTrust Extended Validation Audit Criteria"
> on the CAB Forum web site; however it's marked as draft and the
> guidelines themselves don't mention it by name AFAICT. (The guidelines
> instead use the term "WebTrust EV Program".)
I believe that the two things are supposed to be equivalent; the
different language is just sloppy drafting. As I understand it, this
document is going to be finalised soon.
> My initial conclusion is
> that we don't need to reference the WebTrust draft document, but can
> confine ourselves to referencing the relevant section(s) of the guidelines.
Without an audit, how do we assure compliance?
One of the big advantages of EV is that we have a minimum standard for
vetting that is actually enforced by audit - i.e. we don't have to
assess the vetting practices of every CA (even if they would tell us
what they were), because someone else has done it for us.
It seems to me that it makes sense to leverage that, by saying that our
criteria for EV enablement is a passed WebTrust EV Audit.
Gerv
Eddy Nigg (StartCom Ltd.)
Gervase Markham wrote:
> One of the big advantages of EV is that we have a minimum standard for
> vetting that is actually enforced by audit - i.e. we don't have to
> assess the vetting practices of every CA (even if they would tell us
> what they were), because someone else has done it for us.
>
> It seems to me that it makes sense to leverage that, by saying that our
> criteria for EV enablement is a passed WebTrust EV Audit.
>
I just would like to remind you about the promise made at the beginning
of this year (at and after the conference call), that Mozilla will work
at the CAB forum for alternative (and definition of equivalent) third
party audit other than webtrust and/or implement its own alternative
binding for Mozilla products only.
Since the guidelines for the EV audit are published in addition to the
EV guidelines for CAs themselves, capable audit firms could perform this
task without the CA having to use a webtrust accredited auditor. This
should only have an affect on the choice of acceptable auditors and not
reduce the value of EV and the audit itself. The EV policy extension
could be the place for such a definition.
--
Regards
Signer: Eddy Nigg, StartCom Ltd. <http://www.startcom.org>
Jabber: star...@startcom.org <xmpp:star...@startcom.org>
Blog: Join the Revolution! <http://blog.startcom.org>
Phone: +1.213.341.0390
Frank Hecker
> Frank Hecker wrote:
<snip>
>> My initial conclusion is that we don't need to reference the WebTrust
>> draft document, but can confine ourselves to referencing the relevant
>> section(s) of the guidelines.
>
> Without an audit, how do we assure compliance?
I wasn't implying that we would require an audit; see below.
> It seems to me that it makes sense to leverage that, by saying that our
> criteria for EV enablement is a passed WebTrust EV Audit.
But that's being more specific than what the guidelines actually say.
(This is relevant to Eddy's point as well.)
Let's suppose we have language like the following (note that this is
*not* proposed draft language at this point, it's just me thinking out
loud):
In order for its root CA certificate to be marked as EV-capable, the
CA must comply with the "Guidelines for the Issuance and Management
of Extended Validation Certificates, Version 1.0" as published by the
CAB Forum.
Inherent in that compliance is compliance to section 4(a)(3) of the
guidelines:
(3) Comply with the requirements of (i) the then-current WebTrust
Program for CAs, and (ii) the then-current WebTrust EV Program, or an
equivalent for both (i) and (ii) as approved by the CA/Browser Forum;
as well as compliance to section 35 of the guidelines, which has similar
language but goes into more detail. So I think the requirement for an
audit is inherent in the requirement for compliance with the guidelines.
If we wanted to emphasize the audit requirement, we could say something like
... CA must comply with the "Guidelines for the Issuance and
Management of Extended Validation Certificates, Version 1.0",
including the requirements of section 35, "Audit Requirements".
The above is why I don't think we need to reference the WebTrust
document specifically. Your thoughts?
Frank Hecker
> I wasn't implying that we would require an audit; see below.
Sorry, s/would/would not/
(Those double negatives will trip you up every time :-)
Frank Hecker
> I just would like to remind you about the promise made at the beginning
> of this year (at and after the conference call), that Mozilla will work
> at the CAB forum for alternative (and definition of equivalent) third
> party audit other than webtrust and/or implement its own alternative
> binding for Mozilla products only.
I'll consider myself reminded :-)
But how should that affect this current proposal to change the Mozilla
CA policy? As I noted in my previous message, I think requiring
compliance to the CAB Forum guidelines implies compliance with the audit
requirements of those guidelines, and those guidelines already allow for
the possibility of non-WebTrust audits. ("...or an equivalent for both
(i) and (ii) as approved by the CA/Browser Forum", to quote the relevant
clauses of section 35.)
We then have the following alternative options:
A. Change our policy to adopt language like I suggested in my last
message, and then separately work through the CAB Forum to get some
non-WebTrust audit programs approved by the CAB Forum as "equivalent" to
the WebTrust programs.
or
B. Try to come up with an alternative audit program ourselves, and
change our policy to allow that program to satisfy our own requirements
for EV certs, independent of what the CAB Forum does or doesn't do.
My personal preference is to go with option A. First, I don't want to
gate updating our policy on solving the problem of defining a
WebTrust-equivalent EV audit regime. Second, I would prefer that we use
the standard CAB Forum mechanisms to try and address this issue.
Eddy Nigg (StartCom Ltd.)
>
> I'll consider myself reminded :-)
>
> But how should that affect this current proposal to change the Mozilla
> CA policy? As I noted in my previous message, I think requiring
> compliance to the CAB Forum guidelines implies compliance with the audit
> requirements of those guidelines, and those guidelines already allow for
> the possibility of non-WebTrust audits. ("...or an equivalent for both
> (i) and (ii) as approved by the CA/Browser Forum", to quote the relevant
> clauses of section 35.)
>
> We then have the following alternative options:
>
> A. Change our policy to adopt language like I suggested in my last
> message, and then separately work through the CAB Forum to get some
> non-WebTrust audit programs approved by the CAB Forum as "equivalent" to
> the WebTrust programs.
>
> or
>
> B. Try to come up with an alternative audit program ourselves, and
> change our policy to allow that program to satisfy our own requirements
> for EV certs, independent of what the CAB Forum does or doesn't do.
>
> My personal preference is to go with option A. First, I don't want to
> gate updating our policy on solving the problem of defining a
> WebTrust-equivalent EV audit regime. Second, I would prefer that we use
> the standard CAB Forum mechanisms to try and address this issue.
the comment above makes perfect sense. Additionally I'd also agree on A
as well as the preferred option should it be made possible. However I
suggest we all agree on a plan and time line which would result in
option B in case of failure of A.
Mozilla has voted in favor of the guidelines and some time has past
since. I haven't been updated if anything happened in that direction,
but supposed that nothing could be advanced as of now, we should define
when/where/what happens if there is no solution found to the
"WebTrust-equivalent EV audit regime" problem (your words ;-) ). Your
option B could be a very likely solution in such as case.
Frank Hecker
> I've filed a bug against myself (399214) to update the current Mozilla
> CA certificate policy to address the issue of "extended validation"
> certificates.
After thinking about it, I think it may be possible to do this just by
adding a final paragraph to section 6 of the current policy:
In addition, if a CA wishes its certificate to be marked to note that
Extended Validation certificates may be issued under the associated CA
hierarchy then we require that the CA comply with the "Guidelines for
the Issuance and Management of Extended Validation Certificates,
Version 1.0" (as modified by the erratum published by the CAB Forum),
and have its compliance attested to in accordance with the
requirements of Section J of that document.
I've attached a proposed patch to this effect to bug 399214.
Your comments are welcome.
Nelson B
I think that's fine in terms of stating the qualifications. However,
I think there are also procedural questions/issues to be addressed.
During his term as administrator of the Root CA cert policy, Gerv created
a questionnaire that he routinely asked CAs to answer in their applications.
I think it would be good to publish that along with the formal policy.
To handle EV CAs, that questionnaire needs to be extended slightly.
It needs to ask, for each root cert being put forward, whether that cert
will be a root for EV certs, and if so, what is the EV policy OID that
will be used in all EV certs that chain up to that root?
--
Nelson B
Eddy Nigg (StartCom Ltd.)
> After thinking about it, I think it may be possible to do this just by
> adding a final paragraph to section 6 of the current policy:
>
> In addition, if a CA wishes its certificate to be marked to note that
> Extended Validation certificates may be issued under the associated CA
> hierarchy then we require that the CA comply with the "Guidelines for
> the Issuance and Management of Extended Validation Certificates,
> Version 1.0" (as modified by the erratum published by the CAB Forum),
> and have its compliance attested to in accordance with the
> requirements of Section J of that document.
>
Shouldn't be this be part of section 8 as this is a criteria for CA
operations (and its associated audits).
After reading your proposal I would suggest alternatively the following:
_Under section 7_ "We consider verification of certificate signing
requests to be acceptable if it meets or exceeds the following
requirements:"
Add a fourth part with something like this:
"for a certificate to be used for and marked as Extended Validation the
CA complies with the "Guidelines for the Issuance and Management of
Extended Validation Certificates, Version 1.0" (as modified by the
erratum published by the CAB Forum), and have its compliance attested to
in accordance with the requirements of Section J of that document."
(As a by-note, I'm note sure the version number should be used and or
include any future versions instead. Something like "Guidelines for the
Issuance and Management of Extended Validation Certificates according to
the most actual version as published by the CAB forum....")
_Under section 8_ "We consider the criteria for CA operations published
in any of the following documents to be acceptable:"
Add the criteria and guidelines for the Issuance and Management of
Extended Validation Certificates as published by the CAB forum.
(Obviously after performing an EV audit, this should allow to issue
regular non-EV certificates as well.)
Additionally I would like to see somewhere a disclaimer which would
allow Mozilla in the future to accept alternative auditors other than
the ones approved by the CAB forum for EV without the need to change the
Mozilla CA policy again in order to allow that. This doesn't mean that
Mozilla _must_ accept, but would keep the option open in the same way as
the policy has other such disclaimers concerning different aspects.
Eddy Nigg (StartCom Ltd.)
> I think that's fine in terms of stating the qualifications. However,
> I think there are also procedural questions/issues to be addressed.
>
> During his term as administrator of the Root CA cert policy, Gerv created
> a questionnaire that he routinely asked CAs to answer in their applications.
> I think it would be good to publish that along with the formal policy.
>
> To handle EV CAs, that questionnaire needs to be extended slightly.
> It needs to ask, for each root cert being put forward, whether that cert
> will be a root for EV certs, and if so, what is the EV policy OID that
> will be used in all EV certs that chain up to that root?
>
perhaps we need some agreed guidelines and practices concerning the
process of CA acceptance. This would guaranty that the process would be
performed always according to the same regulations and wouldn't depend
on a specific person. I think Gerv has structured and standardized that
process quite a bit and this should be somewhere nailed down a
bit....just in case Gerv goes on some long-term vacation to the Bahamas
or such ;-)
Gervase Markham
> The above is why I don't think we need to reference the WebTrust
> document specifically. Your thoughts?
Sounds fine. :-) If, in some strange universe, the CABForum decided not
to require audits for compliance any more, then we could just update our
policy again.
Gerv
Frank Hecker
>> After thinking about it, I think it may be possible to do this just by
>> adding a final paragraph to section 6 of the current policy:
> Shouldn't be this be part of section 8 as this is a criteria for CA
> operations (and its associated audits).
My apologies for the long delay in responding to your message. I am now
ready to take up this issue again, and hope to conclude it soon.
> After reading your proposal I would suggest alternatively the following:
>
> _Under section 7_ "We consider verification of certificate signing
> requests to be acceptable if it meets or exceeds the following
> requirements:"
>
> Add a fourth part with something like this:
<snip>
I agree that section 7 is a good place for this (since EV practices
primarily address the verification steps), and is perhaps better than
putting it in section 6 as I previously proposed.
> "for a certificate to be used for and marked as Extended Validation the
> CA complies with the "Guidelines for the Issuance and Management of
> Extended Validation Certificates, Version 1.0" (as modified by the
> erratum published by the CAB Forum), and have its compliance attested to
> in accordance with the requirements of Section J of that document."
>
> (As a by-note, I'm note sure the version number should be used and or
> include any future versions instead. Something like "Guidelines for the
> Issuance and Management of Extended Validation Certificates according to
> the most actual version as published by the CAB forum....")
After thinking about it, my proposal is to use the text as you give it,
except I would delete the "Version 1.0" reference. I'm not exactly sure
how to word a provision specifying use of any version, or the current
version as of the time of the CA's application, or whatever, so I'm not
going to try that approach.
One issue here is that the CAB Forum didn't version the URLs for the
guidelines and the erratum. I don't know if future versions of the
guidelines will have a different URL or not, so I thought the best
approach was to omit the version number and use the current URL for the
guidelines.
> _Under section 8_ "We consider the criteria for CA operations published
> in any of the following documents to be acceptable:"
>
> Add the criteria and guidelines for the Issuance and Management of
> Extended Validation Certificates as published by the CAB forum.
Your implication here is that the CAB Forum EV guidelines can be used as
stand-alone guidelines comparable to the other criteria referenced in
section 8 (WebTrust for CAs, ETSI TS 101 456 and 102 242, and ANSI
X9.79). I'm not convinced that this is in fact the case. In this
connection, note that the WebTrust for CAs EV Audit Criteria document is
explicitly characterized as a supplement to the base WebTrust for CAs
criteria, not as a replacement for or superset of the traditional
WebTrust for CAs criteria. (See for example sections 7-9 of the WebTrust
EV document.)
> (Obviously after performing an EV audit, this should allow to issue
> regular non-EV certificates as well.)
Again, the current WebTrust approach is to audit to both the traditional
WebTrust criteria and to the WebTrust EV criteria, either simultaneously
or separately.
Because I'm not convinced that the CAB Forum EV guidelines does or can
function as a standalone set of criteria for CAs, I'd like to omit
mentioning EV stuff in section 8 of the Mozilla CA policy, at least in
this version of the policy. We can revisit this question later once I
and/or others have a chance to do a detailed comparison of the EV
guidelines to the other criteria already referenced in the policy.
One possible approach would be to explicitly mention the WebTrust EV
criteria in section 8 as a supplement to the referenced WebTrust
criteria. We could do the same thing for the ETSI criteria if/when an EV
supplement document is created for those criteria. (IIRC someone is
looking to create something like this.)
However at least for now I'd prefer not to mention the WebTrust EV
criteria (or any other EV audit criteria) explicitly, for the reason
I've discussed before: The WebTrust EV audit criteria and any other EV
audit criteria are in effect incorporated by reference into section J of
the EV guidelines, and so don't really need to be separately referenced.
> Additionally I would like to see somewhere a disclaimer which would
> allow Mozilla in the future to accept alternative auditors other than
> the ones approved by the CAB forum for EV without the need to change the
> Mozilla CA policy again in order to allow that.
I don't think adding such a disclaimer really saves any work on our
part. If we included such a disclaimer then if we ever wanted to accept
alternative EV auditors we'd still have to have public discussion and
consensus on which auditors we'd accept -- most likely the exact same
discussion we'd have if we had to change the actual policy.
We have the freedom to set our own policy in any case, and all other
things being equal I'd prefer not to include such a disclaimer at this
time. I'd prefer to let the CAB Forum alternative auditor discussions go
forward and see where they lead. If the discussions don't go anywhere
then we can revisit the issue.
Frank
P.S. I've attached a new proposed patch to the CA policy document to bug
399214.
--
Frank Hecker
hec...@mozillafoundation.org
Eddy Nigg (StartCom Ltd.)
Frank Hecker wrote:
>
> My apologies for the long delay in responding to your message. I am now
> ready to take up this issue again, and hope to conclude it soon.
>
Relax, I'm kinda used to it from you ;-)
> I agree that section 7 is a good place for this (since EV practices
> primarily address the verification steps), and is perhaps better than
> putting it in section 6 as I previously proposed.
>
+1
>> _Under section 8_ "We consider the criteria for CA operations published
>> in any of the following documents to be acceptable:"
>>
>> Add the criteria and guidelines for the Issuance and Management of
>> Extended Validation Certificates as published by the CAB forum.
>>
>
> Your implication here is that the CAB Forum EV guidelines can be used as
> stand-alone guidelines comparable to the other criteria referenced in
> section 8 (WebTrust for CAs, ETSI TS 101 456 and 102 242, and ANSI
> X9.79). I'm not convinced that this is in fact the case. In this
> connection, note that the WebTrust for CAs EV Audit Criteria document is
> explicitly characterized as a supplement to the base WebTrust for CAs
> criteria, not as a replacement for or superset of the traditional
> WebTrust for CAs criteria. (See for example sections 7-9 of the WebTrust
> EV document.)
>
But doesn't it imply - in this case - an AICPA audit. To all of my
knowledge it does, hence my suggestion to add it as a valid criteria.
Also in your own words you say that it's a supplement and not a
replacement. In my opinion an EV audit *extends* the traditional
criteria and *implements* EV.
> Again, the current WebTrust approach is to audit to both the traditional
> WebTrust criteria and to the WebTrust EV criteria, either simultaneously
> or separately.
>
> Because I'm not convinced that the CAB Forum EV guidelines does or can
> function as a standalone set of criteria for CAs, I'd like to omit
> mentioning EV stuff in section 8 of the Mozilla CA policy, at least in
> this version of the policy. We can revisit this question later once I
> and/or others have a chance to do a detailed comparison of the EV
> guidelines to the other criteria already referenced in the policy.
>
OK
> One possible approach would be to explicitly mention the WebTrust EV
> criteria in section 8 as a supplement to the referenced WebTrust
> criteria.
Possibly an option, so this wasn't my point...
> We could do the same thing for the ETSI criteria if/when an EV
> supplement document is created for those criteria.
OK
>
> However at least for now I'd prefer not to mention the WebTrust EV
> criteria (or any other EV audit criteria) explicitly, for the reason
> I've discussed before: The WebTrust EV audit criteria and any other EV
> audit criteria are in effect incorporated by reference into section J of
> the EV guidelines, and so don't really need to be separately referenced.
>
Correct.
> I don't think adding such a disclaimer really saves any work on our
> part. If we included such a disclaimer then if we ever wanted to accept
> alternative EV auditors we'd still have to have public discussion and
> consensus on which auditors we'd accept -- most likely the exact same
> discussion we'd have if we had to change the actual policy.
>
No problem! Lets have the changes to the Mozilla CA policy done first
and continue with this later on...
> We have the freedom to set our own policy in any case, and all other
> things being equal I'd prefer not to include such a disclaimer at this
> time. I'd prefer to let the CAB Forum alternative auditor discussions go
> forward and see where they lead. If the discussions don't go anywhere
> then we can revisit the issue.
Agreed!
Frank Hecker
> Frank Hecker wrote:
>> Your implication here is that the CAB Forum EV guidelines can be used
>> as stand-alone guidelines comparable to the other criteria referenced
>> in section 8 (WebTrust for CAs, ETSI TS 101 456 and 102 242, and ANSI
>> X9.79). I'm not convinced that this is in fact the case. In this
>> connection, note that the WebTrust for CAs EV Audit Criteria document
>> is explicitly characterized as a supplement to the base WebTrust for
>> CAs criteria, not as a replacement for or superset of the traditional
>> WebTrust for CAs criteria. (See for example sections 7-9 of the
>> WebTrust EV document.)
>>
> But doesn't it imply - in this case - an AICPA audit. To all of my
> knowledge it does, hence my suggestion to add it as a valid criteria.
I think I understand what you mean here: Are you saying that the
WebTrust EV criteria in effect incorporate the traditional WebTrust
criteria by reference, since a WebTrust EV audit has as a prerequisite a
regular WebTrust for CAs audit?
This is a subtle point, and one that could be argued both ways IMO. The
relevant statement in the WebTrust EV document reads: "WT EV Audit
Guidelines are to be used only in conjunction with the Principles and
Criteria in the WebTrust Program for Certification Authorities. CAs that
wish to issue EV Certificates must first go through a WT audit and then
a WT EV audit." I don't read that language as implying "incorporation by
reference", but it is indeed clear that you can't have a WebTrust EV
audit without a WebTrust for CAs audit. (For example, it wouldn't make
sense to have an audit against ETSI TS 101 456 and then try to do a
WebTrust EV audit as a supplement to that; presumably no
WebTrust-authorized auditor would agree to do this.)
> Also in your own words you say that it's a supplement and not a
> replacement. In my opinion an EV audit *extends* the traditional
> criteria and *implements* EV.
I'd agree with that statement.
After thinking about it, if we want to reference the WebTrust EV
criteria in section 8, I think the best way to do this would be to add a
final item to the list in section 8 as follows:
We consider the criteria for CA operations published in any of the
following documents to be acceptable:
...
* "WebTrust for Certification Authorities - Extended Validation Audit
Criteria" in <a href="...">WebTrust for Certification Authorities -
Extended Validation Audit Criteria</a> (in conjunction with
"WebTrust Principles and Criteria for Certification Authorities")
(Note that the item in quotes is the relevant section within the
linked-to document of the same title. Compare this usage to other items
in the section 8 list.)
I think the above language clarifies that the WebTrust EV audit criteria
don't stand on their own but imply use of the standard WebTrust
criteria as well.
Your thoughts?
Eddy Nigg (StartCom Ltd.)
>> But doesn't it imply - in this case - an AICPA audit. To all of my
>> knowledge it does, hence my suggestion to add it as a valid criteria.
>>
>
> I think I understand what you mean here: Are you saying that the
> WebTrust EV criteria in effect incorporate the traditional WebTrust
> criteria by reference, since a WebTrust EV audit has as a prerequisite a
> regular WebTrust for CAs audit?
>
> This is a subtle point, and one that could be argued both ways IMO. The
> relevant statement in the WebTrust EV document reads: "WT EV Audit
> Guidelines are to be used only in conjunction with the Principles and
> Criteria in the WebTrust Program for Certification Authorities. CAs that
> wish to issue EV Certificates must first go through a WT audit and then
> a WT EV audit." I don't read that language as implying "incorporation by
> reference", but it is indeed clear that you can't have a WebTrust EV
> audit without a WebTrust for CAs audit. (For example, it wouldn't make
> sense to have an audit against ETSI TS 101 456 and then try to do a
> WebTrust EV audit as a supplement to that; presumably no
> WebTrust-authorized auditor would agree to do this.)
>
>
>> Also in your own words you say that it's a supplement and not a
>> replacement. In my opinion an EV audit *extends* the traditional
>> criteria and *implements* EV.
>>
>
> I'd agree with that statement.
>
> After thinking about it, if we want to reference the WebTrust EV
> criteria in section 8, I think the best way to do this would be to add a
> final item to the list in section 8 as follows:
>
> We consider the criteria for CA operations published in any of the
> following documents to be acceptable:
>
> ...
>
> * "WebTrust for Certification Authorities - Extended Validation Audit
> Criteria" in <a href="...">WebTrust for Certification Authorities -
> Extended Validation Audit Criteria</a> (in conjunction with
> "WebTrust Principles and Criteria for Certification Authorities")
>
> (Note that the item in quotes is the relevant section within the
> linked-to document of the same title. Compare this usage to other items
> in the section 8 list.)
>
> I think the above language clarifies that the WebTrust EV audit criteria
> don't stand on their own but imply use of the standard WebTrust
> criteria as well.
>
> Your thoughts?
>
Frank Hecker
> Frank Hecker wrote:
<snip>
>> WebTrust EV criteria in effect incorporate the traditional WebTrust
>> criteria by reference, since a WebTrust EV audit has as a prerequisite
>> a regular WebTrust for CAs audit?
>>
> Bingo!
OK, I think we're on the same page now.
>> I think the above language clarifies that the WebTrust EV audit
>> criteria don't stand on their own but imply use of the standard
>> WebTrust criteria as well.
>>
>> Your thoughts?
>>
> +1
I've gone ahead and attached a new proposed patch to bug 399214. Check
out the URL
http://hecker.org/private/index-ev3
to see what the resulting 1.1 policy would like.
Maybe I'm being optimistic, but I think we're getting closer to a final
1.1 version. If anyone has any further comments on the current draft
please post them.
Eddy Nigg (StartCom Ltd.)
> I've gone ahead and attached a new proposed patch to bug 399214. Check
> out the URL
>
> http://hecker.org/private/index-ev3
>
> to see what the resulting 1.1 policy would like.
>
> Maybe I'm being optimistic, but I think we're getting closer to a final
> 1.1 version. If anyone has any further comments on the current draft
> please post them.
>
section 14 another line for the purposes if the root (or a specific
intermediate root) should have the EV extension enabled when submitting
the request.
Frank Hecker
> section 14 another line for the purposes if the root (or a specific
> intermediate root) should have the EV extension enabled when submitting
> the request.
My apologies, I forgot about this. See my latest patch attached to bug
399214. Basically I added a new item in section 14 as follows:
14. ... The request should include the following:
...
* for each CA certificate requested for inclusion, whether the CA
issues Extended Validation certificates within the CA hierarchy
associated with the CA certificate and, if so, the EV policy OID
associated with the CA certificate;
The proposed patch also contains some other new changes, but this is the
only substantive one.
Incidentally, just to be clear on this, my understanding is there is no
EV certificate extension per se. The EV policy OID is just added as
separate metadata to be associated with the pre-loaded root CA
certificate; there is nothing in the CA certificate itself that is
specifically EV-related.
Eddy Nigg (StartCom Ltd.)
> The proposed patch also contains some other new changes, but this is the
> only substantive one.
>
> Incidentally, just to be clear on this, my understanding is there is no
> EV certificate extension per se. The EV policy OID is just added as
> separate metadata to be associated with the pre-loaded root CA
> certificate; there is nothing in the CA certificate itself that is
> specifically EV-related.
>
Frank Hecker
OK, absent any objections my plan is to go ahead and commit this change
later today or tomorrow. I submitted bug 399214 on October 9, so we've
had a month to discuss this issue and the proposed policy changes; based
on the results of those discussions I think we now have consensus on a
1.1 policy revision, and I want to finish this up so we can proceed to
invite CAs to submit requests for EV treatment for their CA certs.
Frank Hecker
> OK, absent any objections my plan is to go ahead and commit this change
> later today or tomorrow.
Done. The 1.1 release of the Mozilla CA certificate policy is now live
at the standard URL:
http://www.mozilla.org/projects/security/certs/policy/
Thanks to Eddy, Gerv, and Nelson for providing comments on this
revision, as well as to all the people who participated in the creation
of the original 1.0 policy.
Frank
P.S. to Nelson: I haven't forgotten about your suggestion to create a
companion document to the policy to provide more details about how to
submit requests, and answer any other questions that might be
unaddressed by the policy itself. Unfortunately right now I don't have
time to create such a document; hopefully I'll be able to come back to
this later in the month.
--
Frank Hecker
hec...@mozillafoundation.org