Eddy Nigg wrote:
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
Eddy Nigg wrote:
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
On 02/03/2009 01:47 PM, Johnathan Nightingale:
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
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
Frank filed the inclusion request for SecomTrust on Dec. 8th, 2008.
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
On 02/03/2009 03:20 AM, Gen Kanai:
Frank filed the inclusion request for SecomTrust on Dec. 8th, 2008.
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
EV requires OCSP. 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).
So, by my reading (and subject to the possible misbelief above), even
if the root is enabled for EV it won't necessarily work
Kyle Hamilton wrote:
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
Are you saying that your OCSP is (going to be) operating now as expected?
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
On 12/30/2008 06:23 PM, István Zsolt BERTA:
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
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
Ian G wrote re CPSs not available in English:
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
On 12/18/2008 07:14 PM, István Zsolt BERTA:
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
On 18/12/08 18:14, István Zsolt BERTA wrote:
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
Ian G wrote re CPSs not available in English:
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,
On 12/13/2008 01:15 PM, Ian G:
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
Kyle Hamilton wrote:
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
On 12/12/08 07:51, Kyle Hamilton wrote:
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
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?)
...
... I'm going to make an
exception again in this case.
...
However since we received the
Frank Hecker wrote:
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
Frank Hecker wrote:
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
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
On 12/06/2008 08:33 AM, Frank Hecker:
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 Hecker wrote:
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=816file=pdf
My mistake. This report is for SECOM Trust.net Root1 CA (ValiCert Class
1 Policy Validation CA) and
Eddy Nigg wrote:
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;
Frank Hecker wrote:
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,
On Saturday 06 December 2008 06:33:13 Frank Hecker wrote:
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
Per the CA schedule (for which I need to update dates), the next CA on
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:
28 matches
Mail list logo
