Certigna Root Inclusion Request
kathle...@yahoo.com
Certigna is the next request in the queue for public discussion.
Certigna (a French CA for the European market) has applied to add one
new root CA certificate to the Mozilla root store, as documented in
the following bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=393166
and in the pending certificates list here:
http://www.mozilla.org/projects/security/certs/pending/#Certigna%20of%20Dhimyotis
Summary of Information Gathered and Verified:
https://bugzilla.mozilla.org/attachment.cgi?id=359344
Some quick comments regarding noteworthy points:
* The Certigna root has three internally operated subordinated CA’s:
Certigna SSL is for SSL-enabled servers, Certigna ID is for
authentication and digitally-signed email, and Certigna Chiffrement is
for encrypting email.
* The CP documents are in French. English translations for relevant
sections have been provided and verified.
* Certigna has undergone audits by La Sécurité des Technologies de
l'Information (LSTI), a private certification body specializing in the
field of information security. The audits are current, and the audit
statement from 2008 has been verified.
This begins the one-week discussion period. After that week, I will
provide a summary of issues noted and action items. If there are no
outstanding issues, then this request can be approved for inclusion.
If there are outstanding issues or action items, then an additional
discussion may be needed as follow-up.
Kathleen Wilson
kathle...@yahoo.com
week now. No issues or concerns about this request have been raised.
According to https://wiki.mozilla.org/CA:How_to_apply
“If there are no open issues or action items after the first
discussion period, and there is general agreement that you comply with
our policy requirements, then at the Foundation's discretion the
second phase of public discussion may be skipped, the request will be
immediately approved, and the request will move into the inclusion
phase…”
If no issues or concerns are raised in the next couple of days, then I
will post the summary in the bug and request approval for inclusion.
Kathleen
Eddy Nigg
Kathleen, I request another few days if you allow.
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
Jabber: star...@startcom.org
Blog: https://blog.startcom.org
kathle...@yahoo.com
Eddy Nigg
> Of course. I will await your next post to this discussion.
>
Just browsing through the various documents and I noticed the following
so far.
It seems to me that the code signing bit *should not* be activated, it
should be reflected in the "Pending" page as well.
Email validation seems to me ambiguous at least and apparently not
defined in their CP/CPS. Neither is domain ownership/control validation
defined as I understand.
Repeated requests for translating the relevant parts have not been
complied. Comments in this respect (bug 393166, comment 15, d) ) have no
relevance to the question asked and your questions in comment 13 have
partly not been answered, in particular 2.d. Besides a general denial in
regards of problematic practices, no details have been provided. In
particular I couldn't find out for how long their certificates are valid
and how S/MIME certificates are provided to the subscriber ("We send the
certificate to the subscriber by mail").
Overall I think there is very little information available about this CA
(in English) and I'm hesitant to continue without a more thorough review
of critical aspects.
Eddy Nigg
> Eddy Nigg wrote, On 2009-02-09 11:54:
>> On 02/09/2009 09:35 PM, kathle...@yahoo.com:
>>> Of course. I will await your next post to this discussion.
>>>
>> Just browsing through the various documents and I noticed the following
>> so far.
>>
>> It seems to me that the code signing bit *should not* be activated, it
>> should be reflected in the "Pending" page as well.
>
>
Because their CPS doesn't define code signing.
Yannick LEPLARD
On 02/09/2009 09:35 PM, kathle...@yahoo.com:Of course. I will await your next post to this discussion.
Just browsing through the various documents and I noticed the following so far.
It seems to me that the code signing bit *should not* be activated, it should be reflected in the "Pending" page as well.
certificates, and it appears in our CP/CPS.
Email validation seems to me ambiguous at least and apparently not defined in their CP/CPS. Neither is domain ownership/control validation defined as I understand.
and in our CPS too.
Unfortunately, CPS are not published (they described internal technical and
organizational measurements)
RA operators must obtain guarantee than the e-mail address is owned by the
requester.
It's difficult in fact to make such controls. In practice the name of the
requester must appear in the left part of the e-mail address... If not, RA
operators are likely to get proof of possession (the request can be rejected
in case of doubt). For employees it's easier : the name of the suscriber and
domain name of the company can be easily checked.
Repeated requests for translating the relevant parts have not been complied. Comments in this respect (bug 393166, comment 15, d) ) have no relevance to the question asked and your questions in comment 13 have partly not been answered, in particular 2.d. Besides a general denial in regards of problematic practices, no details have been provided.
- Software private keys are generated on the suscriber computer with a
signed applet
- When the suscriber is using a smartcard, the private key is generated
onboard.
In particular I couldn't find out for how long their certificates are valid and how S/MIME certificates are provided to the subscriber ("We send the certificate to the subscriber by mail").
- S/MIME certificates are provided to the suscriber by email (not mail,
sorry). the suscriber must agree with the certificate and send a return
receipt with certificate eacceptance.
There is a signed applet for the suscriber to ask for a certificate, and to
install the issued certificate.
Overall I think there is very little information available about this CA (in English) and I'm hesitant to continue without a more thorough review of critical aspects.
On february 2009, the 5th, we obtain the compliance with PRIS/RGS for our
CAs ( and our CP, CPS are compliant with the exemplifications CP/CPS of
http://www.mozilla.org/projects/security/certs/pending/#DCSSI
)
( cf :
http://www.references.modernisation.gouv.fr/outil-de-suivi-des-qualification
s-et-des-referencements-des-offres-de-certificats
)
--
Regards
20, allée de la râperie
Ce mail est signé électroniquement grâce à un certificat Certigna. Il a valeur légale.
David E. Ross
>
> Le 9 févr. 09 à 20:54, Eddy Nigg a écrit :
>
You state ". . . CPS are not published . . . "
Repeatedly, the "WebTrust Program for Certification Authorities"
indicates that the CPS is PUBLISHED. This means it is made available to
the public, to both those who have certificates and those who trust
those certificates. If you were audited in conformance with WebTrust
criteria, how did you pass the audit without publishing your CPS?
--
David E. Ross
<http://www.rossde.com/>
Go to Mozdev at <http://www.mozdev.org/> for quick access to
extensions for Firefox, Thunderbird, SeaMonkey, and other
Mozilla-related applications. You can access Mozdev much
more quickly than you can Mozilla Add-Ons.
Eddy Nigg
>
> The initial comment was written on august 2008, and now we have code signing
> certificates, and it appears in our CP/CPS.
To my understanding the audit wasn't performed with those changes.
>
> Yes it is not defined in our CP but in our internal operational processes
> and in our CPS too.
> Unfortunately, CPS are not published (they described internal technical and
> organizational measurements)
This must be stated in the CPS and publicly disclosed. I'm sorry, but in
my opinion this is insufficient and will most likely not work.
> RA operators must obtain guarantee than the e-mail address is owned by the
> requester.
> It's difficult in fact to make such controls.
Email validation isn't too difficult to implement, however we have seen
various times that this isn't done sufficiently or correctly.
>
> - Software private keys are generated on the suscriber computer with a
> signed applet
This is interesting! Can you provide us some more information about this
applet? Can I test it somewhere?
>
> We are at the same level than the DCSSI CA that was approved a few days ago.
Each CA is looked at independently and each CA has its own CP/CPS, audit
etc.
Ian G
>> The initial comment was written on august 2008, and now we have code
>> signing
>> certificates, and it appears in our CP/CPS.
>
> To my understanding the audit wasn't performed with those changes.
In general terms, and without commenting at all on the current case,
here are a few observations. I think this is another area where there
is a misunderstanding as to the role of audit.
a. Time. There is always some element of change between the last audit
and current practice. Audits are "snapshots of the past" not proofs
over the present nor future. And, there is an expectation that audits
are repeated over time, the new guy has to have something to work with.
Also, factor in 40 week + distro delays, and consider asking CAs to
sit on their hands for a year or so.
b. The emphasis of the audit is over whether management has put in
place policies and procedures, sticks to them. Any check over
particular activities is not there to "audit those activities in
themselves" but to provide evidence of the policies and procedures in
general as a reliable guide to the reading public.
E.g., they do what they write, they write what they do.
d. Having said that, a specific audit criteria may state a check is
needed on X. One would have to go back and read WebTrust to see if it
has a criteria on X==codesigning. That still doesn't change the other
issues, but it may give you something to "rely" on when it comes to
codesigning specifically.
c. One of the policies and practices that audits look at is generally
whether CPSs and so forth are updated according to a reliable regime.
Of course, we can really only do that when we see that change is done,
so this is actually a positive chance for the next auditor to check the
progress. I say this with some relish, because extracting good evidence
is quite hard when most things are just written because the auditor says
it is needed, and then ignored forever more......
That's my view at the moment, I'm looking forward to others!
iang
Yannick LEPLARD
>
>>
>> We are at the same level than the DCSSI CA that was approved a few
>> days ago.
>
> Each CA is looked at independently and each CA has its own CP/CPS,
> audit etc.
>
I just wanted to explain that DCSSI is the french government CA,
and PRIS/RGS is the new highest level standard for french CAs.
It is ETSI TS 102 042 compliant, and ETSI 101 456 compliant for
qualified signing certificates.
Yannick LEPLARD
> You state ". . . CPS are not published . . . "
>
> Repeatedly, the "WebTrust Program for Certification Authorities"
> indicates that the CPS is PUBLISHED. This means it is made
> available to
> the public, to both those who have certificates and those who trust
> those certificates. If you were audited in conformance with WebTrust
> criteria, how did you pass the audit without publishing your CPS?
>
we have ETSI TS 102 042 audits and only CP have to be published.
Eddy Nigg
> a. Time. There is always some element of change between the last audit
> and current practice. Audits are "snapshots of the past" not proofs over
> the present nor future.
So far correct.
> And, there is an expectation that audits are
> repeated over time, the new guy has to have something to work with.
Correct, but it's not audited - whatever it is.
> Also, factor in 40 week + distro delays, and consider asking CAs to sit
> on their hands for a year or so.
No, did anybody suggest that and where?
> b. The emphasis of the audit is over whether management has put in place
> policies and procedures, sticks to them. Any check over particular
> activities is not there to "audit those activities in themselves" but to
> provide evidence of the policies and procedures in general as a reliable
> guide to the reading public.
No, that statement is basically bullshit :-)
Particular activities are audited including evidence of the specific
policies and procedures.
> d. Having said that, a specific audit criteria may state a check is
> needed on X. One would have to go back and read WebTrust to see if it
> has a criteria on X==codesigning. That still doesn't change the other
> issues, but it may give you something to "rely" on when it comes to
> codesigning specifically.
Wrong! If the CPS doesn't mention code signing than it's not audited. No
samples of those procedures are taken by the auditor either. Audits
pretty much confirm what the CA claims to do.
>
> That's my view at the moment, I'm looking forward to others!
>
Audits are very specific and you can forget about the "general"
references. As such we have precedence in this respect (in particular
code signing).
Frank Hecker
> Unfortunately, CPS are not published (they described internal technical and
> organizational measurements)
I acknowledge your comment that ETSI TS 102 042 does not require the CPS
to be published. However we depend on public documents to document the
exact claims that CAs make and whether these meet our policy
requirement. So this causes a problem for us when we do not have access
to CPSs and related documents.
If you cannot publish the CPS because it contains private information, I
suggest as an alternative that you provide some sort of official
Certigna document that summarizes the portions of the CPS that are of
most interest to us (i.e., those relating to validation of subcriber
information).
Frank
--
Frank Hecker
hec...@mozillafoundation.org
Frank Hecker
> On 02/10/2009 04:25 PM, Yannick LEPLARD:
>> RA operators must obtain guarantee than the e-mail address is owned by
>> the
>> requester.
>> It's difficult in fact to make such controls.
>
> Email validation isn't too difficult to implement, however we have seen
> various times that this isn't done sufficiently or correctly.
Note that the official Mozilla policy doesn't attempt to dictate exactly
what mechanisms a CA uses to verify ownership of email addresses, it
simply requires that "the CA takes reasonable measures" to verify this.
We can quibble about whether particular measures are "reasonable" or
not. However traditionally the major concerns we've had were with CAs
that did not have any CPS or CP language at all about verifying email
addresses.
Eddy Nigg
>> Email validation isn't too difficult to implement, however we have
>> seen various times that this isn't done sufficiently or correctly.
>
> Note that the official Mozilla policy doesn't attempt to dictate exactly
> what mechanisms a CA uses to verify ownership of email addresses, it
> simply requires that "the CA takes reasonable measures" to verify this.
Correct. I haven't attempted to dictate about how to do it, but we've
seen cases where it's not done at all.
However some (affected) CAs turned directly to me for advice in the past
concerning email validation and I provided my suggestions and advice.
Some of them might still be subscribed to this list btw.
David E. Ross
THANK YOU!! That was indeed the point of my earlier comment.
However, not only should they provide some alternative documentation but
also that documentation should be considered during the required audit.
Eddy Nigg
> If you cannot publish the CPS because it contains private information, I
> suggest as an alternative that you provide some sort of official
> Certigna document that summarizes the portions of the CPS that are of
> most interest to us (i.e., those relating to validation of subcriber
> information).
That would be a precedent too which I wouldn't recommend. We really want
to know what was audited, don't we?
Ian G
> I acknowledge your comment that ETSI TS 102 042 does not require the CPS
> to be published. However we depend on public documents to document the
> exact claims that CAs make and whether these meet our policy
> requirement. So this causes a problem for us when we do not have access
> to CPSs and related documents.
>
> If you cannot publish the CPS because it contains private information, I
> suggest as an alternative that you provide some sort of official
> Certigna document that summarizes the portions of the CPS that are of
> most interest to us (i.e., those relating to validation of subcriber
> information).
I had to re-read the policy and think about this a few times. Yes, I
think that is it.
The policy says, we need published information, *eg* the CPS.
Not, "CPS must be published." So there are two reasons not to enforce
publication of the CPS: one is that ETSI (allegedly) doesn't require
it. Another is that the CPS pretty much always has things in it like
"and then we use this private practices statement to achieve X." Or, it
doesn't say that, but either way, the auditor is faced with 2 sets of
documents, one of which is private, one public. Both valid and
verifiable. The auditor loves secret documents, that's bread & milk.
Then there are reasons to enforce publication. One is, we can only
verify -- as an *enduser* -- what we can read. Another is that an
"opinion" rendered over a secret document has to be taken with a large
dose of salt. Just exactly how much room is there for manoeuvre?
Given these complications, I think the policy is about right. It is
useful to promote publication of documents, it is quite useful to state
clearly that Mozilla only relies on public documents, and it is very
useful to state what information is needed.
But it is not particularly useful to try and draw a line in the sand
based on the title of some document.
iang
PS: with a nod to David's point that a new document provided (as an
extract?) might not be representative / outside an audit scope. Where
to draw the line?
Frank Hecker
> On 2/10/2009 12:06 PM, Frank Hecker wrote:
>> If you cannot publish the CPS because it contains private information, I
>> suggest as an alternative that you provide some sort of official
>> Certigna document that summarizes the portions of the CPS that are of
>> most interest to us (i.e., those relating to validation of subcriber
>> information).
> However, not only should they provide some alternative documentation but
> also that documentation should be considered during the required audit.
My assumption was that if the material in the document was based on the
CPS then it would have been covered in the audit, since presumably the
audit was based on what was in the CPS.
Frank Hecker
> On 02/10/2009 10:06 PM, Frank Hecker:
>> If you cannot publish the CPS because it contains private information, I
>> suggest as an alternative that you provide some sort of official
>> Certigna document that summarizes the portions of the CPS that are of
>> most interest to us (i.e., those relating to validation of subcriber
>> information).
>
> That would be a precedent too which I wouldn't recommend. We really want
> to know what was audited, don't we?
See my comment to David Ross.
Frank Hecker
> The policy says, we need published information, *eg* the CPS.
>
> Not, "CPS must be published."
Yes, exactly. We typically use the CPS and/or CP because almost all CAs
publish those documents; however there is no requirement that the
information published by the CA be in the form of a CPS or CP.
Speaking personally, I think think that it is good practice for CAs to
publish a CPS. If a CA has private information relating to detailed
internal processes that it does not wish to make public, I suggest that
it put such material in a separate "CA operations manual" that is
internal-only.
Eddy Nigg
>
> My assumption was that if the material in the document was based on the
> CPS then it would have been covered in the audit, since presumably the
> audit was based on what was in the CPS.
>
Well no, than any CA can write whatever it feels in such a document
which would be entirely non-binding and not audited. If you think that
to be sufficient I can send you also a few such documents and hide the
CPS away... :S
Eddy Nigg
> Ian G wrote:
>> The policy says, we need published information, *eg* the CPS.
>>
>> Not, "CPS must be published."
>
> Yes, exactly. We typically use the CPS and/or CP because almost all CAs
> publish those documents; however there is no requirement that the
> information published by the CA be in the form of a CPS or CP.
But it must have relevance to what was audited, no? If the document
wasn't an official and binding part of the audit, it shouldn't be used
in this context either I think. Nor shouldn't it be provided and
published after the audit was performed.
>
> Speaking personally, I think think that it is good practice for CAs to
> publish a CPS. If a CA has private information relating to detailed
> internal processes that it does not wish to make public, I suggest that
> it put such material in a separate "CA operations manual" that is
> internal-only.
That's of course what CAs usually do. They disclose those procedures to
the auditor, but not publicly. WebTrust has a defined set of criterion
about what exactly needs to be disclosed publicly. In this respect I
question the usefulness of the ETSI audit criteria and I
suggest/recommend to make the publishing of the CPS a requirement in the
Mozilla CA policy. I assumed wrongly that this is a requirement by the
audit criterion which Mozilla accepts.
Frank Hecker
> Well no, than any CA can write whatever it feels in such a document
> which would be entirely non-binding and not audited.
Yes in theory, but I'm not convinced that this is a real risk in
practice. In the past we've had several cases where we've accepted
public statements by CAs that went beyond what was in their CPS or CP.
In some cases these were clarifications of CP/CPS langusge, in other
cases they covered stuff that was not in the CP or CPS at all. In a
number of cases the CAs updated (or committed to update) their CP/CPS to
reflect their supplementary statements, and for purposes of our
evaluation we accepted the statements in advance of their actually
completing an audit against the new CPS.
So, again, I'm not prepared to make a blanket statement that we must
always have a published CPS and cannot rely on documents apart from the CPS.
pascal...@gmail.com
> Eddy Nigg wrote:
> > On 02/10/2009 10:06 PM, Frank Hecker:
> >> If you cannot publish the CPS because it contains private information, I
> >> suggest as an alternative that you provide some sort of official
> >> most interest to us (i.e., those relating to validation of subcriber
> >> information).
>
> > That would be a precedent too which I wouldn't recommend. We really want
> > to know what was audited, don't we?
>
> See my comment to David Ross.
>
> Frank
>
> --
> Frank Hecker
> hec...@mozillafoundation.org
I don't really understand what's the matter This CA has obtained ETSI
TS 102042 certification from LSTI. I've found the information at
http://www.lsti-certification.fr/index.php?option=com_content&view=article&id=55&Itemid=15
This company has an agreement from COFRAC the official french
committee of accreditation.
The COFRAC has published an audit guide for CA audits. So, I suppose
that these auditors have done their job according to this guide which
is in my opinion very exhaustive.
So I wonder why some people here want to investigate so deeply...
Pascal MERLIN
Consultant en sécurité
www.auditiel.fr
Eddy Nigg
> Yes in theory, but I'm not convinced that this is a real risk in
> practice. In the past we've had several cases where we've accepted
> public statements by CAs that went beyond what was in their CPS or CP.
> In some cases these were clarifications of CP/CPS langusge, in other
> cases they covered stuff that was not in the CP or CPS at all.
Clarifications I think yes. Something which isn't in the CPS must be
easily verifiable, something critical and not covered in the CPS is in
my opinion not sufficient.
> In a
> number of cases the CAs updated (or committed to update) their CP/CPS to
> reflect their supplementary statements, and for purposes of our
> evaluation we accepted the statements in advance of their actually
> completing an audit against the new CPS.
Yes, also this is in my opinion sufficient, but there are some problems.
First Mozilla hasn't been on record to follow up - neither on EV nor on
other matters. Second we need to draw a clear line here...I believe that
CAs weren't approved generally if they couldn't demonstrate clearly
through their published CPS and audit statements compliance to the
Mozilla CA policy. Some CAs were sent back to the drawing board for
fixing. I believe this case isn't any different.
>
> So, again, I'm not prepared to make a blanket statement that we must
> always have a published CPS and cannot rely on documents apart from the
> CPS.
>
Yes, everything within reasons. But that should be established during
information gathering and perhaps receive your approval prior to
arriving here. It should be disclosed during the presentation statement
at the list and such a document shouldn't be provided AFTER it gets to
the comments and review week here. This clearly means, there is no audit
behind it, it would be just hot air.
Ian G
OK, I made some changes on the wiki and added these words:
https://wiki.mozilla.org/CA:Recommended_Practices#Recommended_practices
# .... (we rely on public documents only).
# If you do not publish the CP/CPS (not recommended), you will need
to publish an extract that summarizes the portions that are of most
interest to us.
This only reflects my understanding of the situation. Also, I recognise
that the words on the wiki already almost nailed it, so we are in danger
of bureaucratic freefall... Hack away...
iang
David E. Ross
If the information is critical for determining whether a CA's root
should be in the certificate store, then the document should be audited.
In the case at hand, the issue is whether the root should be enabled
for E-mail validation. Because that issue is addressed in the CPS,
which we cannot see, we don't have any way to judge if the E-mail bit
should be enabled.
With an unaudited supplemental document, we would have no assurance that
Certigna operates in compliance with that document. We should either
see an audit statement for the supplemental document or a certification
from the auditor or other trusted outside party that the document
substantially echoes the audited CPS.
--
David E. Ross
<http://www.rossde.com/>.
Don't ask "Why is there road rage?" Instead, ask
"Why NOT Road Rage?" or "Why Is There No Such
Thing as Fast Enough?"
<http://www.rossde.com/roadrage.html>
David E. Ross
This would then tie into the later section:
* CAs should supply evidence of their being evaluated according to one
or more of the criteria accepted as suitable per the Mozilla policy.
. . .
* All documents supplied as evidence should be publicly
available.
However, the last sentence should be modified to say:
* All documents supplied as evidence should be publicly available and
must be addressed in any audit.
I don't have (don't want) an account to update the Wiki.
Yannick LEPLARD
> If the information is critical for determining whether a CA's root
> should be in the certificate store, then the document should be
> audited.
> In the case at hand, the issue is whether the root should be enabled
> for E-mail validation. Because that issue is addressed in the CPS,
> which we cannot see, we don't have any way to judge if the E-mail bit
> should be enabled.
>
> With an unaudited supplemental document, we would have no assurance
> that
> Certigna operates in compliance with that document. We should either
> see an audit statement for the supplemental document or a
> certification
> from the auditor or other trusted outside party that the document
> substantially echoes the audited CPS.
>
> --
So What should we do ?
Should we ask our auditor a certified document about our practices for
e-mail validation ?
Yannick LEPLARD
Directeur R&D
Dhimyotis S.A.
Eddy Nigg
>
> OK, I made some changes on the wiki and added these words:
>
> https://wiki.mozilla.org/CA:Recommended_Practices#Recommended_practices
>
> # .... (we rely on public documents only).
> # If you do not publish the CP/CPS (not recommended), you will need to
> publish an extract that summarizes the portions that are of most
> interest to us.
>
First of all I think we should edit this document only after some sort
of agreement here. I think we haven't finished discussion concerning
this issue yet, can you hold back for a minute?
Eddy Nigg
> However, the last sentence should be modified to say:
>
> * All documents supplied as evidence should be publicly available and
> must be addressed in any audit.
>
> I don't have (don't want) an account to update the Wiki.
>
I agree on this definition. Is there anybody objecting to it? (I can
update the page accordingly).
Eddy Nigg
>
> If the information is critical for determining whether a CA's root
> should be in the certificate store, then the document should be audited.
> In the case at hand, the issue is whether the root should be enabled
> for E-mail validation. Because that issue is addressed in the CPS,
> which we cannot see, we don't have any way to judge if the E-mail bit
> should be enabled.
David, it's my understanding that it effects all validations, Email, DV
and code. Code is even more problematic as no definition exists in the
CP either.
Eddy Nigg
> So What should we do ?
> Should we ask our auditor a certified document about our practices for
> e-mail validation ?
Yannick, what are the chances to publish the CPS? Please note that all
CAs which have been included into Mozilla NSS during the last few years
published their CPS, this is common practice.
Ian G
> On 02/11/2009 07:12 PM, David E. Ross:
>> However, the last sentence should be modified to say:
>>
>> * All documents supplied as evidence should be publicly available and
>> must be addressed in any audit.
>>
>> I don't have (don't want) an account to update the Wiki.
>>
>
> I agree on this definition. Is there anybody objecting to it? (I can
> update the page accordingly).
>
I object.
All documents supplied to Mozilla is within a Mozilla context.
Audit does an audit context. The two are different. Don't mix them;
most all audits are done according to defined audit criteria, such as
WebTrust or ETSI or DRC.
Asking an auditor to sign off on random documents that have nothing to
do with the criteria, the audit world and the direct process raises
questions. I would claim that no (or few) auditors to date has been
asked to verify a CA according to Mozilla review.
If you want "evidence" quality documents then ask for a notary?
iang
PS: I for one would definately champion rewriting the WebTrust process
but this is not the way to do it.
Kyle Hamilton
What we need is an opinion (hey! using your own terminology, Ian,
that means AUDIT, and thus AUDITOR) that the document substantially
reflects the CP/CPS. If not an auditor, who would you suggest to do
it, given that a notary isn't authoritative for opinions other than on
the signer having shown identity?
I think the entire CA approval process is completely FUBARed. I think
Mozilla has managed to paint itself into a corner from which people
like Ian will not let it escape, and has thus been bullied and
intimidated into accepting things into its root program that are
analytically damaging to the PKI and the pursuit of commerce to be
enabled by it. I also believe that it has allowed "commerce" to
define its operations and criteria for far too long.
-Kyle H
On Wed, Feb 11, 2009 at 3:37 PM, Ian G <ia...@iang.org> wrote:
> On 11/2/09 21:29, Eddy Nigg wrote:
>>
>> On 02/11/2009 07:12 PM, David E. Ross:
>>>
>>> However, the last sentence should be modified to say:
>>>
>>> * All documents supplied as evidence should be publicly available and
>>> must be addressed in any audit.
>>>
>>> I don't have (don't want) an account to update the Wiki.
>>>
>>
>> I agree on this definition. Is there anybody objecting to it? (I can
>> update the page accordingly).
>>
>
>
> I object.
>
> All documents supplied to Mozilla is within a Mozilla context.
>
> Audit does an audit context. The two are different. Don't mix them; most
> all audits are done according to defined audit criteria, such as WebTrust or
> ETSI or DRC.
>
> Asking an auditor to sign off on random documents that have nothing to do
> with the criteria, the audit world and the direct process raises questions.
> I would claim that no (or few) auditors to date has been asked to verify a
> CA according to Mozilla review.
>
> If you want "evidence" quality documents then ask for a notary?
>
> iang
>
>
>
> PS: I for one would definately champion rewriting the WebTrust process but
> this is not the way to do it.
> --
> dev-tech-crypto mailing list
> dev-tec...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-crypto
>
Eddy Nigg
> I object.
OK, then back to square one.
>
> All documents supplied to Mozilla is within a Mozilla context.
Huuu?
>
> Audit does an audit context. The two are different. Don't mix them; most
> all audits are done according to defined audit criteria, such as
> WebTrust or ETSI or DRC.
Yes, and Mozilla relies on them, period.
>
> Asking an auditor to sign off on random documents that have nothing to
> do with the criteria, the audit world and the direct process raises
> questions.
Right, that's why CAs MUST publish their CPS.
> I would claim that no (or few) auditors to date has been
> asked to verify a CA according to Mozilla review.
Not "Mozilla Review", but if we want to facilitate other documents
beyond CSP than I have no problem accepting them if an auditor agrees to
confirm those documents. It's really not our problem.
>
> If you want "evidence" quality documents then ask for a notary?
No, what has that to do with it?
> PS: I for one would definately champion rewriting the WebTrust process
> but this is not the way to do it.
PS: PS: Why not? Go for it. Talk to them.
Ian G
> A notary does not verify content, a notary verifies identity.
Actually I meant a notary rather than a notary public, but the
difference is moot.
> What we need is an opinion (hey! using your own terminology, Ian,
> that means AUDIT, and thus AUDITOR) that the document substantially
> reflects the CP/CPS. If not an auditor, who would you suggest to do
> it, given that a notary isn't authoritative for opinions other than
> on the signer having shown identity?
Right, that's on the other point. It would be entirely valid to ask for
the AUDITOR to attest (or otherwise) that the extract "substantially" or
otherwise reflected the CPS, *iff* one were that concerned.
(I would not be that paranoid, and I claim you will get a better system
if you don't demand a priori audit opinion over this document. The
ground breaking work in this was done by Rothschild & Stiglitz, 1976,
and the latter shared in the nobel prize awarded for asymmetric markets
for the consequent rewriting of two industries around their work on
declarations.)
However, the statement originally suggested goes far further, it says
*all documents*.
> I think the entire CA approval process is completely FUBARed.
Well, Ok, we may share some drinks on that. I'd prefer to say it is a
good starting point for a better system, but your more blunt description
will win you more friends !
> I think Mozilla has managed to paint itself into a corner from which
> people like Ian will not let it escape, and has thus been bullied
> and intimidated into accepting things into its root program that are
> analytically damaging to the PKI and the pursuit of commerce to be
> enabled by it. I also believe that it has allowed "commerce" to
> define its operations and criteria for far too long.
I'd agree with ... some of that :) I also wonder what you mean by
"commerce" ... but more drinks required.
iang
Ian G
> On 02/12/2009 01:37 AM, Ian G:
>> Audit does an audit context. The two are different. Don't mix them; most
>> all audits are done according to defined audit criteria, such as
>> WebTrust or ETSI or DRC.
>
> Yes, and Mozilla relies on them, period.
Yes, it's just another relying party to an audit opinion, just like any
other user. This means it gets to read the opinion.
It doesn't get to stipulate any conditions. (Maybe it should, that's
another story.) Imagining conditions doesn't help.
>> Asking an auditor to sign off on random documents that have nothing to
>> do with the criteria, the audit world and the direct process raises
>> questions.
>
> Right, that's why CAs MUST publish their CPS.
I agree this whole thing would go away if all CAs published their CPSs.
But reasons have been outlined why this is not the case, and Mozilla
(/Frank) has decided that's OK.
It's their review, as you mentioned above.
>> I would claim that no (or few) auditors to date has been
>> asked to verify a CA according to Mozilla review.
>
> Not "Mozilla Review", but if we want to facilitate other documents
> beyond CSP than I have no problem accepting them if an auditor agrees to
> confirm those documents. It's really not our problem.
Well, that depends on our metrics of success and efficiency. For my
part, I think it good to hold down costs and only add burden where there
is a commensurate benefit.
If a CA provides a document, there is no commensurate benefit in asking
the auditor to play notary for them. Indeed, there is a benefit in
asking them to provide documents "as is" knowing that a future auditor
can read the submissions and verify the claims made. And, as those
provided documents are there and form part of the public record, there
is plenty of scope for later verification.
>> PS: I for one would definately champion rewriting the WebTrust process
>> but this is not the way to do it.
>
> PS: PS: Why not? Go for it. Talk to them.
lol.... I see you also have a copy of OSS's sabotage manual :)
iang
Eddy Nigg
> ...and has thus been bullied and
> intimidated into accepting things into its root program that are
> analytically damaging to the PKI
I believe - and that's another reason why I'm here, that this can be
reversed and improved. It requires some work and we've came already
close in the past to actually achieve some results.
> enabled by it. I also believe that it has allowed "commerce" to
> define its operations and criteria for far too long.
Commerce or not, here is another interesting one:
https://bugzilla.mozilla.org/show_bug.cgi?id=477783
Yannick LEPLARD
discussion phase.
It sounds like Mozilla's discussion "how to evaluate the CAs /
changes to do in the benchmarks " rather than a Certigna discussion.
We asked for inclusion in Mozilla on 2007 (august).
Mozilla agrees with ETSI 102 042 (like Apple and Microsoft. We are in
these two systems).
There was a long technical verification phase made by three people :
Gervase Markham, Frank Hecker, and Kathleen Wilson.
And now, it seems to be a reconsideration of ETSI 102 042.
About CP /CPS :
I think a public CP and a audit of compliance with a reference norm
(like ETSI, WebTrust, ... ) provide garantees to third party.
CPS and other internal documents are checked by auditors (and they
control that the company do what is written !).
They contain know-how of the company (technical and organizational
measurements), and don't have to be published.
Yannick LEPLARD
Directeur R&D
Eddy Nigg
> First of all, i would like to express my astonishment about the
> discussion phase.
> It sounds like Mozilla's discussion "how to evaluate the CAs / changes
> to do in the benchmarks " rather than a Certigna discussion.
Yes, unfortunately we make the mistake again and again by not changing
the subject line when discussing (un)related issues. However this is a
discussion group as compared to Bugzilla.
> There was a long technical verification phase made by three people :
> Gervase Markham, Frank Hecker, and Kathleen Wilson.
> And now, it seems to be a reconsideration of ETSI 102 042.
No, only Kathleen has reviewed and gathered the information about your
CA. Unfortunately there was a backlog which Mozilla is now working up.
The issue at hand is not the audit criteria of ETSI per se, but the
disclosure of your practices. I think this is the first time that a CA
wasn't willing to disclose the practice statement.
>
> About CP /CPS :
> I think a public CP and a audit of compliance with a reference norm
> (like ETSI, WebTrust, ... ) provide garantees to third party.
> CPS and other internal documents are checked by auditors (and they
> control that the company do what is written !).
Right, and in order to judge what your CA is doing we would like to know
about it. Please note that WebTrust requires public disclosure of the
practices.
> They contain know-how of the company (technical and organizational
> measurements), and don't have to be published.
Well, considering that the top 20 CAs all disclosed their practices, I
can't see which know-how you are trying to protect, but if you are doing
something completly different than all the others than it's perhaps
reason more to know about it.
Please also note that ETSI doesn't require particular validation methods
upon which we can be assumed that you are compliant to the Mozilla CA
policy. And I really wonder if you didn't had to disclose the CPS to
Microsoft as well.
Frank Hecker
> On 02/11/2009 07:19 PM, Yannick LEPLARD:
>> So What should we do ?
>> Should we ask our auditor a certified document about our practices for
>> e-mail validation ?
>
> Yannick, what are the chances to publish the CPS? Please note that all
> CAs which have been included into Mozilla NSS during the last few years
> published their CPS, this is common practice.
To add to Eddy's question: If there is Certigna-confidential information
in the CPS that is not relevant to the questions we have, you could
publish a version of the CPS with the confidential material redacted [1].
Another alternative is to publish just those portions of the CPS that
address the question of email verification, and have your auditor
confirm to us that the section(s) in question are from the CPS that was
referenced in your audit.
Frank
[1] For anyone interested, the US National Security Agency has published
a useful set of guidelines for how to properly redact Microsoft Work
documents published as PDF files:
http://www.fas.org/sgp/othergov/dod/nsa-redact.pdf
--
Frank Hecker
hec...@mozillafoundation.org
Yannick LEPLARD
> Another alternative is to publish just those portions of the CPS
> that address the question of email verification, and have your
> auditor confirm to us that the section(s) in question are from the
> CPS that was referenced in your audit.
>
> Frank
This is a good alternative for us. If everybody agree with, we can
send you the fair portion of CPS in english and our auditor will
confirm you the genuineness of the document.
( I think our CPS is not very different from others, but it refers to
a lot of internal documents. )
Yannick LEPLARD
Directeur R&D
Eddy Nigg
>
> This is a good alternative for us. If everybody agree with, we can send
> you the fair portion of CPS in english and our auditor will confirm you
> the genuineness of the document.
>
In my opinion this would solve the problem. I would like to request that
the auditor confirms that their audit statement confirms the exact
extracts of the CPS. I also would like to request to include all
relevant bits for domain control validation in addition to email.
Additionally if code signing was part of the CPS during your audit, also
the bits relating to code signing.
Ian G
> On 02/11/2009 06:43 PM, Ian G:
>>
>
> First of all I think we should edit this document only after some sort
> of agreement here. I think we haven't finished discussion concerning
> this issue yet, can you hold back for a minute?
Nope. It's a wiki; and there have been frequent invitations to add
comments and help. We can all add comments, and we can collect points
of agreement that exist. Nothing on the wiki is binding, afaik.
One clarified point is collected there, but even it is changeable.
Also, point of order: there is no established way to agree and disagree
in this forum, so "we agreeing here" is a statement that lacks agreement :)
As I understand it, it is Mozilla's review, taken with public
consultation, not the other way around.
Once the CA desk decides that is how it is, after consultation, that's
how it is. Frank held the line against requiring publication, and I for
one will support that against the steamrolling. If Mozilla changes its
mind on this point, that is fine; it's their review.
Mozilla and endusers take on the liability, we don't.
iang
Eddy Nigg
>> First of all I think we should edit this document only after some sort
>> of agreement here. I think we haven't finished discussion concerning
>> this issue yet, can you hold back for a minute?
>
>
> Nope. It's a wiki;
It's a wiki because that's the media Frank decided would be best
suitable for the task.
> and we can collect points of agreement that exist.
Yes, this is very correct: "points of agreement that exist"
> Nothing on the wiki is binding, afaik.
These pages serve as a basis for Kathleen's work and were mostly agreed
upon here.
> Also, point of order: there is no established way to agree and disagree
> in this forum, so "we agreeing here" is a statement that lacks agreement :)
Well, when needed, Frank has made the call. Not everything I proposed
here was agreed upon as far as I can tell.
> As I understand it, it is Mozilla's review, taken with public
> consultation, not the other way around.
Absolutely.
> Once the CA desk decides that is how it is, after consultation, that's
> how it is. Frank held the line against requiring publication, and I for
> one will support that against the steamrolling.
But there were calls made by David and me (others would perhaps join)
that in the absence of a published CPS, any information provided instead
of the lacking CPS must be confirmed by the auditor. If I understand
Franks position, this is exactly what he proposed as well in the
Certigna case. So we have agreement.
Now, do we really need a discussion about how to agree? Feel free, but
we should use our energy and time for other efforts, like reviewing the
next CA in the queue.
Ian G
> On 02/12/2009 09:11 PM, Ian G:
>> Once the CA desk decides that is how it is, after consultation, that's
>> how it is. Frank held the line against requiring publication, and I for
>> one will support that against the steamrolling.
>
> But there were calls made by David and me (others would perhaps join)
> that in the absence of a published CPS, any information provided instead
> of the lacking CPS must be confirmed by the auditor.
Yes, calls exist for that.
> If I understand
> Franks position, this is exactly what he proposed as well in the
> Certigna case. So we have agreement.
No, firstly, David suggested this:
* All documents supplied as evidence should be publicly available and
must be addressed in any audit.
So that is an expansion from "extracts confirmed by auditor" to "re-do
the audit if anything is missing, at least over that document."
Secondly, Frank proposed two alternatives, one of which would require
auditor confirmation.
Hence, my other email posting the various nuances available, and my
comment about using the auditor as notary (in the European concept not
the anglo sense).
So where I see Frank's proposal is something like the below, pt 2.
> Now, do we really need a discussion about how to agree? Feel free, but
> we should use our energy and time for other efforts, like reviewing the
> next CA in the queue.
Yes, browbeating. One writes longer than everyone else, and changes or
forgets the points of the opposition. One wins statistically, short
term, but loses reputation over the long run. It's very costly in
everyone's time.
Then, let's call a halt to discussion and refer the alternatives to Frank:
1. * All documents supplied as evidence should be publicly available
and must be addressed in any audit.
2. * Any substantial ommissions submitted afterwards may need to be
confirmed by auditor, at Mozilla's discretion.
3. Or?
iang
Ben Bucksch
> On 11/2/09 21:26, Eddy Nigg wrote:
>> On 02/11/2009 06:43 PM, Ian G:
>>>
>>> OK, I made some changes on the wiki....
For reference, Ian added, and Eddy reverted:
(old text)
The CP/CPS should be publicly available from the CA's official web site
(added text)
(we rely on public documents only).
If you do not publish the CP/CPS (not recommended), you will need to
publish an extract that summarizes the portions that are of most
interest to us.
>> First of all I think we should edit this document only after some sort
>> of agreement here. I think we haven't finished discussion concerning
>> this issue yet, can you hold back for a minute?
>
>
> Nope.
Ian, I also disagree with your change. CPS IMHO must be public, period.
It's important for "Relying parties". The CPS is the only thing that
shows what the CA actually does and warrants to relying parties.
Even more so must the "recommended practices" be that it's public.
I agree with Eddy's revert, and disagree that you just unilaterally
change the recommended practices to the worse, be it a wiki or not.
Ben
Ben Bucksch
> Ian, I also disagree with your change. CPS IMHO must be public,
> period. It's important for "Relying parties". The CPS is the only
> thing that shows what the CA actually does and warrants to relying
> parties.
> Even more so must the "recommended practices" be that it's public.
>
> I agree with Eddy's revert, and disagree that you just unilaterally
> change the recommended practices to the worse, be it a wiki or not.
Correction: I see that Frank doesn't want to require the CPS be public.
As I said, I disagree.
But even if we don't *require* it, it doesn't mean we shouldn't
*recommend* publishing it.
Ian G
> For reference, Ian added, and Eddy reverted:
>
> (old text)
> The CP/CPS should be publicly available from the CA's official web site
> (added text)
> (we rely on public documents only).
> If you do not publish the CP/CPS (not recommended), you will need to
> publish an extract that summarizes the portions that are of most
> interest to us.
Fine, whatever. Neither text makes the publication of the CPS
obligatory, so they are both "accurate" and we are just quibbling about
the marketing of points of view, and how much info we give to the poor
Europeans. This is not worth a wiki war...
>>> First of all I think we should edit this document only after some sort
>>> of agreement here. I think we haven't finished discussion concerning
>>> this issue yet, can you hold back for a minute?
>>
>>
>> Nope.
>
> Ian, I also disagree with your change. CPS IMHO must be public, period.
> It's important for "Relying parties". The CPS is the only thing that
> shows what the CA actually does and warrants to relying parties.
> Even more so must the "recommended practices" be that it's public.
I agree that it is bad and/or annoying.
But it isn't me that sets the criteria, it is in this case ETSI, and the
*policy* clearly says that ETSI is acceptable, and apparently ETSI say
non-publication is ok. So you either have to take it up with ETSI (good
luck) or you have to add a new policy or practices point which says that
regardless of ETSI, the CPS must be published.
> I agree with Eddy's revert, and disagree that you just unilaterally
> change the recommended practices to the worse, be it a wiki or not.
!
Then, you wrote:
> Correction: I see that Frank doesn't want to
> require the CPS be public.
> As I said, I disagree.
> But even if we don't *require* it, it doesn't mean we shouldn't
> *recommend* publishing it.
On that I agree! I recommend that almost all documents be published,
frequently and loudly. Exceptions have to be justified *and documented*.
I would dearly love to see full disclosure here, as a principle. In
both Mozilla's CA business, and in Mozilla in the large. But we've got
no chance of getting that through so it's not even worth talking about.
iang
Eddy Nigg
> 1. * All documents supplied as evidence should be publicly available and
> must be addressed in any audit.
>
> 2. * Any substantial ommissions submitted afterwards may need to be
> confirmed by auditor, at Mozilla's discretion.
Keeping replies short, #1 and #2 sound fine to me.
Eddy Nigg
> But it isn't me that sets the criteria, it is in this case ETSI, and the
> *policy* clearly says that ETSI is acceptable, and apparently ETSI say
> non-publication is ok. So you either have to take it up with ETSI (good
> luck) or you have to add a new policy or practices point which says that
> regardless of ETSI, the CPS must be published.
I suggest Frank reconsiders this as well. I'm in favor to requiring
publishing the CPS regardless of what ETSI has to say. It would make
everything a lot easier on Mozilla's part and it's accepted practice
really.
On the other hand we can live with alternative and confirmed information
too, I'm not sure if it's worth the effort though.
Ben Bucksch
> But it isn't me that sets the criteria, it is in this case ETSI, and
> the *policy* clearly says that ETSI is acceptable, and apparently ETSI
> say non-publication is ok.
FWIW, this is irrelevant. *We* require the ETSI. We can also require
additional requirements, like that the CPS is published.
> or you have to add a new policy or practices point which says that
> regardless of ETSI, the CPS must be published.
It already states:
"6. We require that all CAs whose certificates are distributed with our
software products:
...
* publicly disclose information about their policies and business
practices (e.g., in a Certificate Policy and Certification Practice
Statement);"
"14. To request that its certificate(s) be added to the default set a CA
should submit a formal request by submitting a bug report
<https://bugzilla.mozilla.org/enter_bug.cgi?product=mozilla.org&component=CA%20Certificates>
into the mozilla.org Bugzilla system ...
...
* a Certificate Policy and Certification Practice Statement (or links to
a CP and CPS) /or/ equivalent disclosure document(s) for the CA or CAs
in question; /and/"
To me, that reads that the CPS (or whatever other document publishes the
practices, no matter how it's called, therefore the "equivalent"
wording) *must* be public.
kathle...@yahoo.com
discussion is as follows.
A publicly available document that is evaluated as part of the annual
audit needs to be provided, and it must include information that
satisfies section 7, parts a, b, and c of the Mozilla CA Certificate
Policy at http://www.mozilla.org/projects/security/certs/policy/.
This document also needs to address the potentially problematic
practices as per https://wiki.mozilla.org/CA:Problematic_Practices.
Certigna’s CPS contains sensitive information that cannot be posted
publicly at this time. As such, the following possible solutions are
recommended:
1) Publish a version of the CPS with the confidential material
redacted.
2) Publish just those portions of the CPS that address the items noted
above, and have your auditor confirm to us that the sections provided
are from the CPS that was referenced in your audit.
This concludes the first public discussion about Certigna’s request to
add one new root CA certificate to the Mozilla root store. This
summary of action items will also be posted in the bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=393166
Eddy Nigg
Kathleen, can you re-post this summary once again but under the subject
"Re: Certigna Root Inclusion Request"? By mistake you posted it under a
different thread and subject. Thanks a lot!
Eddy Nigg
>
> FWIW, this is irrelevant. *We* require the ETSI. We can also require
> additional requirements, like that the CPS is published.
>
>> or you have to add a new policy or practices point which says that
>> regardless of ETSI, the CPS must be published.
>
> It already states:
> "6. We require that all CAs whose certificates are distributed with our
> software products:
> ...
> * publicly disclose information about their policies and business
> practices (e.g., in a Certificate Policy and Certification Practice
> Statement);"
>
> "14. To request that its certificate(s) be added to the default set a CA
> should submit a formal request by submitting a bug report
> <https://bugzilla.mozilla.org/enter_bug.cgi?product=mozilla.org&component=CA%20Certificates>
> into the mozilla.org Bugzilla system ...
> ...
> * a Certificate Policy and Certification Practice Statement (or links to
> a CP and CPS) /or/ equivalent disclosure document(s) for the CA or CAs
> in question; /and/"
>
> To me, that reads that the CPS (or whatever other document publishes the
> practices, no matter how it's called, therefore the "equivalent"
> wording) *must* be public.
Re-reading once again, I think you are right! Putting into question if
it's called CPS or otherwise is really nit-picking!
"publicly disclose information about their policies and business
practices" clearly says what it's meant to be, call it however you want.
The audit requirement makes the context also clear. It's what we
expected really.
Hence I think too that the Mozilla CA policy is clear in its
requirements in this respect.
Ben Bucksch
> Certigna’s CPS contains sensitive information that cannot be posted
> publicly at this time. As such, the following possible solutions are
> recommended:
> 1) Publish a version of the CPS with the confidential material
> redacted.
>
Yeah, that's fine, assuming "confidential material" refers to things
other CAs don't publish in their CPS'.
kathle...@yahoo.com
discussion is as follows.
A publicly available document that is evaluated as part of the annual
audit needs to be provided, and it must include information that
satisfies section 7, parts a, b, and c of the Mozilla CA Certificate
Policy at http://www.mozilla.org/projects/security/certs/policy/.
This document also needs to address the potentially problematic
practices as per https://wiki.mozilla.org/CA:Problematic_Practices.
Certigna’s CPS contains sensitive information that cannot be posted
publicly at this time. As such, the following possible solutions are
recommended:
1) Publish a version of the CPS with the confidential material
redacted.
Frank Hecker
> The summary of the action items resulting from this first public
> discussion is as follows.
>
> A publicly available document that is evaluated as part of the annual
> audit needs to be provided, and it must include information that
> satisfies section 7, parts a, b, and c of the Mozilla CA Certificate
> Policy at http://www.mozilla.org/projects/security/certs/policy/.
> This document also needs to address the potentially problematic
> practices as per https://wiki.mozilla.org/CA:Problematic_Practices.
>
>
> Certigna’s CPS contains sensitive information that cannot be posted
> publicly at this time. As such, the following possible solutions are
> recommended:
> 1) Publish a version of the CPS with the confidential material
> redacted.
> 2) Publish just those portions of the CPS that address the items
> noted
> above, and have your auditor confirm to us that the sections provided
> are from the CPS that was referenced in your audit.
Kathleen, as I understand it, Yannick Leplard of Certigna has proposed
doing option 2 above, and that would be acceptable to us as far as I'm
concerned.
Frank
--
Frank Hecker
hec...@mozillafoundation.org
Frank Hecker
>> Another alternative is to publish just those portions of the CPS that
>> address the question of email verification, and have your auditor
>> confirm to us that the section(s) in question are from the CPS that
>> was referenced in your audit.
>>
>> Frank
>
> This is a good alternative for us. If everybody agree with, we can send
> you the fair portion of CPS in english and our auditor will confirm you
> the genuineness of the document.
To repeat what I wrote elsewhere: This plan is acceptable to us.
Fran
--
Frank Hecker
hec...@mozillafoundation.org
Yannick LEPLARD
Le 14 févr. 09 à 15:09, Frank Hecker a écrit :
We are working on the translation and we make contact with the auditor.
David E. Ross
The key point is that whatever CA policy and practices documents satisfy
the Mozilla policy must be addressed in the CA's audit.
--
David E. Ross
<http://www.rossde.com/>
Go to Mozdev at <http://www.mozdev.org/> for quick access to
extensions for Firefox, Thunderbird, SeaMonkey, and other
Mozilla-related applications. You can access Mozdev much
more quickly than you can Mozilla Add-Ons.
Ian G
This is a big hole in the current regime. How this is addressed will
probably require a lot of discussion.
Meta-comment: It would be nice if we could jot down these issues as
they arise, perhaps on the wiki at CA:. Does anyone know what page they
should go on? I looked and could not find anything suitable. Or should
we just create a page under something like CA:FuturePolicyNotes ?
(The rest of the above text raises another point to be discussed, the
possible tightening up of the language to better state what has to be
published.)
iang