SECOM Trust EV root inclusion request
Frank Hecker
the list for public comment is SECOM Trust, which has applied to add a
new root CA certificate to the Mozilla root store and enable it for EV,
as documented in the following bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=394419
and in the pending certificates list here:
http://www.mozilla.org/projects/security/certs/pending/#SECOM%20Trust
Note that SECOM Trust has one (non-EV) root already in the Mozilla root
list; this is for a new root created specifically for EV use.
Some quick comments regarding noteworthy points:
* Like some other CAs, SECOM Trust has cross-signed its EV root using
its existing root. However the plan is to EV-enable only the EV root,
leaving the existing root as is. This is consistent with the approach
we've taken in other cases, and as far as I know this should work fine
in terms of EV certificate recognition.
* SECOM Trust doesn't currently support OCSP. OCSP is not (yet)
mandatory for EV, so this is not an issue from a policy perspective.
IIRC this will not pose a technical problem either, as long as EV certs
issued by SECOM Trust don't have an AIA extension with OCSP URL.
* SECOM Trust had one caveat on their EV audit, having to do with their
not performing certain background checks on staff. As noted in Kathleen
Wilson's summary document (attached to the bug), this is apparently a
side-effect of Japanese laws and regulations, and not a substantive problem.
I suggest reading Kathleen's summary document to get an overview of this
request; thanks again to Kathleen for preparing these!
For this request and subsequent requests I'm going to adopt a suggestion
made by Eddy a little while back: Rather than having a two-week
discussion period divided into two phases, I'm going to have a single
one-week discussion period. After that week, if there are no outstanding
issues relating to the request then I am going to go ahead and
officially approve it.
However if there are outstanding issues that in my opinion are relevant,
then I'm going to postpone further consideration of the request. This
will allow time to try to get the issues resolved, after which we can
start a new public discussion period.
Frank
--
Frank Hecker
hec...@mozillafoundation.org
Rob Stradling
<snip>
> * SECOM Trust doesn't currently support OCSP. OCSP is not (yet)
> mandatory for EV, so this is not an issue from a policy perspective.
> IIRC this will not pose a technical problem either, as long as EV certs
> issued by SECOM Trust don't have an AIA extension with OCSP URL.
That assumes that https://bugzilla.mozilla.org/show_bug.cgi?id=413997 will not
be implemented before such time as SECOM Trust do start to support OCSP.
> * SECOM Trust had one caveat on their EV audit, having to do with their
> not performing certain background checks on staff. As noted in Kathleen
> Wilson's summary document (attached to the bug), this is apparently a
> side-effect of Japanese laws and regulations, and not a substantive
> problem.
>
> I suggest reading Kathleen's summary document to get an overview of this
> request; thanks again to Kathleen for preparing these!
>
> For this request and subsequent requests I'm going to adopt a suggestion
> made by Eddy a little while back: Rather than having a two-week
> discussion period divided into two phases, I'm going to have a single
> one-week discussion period. After that week, if there are no outstanding
> issues relating to the request then I am going to go ahead and
> officially approve it.
>
> However if there are outstanding issues that in my opinion are relevant,
> then I'm going to postpone further consideration of the request. This
> will allow time to try to get the issues resolved, after which we can
> start a new public discussion period.
>
> Frank
--
Rob Stradling
Senior Research & Development Scientist
Comodo - Creating Trust Online
Office Tel: +44.(0)1274.730505
Fax Europe: +44.(0)1274.730909
www.comodo.com
Comodo CA Limited, Registered in England No. 04058690
Registered Office:
3rd Floor, 26 Office Village, Exchange Quay,
Trafford Road, Salford, Manchester M5 3EQ
This e-mail and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed.
If you have received this email in error please notify the sender by replying
to the e-mail containing this attachment. Replies to this email may be
monitored by Comodo for operational or business reasons. Whilst every
endeavour is taken to ensure that e-mails are free from viruses, no liability
can be accepted and the recipient is requested to use their own virus checking
software.
Eddy Nigg
>
> * SECOM Trust had one caveat on their EV audit, having to do with their
> not performing certain background checks on staff. As noted in Kathleen
> Wilson's summary document (attached to the bug), this is apparently a
> side-effect of Japanese laws and regulations, and not a substantive
> problem.
>
Frank, it's not clear to me why their audit report is secret. One report
from 2007 is posted at bugzilla, an updated one isn't. Why is that?
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
Jabber: star...@startcom.org
Blog: https://blog.startcom.org
Frank Hecker
> Frank, it's not clear to me why their audit report is secret. One report
> from 2007 is posted at bugzilla, an updated one isn't. Why is that?
There was apparently some sort of mix-up between the SECOM Trust folks
and Kathleen and me regarding getting the latest audit report; they
thought they had sent us something, but we apparently didn't get it.
Kathleen is going to try to straighten it out.
Frank Hecker
> There was apparently some sort of mix-up between the SECOM Trust folks
> and Kathleen and me regarding getting the latest audit report; they
> thought they had sent us something, but we apparently didn't get it.
> Kathleen is going to try to straighten it out.
As it turns out, the latest WebTrust report for SECOM Trust (for 2008)
is actually available from the WebTrust site [1]:
http://cert.webtrust.org/SealFile?seal=816&file=pdf
That leaves the WebTrust EV report. To my knowledge WebTrust still isn't
publishing EV reports at the official site, so we'll have to get that
separately.
Frank
[1] I find it annoying that WebTrust doesn't publish an index of
reports, so periodically I run a script to download all "sealfile" files
from the site by number; that's how I found this one just now.
--
Frank Hecker
hec...@mozillafoundation.org
Eddy Nigg
> then I'm going to postpone further consideration of the request. This
> will allow time to try to get the issues resolved, after which we can
> start a new public discussion period.
>
Besides the audit report (and the OCSP issue Rob mentioned) it's a
little bit hard to review the CP/CSP of this CA ;-)
Considering that this is a root for EV certificates only (and I hope
this is indeed the case and no other certificates will be issued from
this root), I think that we can rely on the audit report solemnly,
without being able to read the CP/CPS.
Are there any guaranties that this root will be used only for EV? Is
this what the audit report(s) confirm? Are we able to review the audit
report or is the non-disclosure clause acceptable? Besides that I still
don't understand from where this comes from really...Frank, any suggestions?
Frank Hecker
> As it turns out, the latest WebTrust report for SECOM Trust (for 2008)
> is actually available from the WebTrust site [1]:
>
> http://cert.webtrust.org/SealFile?seal=816&file=pdf
My mistake. This report is for SECOM Trust.net Root1 CA (ValiCert Class
1 Policy Validation CA) and Security Communication Root1 CA, the two
SECOM Trust roots that are already included in Mozilla. So the report is
not relevant to this particular request, but at least it does tell us
that SECOM Trust has a current WebTrust audit for its existing roots.
I am currently working with SECOM Trust to determine the status of the
reports for Security Communication EV RootCA1, which is the new EV root
that SECOM Trust is requesting to be included (per bug 394419). I will
post more information as I have it.
Frank Hecker
> I am currently working with SECOM Trust to determine the status of the
> reports for Security Communication EV RootCA1, which is the new EV root
> that SECOM Trust is requesting to be included (per bug 394419). I will
> post more information as I have it.
OK, I now have more information. SECOM Trust has provided me copies of
their current WebTrust for CAs audit report and WebTrust EV audit report
for Security Communication EV Root CA1. (Incidentally, the delay on this
was because both Kathleen and I were having problems with
over-aggressive spam filters causing problems with our receiving email
messages from SECOM Trust. SECOM Trust actually sent us the reports some
time ago, but we didn't notice.)
Both reports are in English, are dated October 31, 2008, and cover the
period from June 9, 2007, to June 8, 2008. The auditor for both reports
is PricewaterhouseCoopers Aarata <http://www.pwcaarata.or.jp/>. The
reports are perfectly in order, with no issues noted in terms of SECOM
Trust's operation. Based on these reports, it appears that SECOM Trust
fulfills the requirements of our Mozilla policy for CAs that want to
have their roots included and EV-enabled.
Unfortunately I cannot post these reports on the public Bugzilla site.
As I understand it, the situation is that the Japanese Institute of
Certified Public Accountants (JICPA), the organization overseeing the
WebTrust program in Japan, has not yet issued guidance to Japanese
WebTrust auditors regarding how WebTrust EV reports are to be handled.
(This may be related to the fact that the WebTrust.org site does not yet
publish EV reports.) In the absence of such guidance PWC Aarata has
asked SECOM Trust to limit dissemination of these two reports to
official representatives of vendors participating in the CA/Browser
Forum, and the reports themselves have a condition to that effect.
As far as I am concerned there is nothing whatsoever in these reports
that is sensitive information, that is embarrassing to SECOM Trust or
PWC Aarata, or that is otherwise unsuitable for public view. The reports
are similar to (and to a large extent word-for-word identical to) other
WebTrust for CAs reports or WebTrust EV reports that we've seen for
other CAs. I personally think that JICPA and/or PWC Aarata are being
overly cautious with regard to dissemination of these reports [1], and I
encourage them to change their policies.
Normally we require audit reports to be public, in accordance with our
Mozilla CA certificate policy. However I've made an exception to this
requirement at least once in the past, and I'm going to make an
exception again in this case. SECOM Trust did not cause this situation,
and I am not going to penalize them for it. I am personally vouching for
the contents of these reports, and I'd be glad to have Kathleen Wilson
and/or Gen Kanai of Mozilla Japan (who also have copies of the reports)
do so as well.
However since we received the reports from SECOM Trust and not from PWC
Aarata, we do need to verify that they are indeed genuine reports, just
as we have done for other WebTrust reports that were published on the
WebTrust.org site. Kathleen will be working with Gen to do that final
verification.
I'm going to be making a decision on SECOM Trust's request before the
end of the day on Friday, December 12. However because of the mix-up
over the audit reports and the need to do verification of their
genuineness, it's likely that I'll just make a preliminary decision and
postpone a final decision until sometime next week.
Frank
[1] I also think that the people running the WebTrust program may come
in for some blame here. It is now over a year since the WebTrust EV
criteria were finalized and WebTrust-authorized auditors have been doing
WebTrust EV audits, and apparently there are still no procedures to get
EV reports published at the WebTrust.org web site. (At least, I've never
seen an EV report at webtrust.org.) If I recall correctly, one goal of
the EV guidelines and the associated WebTrust EV criteria was to
increase confidence in CAs and the SSL certificates they issue. In my
opinion that goal is not furthered (to put it mildly) if WebTrust EV
reports are treated as semi-private documents that are not generally
available to the public at large.
--
Frank Hecker
hec...@mozillafoundation.org
Frank Hecker
> However since we received the reports from SECOM Trust and not from PWC
> Aarata, we do need to verify that they are indeed genuine reports, just
> as we have done for other WebTrust reports that were published on the
> WebTrust.org site.
I meant to write, "just as we have done for other WebTrust reports that
were *not* published on the WebTrust.org site".
Kyle Hamilton
extremely stupid answer), but why can't the companies involved ask the
auditors to send the reports out to the vendors that they have
relationships with, which would provide a direct means of verifying
that the documents presented are indeed authentic?
(Note that this is not a critique of your decision in how to handle
this situation, and I do agree with your waiving of the public-audit
requirement in this case, and also agree with your personal decision
to encourage them to change their policies. Furthermore, I think that
this is an issue that should be brought to the folks in charge for a
vote on organizational approval of this encouragement, if this is not
something that you can speak for Mozilla on; if it is, I think that
you should subtly strengthen that 'I encourage them to' to 'the
Mozilla Foundation encourages them to'.)
-Kyle H
> _______________________________________________
> dev-tech-crypto mailing list
> dev-tec...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-crypto
>
Frank Hecker
> Erm... this might be a very stupid question (or it might have an
> extremely stupid answer), but why can't the companies involved ask the
> auditors to send the reports out to the vendors that they have
> relationships with, which would provide a direct means of verifying
> that the documents presented are indeed authentic?
They could, but usually it's the CAs we deal with directly (because
they're the ones making the request), not the auditors, and usually the
CAs send us the reports first. So usually we end up following up with
the auditors to confirm that the reports are genuine.
You do make a good point though: in cases where the reports are not
publicly available, we can ask the CA up front to have them sent by
their auditor(s). I've added that to the "how to apply" document:
https://wiki.mozilla.org/CA:How_to_apply
> (Furthermore, I think that
> this is an issue that should be brought to the folks in charge for a
> vote on organizational approval of this encouragement, if this is not
> something that you can speak for Mozilla on; if it is, I think that
> you should subtly strengthen that 'I encourage them to' to 'the
> Mozilla Foundation encourages them to'.)
Good point. I can speak for the Mozilla Foundation on this, so CAs
should indeed consider my previous comments as "The Mozilla Foundation
encourages them..."
Ian G
> Erm... this might be a very stupid question (or it might have an
> extremely stupid answer), but why can't the companies involved ask the
> auditors to send the reports out to the vendors that they have
> relationships with, which would provide a direct means of verifying
> that the documents presented are indeed authentic?
Not a stupid question; there is no easy answer.
The problem is partly the structure. In CA audits, the CA requests the
audit of the auditor. So the CA is the paying body, and the CA
specifies the criteria and purpose, and is the body to whom the audit is
delivered.
In other auditing contexts, the audit is commissioned by a 3rd party for
their benefit. I think CC works this way. If it were done this way,
Mozilla would commission the audit, for its benefit, and would receive
the report.
In the practical sense, I think Frank has solved it in the How To, point 4.
It does rather underscore the oddity of the situation. The audit report
says very little, it is quite boilerplate. So Mozilla is depending very
heavily on the presence of the auditor, and not on the report itself.
Along those lines, it would make more sense if Mozilla requested the
audit directly of the auditor, and then specified what was interesting
to Mozilla, and got a report on its interesting aspects.
(I'm not proposing such a drastic change, just a though experiment.)
iang
Ian G
> Frank Hecker wrote:
> over-aggressive spam filters....
(hmm, hesitation... I had noticed over-busyness, but perhaps I should
resend some recent emails?)
...
> ... I'm going to make an
> exception again in this case.
...
> However since we received the reports from SECOM Trust and not from PWC
> Aarata, we do need to verify that they are indeed genuine reports,...
Looks like a good judgement call to me.
iang
Frank Hecker
> On 12/12/08 04:56, Frank Hecker wrote:
>> Frank Hecker wrote:
>> over-aggressive spam filters....
>
> (hmm, hesitation... I had noticed over-busyness, but perhaps I should
> resend some recent emails?)
No, I got your (and others') emails (only SECOM Trust had problems).
It's just busyness on my part. Unfortunately I've been able to respond
in depth to only 1 out of every 5-10 things posted on this forum and
sent to me via email.
Frank Hecker
> Considering that this is a root for EV certificates only (and I hope
> this is indeed the case and no other certificates will be issued from
> this root),
Per comment #15 of bug 394419 and the CA hierarchy diagram submitted by
SECOM Trust and attached to the bug, Security Communication EV RootCA1
(the root at issue here) is being used only for EV SSL certificates. It
has a single subordinate CA, SECOM Passport for Web EV CA (also operated
by SECOM Trust), that is the actual issuing CA.
SECOM Trust has another root (Security Communication RootCA1, no "EV")
already in Mozilla, so they have no need to use this new root for non-EV
SSL certificates. Per comment #15, SECOM Trust may consider using the
new root for other purposes in the future, e.g., object signing
certificates. If they want to do that at some point then they will need
to submit a new request. The current request is to enable the new root
for SSL use only.
Note that I have in fact reviewed various sections of the CPS and CP,
using Google Translate. I didn't see anything in them that was
inconsistent with what I've written above.
Eddy Nigg
Excellent!
Ian G
> Note that I have in fact reviewed various sections of the CPS and CP,
> using Google Translate. I didn't see anything in them that was
> inconsistent with what I've written above.
I find this fascinating. According to the policy, this works.
(Let me be clear: according to the what I see, SECOM passes muster, and
I am not commenting on them. This is comments on the wider scope of
things, and Mozilla's regime.)
But it seems to raise some questions (or emphasise ones made earlier).
I think there is a solution, but first to ramble some.
We can only see the document through the eyes of Google Translate. I'm
well aware of that tool, I use it all the time for documents, and it
isn't what I would call "reliable". "IMHO."
Which leaves us with a google-eye-view and a boilerplate audit report.
Well, ok: It leaves the *non-japanese-reader* with that. And it leaves
Mozilla's due diligence with that.
Switching to userland, my decision to rely on such a cert is based on
what? Nothing, because it is all in japanese or legalese? Or, it is
based on Mozo's DD, which was ... based on not much more.
Which leads to the first easy fix: insist that all non-english CAs
translate all their docs. Then I can read the CPS! I personally am
unsatisfied at that, I see flaws.
1. Frank has made the case for regional and local CAs. The web is
wide, and CPSs are very long documents. So I think translating *all*
important documents to english is not only impractical but also
discriminatory, as non-english cultures (most of them) will then face a
barrier that the english do not do not.
2. OTOH, we do have a Mozilla policy (unwritten perhaps) that all CAs
are the same. So I as end-user do not need to read the CPS in order to
pursue my dodgy trade, mozo did this for me... Whether we agree with
the substance of it or not, Mozo has to act as if it were true, because
it takes on such a heavy load in due diligence, and the UI does its best
to hide any DD info from the user. Which leaves only Mozo needing to
review the translated documents .... and only it? I can't see this
scaling either because of the next point.
3. CPSs are dynamic, or should be dynamic. OK, that's not quite true,
but it is true that threats are dynamic, and therefore security models
should be dynamic, and CPSs should respond alike. If one is really
interested in security, one would be unimpressed by controlled
translations, because the result would be static security (c.f., Boyd).
As I see it, mass translation doesn't scale.
A possible solution is an open end-user offer. I have before mentioned
that each CA should have a relying party agreement or similar; something
on offer to the mozo end-user. It should be the minimum, or default, or
entry-level document for the end-user. It should apply even if the user
never saw it, like an open source licence. It should set liabilities
between CA and end-user.
Now, if such a document were written by each CA, that would be a
*reasonable* target for translation. Indeed, it may work for mozo to say:
* you must have an end-user offer or RPA or similar
* it should be short and sweet and plain language
* it must have a reliable translation in english or be in english
* it must set a liability limit
* it must be prominent, easily available, unmistakable
CAs generally have these already, they are about 3 pages, they are not
impossible to read, and they don't change much. No real drama for
translation.
If such a thing existed in Mozo's policy, it would probably sweep away a
lot of the woes circling around the above situation.
iang
Frank Hecker
> A possible solution is an open end-user offer. I have before mentioned
> that each CA should have a relying party agreement or similar; something
> on offer to the mozo end-user. It should be the minimum, or default, or
> entry-level document for the end-user. It should apply even if the user
> never saw it, like an open source licence. It should set liabilities
> between CA and end-user.
It sounds like you're referring to something like a PKI Disclosure
Statement idea that's been discussed in the past:
http://www.verisign.com/repository/pds.txt
Some CAs do indeed have these, but not all.
Eddy Nigg
> 2. OTOH, we do have a Mozilla policy (unwritten perhaps) that all CAs
> are the same.
This is correct to the extend that all CAs must conform to the minimum
requirements of the Mozilla CA policy. This is the lowest denominator of
all CAs.
> It should apply even if the user
> never saw it, like an open source licence. It should set liabilities
> between CA and end-user.
To some extend this is common practice and relying party obligations are
usually limited to what the software does anyway already (e.g. check
expiration, revocation etc.)
> If such a thing existed in Mozo's policy, it would probably sweep away a
> lot of the woes circling around the above situation.
For the evaluation of CAs I don't think that's sufficient, however as
Frank already suggested, for the RP a statement in the form of the
proposed PKI Disclosure Statement could be very useful.
Ian G
> Ian G wrote:
>
>> A possible solution is an open end-user offer. I have before mentioned
>> that each CA should have a relying party agreement or similar;
>> something on offer to the mozo end-user. It should be the minimum, or
>> default, or entry-level document for the end-user. It should apply
>> even if the user never saw it, like an open source licence. It should
>> set liabilities between CA and end-user.
>
> It sounds like you're referring to something like a PKI Disclosure
> Statement idea that's been discussed in the past:
>
> http://www.verisign.com/repository/pds.txt
Heading in the right direction, because that is a simple and readable
document.
But the emphasis is different. That document asks for a mini-CPS.
What I am thinking is more like the RPA ("relying party agreements"),
already found on most CAs sites. This is not a PKI document but a legal
document, and a business document. This is what the lawyer wants to
see. The lawyers forced it on the CAs, not the PKI people.
> Some CAs do indeed have these, but not all.
There are three reasons I would not propose it.
1. it seems to have a bug: everything is a SHALL which means if you
don't like one section, you don't do the document, at all. This was
probably unintended.)
2. it includes things that should not be there, as below.
3. it is emphasising PKI not legal relationships.
(actually they are all related, maybe the same bug.)
The reason for doing an RPA is that it draws a straight line from the
end-user to the CA, for all the parties and stakeholders, and especially
the lawyers. Right now, there is a connection, but no reliable map, and
anyone can walk the path, but in many different ways. What we need is a
route map. The RPA is that; an RPA lists the primary route.
Which explicitly removes the vendor from the primary route. Which
addresses the issue of due diligence with unreadable CPSs.
iang
PS: more explanatory notes:
The offer I have in my mind includes (roughly compared to that RFC's
fields):
Name, URL of the CA, whatever for a legal offer.
The disclaimer on liabilities, warranties, indemnities, etc.
Applicable law + forum of dispute resolution
Maybe no more than that? Again from the RFC, it would be optional to
include:
Certificate type: likely all are covered
Statement on Reliance, if so, how, etc.
Information & status checking obligations
Including these things would depend heavily on ones views on PKI. And
these things would be definately wrong:
subscribers: they have another agreement.
Applicable agreements: irrelevant, there is only this one.
privacy policy: the end-user's privacy is not at issue
Refund policy: the end-user didn't pay a buck.
Especially, this last one:
CA and repository licenses, trust marks, and audit
is exactly the thing that is not wanted in an RPA or end user offer.
That's guaranteed to sent your legal cousel into paroxyms...
All the existing RPAs I have skimmed match this view. There is nothing
novel about this; we just need to appreciate it and make it clear that
this is the standard approach in the legal perspective of CAs.
https://www.verisign.com/repository/rpa.html
(I hate to pick on Verisign, but their RPA is the best one for
explanatory purposes. It's clear, short, easy to read, and there are
reasons to believe it is the state of the art in legal perspectives.)
Frank Hecker
> Which leads to the first easy fix: insist that all non-english CAs
> translate all their docs. Then I can read the CPS! I personally am
> unsatisfied at that, I see flaws.
>
> 1. Frank has made the case for regional and local CAs. The web is
> wide, and CPSs are very long documents. So I think translating *all*
> important documents to english is not only impractical but also
> discriminatory, as non-english cultures (most of them) will then face a
> barrier that the english do not do not.
I'll differ from you somewhat here. As a practical matter browser
vendors are a major audience for a CA's CPS, along with the CA's
auditor, possibly government agencies concerned with the CA's
operations, and whoever else might care to read it. I can understand a
CA issuing its CPS in the native language of the country in which it
operates; that's probably the best strategy to make sure the document is
properly understood by relevant government agencies and by its auditors
(if they're local).
However if a CA doesn't offer an English translation of its CPS and
other relevant documents then it disadvantages browser vendors and other
application software vendors who might be interested in supporting use
of the CA's certificates. I don't support making it mandatory that CAs
provide an English version of the CPS, but I have no problem with
telling CAs that not having an English version will likely cause delays
with their application.
István Zsolt BERTA
Perhaps, making such (discriminatory) criteria mandatory could still
be better than enforcing it without stating it clearly.
Our CA (Microsec Ltd, a leading CA in Hungary) submitted its inclusion
request February 2007.
https://bugzilla.mozilla.org/show_bug.cgi?id=370505
Our first public discussion phase was opened October 2008,
http://groups.google.com/group/mozilla.dev.tech.crypto/browse_thread/thread/416427a350db11a9#
this public discussion has been postponed, scheduled again and it seem
to be postponed again. I think, only the language of our documentation
remains the only open issue today.
Had we known that in order to be accepted to Mozilla, we MUST/SHOULD
submit either an English translation of our CPS/CPSs or we need to
maintain our complete documentation in English, perhaps we would have
made different decisions in the past two years. Our primary focus are
electronic signatures; browsers and SSL certificates are a marginal
issue for us. While submitting the English translation of a snapshot
of our documentation may be impractical and costly, maintaining a
complete documentation both in English and in Hungarian is a major
investment that shall perhaps never be justified.
Had we known that English documentation is a requirement, we could
have chosen to fulfill it by submitting a translation, we could have
sought other way to sell certificates accepted by Mozilla, or we could
have decided to forget about the Mozilla-inclusion-issue and to advise
the Hungarian public to use Explorer instead. Mozilla has the right to
determine the requirements for including CAs, but if this is a
requirement, then why it is not stated, why it is not public?
Being a long-term Mozilla fan, I am really sorry to say that the same
procedure at Microsoft was faster, much better defined, less ad hoc,
and a lot more transparent.
Regards,
István
Eddy Nigg
>
> Had we known that English documentation is a requirement, we could
> have chosen to fulfill it by submitting a translation, we could have
> sought other way to sell certificates accepted by Mozilla, or we could
> have decided to forget about the Mozilla-inclusion-issue and to advise
> the Hungarian public to use Explorer instead. Mozilla has the right to
> determine the requirements for including CAs, but if this is a
> requirement, then why it is not stated, why it is not public?
>
István, even though I understand your frustration and agree with the
basic understanding that requirements should be published accordingly, I
also must state there has been at least one issue (notably with your
OCSP responder I think) in addition to our inability simply not to be
able to read the CP/CPS. As more and more CAs from Non-English speaking
countries are applying for inclusion, Mozilla will have to find a
solution (in this or the other way). Please note that many CAs from such
countries publish their CP/CPS in English, sometimes in addition to
their native language. This is in my opinion expected behavior and
practice in this industry - specially if the CA is supposed to be
included in a product used to be world-wide and hence the relying parties.
> Being a long-term Mozilla fan, I am really sorry to say that the same
> procedure at Microsoft was faster, much better defined, less ad hoc,
> and a lot more transparent.
Agreed, Microsoft is a professional company which doesn't involve any
input from a community as with Mozilla. But how did they verify and
understand your CP/CPS? Did they rely solemnly on the audit report? Does
your OCSP responder not present a problem to them?
Ian G
>> I'll differ from you somewhat here. As a practical matter browser
>> vendors are a major audience for a CA's CPS, along with the CA's
>> auditor, possibly government agencies concerned with the CA's
>> operations, and whoever else might care to read it. I can understand
>> a CA issuing its CPS in the native language of the country in which
>> it operates; that's probably the best strategy to make sure the
>> document is properly understood by relevant government agencies and
>> by its auditors (if they're local).
(I agree with that!)
>> However if a CA doesn't offer an English translation of its CPS and
>> other relevant documents then it disadvantages browser vendors and
>> other application software vendors who might be interested in
>> supporting use of the CA's certificates. I don't support making it
>> mandatory that CAs provide an English version of the CPS, but I have
>> no problem with telling CAs that not having an English version will
>> likely cause delays with their application.
(And I can't disagree with that!)
On to István's comments:
> Perhaps, making such (discriminatory) criteria mandatory could still
> be better than enforcing it without stating it clearly.
I don't think this criteria exists. I for one would not like it. But,
there is, IMO, a need for something, and something short and simple was
what I was exploring.
I would point out that all my comments are aimed at the future. I
wouldn't want to slow down any current contender. You seem to meet the
rules and practices, so no need to dwell on this.
> Being a long-term Mozilla fan, I am really sorry to say that the same
> procedure at Microsoft was faster, much better defined, less ad hoc,
> and a lot more transparent.
OK! I think I for one would really like to hear a summary of that. I'm
not trying to stir the pot, just wondering whether there is any way to
improve the current Mozilla process, either up or down.
iang
István Zsolt BERTA
> basic understanding that requirements should be published
> accordingly, I also must state there has been at least one issue
> (notably with your OCSP responder I think) in addition to our
I think the OCSP issue has been resolved: As I recall, on the short
run it does not cause problems with the current release of Firefox.
However, we accepted your arguments, we made some changes in our
systems and promised further changes in the future, so that it shall
not cause problems on the long run either.
> inability simply not to be able to read the CP/CPS. As more and more
> CAs from Non-English speaking countries are applying for inclusion,
> Mozilla will have to find a solution (in this or the other way).
> Please note that many CAs from such countries publish their CP/CPS in
> English, sometimes in addition to their native language. This is in
> my opinion expected behavior and practice in this industry -
> specially if the CA is supposed to be included in a product used to
> be world-wide and hence the relying parties.
I may accept this statement, but if there is such a requirement, it
should be stated in advance.
If there is no such requirement, it should not hinder the process, but
there should be defined ways to resolve this issue.
>> Being a long-term Mozilla fan, I am really sorry to say that the
>> same procedure at Microsoft was faster, much better defined, less
>> ad hoc, and a lot more transparent.
>
> Agreed, Microsoft is a professional company which doesn't involve any
> input from a community as with Mozilla. But how did they verify and
> understand your CP/CPS? Did they rely solemnly on the audit report?
> Does your OCSP responder not present a problem to them?
We were requested to submit further documentation on the audit in
English. We had the detailed report of our auditor translated and we
sent it to Microsoft. (This is a non-public document that describes
our systems in depth similar to our CPS.)
They did not examine our CPS. (If we had been asked to submit a
translation of the current CPSs, we would have done so.) They relied
on the audit statement and on the detailed report of our auditor.
We were asked a set of questions that were public before the process,
we had some discussion concerning some of them (especially about the
extended key usages).
At that time, Microsoft stated that OCSP responders under a separate
root are not supported, so our OCSP root was not included in Windows.
However, the OCSP URL in the AIA field was not raised as a problem.
Other issues were not raised during the process.
Whatever I criticized was not the scrunity of the process at Mozilla,
but its transparency and the way we can make our plans concerning it.
I mentioned Microsoft, because there we had a much better idea of what
was going to happen at what time, what was examined, what the exact
criteria was, and when they wanted us to submit some documentation,
they asked us to do so.
> On to István's comments:
>
>> Perhaps, making such (discriminatory) criteria mandatory could
>> still be better than enforcing it without stating it clearly.
>
> I don't think this criteria exists. I for one would not like it.
> But, there is, IMO, a need for something, and something short and
> simple was what I was exploring.
>
> I would point out that all my comments are aimed at the future. I
> wouldn't want to slow down any current contender. You seem to meet
> the rules and practices, so no need to dwell on this.
>
>> Being a long-term Mozilla fan, I am really sorry to say that the
>> same procedure at Microsoft was faster, much better defined, less
>> ad hoc, and a lot more transparent.
>
> OK! I think I for one would really like to hear a summary of that.
> I'm not trying to stir the pot, just wondering whether there is any
> way to improve the current Mozilla process, either up or down.
OK, thanks, I tried to summarize the main points above.
Eddy Nigg
>> István, even though I understand your frustration and agree with the
>> basic understanding that requirements should be published
>> accordingly, I also must state there has been at least one issue
>> (notably with your OCSP responder I think) in addition to our
>
> I think the OCSP issue has been resolved: As I recall, on the short
> run it does not cause problems with the current release of Firefox.
> However, we accepted your arguments, we made some changes in our
> systems and promised further changes in the future, so that it shall
> not cause problems on the long run either.
Are you saying that your OCSP is (going to be) operating now as expected?
> I may accept this statement, but if there is such a requirement, it
> should be stated in advance.
I agree with you.
> If there is no such requirement, it should not hinder the process, but
> there should be defined ways to resolve this issue.
Apparently it does hinder the process (not intentional, just by the fact
that it's hard to get to the information).
> We were requested to submit further documentation on the audit in
> English. We had the detailed report of our auditor translated and we
> sent it to Microsoft. (This is a non-public document that describes
> our systems in depth similar to our CPS.)
So there is a disadvantage to Mozilla as you aren't willing to provide
the same information as you did to Microsoft.
>
> They did not examine our CPS. (If we had been asked to submit a
> translation of the current CPSs, we would have done so.) They relied
> on the audit statement and on the detailed report of our auditor.
Well, yes, that's pretty detailed I guess. It might be actually easier
to read the detailed report than the CPS many times.
> At that time, Microsoft stated that OCSP responders under a separate
> root are not supported, so our OCSP root was not included in Windows.
> However, the OCSP URL in the AIA field was not raised as a problem.
Therefore OCSP is effectively not working for Microsoft software too,
correct? I know however that CRLs are better supported than with NSS.
> was going to happen at what time, what was examined, what the exact
> criteria was, and when they wanted us to submit some documentation,
> they asked us to do so.
Yes, I guess Mozilla can make such a request too.
> OK, thanks, I tried to summarize the main points above.
And sorry for the late reply, your message almost drowned at the list
(but I marked it to respond to you later).
István Zsolt BERTA
Yes. According to this thread
http://groups.google.com/group/mozilla.dev.tech.crypto/browse_thread/thread/416427a350db11a9
We have already removed the problematic OCSP URL from our SSL
certificates,
and also removed the problematic OCSP URL from CA certificates
that are used for the validation of SSL certificates.
Our root does contain an OCSP URL, but according to the thread it does
not cause a problem in Mozilla, as the revocation status of the root
cannot and shall not be checked via OCSP.
This means, there are not any problems even on the short run.
As we promised, we shall also address the problem on the long run by
introducing an
OCSP service that is usable for the general public, i.e. that does
not require authentication and works using the 'authorized responder'
concept.
http://groups.google.com/group/mozilla.dev.tech.crypto/msg/71ff5be3141529a8?
On the long run, we shall be required to phase out SHA-1 from our
systems so we shall
have to introduce a new hierarchy. The new hierarchy shall have an
OCSP usable for the
general public, and its' root certificate shall not contain an OCSP
URL.
However, the whole process of migration to the new hierarchy and the
phasing out the current one
will be long.
> > I may accept this statement, but if there is such a requirement, it
> > should be stated in advance.
>
> I agree with you.
>
> > If there is no such requirement, it should not hinder the process, but
> > there should be defined ways to resolve this issue.
>
> Apparently it does hinder the process (not intentional, just by the fact
> that it's hard to get to the information).
>
> > We were requested to submit further documentation on the audit in
> > English. We had the detailed report of our auditor translated and we
> > sent it to Microsoft. (This is a non-public document that describes
> > our systems in depth similar to our CPS.)
>
> So there is a disadvantage to Mozilla as you aren't willing to provide
> the same information as you did to Microsoft.
We are willing to provide information but nobody asked it :).
It was not stated among the requirements for inclusion to submit a CSP
in English.
I was requested to submit translations of relevant sections of our
CPS,
and I did so. Mozilla has also asked a Hungarian person to double
check my translation.
I was also asked to send our CPS in RTF format so that you can
perform
a machine translation, and I did so. (I also expressed my skepticism
about machine translation
to and from Hungarian.)
We have provided what you asked. Why would we submit something you did
not ask for?
> > was going to happen at what time, what was examined, what the exact
> > criteria was, and when they wanted us to submit some documentation,
> > they asked us to do so.
>
> Yes, I guess Mozilla can make such a request too.
If such a formal request is made, we shall have no problem with it.
(We shall prefer to submit a translation of our CPS and not of the
detailed
audit report, as Mozilla discusses these materials on a public forum,
and the detailed audit report may contain non-public information too.)
However, the translation of a 100-page-long CPS has a major cost,
and I can only justify this cost if I can demonstrate that it is
either
necessary or if I can clearly show what benefits it would bring
(e.g. to what extent it speeds the process up).
Still, if we need to submit a translation, I think we could have been
asked
to do it two years ago when the whole process started. I do not see
why
it took Mozilla two years to come to this conclusion...
> And sorry for the late reply, your message almost drowned at the list
> (but I marked it to respond to you later).
I also apologize for my late reply, we were also flooded with mails
after the holidays.
Regards,
István
Gen Kanai
As we're almost 2 months past the discussion period for this request,
I'd like to reconfirm that there are no other open issues.
If there are any open issues, SecomTrust is eager to resolve them asap
in order to have the cert included in the next possible version.
Your comments would be appreciated.
Eddy Nigg
According to Frank, he has reviewed the audit reports which isn't
public. This might be a problem.
Also because SecomTrust apparently doesn't use an OCSP responder and
isn't required to do so for another year, Firefox has no way to check
the certificates status. Firefox intends to treat such certificates as
non-EV at least as I understood. This might be another problem.
As such there should be an answer in this respect in order to add the
SecomTrust EV root or have them correct whatever needs to be corrected.
Cross-posting to the bug as well.
Kyle Hamilton
functional else it won't pass the internal EV checks to show the green
bar (please correct me if I'm wrong).
So, by my reading (and subject to the possible misbelief above), even
if the root is enabled for EV it won't necessarily work for the EV
functionality requested. This may be a marketing sticking point for
SecomTrust, but I do not believe that it is a Mozilla issue to
resolve.
If Mozilla violates the EV guidelines by showing a green bar even when
OCSP fails, then this root needs to not be enabled for EV, even if
admitted to the root list.
-Kyle H
> --
Kaspar Brand
> EV requires OCSP.
No, not true. From the EV Guidelines, section 26(a):
> CAs MUST support an OCSP capability for Subscriber Certificates that
> are issued after Dec 31, 2010.
Mozilla currently includes EV enabled roots of CAs which do not yet
provide OCSP respondes for their server certs.
> I believe that Mozilla requires OCSP to be
> functional else it won't pass the internal EV checks to show the
> green bar (please correct me if I'm wrong).
It's supposed to do so, but current Firefox versions will happily show
the EV indicator if an EV end-entity cert doesn't include an OCSP
responder URI (see https://bugzilla.mozilla.org/show_bug.cgi?id=413997
and https://bugzilla.mozilla.org/show_bug.cgi?id=474606, and try
https://addons.mozilla.org).
Kaspar
Eddy Nigg
> Mozilla currently includes EV enabled roots of CAs which do not yet
> provide OCSP respondes for their server certs.
Correct and this is a problem for both the CA and Mozilla...
> It's supposed to do so, but current Firefox versions will happily show
> the EV indicator if an EV end-entity cert doesn't include an OCSP
> responder URI (see https://bugzilla.mozilla.org/show_bug.cgi?id=413997
> and https://bugzilla.mozilla.org/show_bug.cgi?id=474606, and try
> https://addons.mozilla.org).
>
....just imagine, the CA has to revoke an EV certificate and Mozilla
continues to happily show the green address bar. This isn't just a
problem for the relying party, this can be a big one for Mozilla (and
the CA).
Johnathan Nightingale
> On 02/03/2009 08:05 AM, Kaspar Brand:
>> Mozilla currently includes EV enabled roots of CAs which do not yet
>> provide OCSP respondes for their server certs.
>
> Correct and this is a problem for both the CA and Mozilla...
>
>> It's supposed to do so, but current Firefox versions will happily show
>> the EV indicator if an EV end-entity cert doesn't include an OCSP
>> responder URI (see https://bugzilla.mozilla.org/show_bug.cgi?id=413997
>> and https://bugzilla.mozilla.org/show_bug.cgi?id=474606, and try
>> https://addons.mozilla.org).
>>
>
> ....just imagine, the CA has to revoke an EV certificate and Mozilla
> continues to happily show the green address bar. This isn't just a
> problem for the relying party, this can be a big one for Mozilla (and
> the CA).
We're talking with our existing CRL-based EV CAs as we speak to work out
a better solution for 3.1, now that the underlying NSS validation code
is (correctly) treating absence of CRL (albeit due to our own lack of
CRLDP support, until recently patent encumbered) as a failure for EV
purposes. One option is to implement base-bones CRLDP in time, another
is to pre-load those CRLs and then employ the already existent (with one
bug that has a patch) CRL auto-update mechanism, and yet another is to
encourage those CAs to move to OCSP ahead of schedule.
As the options resolve themselves, you can be assured that I'll be back
in here to update the situation.
Johnathan
Eddy Nigg
> We're talking with our existing CRL-based EV CAs as we speak to work out
> a better solution for 3.1, now that the underlying NSS validation code
> is (correctly) treating absence of CRL (albeit due to our own lack of
> CRLDP support, until recently patent encumbered) as a failure for EV
> purposes. One option is to implement base-bones CRLDP in time,
Which I would applaud...additionally CRLs could function as a fall back
in case OCSP failed.
> is to pre-load those CRLs and then employ the already existent
Which should be discouraged since there are other CAs relying on CRLs,
additionally the CAs couldn't move the CRLs to a different URL.
> bug that has a patch) CRL auto-update mechanism, and yet another is to
> encourage those CAs to move to OCSP ahead of schedule.
For EV I fail to understand the logic for not implementing OCSP at this
stage. It should have been made mandatory right from the start. Some CAs
have it for years already...
Frank Hecker
> According to Frank, he has reviewed the audit reports which isn't
> public. This might be a problem.
No, I previously posted about that. I don't like having a private audit
report, but it was not SECOM Trust's fault (or even its auditor's fault,
IIRC). The final issue from my point of view was verifying with the
auditors that the report was indeed genuine, which Kathleen and Gen did.
From my perspective there are no further issues preventing approval of
SECOM Trust for inclusion.
> Also because SecomTrust apparently doesn't use an OCSP responder and
> isn't required to do so for another year, Firefox has no way to check
> the certificates status. Firefox intends to treat such certificates as
> non-EV at least as I understood. This might be another problem.
>
> As such there should be an answer in this respect in order to add the
> SecomTrust EV root or have them correct whatever needs to be corrected.
I've already discussed this with Johnathan, and IIRC we agreed to
decouple the issue of approving EV CAs for inclusion and EV enabling
(which is a policy issue) with the issue of how those CAs are handled
for the purposes of the Firefox EV UI. I trust Johnathan, Kai, and
others to make sensible technical decisions about how to handle EV CAs
not yet supporting OCSP.
So I'm going to go ahead and formally approve SECOM Trust's request for
inclusion and for EV enabling. Kathleen, could you post a summary to bug
394419 and then ping me for final approval?