StartCom EV-Enablement Request
Kathleen Wilson
StartCom is the next request in the queue for public discussion.
StartCom (a commercial corporation with customers worldwide) has
applied to enable EV and add the Code Signing trust bit for the
StartCom Certification Authority root certificate which is already
included in NSS.
This request is documented in the following bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=451298
and in the pending certificates list here:
http://www.mozilla.org/projects/security/certs/pending/#StartCom
Summary of Information Gathered and Verified:
https://bug451298.bugzilla.mozilla.org/attachment.cgi?id=366693
Some comments regarding noteworthy points:
* The StartCom PKI is structured by different Class levels (1 - 3, EV)
and different purposes (SSL/TLS Server, Client S/MIME, Object Code)
and every Class and purpose is handled by a different intermediate
CA.
** The intermediate CAs for EV are StartCom Extended Validation Client
CA and StartCom Extended Validation Server CA.
** The intermediate CAs for Code Signing are StartCom Class 2 Primary
Intermediate Object CA and StartCom Class 3 Primary Intermediate
Object CA.
* The CP/CPS is provided in English.
** Verification procedures are described in the CP/CPS in the section
called Certification Rules, and are distinguished by class level:
Class 1 are DV, Class 2 are IV, Class 3 are OV, and there is a
separate section for Extended Validation.
** In CP/CPS section called Domain Names: Additionally the existence
of the domain name is verified by checking the WHOIS records provided
by the domain name registrar.
** In CP/CPS section called Email Addresses: Email accounts are
validated by sending an electronic mail message with a verification
code to the email account in question. The subscriber has to return
and submit the verification code as prove of ownership of the email
account within a limited period sufficient enough to receive an
electronic mail message.
** The minimum validation level for Object Code Signing is Class 2,
Identity Validation.
* StartCom provides both OCSP and CRL.
** CRLs of subscriber certificates are updated at least every 12 hours
or every time a certificate is revoked, whichever comes first. Each
intermediate CA issues its own corresponding CRL for the certificates
it issues.
** OCSP responder service is provided and the respective URL location
of the service are included in the
certificates. The current CRLs are reloaded at least every 60 minutes.
* In CP/CPS section called StartCom Intermediate CA Program (SICAP):
Middle to bigger sized organizations may request to run an
intermediate certification authority, which allows a limited role as
intermediate CA operator…. The intermediate CA is operated at
StartCom’s premise and the organization must accept all conditions and
terms as outlined in the StartCom Intermediate Certification Authority
Policy Appendix.
* StartCom has been audited by Ernst & Young using the WebTrust CA and
WebTrust EV criteria. The audit reports are both dated December 31,
2008. Both audit reports have been attached to the bug and 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
Eddy Nigg
> As per the CA Schedule at https://wiki.mozilla.org/CA:Schedule
> StartCom is the next request in the queue for public discussion.
>
As always, thanks Kathleen!
Even though I'd have some opinion about this request to enable EV, I
guess this time I'm on the receiving end ;-)
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
Jabber: star...@startcom.org
Blog: https://blog.startcom.org
Nelson Bolyard
> As per the CA Schedule at https://wiki.mozilla.org/CA:Schedule
> StartCom is the next request in the queue for public discussion.
How many of these public discussions are going on simultaneously?
On one single day this past week, I got 3 emails announcing the start
of the public discussion period for different CAs. 3 on one day.
What the heck?
Should we just let them all run concurrently?
That would surely clear the backlog in a hurry!
Eddy Nigg
> Kathleen Wilson wrote, On 2009-04-10 13:34:
>
>> As per the CA Schedule at https://wiki.mozilla.org/CA:Schedule
>> StartCom is the next request in the queue for public discussion.
>>
> How many of these public discussions are going on simultaneously?
>
Currently we have ComSign's second round. I believe there are two
questions open for them.
Than we've got Verizon and SSC. Both were discussed up to some point....
> On one single day this past week, I got 3 emails announcing the start
> of the public discussion period for different CAs. 3 on one day.
>
Yes? I can't find such a day, or even 3 in a week....But the last second
rounds were followed quickly by each other (German's TC and T-Systems).
I believe since the CAs in question fully complied to the requests of
Mozilla and no negative comments were made, those were processed rather
quick.
> What the heck?
>
It's good that you complain, if there are too many.
> Should we just let them all run concurrently?
> That would surely clear the backlog in a hurry!
>
No, I happen to know that Kathleen went on vacation for the next ten
days and won't tend to Mozilla matters until then. She told me that
before announcing StartCom's EV-Enablement request. Well, in the
meantime we can discuss all of them to death.... :-)
Kyle Hamilton
available for corporations and other non-natural persons?
Do the EV certificates include both the "web client" and "web server"
eKU extensions, the way the Class I webserver certificates do?
(Sorry for being rather more direct, Eddy; I just happen to have a
couple of certs from StartCom and I'd like to know how the EV
certificates work.)
-Kyle H
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
Eddy Nigg
> ....how can you have an "Extended Validation Client CA"? EV is only
> available for corporations and other non-natural persons?
>
LOL..this was just a test to see if you are awake... :-)
Nonono...now the serious answer:
When we created and signed the first intermediate CA certificates for EV
back in 2007 we anticipated that the CA/Browser forum will create
guidelines for client certificates as well. This was the buzz at this
mailing list anyway IIRC....
However the CA/Browser forum went a different direction and it appears
that they implemented guidelines for code signing certificates instead.
For the time-being the "StartCom Extended Validation Client" CA
certificates hasn't been used and withdrawn from the current repository.
This intermediate CA has therefore to this date only issued some test
certificates and the CRL is empty. It's not operational at the moment
and StartCom doesn't issue EV code signing certificates at the moment
either.
As such, I believe corporations can also have and use client
certificates basically. I'm not sure why client certificates must be
limited to natural persons only....but it's a theoretical question
really, including what StartCom concerns.
> Do the EV certificates include both the "web client" and "web server"
> eKU extensions, the way the Class I webserver certificates do?
>
Actually the Class 1 certificates don't have the "TLS Web Client
Authentication" extension, but any higher validated certificate has,
e.g. Class 2 and higher including EV. Some certain implementations
depend on it, in particular when used with multiple domain names and
firewall/proxy setups. According to my interpretation, the EV guidelines
don't prohibit its use.
> (Sorry for being rather more direct, Eddy; I just happen to have a
> couple of certs from StartCom and I'd like to know how the EV
> certificates work.)
>
No need to apologize, this is a comments period as any other.
Jean-Marc Desperrier
> ** CRLs of subscriber certificates are updated at least every 12 hours
> or every time a certificate is revoked, whichever comes first. Each
> intermediate CA issues its own corresponding CRL for the certificates
> it issues.
> ** OCSP responder service is provided and the respective URL location
> of the service are included in the
> certificates. The current CRLs are reloaded at least every 60 minutes.
This description is a bit unclear to me, because of that sentence
"current CRLs are reloaded at least every 60 minutes"
I wonder if that's just a technical specificity that has no consequences
externally.
I will ask a few question to confirm that :
- Does the "at least" in "The current CRLs are reloaded at least every
60 minutes" mean that the CRL will be immediately reloaded if it's
updated so that OCSP information will never be *less* up to date than
CRL information ?
- I understand that OCSP is basing it's information on the same CRLs
that are otherwise made public, so that using OCSP will not really bring
a newer information on revocation than using CRL ?
(I'm not criticizing that, it's just that I think it is that info that
should be put forward when describing it, rather than the 60 minutes
that are not really important if more up to date CRL are immediately
reloaded)
Eddy Nigg
Thank you for your question!
On 04/14/2009 02:27 PM, Jean-Marc Desperrier:
> Kathleen Wilson wrote:
>> ** CRLs of subscriber certificates are updated at least every 12 hours
>> or every time a certificate is revoked, whichever comes first. Each
>> intermediate CA issues its own corresponding CRL for the certificates
>> it issues.
>> ** OCSP responder service is provided and the respective URL location
>> of the service are included in the
>> certificates. The current CRLs are reloaded at least every 60 minutes.
>
> This description is a bit unclear to me, because of that sentence
> "current CRLs are reloaded at least every 60 minutes"
It's a technical configuration setting and implementation of the
infrastructural aspects. This means, that if a certificates was revoked
at the first minute of the cycle (which implies automatic issuance and
distribution of a new CRL), the OCSP responder might return a valid
result for the next 59 minutes until the OCSP responder received the new
CRL and forced a reload of it.
> I will ask a few question to confirm that :
>
> - Does the "at least" in "The current CRLs are reloaded at least every
> 60 minutes" mean that the CRL will be immediately reloaded if it's
> updated so that OCSP information will never be *less* up to date than
> CRL information ?
CRL nextUpdate information is ignored by the OCSP responder and it
forces a reload of the CRL every 60 minutes.
> - I understand that OCSP is basing it's information on the same CRLs
> that are otherwise made public, so that using OCSP will not really
> bring a newer information on revocation than using CRL ?
Right. However CRLs are typically not reloaded by applications before
the nextUpdate time indicated in the CRL if it exists in the cache
already. Some applications including Firefox may however have different
update/reload settings such as every X days or X days before nextUpdate
is due.
> (I'm not criticizing that, it's just that I think it is that info that
> should be put forward when describing it, rather than the 60 minutes
> that are not really important if more up to date CRL are immediately
> reloaded)
We could have decided on a more frequent sync of the CRLs, however we
believe that a 60 minute cycle is reasonable. It's obviously more
accurate and responsive than an already cached CRL, which it's also
supposed to be. Just for comparison, the EV guidelines speak about
re-issuance of the end-user certificates CRL of at least every week
(seven days) and the OCSP responder should reload the CRL (they call it
"update") at least every four days.
Kaspar Brand
> As per the CA Schedule at https://wiki.mozilla.org/CA:Schedule
> StartCom is the next request in the queue for public discussion.
>
> StartCom (a commercial corporation with customers worldwide) has
> applied to enable EV and add the Code Signing trust bit for the
> StartCom Certification Authority root certificate which is already
> included in NSS.
Is this request for EV enablement on some sort of fast track? I was
under the impression that for any EV enablement request a test URL is
required (and would assume that public discussion only starts when a
test URL is available).
Anyway, here are a couple of comments. They only relate to the EV
part of bug 451298, and I think that combining EV and code signing
enablement into one request is rather awkward. (I would suggest to split
it into separate issues. The subject of this thread is certainly
misleading if the discussion should cover both requests.)
1) It should be noted that the Webtrust EV audit report for this CA
(https://bugzilla.mozilla.org/attachment.cgi?id=366568) is only a "point
in time report", as it states
StartCom has not placed its Extended Validation Certification
Authority services in operation and, therefore, we have performed no
procedures to evaluate the operating effectiveness of its controls.
Accordingly, we express no opinion on the operating effectiveness of
any aspects of StartCom’s controls, individually or in the aggregate.
There's nothing wrong with that by itself, but it appears to me that the
audit was carried out before the operations of the EV issuing CA could
be verified (given the findings reported below, it would be surprising
if E&Y didn't notice at least some of these issues).
2) The EV policy appendix (available at
http://www.startssl.com/extended.pdf) still says "Version: 0.9, Status:
Draft". I don't think that Mozilla wants to EV enable CAs based on draft
CP/CPS documents.
3) In
http://www.startssl.com/extended-validation-application-request.pdf,
page 2 consists of a form entitled "Acknowledgment of the StartCom
Extended Validation Subscriber Agreement". However, I could not find
that subscriber agreement anywhere on the Web site. The EV guidelines
(section 12) make it clear that a subscriber agreement is mandatory for
EV requests, and have fairly detailed requirements on its very content.
4) Assuming that the certificate now configured at
https://cert.startcom.org (issued on 10 April 200) purports to be an EV
SSL certificate (as indicated by its policy OID), there are a couple of
strange things to note:
4a) the subject DN does not include the business category attribute
(mandatory according to the EV guidelines, section 6). It's not
mentioned in the "Policy & Practice Statements" document
(http://www.startssl.com/policy.pdf) either, on page 23. (The pages are
unnumbered, you need a PDF viewer to figure them out. Haven't page
numbers be invented quite some time ago? I thought so at least.)
4b) It has a caIssuers URI which points to
http://www.startssl.com/certs/sub.class4.server.ca.crt. I only get a 404
for this resource.
4c) Retrieving http://www.startssl.com/crt4-crl.crl (which is referenced
in the CRLDP extension) gives me an v1 CRL... yes, version 1, that's
right. Even RFC 2459, published more than 10 years ago, already required
compliant CAs to issue v2 CRLs. Furthermore, that CRL also has an
entry for cert with serial number 02, which was apparently revoked on 12
May 2008 - many months before the issuing CA (CN=StartCom Extended
Validation Server CA) was in operation, judging from its notBefore date
(1st January 2009). Makes you wonder how that certificate with serial
number 02 actually came into existence.
5) Looking at the EV issuing CA cert (available at
http://www.startssl.com/certs/sub.ev.server.ca.crt, in case someone is
still desperately looking for sub.class4.server.ca.crt), we find
additional oddities:
5a) an empty issuerAltName extension (yes, completely empty). Of course
RFC 5280 specifies a different syntax for this extension:
"GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName"
5b) a CRLDP extension with an entry for
http://crl.startssl.com/sfsca.crl, which again brings us to a v1 CRL.
This time it's even one with an MD5 signature (already long before 25C3,
using MD5 for hashing was definitely not considered best current practice).
6) Looking at appendix C of the EV guidelines, we find the statement:
"The CA MUST host test Web pages that allow Application Software Vendors
to test their software. At a minimum, the CA MUST host separate Web
pages using certificates that are (a) valid (b) revoked and (c)
expired." - Could URLs for (b) and (c) please be provided?
That's it for the time being - I didn't really delve further into the
"Policy & Practice Statements" document... if I find more time, I may
have additional comments.
Kaspar
Eddy Nigg
I'm glad to see you joining to review CAs. Hopefully this isn't a
one-time effort of yours!
On 04/14/2009 07:24 PM, Kaspar Brand:
> Is this request for EV enablement on some sort of fast track?
Not as far as I know. The bug has been filed quite a while ago and has
been scheduled accordingly. You can review it here:
https://wiki.mozilla.org/CA:Schedule#Queue_for_Public_Discussion
> I was
> under the impression that for any EV enablement request a test URL is
> required (and would assume that public discussion only starts when a
> test URL is available).
>
Yes, it has been provided at the first comment of the bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=451298
In the meantime we changed some of the URLs, but
https://forum.startcom.org/ is still an EV certificate and we can
perhaps add another few, for example https://cert.startcom.org/
> Anyway, here are a couple of comments. They only relate to the EV
> part of bug 451298, and I think that combining EV and code signing
> enablement into one request is rather awkward.
>
It has been very common to include at the bug, the following discussion
and approval, all required changes. This request is not different than
any other as you might know if you followed recent inclusion and EV
enablement discussions.
> 1) It should be noted that the Webtrust EV audit report for this CA
> (https://bugzilla.mozilla.org/attachment.cgi?id=366568) is only a "point
> in time report", as it states
>
> StartCom has not placed its Extended Validation Certification
> Authority services in operation and, therefore, we have performed no
> procedures to evaluate the operating effectiveness of its controls.
> Accordingly, we express no opinion on the operating effectiveness of
> any aspects of StartCom’s controls, individually or in the aggregate.
>
Correct. Most, if not *all* CAs were approved and had the EV OID enabled
based upon the EV readiness audit. Myself asked this question quite a
while ago as well. CAs can start the issuing of EV certificates only
after completion of the readiness audit.
> 2) The EV policy appendix (available at
> http://www.startssl.com/extended.pdf) still says "Version: 0.9, Status:
> Draft". I don't think that Mozilla wants to EV enable CAs based on draft
> CP/CPS documents.
>
StartCom operates currently a beta program for EV certificates where it
invites subscribers to become part of the program for reduced fees.
During the course of this program changes can still happen and
modifications performed, including re-issuance of certificates should
need arise. This is typical for our procedures when introducing a new
product and we had beta programs in place for most of our products. This
includes currently also the code signing certificates we issue.
The "StartCom Extended Validation Certificates Policy Appendix" will
become final once we exit our beta program. We follow the internal
procedures of approval of changes and publishing of the public policies
and various statements and this is what has been audited, attested and
found to be correct. Otherwise - beyond possible modifications reserved
- the appendix is binding.
> 3) In
> http://www.startssl.com/extended-validation-application-request.pdf,
> page 2 consists of a form entitled "Acknowledgment of the StartCom
> Extended Validation Subscriber Agreement". However, I could not find
> that subscriber agreement anywhere on the Web site. The EV guidelines
> (section 12) make it clear that a subscriber agreement is mandatory for
> EV requests, and have fairly detailed requirements on its very content.
>
Correct. This document is compliant with the "Subscriber Agreement
Requirements" of section 12 of the EV guidelines and references to the
relevant obligations outlined in the CA policies which comprise part of
the subscriber agreement. Any other agreements which a subscriber may or
may not be required to enter are not publicly disclosed.
> 4) Assuming that the certificate now configured at
> https://cert.startcom.org (issued on 10 April 200) purports to be an EV
> SSL certificate (as indicated by its policy OID), there are a couple of
> strange things to note:
>
> 4a) the subject DN does not include the business category attribute
> (mandatory according to the EV guidelines, section 6). It's not
> mentioned in the "Policy& Practice Statements" document
> (http://www.startssl.com/policy.pdf) either, on page 23.
>
This might be a deficiency in the certificate and we'll look into it.
> 4b) It has a caIssuers URI which points to
> http://www.startssl.com/certs/sub.class4.server.ca.crt. I only get a 404
> for this resource.
>
We changed the name of the certificate recently. A shortcut has been
placed since then.
> 4c) Retrieving http://www.startssl.com/crt4-crl.crl (which is referenced
> in the CRLDP extension) gives me an v1 CRL... yes, version 1, that's
> right. Even RFC 2459, published more than 10 years ago, already required
> compliant CAs to issue v2 CRLs.
I'm ignoring this part since version 1 CRLs are legitimate, smaller and
functional in every respect. Besides that various CA still use version 1
CRLs and never has been the basis for concern so far.
> Furthermore, that CRL also has an
> entry for cert with serial number 02, which was apparently revoked on 12
> May 2008 - many months before the issuing CA (CN=StartCom Extended
> Validation Server CA) was in operation, judging from its notBefore date
> (1st January 2009). Makes you wonder how that certificate with serial
> number 02 actually came into existence.
>
Nothing to wonder really! Various testing occurs before an intermediate
CA certificate becomes operational which includes the testing and
issuing of certificates, OCSP responder certificate, revocation of
certificates, issuing and publishing of CRLs etc. It would be NOT normal
to have NO entries in a CRL for an end-user certificate issuing CA.
> 5a) an empty issuerAltName extension (yes, completely empty). Of course
> RFC 5280 specifies a different syntax for this extension:
> "GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName"
>
We'll check if this should be corrected or not.
> 5b) a CRLDP extension with an entry for
> http://crl.startssl.com/sfsca.crl, which again brings us to a v1 CRL.
> This time it's even one with an MD5 signature (already long before 25C3,
> using MD5 for hashing was definitely not considered best current practice).
>
The threat and attack pattern of 25C3 doesn't apply to CRLs. This is one
of the reasons why we opted not to replace the CRL in question until
next issuance.
> 6) Looking at appendix C of the EV guidelines, we find the statement:
> "The CA MUST host test Web pages that allow Application Software Vendors
> to test their software. At a minimum, the CA MUST host separate Web
> pages using certificates that are (a) valid (b) revoked and (c)
> expired." - Could URLs for (b) and (c) please be provided?
>
I think we've been through this one also already at this list previously
since it's hard to provide an expired certificate just after completion
of the EV readiness audit. However I'll look into providing a site with
a revoked certificate. I wonder if those tests are/were performed at all
here...I'm not aware of that, but principally you are right that this
should be provided.
> That's it for the time being - I didn't really delve further into the
> "Policy& Practice Statements" document... if I find more time, I may
> have additional comments.
>
Thank you Kaspar for taking the time, the scrutiny and extensive review
by you shall serve to our advantage!
Eddy Nigg
>> Furthermore, that CRL also has an
>> entry for cert with serial number 02, which was apparently revoked on 12
>> May 2008 - many months before the issuing CA (CN=StartCom Extended
>> Validation Server CA) was in operation, judging from its notBefore date
>> (1st January 2009). Makes you wonder how that certificate with serial
>> number 02 actually came into existence.
>
> Nothing to wonder really! Various testing occurs before an
> intermediate CA certificate becomes operational which includes the
> testing and issuing of certificates, OCSP responder certificate,
> revocation of certificates, issuing and publishing of CRLs etc. It
> would be NOT normal to have NO entries in a CRL for an end-user
> certificate issuing CA.
Sorry Kaspar, after re-reading I realized that I perhaps misunderstood
your point. The correct answer is, that we recently re-issued the
intermediate EV CA certificate in order to correct a minor deficiency in
the certificate. It uses the same keys and hence continued the
operations of the previous certificate. Since any certificate issued
before the first of January 2009 would not be valid anyway, the revoked
certificate is not valid too and could be removed from the CRL. However
we have the practice of never removing revoked certificates from the CRL
during the complete life-time of the issuer certificate, hence this
entry hasn't been removed.
Eddy Nigg
>> (mandatory according to the EV guidelines, section 6). It's not
>> mentioned in the "Policy& Practice Statements" document
>> (http://www.startssl.com/policy.pdf) either, on page 23.
>
> This might be a deficiency in the certificate and we'll look into it.
OK, this was an easy one :-) The omission can be understood because the
Version 1.0 – Draft 11 didn't require that field which was the basis of
our initial work.
Since we are without doubt ourselves the oldest subscriber, our
information isn't updated the same as with a (new) subscriber. This
field was missing because the data didn't existed in our profile. A hard
failure should have prevented that, instead of continue, therefor we
changed it to a hard failure now. Thanks for pointing out.
Eddy Nigg
>> "The CA MUST host test Web pages that allow Application Software Vendors
>> to test their software. At a minimum, the CA MUST host separate Web
>> pages using certificates that are (a) valid (b) revoked and (c)
>> expired." - Could URLs for (b) and (c) please be provided?
>
> I think we've been through this one also already at this list
> previously since it's hard to provide an expired certificate just
> after completion of the EV readiness audit. However I'll look into
> providing a site with a revoked certificate. I wonder if those tests
> are/were performed at all here...I'm not aware of that, but
> principally you are right that this should be provided.
>
I created https://bad.startcom.org/ for revocation checking. I'll also
update the bug. Hope this helps.
Jean-Marc Desperrier
> On 04/14/2009 09:15 PM, Eddy Nigg:
>>> Furthermore, that CRL also has an
>>> entry for cert with serial number 02, which was apparently revoked on 12
>>> May 2008 - many months before the issuing CA (CN=StartCom Extended
> [...] The correct answer is, that we recently re-issued the
> intermediate EV CA certificate in order to correct a minor deficiency in
> the certificate. It uses the same keys and hence continued the
> operations of the previous certificate. Since any certificate issued
> before the first of January 2009 would not be valid anyway,[...]
I understand that the new intermediate EV CA certificate has the same DN
as the older one. When you strictly apply X509/PKIX rules, it's the only
important point here (changing or not the private key does not count).
So under a strict interpretation of X509/PKIX rules, it's perfectly
correct to verify the signature of that serial number 02 certificate
with the former intermediate EV CA (which you may have withdrawn but
can't guarantee no copy of still doesn't exist somewhere), and to use
the CRL issued under the current intermediate EV CA to verify if it has
been revoked.
So, you have made the perfectly correct and in fact *absolutely*
*required* thing by keeping it's serial number inside the new CRL.
I wanted to insist on this, because in your description it looks like
something that you did for some random reason when it is absolutely the
proper and required way of handling that situation, and other CAs should
do the same if they happen to have the same case.
Eddy Nigg
> Eddy Nigg wrote:
>> On 04/14/2009 09:15 PM, Eddy Nigg:
>>>> Furthermore, that CRL also has an
>>>> entry for cert with serial number 02, which was apparently revoked
>>>> on 12
>>>> May 2008 - many months before the issuing CA (CN=StartCom Extended
>>>> Validation Server CA) was in operation, [...]
>
>> [...] The correct answer is, that we recently re-issued the
>> intermediate EV CA certificate in order to correct a minor deficiency in
>> the certificate. It uses the same keys and hence continued the
>> operations of the previous certificate. Since any certificate issued
>> before the first of January 2009 would not be valid anyway,[...]
>
> I understand that the new intermediate EV CA certificate has the same
> DN as the older one. When you strictly apply X509/PKIX rules, it's the
> only important point here (changing or not the private key does not
> count).
>
> So under a strict interpretation of X509/PKIX rules, it's perfectly
> correct to verify the signature of that serial number 02 certificate
> with the former intermediate EV CA (which you may have withdrawn but
> can't guarantee no copy of still doesn't exist somewhere), and to use
> the CRL issued under the current intermediate EV CA to verify if it
> has been revoked.
First of all it's obvious that the certificate(s) in question which were
issued from that ICA have been under our sole control. This includes all
certificates issued prior to the first of January 2009. Therefore the
potential risk you mentioned above would be minimal to non-existent.
>
> So, you have made the perfectly correct and in fact *absolutely*
> *required* thing by keeping it's serial number inside the new CRL.
I assume that you expect that the certificate hasn't expired yet.
Otherwise - if I interpret you correctly - quite some CAs would be in
trouble which regularly remove expired certificates from the CRLs.
>
> I wanted to insist on this, because in your description it looks like
> something that you did for some random reason when it is absolutely
> the proper and required way of handling that situation, and other CAs
> should do the same if they happen to have the same case.
No, it's a matter of policy! I said it "could" be removed to my
understanding, but we never do that anyway, hence this entry hasn't been
Jean-Marc Desperrier
>> Does the "at least" in "The current CRLs are reloaded at least every
>> 60 minutes" mean that the CRL will be immediately reloaded if it's
>> updated so that OCSP information will never be *less* up to date than
>> CRL information ?
>
> CRL nextUpdate information is ignored by the OCSP responder and it
> forces a reload of the CRL every 60 minutes.
>
>> - I understand that OCSP is basing it's information on the same CRLs
>> that are otherwise made public, so that using OCSP will not really
>> bring a newer information on revocation than using CRL ?
>
>
>> (I'm not criticizing that, it's just that I think it is that info that
>> should be put forward when describing it, rather than the 60 minutes
>> that are not really important if more up to date CRL are immediately
>> reloaded)
>
> We could have decided on a more frequent sync of the CRLs, however we
> believe that a 60 minute cycle is reasonable. It's obviously more
> accurate and responsive than an already cached CRL, which it's also
> supposed to be. Just for comparison, the EV guidelines speak about
> re-issuance of the end-user certificates CRL of at least every week
> (seven days) and the OCSP responder should reload the CRL (they call it
> "update") at least every four days.
The frequency of update is indeed much higher than the EV guideline and
also much higher that what most other CA are doing, so there is strictly
no problem here with regard to the evaluation for inclusion in the
Mozilla root.
This being said, the end results breaks the expectations people usually
have, in that it's possible for the OCSP status to be up to 59 minutes
late WRT the latest published CRL.
So if user wants to get revocation information from StartCom EV root, he
can, in order of getting the most up-to-date info :
- use cached CRL up to their nextUpdate
- use OCSP that is guaranteed to be no more than 60 minutes late
- force download of the latest CRL before each verification (or test
that no newer CRL is available with an If-Modified-Since http header)
which will be the very latest information as soon as the certificate is
revoked
I think the best would be to simply, openly document that so that nobody
is surprised by this behavior.
Jean-Marc Desperrier
> you expect that the certificate hasn't expired yet. Otherwise - if I
> interpret you correctly - quite some CAs would be in trouble which
> regularly remove expired certificates from the CRLs.
Yes, I thought you had stated that cert was not expired yet.
If it is expired, then keeping it's serial number on the CRL or not is
just a question of policy.
Eddy Nigg
>
> I think the best would be to simply, openly document that so that
> nobody is surprised by this behavior.
This has been disclosed sufficiently in the CP/CPS:
https://www.startssl.com/policy.pdf
Sub Sections "Distribution of Certificate Revocation List" and "OCSP
Responder Service" address exactly what you stated above:
....Certificate Revocation Lists (CRL) of subscriber certificates are
updated every 12 hours or every time a certificate is revoked...
...The OCSP responder provides results about the status of a certificate
instantly. The current CRLs are reloaded at least every 60 minutes.
Kaspar Brand
>
> Not as far as I know. The bug has been filed quite a while ago and has
> been scheduled accordingly. You can review it here:
> https://wiki.mozilla.org/CA:Schedule#Queue_for_Public_Discussion
Given the fact that it only got the "Information confirmed complete"
status on 2009-03-10, I wonder why other requests which changed to
"Information confirmed complete" quite some time ago (e.g. bug 455878
[2008-11-25], or 409235 [2008-09-11], or 453460 [2008-11-19]) have been
in the queue for a much longer period. If requests are reordered in the
queue, I would at least expect Kathleen to make such a decision
transparent, when announcing the discussion period for a new request.
> It has been very common to include at the bug, the following discussion
> and approval, all required changes. This request is not different than
> any other as you might know if you followed recent inclusion and EV
> enablement discussions.
Maybe when adding a completely new root (where EV is "combined" with
setting the SSL trust bit). I would yet have to see a another request
which combines code signing with EV SSL - and again, the subject of this
thread is still misleading.
> The "StartCom Extended Validation Certificates Policy Appendix" will
> become final once we exit our beta program. We follow the internal
> procedures of approval of changes and publishing of the public policies
> and various statements and this is what has been audited, attested and
> found to be correct. Otherwise - beyond possible modifications reserved
> - the appendix is binding.
Well, then if this Beta program has been running for some time, why did
E&Y not have a closer look at your infrastructure? Did E&Y not notice
any of the shortcomings I listed previously? Makes their audit appear
rather cursory.
> This document is compliant with the "Subscriber Agreement
> Requirements" of section 12 of the EV guidelines and references to the
> relevant obligations outlined in the CA policies which comprise part of
> the subscriber agreement.
It is not. First, if the person signs a form which is called
"Acknowledgement of the StartCom Extended Validation Subscriber
Agreement", then 1) there has to be such a document ("Subscriber
Agreement") and b) it must include all requirements set forth in section
12 of the EV guidelines. Even if we consider your "Policy & Practice
Statements" document as the "Subscriber Agreement", where e.g. does it
have a stipulation regarding item (b)(5) of said guidelines? Or item
(b)(3), for that matter?
Furthermore, looking at this text from your "Acknowledgement" form, can
you tell me what that "_____" is, which is apparently available at
https://www.startssl.com/?app=26 ?
> I have read and confirm my company's acceptance and acceptance by
> myself of all obligations placed upon me and my company by the
> StartCom Certification Authority Policy & Practice Statements and
> StartCom Extended Validation Certificates Policy Appendix , that
> includes all Extended Validation terms and conditions on behalf of
> _________________________________________________, which is available at
> https://www.startssl.com/?app=26.
>>> >> 4a) the subject DN does not include the business category attribute
>>> >> (mandatory according to the EV guidelines, section 6). It's not
>>> >> mentioned in the "Policy& Practice Statements" document
>>> >> (http://www.startssl.com/policy.pdf) either, on page 23.
>> >
>> > This might be a deficiency in the certificate and we'll look into it.
>
> OK, this was an easy one :-) The omission can be understood because the
> Version 1.0 – Draft 11 didn't require that field which was the basis of
> our initial work.
>
> Since we are without doubt ourselves the oldest subscriber, our
> information isn't updated the same as with a (new) subscriber. This
> field was missing because the data didn't existed in our profile. A hard
> failure should have prevented that, instead of continue, therefor we
> changed it to a hard failure now. Thanks for pointing out.
So, when can we expect 1) the "Policy & Practice Statements" document to
be updated accordingly and 2) all existing certificates issued with the
1.3.6.1.4.1.23223.2 policy OID, but lacking the business category
attribute to be revoked and replaced?
>> 4b) It has a caIssuers URI which points to
>> http://www.startssl.com/certs/sub.class4.server.ca.crt. I only get a 404
>> for this resource.
>>
>
> We changed the name of the certificate recently. A shortcut has been
> placed since then.
RFC 5280 says that "the URI MUST point to [...] a single DER encoded
certificate". I suggest you try again (and maybe rethink your change
management - this issue should have been noticed before it went online,
shouldn't it?).
>> 4c) Retrieving http://www.startssl.com/crt4-crl.crl (which is referenced
>> in the CRLDP extension) gives me an v1 CRL... yes, version 1, that's
>> right. Even RFC 2459, published more than 10 years ago, already required
>> compliant CAs to issue v2 CRLs.
>
> I'm ignoring this part since version 1 CRLs are legitimate, smaller and
> functional in every respect. Besides that various CA still use version 1
> CRLs and never has been the basis for concern so far.
The EV guidelines make it pretty clear that the CA has to follow RFC
3280 when issuing certificates (see e.g. appendix B). And RFC 3280/5280
very clearly state:
When CRLs are issued,
the CRLs MUST be version 2 CRLs, include the date by which the next
CRL will be issued in the nextUpdate field (section 5.1.2.5), include
the CRL number extension (section 5.2.3), and include the authority
key identifier extension (section 5.2.1).
If you insist on using v1 CRLs, then maybe that's good enough for your
other ICAs, but it doesn't meet the requirements for validating EV certs.
> Nothing to wonder really! Various testing occurs before an intermediate
> CA certificate becomes operational which includes the testing and
> issuing of certificates, OCSP responder certificate, revocation of
> certificates, issuing and publishing of CRLs etc. It would be NOT normal
> to have NO entries in a CRL for an end-user certificate issuing CA.
> The correct answer is, that we recently re-issued the
> intermediate EV CA certificate in order to correct a minor deficiency in
> the certificate. It uses the same keys and hence continued the
> operations of the previous certificate.
Private keys also have (or MUST have, more precisely) maximum lifetimes.
Your "Policy & Practice Statements" document, which I don't consider a
state-of-the-art CP/CPS (due to its lack of an RFC 3647 based structure,
mostly), should actually contain stipulations about things like key-pair
reuse, certificate renewal etc. Since it's lacking this sort of
information, I take at least the statement "Certificate shall be valid
for 10 years" on page 24 to imply that the key-pair of the EV issuing CA
will be used for 10 years at most. If you used that key pair to sign a
certificates which was revoked in May 2008, then the current EV ICA
certificate issued for the same key pair can hardly have a notAfter date
set to January 2019. At least the notAfter date of that ICA certificate
needs to be adjusted, and doing the same for the notBefore date seems
reasonable (given that it's usually understood as the "date of creation"
of a particular CA).
>> 5a) an empty issuerAltName extension (yes, completely empty). Of course
>> RFC 5280 specifies a different syntax for this extension:
>> "GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName"
>>
>
> We'll check if this should be corrected or not.
Of course it MUST. Quoting the EV guidelines appendix B, section 2: "All
other fields and extensions set in accordance to RFC 3280."
>> 5b) a CRLDP extension with an entry for
>> http://crl.startssl.com/sfsca.crl, which again brings us to a v1 CRL.
>> This time it's even one with an MD5 signature (already long before 25C3,
>> using MD5 for hashing was definitely not considered best current practice).
>>
>
> The threat and attack pattern of 25C3 doesn't apply to CRLs. This is one
> of the reasons why we opted not to replace the CRL in question until
> next issuance.
For a root CA which was created in September 2006, it's really bad
practice to use MD5 for hashing, irrespective of whether the attack
demonstrated at 25C3 applies to that specific case or not. It was
definitely not best current practice in September 2008, nor in the years
before.
>> 6) Looking at appendix C of the EV guidelines, we find the statement:
>> "The CA MUST host test Web pages that allow Application Software Vendors
>> to test their software. At a minimum, the CA MUST host separate Web
>> pages using certificates that are (a) valid (b) revoked and (c)
>> expired." - Could URLs for (b) and (c) please be provided?
>>
>
> I think we've been through this one also already at this list previously
> since it's hard to provide an expired certificate just after completion
> of the EV readiness audit.
Nothing prevents you from issuing an EV SSL cert with a validity of one
day only. And as you say that the "basis of your initial work" was draft
11 of the EV guidelines (published in October 2006), I expect that in
the past 2.5 years you certainly issued certificates during your Beta
program which have expired by now, or am I missing something?
> However I'll look into providing a site with a revoked certificate.
At bad.startcom.org [192.116.242.26] port 443, I currently get the
certificate with serial number 0x7f, with CN=cert.startcom.org, and the
following subjectAltName entries:
cert.startcom.org
startcom.org
linux.startcom.org
talk.startcom.org
bugzilla.startcom.org
forum.startcom.org
blog.startcom.org
wiki.startcom.org
This isn't a proper test site for revocation checking - not all clients
possibly perform revocation checking before they check host name
equivalence. Please configure a (revoked) certificate which has at least
a subjectAltName entry for bad.startcom.org.
Kaspar
Eddy Nigg
Given the fact that it only got the "Information confirmed complete" status on 2009-03-10, I wonder why other requests which changed to "Information confirmed complete" quite some time ago (e.g. bug 455878 [2008-11-25], or 409235 [2008-09-11], or 453460 [2008-11-19]) have been in the queue for a much longer period.
Maybe when adding a completely new root (where EV is "combined" with setting the SSL trust bit). I would yet have to see a another request which combines code signing with EV SSL - and again, the subject of this thread is still misleading.
Is there any concern or valid objection to not enable the code signing bit which would require separating the discussion? Else we can just skip this complaint perhaps and continue...
Well, then if this Beta program has been running for some time, why did E&Y not have a closer look at your infrastructure? Did E&Y not notice any of the shortcomings I listed previously? Makes their audit appear rather cursory.
What do you know about StartCom's Beta program?
For how long has it been running?
When had the infrastructure become operational?
When was the first EV certificate issued?
What does the EV readiness audit entail?
What did the auditor confirm?
If you have any problem with this approach, go back to the CA/Browser forum and request changes to the current requirements and practices.
Also minor deficiencies are to be expected and that's why we run a Beta program (as compared to many others). We'll exit the Beta program according to plan, which includes the processing of our applications at some browser vendors at least and until we are reasonable sure that we comply to the EV guidelines.
For comparison please read one of your own comments about a major CA which omitted the country field in their EV certs: https://bugzilla.mozilla.org/show_bug.cgi?id=466488#c4
It is not. First, if the person signs a form which is called
"Acknowledgement of the StartCom Extended Validation Subscriber
Agreement", then 1) there has to be such a document ("Subscriber
Agreement") and b) it must include all requirements set forth in section
12 of the EV guidelines. Even if we consider your "Policy & Practice
Statements" document as the "Subscriber Agreement", where e.g. does it
have a stipulation regarding item (b)(5) of said guidelines? Or item
(b)(3), for that matter?
So, when can we expect 1) the "Policy & Practice Statements" document to be updated accordingly
2) all existing certificates issued with the 1.3.6.1.4.1.23223.2 policy OID, but lacking the business category attribute to be revoked and replaced?
RFC 5280 says that "the URI MUST point to [...] a single DER encoded certificate".
When CRLs are issued, the CRLs MUST be version 2 CRLs, include the date by which the next CRL will be issued in the nextUpdate field (section 5.1.2.5), include the CRL number extension (section 5.2.3), and include the authority key identifier extension (section 5.2.1).
Of course it MUST. Quoting the EV guidelines appendix B, section 2: "All other fields and extensions set in accordance to RFC 3280."
The threat and attack pattern of 25C3 doesn't apply to CRLs. This is one of the reasons why we opted not to replace the CRL in question until next issuance.For a root CA which was created in September 2006, it's really bad practice to use MD5 for hashing, irrespective of whether the attack demonstrated at 25C3 applies to that specific case or not. It was definitely not best current practice in September 2008, nor in the years before.
Nothing prevents you from issuing an EV SSL cert with a validity of one day only. And as you say that the "basis of your initial work" was draft 11 of the EV guidelines (published in October 2006), I expect that in the past 2.5 years you certainly issued certificates during your Beta program which have expired by now, or am I missing something?
But no, we don't have any expired EV certs at the moment. As you might recall, the first entry in the CRL is from May 2008 which hasn't expired yet. Nor would those test certificates be any good I suspect.
This isn't a proper test site for revocation checking - not all clients possibly perform revocation checking before they check host name equivalence.
As such, and even though I appreciate the expected and anticipated added scrutiny and your finding of some minor deficiencies - which is certainly going to be helpful for us, I wonder if you have any real concerns to voice or any other objection which should prevent enabling of the EV OID for StartCom in Mozilla software? In my opinion, StartCom complies in full to the Mozilla CA Policy and doesn't have to declare any problematic practice!
Eddy Nigg
>
>> When CRLs are issued,
>> the CRLs MUST be version 2 CRLs, include the date by which the next
>> CRL will be issued in the nextUpdate field (section 5.1.2.5), include
>> the CRL number extension (section 5.2.3), and include the authority
>> key identifier extension (section 5.2.1).
>>
>
> Thanks, point taken. As indicated in the previous mail, we'll follow
> up on this.
I've followed up on this and at the moment I can't see anywhere any
requirement that CRLs should be or must be version 2. Can you point me
to the exact section in the EV guidelines which says so? Appendix B
doesn't deal with CRLs at all and refer to x.509 v3 certificates only.
It mentions that "all other fields and extensions are set in accordance
to RFC 3280" beyond the ones explicitly defined. Additionally the errata
to the guidelines doesn't specify anything either, but says "replace
'RFC3280' with 'RFC5280' throughout the document. "
According to my interpretation there is no such requirement!
Eddy Nigg
>> other fields and extensions set in accordance to RFC 3280."
>>
>
> Again, we'll check if, when and how this should be corrected. Thanks
> again for the pointer anyway.
Also here, following RFC 3280 and 5280 the issuerAltName has no MUST
clause disallowing a non-empty X.500 distinguished name like the issuer
name requires. In particular issuer alternative names are not used in
name chaining and name constraints are not enforced.
I agree that an empty value in the issuerAltName is perhaps a bit
unlucky, however not critical at all that it would prevent correct
functioning in any applicable software nor is it required by the EV
guidelines.
Eddy Nigg
On 04/15/2009 02:26 PM, Kaspar Brand:
Nothing prevents you from issuing an EV SSL cert with a validity of one day only. And as you say that the "basis of your initial work" was draft 11 of the EV guidelines (published in October 2006), I expect that in the past 2.5 years you certainly issued certificates during your Beta program which have expired by now, or am I missing something?
I'm not aware that an expired certificate ever was requested here - certainly not in the public discussion. At the most a site with a valid EV certificate was requested at the bug...not even revocation checking was EVER performed if I follow the bugs correctly...
To add some more information to this issue, which apparently greatly concerns you..... how would you explain this bug?
https://bugzilla.mozilla.org/show_bug.cgi?id=477244
Can you point me to anywhere in bugzilla where revocation checking with any of these CAs was EVER performed and confirmed successfully? Can you point me to any other CA that had the EV OID enabled and revocation checking has been EVER done successfully and confirmed? Can you point me to any bug in all of bugzilla where expiration of an EV certificate was tested and confirmed? Please note that there are most likely more than 15 CAs enabled for EV already....
...can you show me where you ever voiced your concern about the procedures for enabling CAs in general and for EV OIDs in particular? Did you ever raise your voice to have CAs tested for revocation? Did anybody else (besides me) raise the concern that CA which don't operate a working OCSP provider will have no means for signaling revocation of a certificate with Mozilla software - specially in conjunction with EV certificates?
Kaspar Brand
> Is there any concern or valid objection to not enable the code
> signing bit which would require separating the discussion? Else we
> can just skip this complaint perhaps and continue...
I don't really bother about the code signing part of this request, as
long as we're not considering *EV* code signing certs (which Mozilla
currently doesn't support). I leave it to other readers of this newgroup
to address this part of the request.
> What do you know about StartCom's Beta program? For how long has it
> been running? When had the infrastructure become operational? When
> was the first EV certificate issued? What does the EV readiness audit
> entail? What did the auditor confirm?
I don't think it's my job to answer these questions, but let's recall:
you stated that "Version 1.0 – Draft 11 [...] was the basis of
our initial work", so I guess that was certainly before June 2007 (at
that time V1.0 was published). Do you now want to say that you didn't
issue a single "EV" certificate between June 2007 and December 2008? Not
even the one with serial number 02, which was revoked in May 2008?
In any case, leaving a 2-page EV policy appendix in draft state for more
than half a year seems rather odd. At least when the first audit was
completed, it should have been declared final.
> For comparison please read one of your own comments about a major CA
> which omitted the country field in their EV certs:
> https://bugzilla.mozilla.org/show_bug.cgi?id=466488#c4
Wrong approach, sorry. This EV enablement request is about the
compliance of *your* CA with the EV guidelines. Fingerpointing at
competitors which fail to meet the guidelines doesn't change any
requirements applying to *your* CA.
> I'm not going to comment on this, since it's entirely out of scope in
> respect to the EV enablement request and a matter of legal
> implementations and interpretation.
Of course it's well within the scope of your EV enablement request. See
item 4 of the WebTrust EV Audit Criteria.
> Leave that to the auditors for this years audit.
A point-in-time record is not a blank check for postponing any changes
to the next yearly audit. It's the obligation of the CA to make sure
that it complies with the EV requirements at any time (and to fix issues
which are brought to its attention on an ongoing basis).
>> So, when can we expect 1) the "Policy& Practice Statements"
>> document to be updated accordingly
>
> IF we add it to this policy, it will be most likely not before our
> planned update cycle this summer. However it's in any case covered
> implicit in the "Extended Validation Certificates Policy Appendix".
What's the value of that policy document, then, if it's not accurately
stating what your CA does? As a relying party, if I'm now looking at
that document, do I have to read these sections like "the certificates
we currently issue may or may not have these properties, but please
check back later for updated versions of this policy"?
>> RFC 5280 says that "the URI MUST point to [...] a single DER
>> encoded certificate".
>
> A shortcut is a valid URI. It's not a redirect.
Did you ever see DER encoded data start with ----BEGIN CERTIFICATE-----?
>> When CRLs are issued, the CRLs MUST be version 2 CRLs, include the
>> date by which the next CRL will be issued in the nextUpdate field
>> (section 5.1.2.5), include the CRL number extension (section
>> 5.2.3), and include the authority key identifier extension (section
>> 5.2.1).
>>
>
> Thanks, point taken. As indicated in the previous mail, we'll follow
> up on this.
> I've followed up on this and at the moment I can't see anywhere any
> requirement that CRLs should be or must be version 2. Can you point me
> to the exact section in the EV guidelines which says so?
Why should the EV guidelines specify things which are explicitly stated
in the RFC? It's pretty obvious that the EV guidelines expect the CAs to
be compliant with RFC 3280/5280, no?
>> Of course it MUST. Quoting the EV guidelines appendix B, section 2:
>> "All other fields and extensions set in accordance to RFC 3280."
>>
>
> Again, we'll check if, when and how this should be corrected. Thanks
> again for the pointer anyway.
> Also here, following RFC 3280 and 5280 the issuerAltName has no MUST
> clause disallowing a non-empty X.500 distinguished name like the issuer
> name requires.
Just because the text in that particular section doesn't explicitly
disallow the extension to be empty doesn't mean that such a cert is
conforming to the syntax specified in RFC 5280. Look again at its ASN.1
definition:
IssuerAltName ::= GeneralNames
GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName
GeneralName ::= CHOICE {
otherName [0] AnotherName,
rfc822Name [1] IA5String,
dNSName [2] IA5String,
x400Address [3] ORAddress,
directoryName [4] Name,
ediPartyName [5] EDIPartyName,
uniformResourceIdentifier [6] IA5String,
iPAddress [7] OCTET STRING,
registeredID [8] OBJECT IDENTIFIER }
What your EV ICA cert has, however, is an *empty* GeneralNames SEQUENCE.
Empty is definitely not what SIZE (1..MAX) requires. Your cert violates
the syntax of RFC 5280 - it's as simple as that. No further arguing needed.
> I'm not aware that an expired certificate ever was requested here -
> certainly not in the public discussion. At the most a site with a
> valid EV certificate was requested at the bug...not even revocation
> checking was EVER performed if I follow the bugs correctly...
Again, it's not relevant how other requests were processed, the question
is whether your CA complies with the EV requirements.
> As such, and even though I appreciate the expected and anticipated
> added scrutiny and your finding of some minor deficiencies - which
> is certainly going to be helpful for us, I wonder if you have any
> real concerns to voice or any other objection which should prevent
> enabling of the EV OID for StartCom in Mozilla software? In my
> opinion, StartCom complies in full to the Mozilla CA Policy and
> doesn't have to declare any problematic practice!
It's not me who is going to be the judge in this case, obviously - maybe
you're successful in simply declaring all these shortcomings as "minor"
and downplaying their relevance... we'll see. I wouldn't be surprised to
find further issues when examining your "Policy & Practice Statements"
document (e.g., what kind of certification does the HSM for your root
keys have?), but that would actually have been the job of E&Y, not mine.
Kaspar
Kyle Hamilton
> On 04/15/2009 02:26 PM, Kaspar Brand:
>
> day only. And as you say that the "basis of your initial work" was draft
> 11 of the EV guidelines (published in October 2006), I expect that in
> the past 2.5 years you certainly issued certificates during your Beta
> program which have expired by now, or am I missing something?
>
>
> I'm not aware that an expired certificate ever was requested here -
> certainly not in the public discussion. At the most a site with a valid EV
> certificate was requested at the bug...not even revocation checking was EVER
> performed if I follow the bugs correctly...
>
> But no, we don't have any expired EV certs at the moment. As you might
> recall, the first entry in the CRL is from May 2008 which hasn't expired
> yet. Nor would those test certificates be any good I suspect.
Can you create a certificate (for your own company) signed under the
EV policy that is only valid for two minutes from time-of-signing, set
it up on another IP, and then point us to it once it's expired?
>
> This isn't a proper test site for revocation checking - not all clients
> possibly perform revocation checking before they check host name
> equivalence.
>
> Just for the record, which clients exactly don't perform the revocation
> checking first? Firefox? Thunderbird? SeaMonkey? Else? But this is a small
> request I'll gladly comply.
>
> As such, and even though I appreciate the expected and anticipated added
> scrutiny and your finding of some minor deficiencies - which is certainly
> going to be helpful for us, I wonder if you have any real concerns to voice
> or any other objection which should prevent enabling of the EV OID for
> StartCom in Mozilla software? In my opinion, StartCom complies in full to
> the Mozilla CA Policy and doesn't have to declare any problematic practice!
To be perfectly honest (I would say 'to be perfectly frank', but I
don't want to give anyone any indication that I'm trying to be
perfectly Frank ;)):
I'd rather see StartCom included than Verisign. I'd rather see
StartCom included than Thawte. I'd certainly rather see StartCom
included than the Lithuanian "it is software makers' duty to comply
with national law" folks. I'd also rather see StartCom included than
Comodo, which problematic practices were identified and still allowed
to enter the root program. I've seen the process by which SC issues
their certificates, I've seen how easily their workflow can be logged,
and we've even seen a situation where they identified a deficiency in
their workflow and publicly disclosed it, as well as the resolution.
I have more trust in StartCom than any other commercial CA. There are
certainly a few deficiencies (such as not disclosing exactly which
versions of which standards they built their system around, so that
their externally-visible interfaces can be audited by users without
bringing incorrect criteria into play), but on the whole I'd rather
see them than most anyone else.
I must, however, point out that I may not be viewed as unbiased in
this topic. I am not an employee of StartCom, and I do not have any
interest in StartCom (except as an example of a CA done right)... but
my perception is that I've agreed with Eddy too often in the past to
be considered an "unbiased voice" (even though he and I have also
disagreed very often). If my viewpoint is deemed sufficiently
unbiased:
I recommend the enablement of EV and code trust bits for the "StartCom
Certification Authority".
-Kyle H
Eddy Nigg
On 04/15/2009 11:34 PM, Kaspar Brand:
I don't really bother about the code signing part of this request, as long as we're not considering *EV* code signing certs (which Mozilla currently doesn't support).
What do you know about StartCom's Beta program? For how long has it been running? When had the infrastructure become operational? When was the first EV certificate issued? What does the EV readiness audit entail? What did the auditor confirm?I don't think it's my job to answer these questions, but let's recall: you stated that "Version 1.0 – Draft 11 [...] was the basis of our initial work", so I guess that was certainly before June 2007 (at that time V1.0 was published). Do you now want to say that you didn't issue a single "EV" certificate between June 2007 and December 2008? Not even the one with serial number 02, which was revoked in May 2008?
In any case, leaving a 2-page EV policy appendix in draft state for more than half a year seems rather odd. At least when the first audit was completed, it should have been declared final.
For comparison please read one of your own comments about a major CA which omitted the country field in their EV certs: https://bugzilla.mozilla.org/show_bug.cgi?id=466488#c4Wrong approach, sorry. This EV enablement request is about the compliance of *your* CA with the EV guidelines. Fingerpointing at competitors which fail to meet the guidelines doesn't change any requirements applying to *your* CA.
Besides that, I wanted to signal to the Dear Reader, that deficiencies can happen and there are policies, controls and guidelines on how to deal with them. That's important to understand first of all because usually EV OID enablement requests weren't dissected to this extend (usually not at all, since it's regulated by the EV guidelines and audited accordingly, hence we know what we get), a process I've been part of most of the times here.
The only exception was with CAs which were inherited from the Netscape era and which never underwent an inclusion process for their roots. However this is not a request to include a new root, it's to enable the code signing bit and EV OID.
As such I don't mind your interest in this specific request, including the added scrutiny which is only good, but obviously at the end of the day I expect that we handle this request at least somewhat similar to the current practice for enabling EV OIDs. :-)
And in this respect I am the opinion (obviously and understandably) that StartCom complies with the Mozilla CA Policy requirement - its by-laws and other criteria which exist, including current practice for enabling EV OIDs - in full. See also below...
I'm not going to comment on this, since it's entirely out of scope in respect to the EV enablement request and a matter of legal implementations and interpretation.Of course it's well within the scope of your EV enablement request. See item 4 of the WebTrust EV Audit Criteria.
Leave that to the auditors for this years audit.A point-in-time record is not a blank check for postponing any changes to the next yearly audit. It's the obligation of the CA to make sure that it complies with the EV requirements at any time (and to fix issues which are brought to its attention on an ongoing basis).
IF we add it to this policy, it will be most likely not before our planned update cycle this summer. However it's in any case covered implicit in the "Extended Validation Certificates Policy Appendix".What's the value of that policy document, then, if it's not accurately stating what your CA does? As a relying party, if I'm now looking at that document, do I have to read these sections like "the certificates we currently issue may or may not have these properties, but please check back later for updated versions of this policy"?
The StartCom CA policy is subject to changes and it is the responsibility of the
subscribers and relaying party's to review the policy from time to time. All changes,
if at all, including the CA policy itself are published at the designated web site for
the CA operations. Subscribers and relaying parties will not be notified of impending
changes of the policy. The policy is legally binding from the moment of its
publication.
RFC 5280 says that "the URI MUST point to [...] a single DER encoded certificate".A shortcut is a valid URI. It's not a redirect.Did you ever see DER encoded data start with ----BEGIN CERTIFICATE-----?
Since Firefox very, very unfortunately doesn't fetch the issuer certificates published in the AIA caIssuers extension and Explorer is happy with almost anything thrown at it, it never came to my attention that PEM encoded certificates are not compliant. I admit and take personally responsibility for it. Even when you highlighted it for me I didn't saw the obvious which I see now...
I've followed up on this and at the moment I can't see anywhere any requirement that CRLs should be or must be version 2. Can you point me to the exact section in the EV guidelines which says so?Why should the EV guidelines specify things which are explicitly stated in the RFC? It's pretty obvious that the EV guidelines expect the CAs to be compliant with RFC 3280/5280, no?
IssuerAltName ::= GeneralNames
GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName
GeneralName ::= CHOICE {
otherName [0] AnotherName,
rfc822Name [1] IA5String,
dNSName [2] IA5String,
x400Address [3] ORAddress,
directoryName [4] Name,
ediPartyName [5] EDIPartyName,
uniformResourceIdentifier [6] IA5String,
iPAddress [7] OCTET STRING,
registeredID [8] OBJECT IDENTIFIER }
What your EV ICA cert has, however, is an *empty* GeneralNames SEQUENCE.
Empty is definitely not what SIZE (1..MAX) requires. Your cert violates
the syntax of RFC 5280 - it's as simple as that. No further arguing needed.
Again, it's not relevant how other requests were processed, the question is whether your CA complies with the EV requirements.
However the real question is NOT if we comply to the EV requirements, but if we comply to the requirements of Mozilla! There is a difference between those two!
Kyle Hamilton
> However the real question is NOT if we comply to the EV requirements, but if
> we comply to the requirements of Mozilla! There is a difference between
> those two!
There is... but one of the most important things to realize is that
Mozilla's EV requirements are equal to the requirements of the CA/B
Forum's EV requirements. Thus, if you do not comply to the EV
requirements, you do not comply with Mozilla's requirements.
-Kyle H
Eddy Nigg
On 04/16/2009 12:06 AM, Kyle Hamilton:
> Can you create a certificate (for your own company) signed under the
> EV policy that is only valid for two minutes from time-of-signing, set
> it up on another IP, and then point us to it once it's expired?
>
Not without performing changes at the application levels, which would
require authorization, shutting access to the web interfaces and
reversing those changes thereafter. It's something I'd rather not
do...at least not from the production environment...
...as such I question the usefulness of this requirement really. What is
it that should be tested with an EV certificate and nothing less, which
couldn't be tested otherwise? Expiration? I'm not sure how reasonable
this really is...
> I must, however, point out that I may not be viewed as unbiased in
> this topic. I am not an employee of StartCom, and I do not have any
> interest in StartCom (except as an example of a CA done right)... but
> my perception is that I've agreed with Eddy too often in the past to
> be considered an "unbiased voice" (even though he and I have also
> disagreed very often). If my viewpoint is deemed sufficiently
> unbiased:
>
> I recommend the enablement of EV and code trust bits for the "StartCom
> Certification Authority".
>
>
Thank you for your honest support and (possibly unbiased)
recommendation! :-)
Eddy Nigg
We consider verification of certificate signing requests to be acceptable if it meets or exceeds the following requirements:
for certificates to be used for and marked as Extended Validation, the CA complies with Guidelines for the Issuance and Management of Extended Validation Certificates (as modified by the erratum published by the CAB Forum) (or, for CA requests submitted on or before June 30, 2008, draft 11 of these guidelines), and has its compliance attested to in accordance with the requirements of Section J of that document.
...and...
We consider the criteria for CA operations published in any of the following documents to be acceptable:
"WebTrust for Certification Authorities—Extended Validation Audit Criteria" in WebTrust for Certification Authorities—Extended Validation Audit Criteria (or, for CA requests received on or before June 30, 2008, the November 20, 2006 draft of these criteria) (in conjunction with "WebTrust Principles and Criteria for Certification Authorities").
And it seems that you are principally correct, since the policy states the CA complies with the EV guidelines and has its compliance attested to in accordance with the requirements... this is the requirement of Mozilla.
But if I turn it around a bit: ...has its compliance with the EV guidelines attested in accordance with the requirements... which has been mainly my understanding and interpretation of the policy. We have (and I must say mostly I have) shifted the compliance to the audit mostly and not bothered to review CAs on compliance to the EV guidelines. Because we know what the guidelines are and attestation is provided according to those guidelines...
Kyle Hamilton
-Kyle H
Kaspar Brand
> That's quite correct. Which means, various certificates were issued for
> testing purpose at various stages leading up to December 2008. We were
> not under any pressure obviously due to the ongoing audit. This included
> of course all steps from policy definitions up to the actual implementation.
Fine. Given that E&Y wrote its point-in-time record on 31 December 2008,
I assume that they were certainly be able to get EV "sample"
certificates issued by your CA, correct? But apparently they failed to
check whether they meet the EV requirements, otherwise they would have
pointed out that the business category attribute is missing.
> Besides that, I wanted to signal to the Dear Reader, that deficiencies
> can happen and there are policies, controls and guidelines on how to
> deal with them.
And your guidelines say "wait for the next audit to come - if the
auditor doesn't require us to change things, then leave them as is"?
>>> I'm not going to comment on this, since it's entirely out of scope in
>>> respect to the EV enablement request and a matter of legal
>>> implementations and interpretation.
>>>
>> Of course it's well within the scope of your EV enablement request. See
>> item 4 of the WebTrust EV Audit Criteria.
>>
>
> With all due respect (and I do have respect for you), you are not our
> auditor and StartCom doesn't have to disclose anything to you or anybody
> else for that matter, which it isn't required to disclose in its CP/CPS
> according to the relevant audit criteria. You answered this one actually
> almost by yourself by pointing to the audit criteria. In short, I'm not
> going to discuss it further, sorry.
Just ignoring the requirement and pointing to your audit doesn't make
that problem go away. Let me restate:
a) as a relying party, I need to be sure that the CA issues its "EV"
certificates according to the requirements of the EV guidelines. These
state, on page 16:
> (b) Agreement Requirements The Subscriber Agreement MUST, at a minimum,
> specifically name both Applicant and the individual Contract Signer signing the
> Agreement on Applicant’s behalf, and contain provisions imposing on Applicant
> the following obligations and warranties: [...]
> (3) Acceptance of EV Certificate An obligation and warranty that it will not
> install and use the EV Certificate(s) until it has reviewed and verified the
> accuracy of the data in each EV Certificate; [...]
> (5) Reporting and Revocation Upon Compromise An obligation and warranty to
> promptly cease using an EV Certificate and its associated Private Key, and
> promptly request the CA to revoke the EV Certificate, in the event that: (a)
> any information in the EV Certificate is or becomes incorrect or inaccurate, or
> (b) there is any actual or suspected misuse or compromise of the Subscriber’s
> Private Key associated with the Public Key listed in the EV Certificate;
b) Looking at the documents which you seem to use when processing an EV
request, I have serious doubts whether you meet these requirements. You
definitely didn't invalidate my concerns so far, since you fail to point
out the relevant sections in either your "Policy & Practice Statements"
document or that (possibly non-existing?) "StartCom Extended Validation
Subscriber Agreement".
> This is however also one of the reasons why we are not going to reload
> the intermediate CA certificate in a hurry
Did I anywhere say that you should do so? What I'm saying is that the EV
ICA certificate, as it exists today, does not meet the EV guidelines.
Based on this fact, I would certainly not recommend that Mozilla enables
EV for this CA right now. You're quite welcome to cut another
certificate for that key pair (with all due care), and I would also
warmly recommend to think again about that 10-year lifetime of the key
pair (and the consequences on setting notBefore/notAfter accordingly).
>> What's the value of that policy document, then, if it's not accurately
>> stating what your CA does? As a relying party, if I'm now looking at
>> that document, do I have to read these sections like "the certificates
>> we currently issue may or may not have these properties, but please
>> check back later for updated versions of this policy"?
>>
>
> Bingo! StartCom CA Policy and Practice Statement, section "Change
> Management":
>
> The StartCom CA policy is subject to changes and it is the
> responsibility of the
> subscribers and relaying party's to review the policy from time to time.
> All changes,
> if at all, including the CA policy itself are published at the
> designated web site for
> the CA operations. Subscribers and relaying parties will not be notified
> of impending
> changes of the policy. The policy is legally binding from the moment of its
> publication.
Read my statement again. The point is that your policy needs to be
accurate at the time you issue certificates (and not be updated three
months after you've changed your procedures [apart from the fact that
I'm not a "relaying party", so that stipulation doesn't really apply to
me, actually]). Professional CAs also maintain an archive of their past
CP/CPS versions, BTW.
> Nope...the guidelines need to define, not expect. I have not found any
> definition which requires directly or implicit that CRLs must be of any
> version.
Do you really think the EV guidelines need to state every requirement
which a CA has to meet? E.g., just because neither the EV guidelines nor
the Webtrust program explicitly require CAs to use certified HSMs for
storing CA keys - would it therefore be ok to use softokens in all these
cases?
Do you want to say that you don't care about RFC 2459/3280/5280 when
your CA issues certificates? What specific standards do you use, then?
Kaspar
Eddy Nigg
> Fine. Given that E&Y wrote its point-in-time record on 31 December 2008,
> I assume that they were certainly be able to get EV "sample"
> certificates issued by your CA, correct?
No, you got that totally wrong! We were not issuing any EV certificates
at all until completion of the audit. Hence they were not supposed to
take sample certificates for EV (at least if I remember that part
correctly). Rather they audited the controls in place which leads to
compliance to the EV guidelines. There is also a difference in the
methodology concerning the readiness and the successive audit. But do I
really have to defend the audit criteria and methodology here? Are you
seriously putting the competence of Ernst&Young in question?
Most likely you imagine some auditors running around the place with
copies of the RFCs under their arms....well, those aspects make up a
very small part of the audit really....and it's a small part of the
overall CA business too (important yes, by no means exclusively).
> And your guidelines say "wait for the next audit to come - if the
> auditor doesn't require us to change things, then leave them as is"?
>
Where does it say so? However compliance (to the practices and controls)
is confirmed at the next audit, that's correct!
> Just ignoring the requirement and pointing to your audit doesn't make
> that problem go away.
There is no problem as far as I'm concerned.
> a) as a relying party, I need to be sure that the CA issues its "EV"
> certificates according to the requirements of the EV guidelines.
Are you going to sign our next audit report? To my understanding as a
relying party you've got the audit statement confirming compliance to
the EV guidelines. And the CP/CPS meets the disclosure requirements of
Mozilla. Disclosure beyond the CP/CPS is NOT your business!
You are however invited to suggest changes to the current policy and
other relevant requirements and practices of the inclusion process of
Mozilla. StartCom will most likely comply to them fully or not insist on
being part of the CA root pile.
> b) Looking at the documents which you seem to use when processing an EV
> request, I have serious doubts whether you meet these requirements.
Which is your complete basic right.
> definitely didn't invalidate my concerns so far, since you fail to point
> out the relevant sections in either your "Policy& Practice Statements"
> document or that (possibly non-existing?) "StartCom Extended Validation
> Subscriber Agreement".
>
No, this particular aspect I'm not going to discuss with you. At the
most, Mozilla could request a statement from our auditor attesting IF we
meet that requirement, however I'm not going to show you HOW we are
meeting this requirement. It's up to the auditor to judge. But well,
Mozilla just received that statement, didn't it....?!
Besides that, I'm very positive that StartCom meets this requirement in
full! :-)
> Did I anywhere say that you should do so? What I'm saying is that the EV
> ICA certificate, as it exists today, does not meet the EV guidelines.
>
OK, lets leave the decision, if an empty issuerAltName extension is
reason enough to delay enablement of the StartCom EV OID to Fank at the
moment. We both voiced our opinion on this particular issue and I
explained our intentions.
> Read my statement again. The point is that your policy needs to be
> accurate at the time you issue certificates
Which it is. It's legally binding from the moment of publishing, even if
in this case the status is currently draft. The main document which is
not draft, has also to say a thing or two in this respect....
Besides, the EV guidelines themselves (and auditing and acceptance) were
subject to a draft version. Every concerned party had to bend over to
make EV a reality here and elsewhere...you can read it right up there at
the Mozilla CA Policy. How come a a policy in its final stages should
present a problem to Mozilla? More than that, it wouldn't be a precedent
at Mozilla to accept and confirm a root prior to finalizing the CP/CPS.
> Professional CAs also maintain an archive of their past
> CP/CPS versions, BTW.
>
Duuuh?!
>> Nope...the guidelines need to define, not expect. I have not found any
>> definition which requires directly or implicit that CRLs must be of any
>> version.
>>
> Do you really think the EV guidelines need to state every requirement
> which a CA has to meet?
Yes. If something isn't defined (directly or implicitly) there is simply
no requirement. Oh wait....perhaps I should activate my telepathic
capabilities and follow any imaginary requirement Kaspar wants us to
follow....
> E.g., just because neither the EV guidelines nor
> the Webtrust program explicitly require CAs to use certified HSMs for
> storing CA keys - would it therefore be ok to use softokens in all these
> cases?
Mmmh....I think you don't know the criteria at all, do you?
Ian G
> Hey, Ian, got any comment on this?
I have not evaluated the CA of the moment, so the following remarks are
trying to concentrate on the principles more than the facts.
> On Wed, Apr 15, 2009 at 4:37 PM, Eddy Nigg<eddy...@startcom.org> wrote:
...
>> But if I turn it around a bit: ...has its compliance with the EV guidelines
>> attested in accordance with the requirements... which has been mainly my
>> understanding and interpretation of the policy. We have (and I must say
>> mostly I have) shifted the compliance to the audit mostly and not bothered
>> to review CAs on compliance to the EV guidelines. Because we know what the
>> guidelines are and attestation is provided according to those guidelines...
Personally, I think that is the only smart thing that Mozilla can do
here: leave the bulk of the checking to the audit, and then rely on it,
even if it looks odd at times. This is economic, because it doesn't
make a lot of sense for us to re-do the work, when the auditor has done
it, and when presumably the audit is able to see things we can't see,
and has a fuller understanding of the real whys & wherefores. In the
absence of an open approach to CAs (open governance, in the style of
open source), the basic concept of the audit seeing inside the CA is
still logical.
There are arguments against this.
1. Firstly, as presented recently, the audit is only a first step, and
the second step is as relying party by Mozilla. (I note that this is
simply a proposal not policy; and I myself have frequently said that
Mozilla acts "as if" it were the relying party.)
This argument doesn't really say that much because as a relying party
you don't care about compliance much at all, you care about whether you
can rely on the result. For your use of the certs, etc.
2. Secondly, the old argument is whether the audit is doing a good job.
Undoubtadly, some audits are not doing a good job, and some are doing
a good job. According to writings on my blog, the issue is that it is
rather difficult for the outsider to determine which is which; we would
have to become experts in reading the tea-leafs of the audit report.
(Actually, maybe we are becoming that, as someone did note a rather
salient issue that questions the result.)
But, even if the audit is doing a bad job, the fix is not in any
particular audit, it is in the system. By all means, let us question
weaknesses in any particular audit, but be aware that this may be only
because, _this time we can see it_; it helps us not at all for the
times we can't see, and we should spend our energies fixing the system
for the benefit of the users.
3. Thirdly, there is the liability issue. If Mozilla does not treat
compliance with fullest respect, then as relying party it raises its own
liability in some future hypothetical lawsuit. But, Mozilla's liability
is now set to zero for end-users. So the question of whether the
liability is raised to some unreasonable amount has now been shifted to
the end-users. I personally would judge this as a reasonable risk, for
all sorts of analysis that I won't go into right now (and should
ultimately be done by real lawyers), but high on that list is this: the
only security is that delivered to users.
4. Fourthly, there is the quality issue. Is the quality of this
criteria so important that slavish compliance is the answer?
The answer has to be no. CA/Browser Forum themselves are on record as
saying that the rewrite to the rules does not address phishing, the very
thing that was the spark for their work. For all their years of work
and dozens of meetings and thousands of committee pages, they were not
able to achieve a strong anti-phishing result. They were able to
document comprehensively what the "best practices" were in CAs, so for
that it is a document of value _as a record of the mid-90s model_, and
this is Mozilla's reason of record for accepting the document. But the
document hasn't got enough relevance to today's real security issues to
actually be worth slavish attention. The short proof of this is that
making CAs stronger might be fun, but CAs have never ever been the
vector of breach, so worrying about CAs is not going to help end-users.
5. Fifthly, there is the argument that audit should deliver a complete
and perfect result. This is just wrong. Firstly, an audit is a
snapshot over a given time, so what is true today is not true tomorrow.
Secondly, it is based on "reasonableness". Which means, there may be
weaknesses. You might not like them, but others have made a judgement
call. Thirdly, real business is dynamic, and the auditor knows that.
Which is why part of the audit process is to look at whether the
business is doing a "snapshot" for the auditor, or whether the business
will implement the real controls, later on, after the auditor walks out
the door. It is fairly standard for some things to be fixed or changed
or bettered in the future, and indeed this itself is a proof that the CA
is implementing real controls.
6. Sixthly, there is the "eat your own dogfood" argument, where the CA
concerned has discovered many of its own comments & arguments used
against it. Delicious! Well, sure, as a timely reminder perhaps, but
be careful what you wish for: if we succeed, it simply proves that we
don't do the real review properly to the benefit of the end-users. This
is the classical "raise barriers to entry" argument found in basic
economics / b-school. Once we are "in" make sure the outsiders have to
comply to high/difficult/costly criteria, even if we don't, because that
reduces the number of upstarts. Some might argue this is the entire
point, but one thing is for sure, raising barriers doesn't help
Mozilla's end-users at all, it reduces their security overall.
Which is all to say, we should IMO fall back in this and like cases to
the economic approach: the auditor measures compliance (as indeed this
is their bailiwick) and Mozilla should think of whether there is
anything bad in there *for Mozilla end-users*.
Meanwhile, cast an eye to how we improve the system for the end-users.
This process isn't economic nor delivering lots of security to the
end-users. What's better?
iang
Eddy Nigg
>
> Meanwhile, cast an eye to how we improve the system for the end-users.
> This process isn't economic nor delivering lots of security to the
> end-users. What's better?
>
I would like to come back to this in about a week or so under a
different thread. :-)
Nelson Bolyard
> RFC 5280 says that "the URI MUST point to [...] a single DER encoded
> certificate".
Well, that is a sentence fragment of what it says. I agree that the
response must conform to the RFC, by delivering one of the choices of
response defined by the RFC. But "a single DER encoded certificate" is not
the only choice it offers. I just want this thread to be clear about that.
Eddy Nigg
Right. I'm no stranger to this RFC obviously, but it somehow never
bothered me to send a PEM encoded certificate instead :-)
You see Nelson, we should have a standard compliant client for
that...I'm certain there is a bunch of CAs sending PEM encoded certs...
...wouldn't this be a good reason to fetch the chained certificates at
last? ;-)
Kaspar Brand
> at all until completion of the audit.
On 19 September 2008, when you filed bug 451298, you wrote in its first
comment:
> Web sites for checking of EV are available at https://forum.startcom.org and
> https://blog.startcom.org
I would be quite interested to know what end-entity and intermediate CA
certificates were configured at these sites in the period between 19
September 2008 and 31 December 2008.
> Are you seriously putting the competence of Ernst&Young in question?
I seriously wonder what happened in the time between 19 September
and 31 December, and why E&Y didn't (or didn't want to) take a look at
the certificates configured on the Web sites referenced in bug 451298.
> Most likely you imagine some auditors running around the place with
> copies of the RFCs under their arms....well, those aspects make up a
> very small part of the audit really....and it's a small part of the
> overall CA business too (important yes, by no means exclusively).
Hopefully they also checked a lot of other things, yes (security
plan, DR plans, BCP, risk assessments etc. - the full set of all that
stuff). But from looking at your "Policy & Practice Statements" document
I still maintain that at least as far as the disclosure of your business
practices is concerned, the audit was rather cursory.
>> a) as a relying party, I need to be sure that the CA issues its "EV"
>> certificates according to the requirements of the EV guidelines.
>
> Are you going to sign our next audit report? To my understanding as a
> relying party you've got the audit statement confirming compliance to
> the EV guidelines.
To put it differently: as a relying party, I need "some way to gauge how
much reliance [I] should place on a digital signature supported by a
certificate issued by a particular CA" (that's verbatim from the
WebTrust Program for CAs document, in case you wonder). A third-party
audit is not necessarily sufficient for this, and as the Webtrust
Program further states:
> The first principle is—-The certification authority discloses its key
> and certificate life cycle management business and information privacy
> practices and provides its services in accordance with its disclosed
> practices.
What is understood by disclosure of "key life cycle management" is
then detailed in items 16ff. relating to "Principle 1" of the Webtrust
criteria for "Principle 1" (p. 31ff). In case you didn't do so already,
I suggest that you make yourself familiar with them by reading the
relevant sections (the document can can be retrieved
from http://www.cica.ca/download.cfm?ci_id=45239&la_id=1).
> And the CP/CPS meets the disclosure requirements of Mozilla.
Are you sure? I would again recommend to have a closer look at what the
WebTrust Program for CAs specifically says on this topic.
> No, this particular aspect I'm not going to discuss with you. At the
> most, Mozilla could request a statement from our auditor attesting IF we
> meet that requirement, however I'm not going to show you HOW we are
> meeting this requirement.
Is it some kind of black magic, then? I don't see why you would need to
keep your subscriber agreement secret - none of the major CAs have a
problem with publishing these documents on their Web sites (as can be
easily verified by visiting a random sample of their repository pages).
> It's legally binding from the moment of publishing, even if
> in this case the status is currently draft. The main document which is
> not draft, has also to say a thing or two in this respect....
The latter is exactly the one I'm referring to. You are currently
issuing EV certificates which do not reflect what you state about their
exact content (subject DN) on page 23 of your policy. And if it's
"legally binding from the moment of publishing" (to use your words),
then I would assume that it's also "legally binding" for you as the CA.
And, taking another section of that document (page 26), your CA is
actually required to issue CRLs using the sha1WithRSAEncryption
algorithm, only - at least since 18th June 2008... which is another
reason to either (promptly) update your policy or (better) reissue the
CRL of your root CA with a SHA-1 hash.
> Yes. If something isn't defined (directly or implicitly) there is simply
> no requirement. Oh wait....perhaps I should activate my telepathic
> capabilities and follow any imaginary requirement Kaspar wants us to
> follow....
I'm not interested in continuing this discussion if it gets at a
personal level (I see absolutely no reason for doing so). But to use
another example: simply because the EV guidelines do not explicitly
state that by the "Online Certificate Status Protocol (OCSP) service"
referenced in section 26 they understand an implementation conforming to
RFC 2560, would your argument then be that the implementing CA is free
to choose what parts of RFC 2560 it wants to follow? ("RFC 2560" isn't
mentioned anywhere in the EV guidelines.)
>> E.g., just because neither the EV guidelines nor
>> the Webtrust program explicitly require CAs to use certified HSMs for
>> storing CA keys - would it therefore be ok to use softokens in all these
>> cases?
>
> Mmmh....I think you don't know the criteria at all, do you?
See above. If you find any paragraph in the Webtrust CA criteria which
makes any statement which can be taken as a minimum requirement for the
protection of CA keys (such as "a hardware security module certified
against FIPS 140-2 Level 3" or similar), then please point it out to me.
Another point I'm still interested in is your position re: RFC
2459/3280/5280, BTW.
Kaspar
Eddy Nigg
I would be quite interested to know what end-entity and intermediate CA certificates were configured at these sites in the period between 19 September 2008 and 31 December 2008.
Nevertheless, no EV certificates were issued prior to that to subscribers. And for clarification, I contacted one of our auditors this morning, and he recalled from memory that sampling of EV certificates was not part of the readiness audit. You are beating a dead horse here, give it up...
Are you seriously putting the competence of Ernst&Young in question?I seriously wonder what happened in the time between 19 September and 31 December, and why E&Y didn't (or didn't want to) take a look at the certificates configured on the Web sites referenced in bug 451298.
Hopefully they also checked a lot of other things, yes (security plan, DR plans, BCP, risk assessments etc. - the full set of all that stuff). But from looking at your "Policy & Practice Statements" document I still maintain that at least as far as the disclosure of your business practices is concerned, the audit was rather cursory.
To put it differently: as a relying party, I need "some way to gauge how much reliance [I] should place on a digital signature supported by a certificate issued by a particular CA" (that's verbatim from the WebTrust Program for CAs document, in case you wonder).
And without getting personal here - I don't know who sent you here or who's interests you represent or what your personal interests in StartCom are - however your intentions are rather obvious. You haven't reviewed or commented on any inclusion here during the last two years and you haven't shown any particular interest in the processes here either. I don't have a problem with it and can handle it just fine...just to state the obvious.
However you don't have a case here, no matter how much you question the usefulness of an accepted audit criteria or the competence of its authorized auditors. I know that it apparently hurts some in this industry and took them at surprise that StartCom fully complied to the criterion (and barriers of entry) the very same industry itself set up. StartCom has duly performed a WebTrust for CAs and EV audit according to all the criterion and requirements of the CA/Browser forum and browser vendors and nothing is going to prevent us from reaching our goals in this respect.
StartCom has complied and conforms to all the requirements of the EV guidelines (minor deficiencies notwithstanding which are being dealt with accordingly) and has provided attestation by one of the most respected audit firms in this field. Also is StartCom insured according to the EV guidelines by one of the finest insurers currently on earth...(amazing what money can buy :D ). StartCom does not cause undue risks to users' security and conforms to the Mozilla CA Policy in every respect. StartCom isn't subject to any problem practice either. Anything else is pretty irrelevant IMO.
And the CP/CPS meets the disclosure requirements of Mozilla.Are you sure?
Is it some kind of black magic, then? I don't see why you would need to keep your subscriber agreement secret
The latter is exactly the one I'm referring to. You are currently issuing EV certificates which do not reflect what you state about their exact content (subject DN) on page 23 of your policy.
https://www.startssl.com/extended.pdf states in section "Commitment to Comply with Extended Validation Guidelines":
In the event of any inconsistency between this document and those guidelines, those guidelines take precedence over this document.
Yes. If something isn't defined (directly or implicitly) there is simply no requirement. Oh wait....perhaps I should activate my telepathic capabilities and follow any imaginary requirement Kaspar wants us to follow....I'm not interested in continuing this discussion if it gets at a personal level (I see absolutely no reason for doing so). But to use another example: simply because the EV guidelines do not explicitly state that by the "Online Certificate Status Protocol (OCSP) service" referenced in section 26 they understand an implementation conforming to RFC 2560, would your argument then be that the implementing CA is free to choose what parts of RFC 2560 it wants to follow? ("RFC 2560" isn't mentioned anywhere in the EV guidelines.)
https://bugzilla.mozilla.org/show_bug.cgi?id=477244#c58
The EV Guidelines state that "CAs MUST support an OCSP capability for Subscriber Certificates that are issued after Dec 31, 2010."
Interesting, it doesn't say which OCSP capability according to Robin. And than just below:
Also, note that the EV Guidelines *NEVER* absolutely require the Authority Info Access extension to be present in an EV Certificate!
That's Robin's interpretation as you see.... StartCom doesn't have an issue with OCSP since it operates an RFC 2560 compliant responder already for years. Just in case you missed it...
Have Fun!
Jean-Marc Desperrier
> I'm no stranger to this RFC obviously, but it somehow never bothered me
> to send a PEM encoded certificate instead :-)
>
> You see Nelson, we should have a standard compliant client for
> that...I'm certain there is a bunch of CAs sending PEM encoded certs...
If they do, they are wrong. I don't know about caIssuers, but you *will*
very fast have interoperability problems if you don't send your CRL DER
encoded.
This being said, could you change the MIME type this URL sends back to
"application/pkix-cert" instead of "application/pkcs7-mime" ?
Since "application/pkcs7-mime" is the type you should be sending back if
you sent a CMS instead of an X509 cert.
ro...@comodo.com
> Nevertheless, no EV certificates were issued prior to that to
> subscribers. And for clarification, I contacted one of our auditors this
> morning, and he recalled from memory that sampling of EV certificates
> was not part of the readiness audit. You are beating a dead horse here,
> give it up...
>
proceedings here!
We saw that you had your latest CPS prepared for EV back in July 2008.
We are aware of a number of certificates which include your EV OID and
which
were also issued in July 2008.
How were you able to issue EV certificates so long in advance of your
WebTrust audit opinions?
<snip>
> Concerning the CRLs you are free to suggest clarification on this matter
> at the CA/Browser forum. Concerning the OCSP responder I've got a much
> more surprising answer for you:
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=477244#c58
>
> The EV Guidelines state that "CAs MUST support an OCSP capability for
> Subscriber Certificates that are issued after Dec 31, 2010."
>
> Interesting, it doesn't say which OCSP capability according to Robin.
> And than just below:
>
> Also, note that the EV Guidelines *NEVER* absolutely require the
> Authority Info Access extension to be present in an EV Certificate!
>
> That's Robin's interpretation as you see.... StartCom doesn't have an
> issue with OCSP since it operates an RFC 2560 compliant responder
> already for years. Just in case you missed it...
>
Not me, I'm afraid. That was my colleage Rob Stradling.
Regards
Robin Alden
Comodo
Eddy Nigg
First of all sorry for the mix-up...for me it's always Rob&Robin from
Comodo - I never know to keep you two apart :-)
Maybe a picture of you guys would help ;-)
On 04/17/2009 12:30 AM, ro...@comodo.com:
> Eddy, you mentioned my name and that piqued my interest in the
> proceedings here!
>
Fantastic! Actually I was waiting for you - seriously!
> We saw that you had your latest CPS prepared for EV back in July 2008.
> We are aware of a number of certificates which include your EV OID and
> which
> were also issued in July 2008.
> How were you able to issue EV certificates so long in advance of your
> WebTrust audit opinions?
>
I suspect that you know the answer for a while already through the
CA/Browser forum, but I'm sincerely glad that you give me hereby the
opportunity to respond for the first time publicly. That's specially
because the CA/Browser forum hasn't given StartCom the opportunity to
explain and defend itself from the allegations and accusations which
were made against it! In relation to that it's also very unfortunate
that despite myself heeding your call and accept your invitation to join
the CA/Browser forum hasn't resulted in anything (or was that Rob now?).
And here my explanation (in mostly chronological order):
StartCom has always included the relevant CA policy OID in its end-user
certificates, and this long before the CA/Browser forum and the EV
guidelines even came into existence. Therefore policy OIDs have always
been part of our certificates and are nothing new for us.
Shortly after approval and finalizing of the latest StartCom CA policy
at the 18th of July 2008, we published the updated policy and bumped the
policy OID to version 2. This resulted in the same OID which we
designated for the EV OID.
During the course of a short period - most of them dated the 22nd of
July 2008 - end-user certificates of the type Class 1 and Class 2 were
issued with the OID 1.3.6.1.4.1.23223.2 (note the number two at the end,
this is the current policy number). With the relevant updates to the
various applications which were pending the changes reflected in the
updated CA policy, the successive policy OID of end-user certificates
was changed. This resulted in a new policy OID for Class 1 - 3
certificates and the designated OID for EV certificates as defined.
This clearly shows that StartCom hasn't actually issued EV certificates
nor intended to issue or anything close to it, instead the traditionally
included policy OID increased accordingly when the policy was updated
and published. As such we were aware that a couple of certificates had
the same OID as those designated for EV, but it was of no concern to us
at that time. And there was were a mistake actually happened.
We assumed that because the intermediate CAs which issues the end-user
certificates doesn't have the 2.5.29.32.0 (anyPolicy) OID in its policy
extension (they were Class 1-3 CAs), those certificates wouldn't be
recognized anyway as EV certificates, should at any time in the future
our EV OID be enabled with the browsers. Also important to note that
implementation for EV was mostly pending at that time.
At some time in March 2009 rumors started to circulate that StartCom
issued EV certificates premature and before completion of the EV audit.
At some point we were confronted by our auditors and provided evidence
to the contrary. However it didn't helped and the CA/Browser forum
continued to insist that we issued EV certificates premature to
completion of the EV readiness audit and made us look like lairs. I
received this information through various sources - but I couldn't help
and understand what it's all about - except to continue wonder....
Luckily, Frank Hecker at some point made me aware of specific web sites
the CA/Browser forum claimed to have EV certificates issued by us
premature. This obviously very quickly solved the puzzle and you are
reading its solution now.
(BTW, cudos to the one who found those sites - that's more or less
searching a needle in a haystack...I suspect that about a million sites
would have to be scanned and its certificates completly parsed in order
to find within all those, the StartCom issued certificates, and from
them the very few which had that specific OID. I consider this an
incredible effort and I appreciate the added scrutiny. And actually I
think I know to whom to thank for this effort ;-) It's just a pity that
he didn't confronted me directly since I could have solved the problem
much easier).
After consulting again with the EV guidelines we realized that the
anyPolicy OID has no real functionality and software vendors don't have
to check if this OID (or designated EV OID of the CA) exists in the
issuing CA certificate in order to make it a valid EV certificate.
That's because the EV guidelines state "Subordinate CAs MAY contain the
special anyPolicy OID" and not "MUST contain". What's the use of the
anyPolicy OID in the issuing CA certificates in this case anyway I don't
know. I would certainly request clarification and/or change - if I could.
In short, after being made aware by Frank that those certificates could
pose a problem, we promptly revoked the certificates we found to be
affected and offered to our subscribers new ones instead (there are some
advantages when providing certificates for free - nobody gets angry ;-)
). Later we performed a full scan to ensure that no other certificates
exist which could have this OID. We found none beyond the ones from
approximately the 22nd of July 2008.
But not enough with that - the accusations continued, right? The new
claim of the CA/Browser forum was that we haven't actually revoked those
certificates, just replaced and issued new ones. Well, well....most
likely somebody tried to look up the revocations in the CRL of the EV
intermediate CA instead of the Class 1 CRL. But also here, communication
was totally lacking and again I was left wondering about the new
allegations. It didn't helped to insist and explain that we revoked
those certificates. It was a claim against another claim until at last I
showed to another member of the CAB forum how to see those revocations
in the corresponding CRL which was obviously in the Class 1 intermediate
CA issued CRL and not that of the EV CA.
To summarize this event, it's a shame that the CAB forum didn't found it
necessary to contact us directly and request clarification on this
issue. The total lack of communication made StartCom and in particularly
myself look like liars and as if we committed a crime. Thank you Robin
for providing me the opportunity to refute the allegations, that
StartCom issued EV certificates premature, in this public manner!
Eddy Nigg
> Eddy Nigg a écrit :
>> I'm no stranger to this RFC obviously, but it somehow never bothered me
>> to send a PEM encoded certificate instead :-)
>>
>> You see Nelson, we should have a standard compliant client for
>> that...I'm certain there is a bunch of CAs sending PEM encoded certs...
>
> If they do, they are wrong. I don't know about caIssuers, but you
> *will* very fast have interoperability problems if you don't send your
> CRL DER encoded.
It were the chained and root CA certificate as listed in the AIA
caIssuer extension which were PEM encoded - not the CRLs. Our CRLs are
published since ever in correct encoding.
As such I'm looking forward to the new CRL fetching capabilities in
Firefox! :-)
Eddy Nigg
> To summarize this event, it's a shame that the CAB forum didn't found
> it necessary to contact us directly and request clarification on this
> issue. The total lack of communication made StartCom and in
> particularly myself look like liars and as if we committed a crime.
> Thank you Robin for providing me the opportunity to refute the
> allegations, that StartCom issued EV certificates premature, in this
> public manner!
>
Robin, one more word if you allow, because in regards to your initial
question, there is another side of the story...
Whoever found those couple of sites with the alleged EV certificates,
hasn't done his due diligence. Would he - and the CAB forum - have taken
a half serious look at those certificates, they'd realize that the
certificates were lacking all the typical marks of an EV certificate. In
particular by just looking at the subject line he would have seen the
phrase "StartCom Free Certificate Member" and checking the issuer would
have shown "StartCom Class 1 Primary Intermediate Server CA". StartCom
tries to make it as easy and clear as possible to distinguish the
different certificates it issues. At least anybody working in this field
should have realized at this point, that those certificates were never
intended to be EV certificates and should have prompted further
clarifications.
By failing to do his own due diligence, he turned the entire CA/Browser
forum against us - including the browser vendors - unjustly and unfair!
And with failing to disclose and confront us directly or through a
public forum with the allegations and facts he had at that time, he made
me look like a liar in front of some browser vendors to which I have
contact and in front of our own auditors. Additionally he had our
auditors run for nothing and most likely delayed our various
applications at the browser vendors which we have pending. In the end,
instead of having caught StartCom red-handed at the crime scene - all
that's left are a couple of certificates which had a wrong OID, a
certificate extension we've had in our certificates for years. Not even
the claim that we haven't revoked the affected certificates was true!
I sincerely hope that the CA/Browser forum improves its handling before
making such allegations and starts to communicate with the affected
parties before making unjustified claims! Thank you for your time!
Kaspar Brand
> On 04/16/2009 07:44 PM, Kaspar Brand:
>> I would be quite interested to know what end-entity and intermediate CA
>> certificates were configured at these sites in the period between 19
>> September 2008 and 31 December 2008.
>>
>
> Those were certificates issued to ourselves and I don't see any problem
> here. We are and were entitled to do that for various purposes,
> including testing and anything necessary for preparations of the
> infrastructure, controls and procedures.
You seem to change your mind quite quickly: on 16 April 2009, at 7:32
UTC you stated:
> No, you got that totally wrong! We were not issuing any EV certificates
> at all until completion of the audit.
And on the same day, about 13 hours later (18:22 UTC), you're conceding
that indeed EV certificates were issued before 31 December 2008 (which I
take as the date of the "completion of the audit"). Makes your
respective statements in this thread so far appear rather implausible.
> Nevertheless, no EV certificates were issued prior to that to
> subscribers.
And from a later message:
> In the end, instead of having caught StartCom red-handed at the crime
> scene - all that's left are a couple of certificates which had a
> wrong OID, a certificate extension we've had in our certificates for
years.
Just a wrong OID - no need to worry, of course (who cares?). By the same
logic, issuing a couple of certificates with a wrong name (subject) are
probably also a minor issue?
Policy OIDs are not an ornament on certificates, they are the primary
method of identifying under what exact CP an X.509 certificate was issued.
> They performed the audit exactly as they should as far as I can judge
> that. If you think that anything should be part of the audit criteria
> such as taking samples of the anticipated EV certificates, go to the
> CA/Browser forum and make your suggestions there. This is the wrong list.
Compelling answer. Just firmly state that there is no issue, and in case
someone still raises concerns, send him elsewhere.
> Perhaps you should suggest to Mozilla to remove audits based on the
> WebTrust criteria and performed by WebTrust authorized auditors.
> Everything else is pretty irrelevant.
I'm sorry, but the logic of that eludes me. What is the point you are
trying to make?
> StartCom has complied and conforms to all the requirements of the EV
> guidelines (minor deficiencies notwithstanding which are being dealt
> with accordingly) and has provided attestation by one of the most
> respected audit firms in this field. Also is StartCom insured according
> to the EV guidelines by one of the finest insurers currently on
> earth...(amazing what money can buy :D ). StartCom does not cause undue
> risks to users' security and conforms to the Mozilla CA Policy in every
> respect. StartCom isn't subject to any problem practice either.
> Anything else is pretty irrelevant IMO.
Do you think it's you who is in the position to decide what is relevant
and what is not (and to judge whether you meet the requirements of the
EV guidelines)?
> Did I say secret? I can't recall that....instead I told you that I'm not
> going to publicly discuss it with you, mainly because legal matters are
> involved! That's exactly one of the reasons certain disclosures are for
> the audit only.
In my first posting in this thread, I said:
> 3) In
> http://www.startssl.com/extended-validation-application-request.pdf,
> page 2 consists of a form entitled "Acknowledgment of the StartCom
> Extended Validation Subscriber Agreement". However, I could not find
> that subscriber agreement anywhere on the Web site. The EV guidelines
> (section 12) make it clear that a subscriber agreement is mandatory for
> EV requests, and have fairly detailed requirements on its very content.
To which you then replied:
> Correct. This document is compliant with the "Subscriber Agreement
> Requirements" of section 12 of the EV guidelines and references to the
> relevant obligations outlined in the CA policies which comprise part of
> the subscriber agreement. Any other agreements which a subscriber may or
> may not be required to enter are not publicly disclosed.
You didn't provide (a URL to) that "StartCom Extended Validation
Subscriber Agreement" so far, so I presume that apparently you do not
want to publicly disclose that document (aka "keep it secret"). Or am I
wrong?
> https://www.startssl.com/extended.pdf states in section "Commitment to
> Comply with Extended Validation Guidelines":
>
> /In the event of any inconsistency between this document and those
> guidelines, those guidelines take precedence over this document./
I knew you would point me to that paragraph. Two additional points for
your consideration here: 1) you did not comment on the issue with the
MD5-hashed CRL (where you don't comply with the requirements set forth
in your own policy) and 2) your "Policy & Practice Statements" document
only references the "StartCom Intermediate Certification Authority
Policy Appendix". How should the interested reader/relying party be able
to figure out that a) there is such a thing as an "Extended Validation
Certificates Policy Appendix" and b) that it will possibly overrule
stipulations in the "Policy & Practice Statements" document?
> Concerning the CRLs you are free to suggest clarification on this matter
> at the CA/Browser forum. Concerning the OCSP responder I've got a much
> more surprising answer for you:
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=477244#c58
>
> The EV Guidelines state that "CAs MUST support an OCSP capability for
> Subscriber Certificates that are issued after Dec 31, 2010."
>
> Interesting, it doesn't say which OCSP capability according to Robin.
Not only according to Robin (or Rob, in fact), but according to common
sense as well. As I already said:
> "RFC 2560" isn't mentioned anywhere in the EV guidelines
I used this example to compare it with the case of general RFC 3280/5280
compliance not being mentioned explitly in the EV guidelines either.
When I was asking
> Why should the EV guidelines specify things which are explicitly stated
> in the RFC? It's pretty obvious that the EV guidelines expect the CAs to
> be compliant with RFC 3280/5280, no?
your reaction was
> Nope...the guidelines need to define, not expect. I have not found any
> definition which requires directly or implicit that CRLs must be of any
> version.
The point is that just because the EV guidelines lack explicit
statements of the sort "when issuing EV certificates, CAs are required
to comply with the requirements from RFCs 5280 and RFC 2560" doesn't
mean that (mandatory) requirements from these RFCs do not apply to the
issuance of EV certificates. The EV guidelines are not a self-contained
cookbook for setting up an EV issuing CA, quite a number of additional
standards and specifications need to be taken into account.
So, for the record:
> Do you want to say that you don't care about RFC 2459/3280/5280 when
> your CA issues certificates? What specific standards do you use, then?
In addition to a reply to these questions, I would also appreciate your
comments on the Webtrust criteria regarding CA key protection. Finally,
asking the other way round: would you mind disclosing what kind of
certification the HSM has which is used to store the key of your root CA
created in 2006? I wasn't able to locate this information in the "Policy
& Practice Statements" document.
Kaspar
Ian G
> Robin, one more word if you allow, because in regards to your initial
> question, there is another side of the story...
One thing that separates the cowboys from the civil society is the use
of dispute resolution procedures. Without commenting on any particular
case, it does seem an appropriate moment to point to:
https://wiki.mozilla.org/CA:Dispute_resolution
The advantage sought after here is to channel all the information in a
given dispute into a defined space, with defined rules, and, to draw a
line under the discussion with a ruling.
This protects both the parties, as well as gets the trade moving
efficiently again. I do grant it reduces the fun of being cowboy. All
that whooping and hooping and shooting, they even make movies about it.
iang
Eddy Nigg
I'll try to cut this one short as we seem to have turned into a cycle here...
On 04/17/2009 08:14 AM, Kaspar Brand:
And on the same day, about 13 hours later (18:22 UTC), you're conceding that indeed EV certificates were issued before 31 December 2008 (which I take as the date of the "completion of the audit"). Makes your respective statements in this thread so far appear rather implausible.
Just a wrong OID - no need to worry, of course (who cares?). By the same logic, issuing a couple of certificates with a wrong name (subject) are probably also a minor issue?
Policy OIDs are not an ornament on certificates, they are the primary method of identifying under what exact CP an X.509 certificate was issued.
Perhaps you should suggest to Mozilla to remove audits based on the WebTrust criteria and performed by WebTrust authorized auditors. Everything else is pretty irrelevant.I'm sorry, but the logic of that eludes me. What is the point you are trying to make?
Do you think it's you who is in the position to decide what is relevant and what is not (and to judge whether you meet the requirements of the EV guidelines)?
You didn't provide (a URL to) that "StartCom Extended Validation Subscriber Agreement" so far, so I presume that apparently you do not want to publicly disclose that document (aka "keep it secret"). Or am I wrong?
I knew you would point me to that paragraph.
Two additional points for your consideration here: 1) you did not comment on the issue with the MD5-hashed CRL
How should the interested reader/relying party be able to figure out that a) there is such a thing as an "Extended Validation Certificates Policy Appendix" and b) that it will possibly overrule stipulations in the "Policy & Practice Statements" document?
I used this example to compare it with the case of general RFC 3280/5280 compliance not being mentioned explitly in the EV guidelines either.
The point is that just because the EV guidelines lack explicit statements of the sort "when issuing EV certificates, CAs are required to comply with the requirements from RFCs 5280 and RFC 2560" doesn't mean that (mandatory) requirements from these RFCs do not apply to the issuance of EV certificates.
In addition to a reply to these questions, I would also appreciate your comments on the Webtrust criteria regarding CA key protection. Finally, asking the other way round: would you mind disclosing what kind of certification the HSM has which is used to store the key of your root CA created in 2006? I wasn't able to locate this information in the "Policy & Practice Statements" document.
The intermediate CA certificates are stored in an HSM with FIPS 140-2 achieved level 3 certification. Happy?
(Besides that I'm not required to disclose it, it's not specifically defined in the CPS as the certification level may change.)
Eddy Nigg
> The advantage sought after here is to channel all the information in a
> given dispute into a defined space, with defined rules, and, to draw a
> line under the discussion with a ruling.
Unfortunately this would help only for Mozilla specific issues. CAs are
not bound to use the defined space and rules, therefor I think it's
superfluous.
>
> This protects both the parties, as well as gets the trade moving
> efficiently again. I do grant it reduces the fun of being cowboy.
> All that whooping and hooping and shooting, they even make movies
> about it.
>
Yehhaaa....
Eddy Nigg
Hi Kaspar,
Do you think it's you who is in the position to decide what is relevant and what is not (and to judge whether you meet the requirements of the EV guidelines)?
It's the auditors opinion primarily. The WebTrust for CAs audit confirms disclosure and adherence to our own CP/CSP, the EV audit confirms our readiness for issuing EV according to the guidelines. Besides that I can very well judge if StartCom has any of the listed problematic practices, yes.
To expand on this one, I just want to remind you that this request is not a general review of the CA and request to add this root. This root is already included - it's not a legacy root either. Therefor discussions should not be as if the root is up for discussion. Not that it can't be done at any time and for any reason, it's simply not the scope of this thread.
However my point leading to your question above was, that even though you found a few technical deficiencies - which I view as minor because they don't have any effect on the correct functioning of the certificates or the software **, but which will receive the needed attention by us and for finding them I'm thanking you - I'm not sure if you can demonstrate that by enabling the StartCom EV OID it would cause any undue risk to Mozilla or its users of its software. Neither does StartCom have to declare any problematic practice or is suspected of non-conformance to anything stated in the Mozilla CA Policy.
Conformance to the EV guidelines isn't something judged by me or you, but by the relevant audit requirements. This too is clearly defined in the EV guidelines - to which StartCom has committed itself.
** Since the day Mozilla enabled support for EV by providing a distinct UI for EV certificates, scores of CAs did not provide any means for revocation checking to Mozilla. Neither did Mozilla insist on such a requirement at the CA/Browser forum. I personally view this as a grave situation which didn't receive the required attention for a long time. This is a real issue!
Specially in relation to the above, StartCom's operations are very sound and responsible. You've found technical deficiencies like PEM encoded certificates in the AIA caIssuer field which easily could be corrected and which had no negative effect on this and other browsers and the business category was missing in the certificates issued to ourselves which is corrected too. You've found that the CRL signed from the root has an MD5 hash, something we are reviewing now once again and you've found also an empty issuer alternative field which again has no effect on the correct function of this and other software, because issuer alternative names are not used in name chaining and name constraints.
Besides that, all your other claims are mute as no specific CRL version is required, the published appendix to the policy is legally binding from the minute of its publishing despite having the status "draft" and version "0.9" and you seem to not find the subscriber agreement sufficient. And you seem to question the WebTrust audit criteria, its requirements for the EV readiness audit and the competence of the authorized auditors, which neither is in the scope of this thread.
If I understand correctly, this is the basis of your objection to have the EV OID of StartCom enabled (which I understand is what you are actually saying here). By considering all the effort and scrutiny you and the CAB forum made to find any deficiency in our operations (and don't pretend that you didn't try to find anything you could) and this is what you've come up with, I'm quite happy for StartCom. :-)
I suggest that from now on you join the efforts of Mozilla here and help review all the upcoming requests with the same scrutiny and effort! I think your contribution would be very helpful. As for StartCom I think we have enough material for now in order to come to a decision if to enable the EV OID and can tend to other matters in the meantime.
ro...@comodo.com
> Hi Robin,
>
> First of all sorry for the mix-up...for me it's always Rob&Robin from
> Comodo - I never know to keep you two apart :-)
>
> Maybe a picture of you guys would help ;-)
>
> On 04/17/2009 12:30 AM, ro...@comodo.com:
>
> > Eddy, you mentioned my name and that piqued my interest in the
> > proceedings here!
>
> Fantastic! Actually I was waiting for you - seriously!
>
> > We saw that you had your latest CPS prepared for EV back in July 2008.
> > We are aware of a number of certificates which include your EV OID and
> > which
> > were also issued in July 2008.
> > How were you able to issue EV certificates so long in advance of your
> > WebTrust audit opinions?
>
> I suspect that you know the answer for a while already through the
> CA/Browser forum, but I'm sincerely glad that you give me hereby the
> opportunity to respond for the first time publicly. That's specially
> because the CA/Browser forum hasn't given StartCom the opportunity to
> explain and defend itself from the allegations and accusations which
> were made against it! In relation to that it's also very unfortunate
> that despite myself heeding your call and accept your invitation to join
> the CA/Browser forum hasn't resulted in anything (or was that Rob now?).
>
It was Rob, and he encouraged you to apply for membership. Membership
of the CAB Forum is not "by invitation". Anyone who meets the
membership requirements may apply.
> And here my explanation (in mostly chronological order):
>
> StartCom has always included the relevant CA policy OID in its end-user
> certificates, and this long before the CA/Browser forum and the EV
> guidelines even came into existence. Therefore policy OIDs have always
> been part of our certificates and are nothing new for us.
>
> Shortly after approval and finalizing of the latest StartCom CA policy
> at the 18th of July 2008, we published the updated policy and bumped the
> policy OID to version 2. This resulted in the same OID which we
> designated for the EV OID.
>
> During the course of a short period - most of them dated the 22nd of
> July 2008 - end-user certificates of the type Class 1 and Class 2 were
> issued with the OID 1.3.6.1.4.1.23223.2 (note the number two at the end,
> this is the current policy number). With the relevant updates to the
> various applications which were pending the changes reflected in the
> updated CA policy, the successive policy OID of end-user certificates
> was changed. This resulted in a new policy OID for Class 1 - 3
> certificates and the designated OID for EV certificates as defined.
>
> This clearly shows that StartCom hasn't actually issued EV certificates
I disagree. If you have issued certificates with your EV policy OID
in then you were asserting that they were EV certificates.
As Kaspar pointed out, the policy OID is the primary method of
identifying the policy under which a certificate was issued.
RFC5280 says "In an end entity certificate, these policy information
terms indicate the policy under which the certificate has been issued
and the purposes for which the certificate may be used."
> nor intended to issue or anything close to it, instead the traditionally
You may not have *intended* to issue some or all of these as EV
certificates, but you certainly did so.
> included policy OID increased accordingly when the policy was updated
> and published. As such we were aware that a couple of certificates had
> the same OID as those designated for EV, but it was of no concern to us
> at that time. And there was were a mistake actually happened.
>
And this is where your actions first really puzzle me.
* 18th July 08 you issued your V2.0 CPS which defined (for the first
time, possibly) your EV policy OID as 1.3.6.1.4.1.23223.2.
* You state that you were aware you had issued a number of
certificates on 22nd July 08 which included that EV policy OID.
* Since the EV Guidelines do not allow issuance of EV certificates
before the successful completion of the readiness assessment audits,
why did you not change your EV OID? We would not be having this
discussion if you had done so.
> We assumed that because the intermediate CAs which issues the end-user
> certificates doesn't have the 2.5.29.32.0 (anyPolicy) OID in its policy
> extension (they were Class 1-3 CAs), those certificates wouldn't be
> recognized anyway as EV certificates, should at any time in the future
> our EV OID be enabled with the browsers. Also important to note that
> implementation for EV was mostly pending at that time.
Noted.
>
> At some time in March 2009 rumors started to circulate that StartCom
> issued EV certificates premature and before completion of the EV audit.
> At some point we were confronted by our auditors and provided evidence
> to the contrary. However it didn't helped and the CA/Browser forum
> continued to insist that we issued EV certificates premature to
> completion of the EV readiness audit and made us look like lairs. I
> received this information through various sources - but I couldn't help
> and understand what it's all about - except to continue wonder....
Sure, but this is all way after the fact. The certificates which are
of interest were all issued back in 2008.
>
> Luckily, Frank Hecker at some point made me aware of specific web sites
> the CA/Browser forum claimed to have EV certificates issued by us
> premature. This obviously very quickly solved the puzzle and you are
> reading its solution now.
>
<snip>
>
> In short, after being made aware by Frank that those certificates could
> pose a problem, we promptly revoked the certificates we found to be
> affected and offered to our subscribers new ones instead (there are some
> advantages when providing certificates for free - nobody gets angry ;-)
> ). Later we performed a full scan to ensure that no other certificates
> exist which could have this OID. We found none beyond the ones from
> approximately the 22nd of July 2008.
OK, so you revoked some certificates, that seems good. Just to be
clear, are you saying that you revoked all certificates which StartCom
issued before your audit dates which included the EV OID?
<snip>
How does revoking all those certificates square with the EV Beta
certificates which you were offering before your audit was complete?
We had seen the EV Beta program on your website and (before your audit
dates) your website said "Disclaimer: StartSSL Extended Validation
certificates won't be recognized and won't show the green address bar
before January 2009. Because of that, our EV certificates are now
available for a time-limited introductory price of only US $". Were
we wrong to assume from that that you were selling EV certificates in
advance of your audits and expecting them to gain the green bar at
some future point in time?
Regards
Robin
ro...@comodo.com
> On 04/17/2009 02:53 AM, Eddy Nigg:
>
> > To summarize this event, it's a shame that the CAB forum didn't found
> > it necessary to contact us directly and request clarification on this
> > issue. The total lack of communication made StartCom and in
> > particularly myself look like liars and as if we committed a crime.
> > Thank you Robin for providing me the opportunity to refute the
> > allegations, that StartCom issued EV certificates premature, in this
> > public manner!
>
> Robin, one more word if you allow, because in regards to your initial
> question, there is another side of the story...
>
> Whoever found those couple of sites with the alleged EV certificates,
> hasn't done his due diligence. Would he - and the CAB forum - have taken
> a half serious look at those certificates, they'd realize that the
> certificates were lacking all the typical marks of an EV certificate. In
> particular by just looking at the subject line he would have seen the
> phrase "StartCom Free Certificate Member" and checking the issuer would
> have shown "StartCom Class 1 Primary Intermediate Server CA". StartCom
> tries to make it as easy and clear as possible to distinguish the
> different certificates it issues. At least anybody working in this field
> should have realized at this point, that those certificates were never
> intended to be EV certificates and should have prompted further
> clarifications.
But when one examines a certificate to determine if it is purporting
to be an EV certificate, the first thing one would examine is the
policy OID present in the certificate policy extension. If that
proclaims itself to be an EV certificate then so be it.
If the policy OID is not definitive, then how would you have me
distinguish between an EV certificate with the EV policy OID and a non-
EV certificate with the EV policy OID?
Are you suggesting it is acceptable to put the EV policy OID into
every certificate you issue, and to use other means to enable or
disable the significance of the OID?
We do not accept that some other flaw in the certificate's
implementation renders the EV policy null and void. You say that we
should examine the subject of the certificates, but until Kaspar
pointed it out to you earlier in this thread you were mistakenly
issuing EV certificates according to an old version of the EV
guidelines and not including the "business category" attribute. Are
you saying that a StartCom issued EV certificate without the business
category attribute is not an EV certificate because it does not comply
with the guidelines?
Are you saying that the liability insurance which you have in place
for EV applies to such a certificate because it includes the EV policy
OID - or are you saying the insurance does not apply to such a
certificate because the subject is imperfectly formed?
>
> By failing to do his own due diligence, he turned the entire CA/Browser
> forum against us - including the browser vendors - unjustly and unfair!
I'm not aware that the entire CA/Browser forum has been turned against
you, whether justly and fairly or not.
> And with failing to disclose and confront us directly or through a
> public forum with the allegations and facts he had at that time, he made
> me look like a liar in front of some browser vendors to which I have
> contact and in front of our own auditors. Additionally he had our
> auditors run for nothing and most likely delayed our various
> applications at the browser vendors which we have pending. In the end,
> instead of having caught StartCom red-handed at the crime scene - all
> that's left are a couple of certificates which had a wrong OID, a
> certificate extension we've had in our certificates for years. Not even
> the claim that we haven't revoked the affected certificates was true!
So it seems that the obstacle that remains is that, when asked if you
issued EV certificates before the audit dates, you say you did not,
despite the certificates existing with the EV OID in them and your
website seeming to have offered EV in advance of the audit dates.
Isn't it the case that the problem is your refusal to acknowledge that
those two certificates issued before the audit date are EV
certificates?
It is the clash of your statement that they are not EV together with
the observed facts that causes observers to take pause to examine your
actions further.
If you had issued EV certificates in advance of the audit dates, you
could be called upon to revoke them - but you have already done that.
>
> I sincerely hope that the CA/Browser forum improves its handling before
> making such allegations and starts to communicate with the affected
> parties before making unjustified claims! Thank you for your time!
This isn't the CAB Forum. I'm not aware that the CAB Forum has made
unjustified allegations or claims.
Surely the issues being raised in public here around your EV
enablement in Mozilla are the whole matters of importance.
Regards
Robin
Eddy Nigg
On 04/17/2009 04:04 PM, ro...@comodo.com:
> It was Rob, and he encouraged you to apply for membership. Membership
> of the CAB Forum is not "by invitation". Anyone who meets the
> membership requirements may apply.
>
Which StartCom did.
> I disagree. If you have issued certificates with your EV policy OID
> in then you were asserting that they were EV certificates.
> As Kaspar pointed out, the policy OID is the primary method of
> identifying the policy under which a certificate was issued.
> RFC5280 says "In an end entity certificate, these policy information
> terms indicate the policy under which the certificate has been issued
> and the purposes for which the certificate may be used."
>
I don't disagree with RFC 5280 since this was the correct policy OID at
that time, pending changes to the new implementation and numbering
sequence of our certificates. I disagree that those were EV certificates
in every respect nor meant to be nor tried to pretend to be, since they
lacked any of the clear markings of an EV certificate. This must be
recognized by the concerned parties.
> * Since the EV Guidelines do not allow issuance of EV certificates
> before the successful completion of the readiness assessment audits,
> why did you not change your EV OID? We would not be having this
> discussion if you had done so.
>
This could have been a very easy solution indeed and I'm sorry for
having missed that chance. Why it happened I explained below:
>> We assumed that because the intermediate CAs which issues the end-user
>> certificates doesn't have the 2.5.29.32.0 (anyPolicy) OID in its policy
>> extension (they were Class 1-3 CAs), those certificates wouldn't be
>> recognized anyway as EV certificates, should at any time in the future
>> our EV OID be enabled with the browsers.
> Sure, but this is all way after the fact. The certificates which are
> of interest were all issued back in 2008.
>
Which isn't really an excuse for the total lack of communication, isn't it?
> OK, so you revoked some certificates, that seems good. Just to be
> clear, are you saying that you revoked all certificates which StartCom
> issued before your audit dates which included the EV OID?
>
Yes and you can check it by yourself:
wget www.startssl.com/crt1-crl.crl
openssl crl -in crt1-crl.crl -text -noout -inform DER | grep "Mar 19"
> How does revoking all those certificates square with the EV Beta
> certificates which you were offering before your audit was complete?
>
It's not a problem since no EV certificates were issued during that
time. As a matter of fact, the first EV certificate was issued at the
30th of January 2009 (which has been replaced due to correction by now).
Those from the 22nd of July were clearly not meant to be EV nor was
there a Beta program anywhere visible...
> We had seen the EV Beta program on your website and (before your audit
> dates) your website said "Disclaimer: StartSSL Extended Validation
> certificates won't be recognized and won't show the green address bar
> before January 2009. Because of that, our EV certificates are now
> available for a time-limited introductory price of only US $". Were
> we wrong to assume from that that you were selling EV certificates in
> advance of your audits and expecting them to gain the green bar at
> some future point in time?
Yes! Selling and issuing certificates are two different things. I guess
there is nothing which prohibits from having subscribers pay in order to
participate in a Beta program and wait until we are actually performing
the validations and issue the certificates, right.? :-)
Eddy Nigg
> But when one examines a certificate to determine if it is purporting
> to be an EV certificate, the first thing one would examine is the
> policy OID present in the certificate policy extension.
Correct, I would have done the same. Since you were searching for them
(I don't mean you personally since I don't know who searched), that's
the way to find them. The second step however should have been to look
at the certificate, the third step perhaps to confront us with the findings.
> Are you suggesting it is acceptable to put the EV policy OID into
> every certificate you issue, and to use other means to enable or
> disable the significance of the OID?
>
No, according to the guidelines it's not and I never claimed anything else.
> Are
> you saying that a StartCom issued EV certificate without the business
> category attribute is not an EV certificate because it does not comply
> with the guidelines?
>
That's an interesting question actually. But it's certainly a deficiency
requiring correction upon detection.
> Are you saying that the liability insurance which you have in place
> for EV applies to such a certificate because it includes the EV policy
> OID - or are you saying the insurance does not apply to such a
> certificate because the subject is imperfectly formed?
>
Well, the insurance applies to all the CA business, hence the question
is maybe irrelevant. The rest would be for the lawyers I guess...
> I'm not aware that the entire CA/Browser forum has been turned against
> you, whether justly and fairly or not.
>
I'm glad to hear, but it's not what others relayed to me.
> Isn't it the case that the problem is your refusal to acknowledge that
> those two certificates issued before the audit date are EV
> certificates?
>
Those certificates were not issued according to the procedures and
criteria of the EV guidelines. They were not issued from the designated
EV intermediate CA. They had clear markings of a different type of
certificate (Class 1). They had however a CA policy OID which it shouldn't.
As such, I indeed refuse to acknowledge that StartCom issued EV
certificate before eligible to do so, I acknowledge however that a
mistake happened with assessing the severance of certificates with that
OID, because of the misinterpretation of the functionality of the
anyPolicy OID in the issuer certificate.
> Surely the issues being raised in public here around your EV
> enablement in Mozilla are the whole matters of importance.
>
Of course I anticipated and excepted this issue to come up and was
prepared to provide the needed explanations in regards to this matter.
I'm also immensely grateful that this forum exists and that Mozilla
provided this stage to openly discuss this matter. And thank you again
that you raised this issue and allowed me to provide my explanation
about what exactly happened.
Frank Hecker
> Is this request for EV enablement on some sort of fast track?
As Eddy noted, we've been following a general policy of prioritizing
EV-related requests over non-EV requests. To my knowledge we've done
this with every EV request thus far, so Startcom isn't being singled out
for special treatment. IIRC the other bugs you mentioned were for non-EV
requests.
Strictly speaking the Startcom request to enable the code signing bit
could have been handled separately from the EV request, but if we can
get both requests handled at the same time that's fine by me. If there
are any outstanding issues with the code signing request that prevent
processing it now, then we'll drop it back in the queue with the other
non-EV requests.
Frank
--
Frank Hecker
hec...@mozillafoundation.org
Kaspar Brand
>> method of identifying under what exact CP an X.509 certificate was issued.
>>
>
> Correct, and we've done that for yours!
What exactly did you do for me (can't follow you here)? Apparently you
were not that careful with when putting policy OIDs into your
certificates - otherwise the (purported EV) OID 1.3.6.1.4.1.23223.2
would not have ended up in a Class 1 certificate. If the controls
implemented at your CA do not prevent such things from happening, then
I'm quite sceptical about the quality and efficiency of your other
controls, too.
>> Two additional points for
>> your consideration here: 1) you did not comment on the issue with the
>> MD5-hashed CRL
>
> Actually I commented on it.
You commented on the use of MD5 in the CRL issued last September, but
you did not comment on this observation:
> And, taking another section of that document (page 26), your CA is
> actually required to issue CRLs using the sha1WithRSAEncryption
> algorithm, only - at least since 18th June 2008... which is another
> reason to either (promptly) update your policy or (better) reissue the
> CRL of your root CA with a SHA-1 hash.
To restate: you're not complying with your own policy (version 2.0,
dated 18 July 2008). Either update reality to reflect what your policy
says, or update the policy to state what you do in reality.
>> How should the interested reader/relying party be able
>> to figure out that a) there is such a thing as an "Extended Validation
>> Certificates Policy Appendix" and b) that it will possibly overrule
>> stipulations in the "Policy& Practice Statements" document?
>>
>
> Perhaps by going to the bug
> https://bugzilla.mozilla.org/show_bug.cgi?id=451298 and read the first
> comment?
As a relying party, when visiting a Web site authenticated by an EV SSL
certificate issued by Startcom, do you really think that users will
figure out that URL? You fail to mention the EV appendix in (and its
relevance to) your "Policy & Practice Statements" document, and are
expecting people to find a statement buried deep down in a bug tracking
system? You must be joking.
> Right, and according to Rob's opinion, not only does it NOT have to be
> compliant to any RFC, he claims that just **a** OCSP capability must be
> provided, not **the** OCSP responder confirming to RFC 2560 and specific
> configuration (like AIA URI).
I'm not Rob, and I would certainly hold that despite the lack of an
explicit reference to RFC 2560 it's "pretty obvious that the EV
guidelines expect the CAs to be compliant with RFC 2560" (same as I said
for RFC 3280/5280). I'm not familiar with Rob's previous statements, but
it's very well possible that I disagree with them. And there's no point
in bringing them up in the discussion with me, actually.
>> In addition to a reply to these questions, I would also appreciate your
>> comments on the Webtrust criteria regarding CA key protection. Finally,
>> asking the other way round: would you mind disclosing what kind of
>> certification the HSM has which is used to store the key of your root CA
>> created in 2006? I wasn't able to locate this information in the "Policy
>> & Practice Statements" document.
>>
>
> How about section "CA Key Generation, Protection, Recovery &
> Publication"? It clearly states how the root has to be protected, no?
It seems to me that you don't really understand the purpose (nor the
specific content) of the Webtrust criteria. If you have another look at
said document, then please pay attention to what exactly the header for
the right column of all these tables says ("Illustrative Disclosures",
"Illustrative Controls"). Next, read this statement from page 31:
> For each of the disclosure and control criteria, there is a detailed
> list of illustrative disclosures and control procedures that might
> be followed by the CA to meet the related criteria. The illustrative
> disclosures and controls do not necessarily need to be in place
> for a criterion to be met in a given business circumstance and
> alternatives may be sufficient.
The "AICPA/CICA WebTrust Program for Certification Authorities" document
(in its version from August 2000) do not define specific minimum
requirements (contrary to popular belief), their primary purpose is to
list the things which a CA needs to disclose (principle 1) and what
controls need to be in place to comply with principles 2 (service
integrity) and 3 (CA environment controls).
The Webtrust for CAs program also states (p.24):
> To have a basis for such assertions, the CA’s management should
> have made a risk assessment and implemented appropriate controls
> for its CA operations. The WebTrust for Certification Authorities
> criteria and illustrative controls provide a basis for a risk
> assessment and a minimum set of CA controls.
>
> An independent, objective, and knowledgeable practitioner will
> perform tests of these representations under AICPA professional
> standards and provide a professional opinion, which adds to
> the credibility of management’s representations.
E&Y has provided an opinion, in your case, sure. But from this
point-in-time record doesn't necessarily follow the right of having
Mozilla enable your CA for EV SSL. Irrespective of any audit, you have
to fully comply with the requirements set forth in the EV Guidelines
(which I happen to deny for the Startcom CA in its current state, in
case it shouldn't be obvious from my previous messages).
> The intermediate CA certificates are stored in an HSM with FIPS 140-2
> achieved level 3 certification. Happy?
No. I was asking about "the HSM [...] which is used to store the key of
your root CA created in 2006". By this, I mean the private key whose
public part is identified by the
4e:0b:ef:1a:a4:40:5b:a5:17:69:87:30:ca:34:68:43:d0:41:ae:f2 key
identifier (SHA-1 hash of the respective subjectPublicKey structure).
The RSA modulus of this key (4096 bits) starts with c1:88:db:09:...,
which should certainly make it clear what key pair I'm referring to.
> As for StartCom I think
> we have enough material for now in order to come to a decision if to
> enable the EV OID and can tend to other matters in the meantime.
Are you now also taking the role of the moderator of this
newsgroup/list? Consequently, the next step would then probably be that
you instruct Kathleen and/or Frank on their further actions... the way
you're trying to control this discussion is really very, very -
remarkable, to say the least.
As mentioned previously: maybe you will be successful with your strategy
of declaring all issues as minor, downplaying the relevance of your
errors, denying the applicability of requirements and ignoring
inconvenient questions... the decision taken by *Mozilla* regarding your
request(s) will certainly be a very important indicator to me for
gauging the overall quality of its root inclusion / EV enablement
process (I might as well just end up with the conclusion of considering
it another instance of a security theater, in the future).
Kaspar
ro...@comodo.com
> Hi Robin,
>
> On 04/17/2009 04:04 PM, ro...@comodo.com:
> > It was Rob, and he encouraged you to apply for membership. Membership
> > of the CAB Forum is not "by invitation". Anyone who meets the
> > membership requirements may apply.
>
> Which StartCom did.
Sure, my point was that it didn't need our invitation.
> > I disagree. If you have issued certificates with your EV policy OID
> > in then you were asserting that they were EV certificates.
> > As Kaspar pointed out, the policy OID is the primary method of
> > identifying the policy under which a certificate was issued.
> > RFC5280 says "In an end entity certificate, these policy information
> > terms indicate the policy under which the certificate has been issued
> > and the purposes for which the certificate may be used."
>
> I don't disagree with RFC 5280 since this was the correct policy OID at
> that time, pending changes to the new implementation and numbering
> sequence of our certificates. I disagree that those were EV certificates
> in every respect nor meant to be nor tried to pretend to be, since they
> lacked any of the clear markings of an EV certificate. This must be
> recognized by the concerned parties.
You can't agree that the certificates contained your EV policy OID and
in the same paragraph say that they "lacked any of the clear markings
of an EV certificate"
> > OK, so you revoked some certificates, that seems good. Just to be
> > clear, are you saying that you revoked all certificates which StartCom
> > issued before your audit dates which included the EV OID?
>
> Yes and you can check it by yourself:
>
> wget www.startssl.com/crt1-crl.crl
> openssl crl -in crt1-crl.crl -text -noout -inform DER | grep "Mar 19"
There are 60 certificates revoked on that date. That's not just a
couple....
> > We had seen the EV Beta program on your website and (before your audit
> > dates) your website said "Disclaimer: StartSSL Extended Validation
> > certificates won't be recognized and won't show the green address bar
> > before January 2009. Because of that, our EV certificates are now
> > available for a time-limited introductory price of only US $". Were
> > we wrong to assume from that that you were selling EV certificates in
> > advance of your audits and expecting them to gain the green bar at
> > some future point in time?
>
> Yes! Selling and issuing certificates are two different things. I guess
> there is nothing which prohibits from having subscribers pay in order to
> participate in a Beta program and wait until we are actually performing
> the validations and issue the certificates, right.? :-)
It's a strange business model, but I agree there is nothing in
Mozilla's CA policy (so far as I am aware) or in the EV Guidelines
which prevent you from selling something you can't issue.
It can't be a surprise that some people would infer from the fact of
your selling EV certificates that you might also be issuing them.
Regards
Robin
Eddy Nigg
>> Isn't it the case that the problem is your refusal to acknowledge that
>> those two certificates issued before the audit date are EV
>> certificates?
>
> Those certificates were not issued according to the procedures and
> criteria of the EV guidelines. They were not issued from the
> designated EV intermediate CA. They had clear markings of a different
> type of certificate (Class 1). They had however a CA policy OID which
> it shouldn't.
>
> As such, I indeed refuse to acknowledge that StartCom issued EV
> certificate before eligible to do so, I acknowledge however that a
> mistake happened with assessing the severance of certificates with
> that OID, because of the misinterpretation of the functionality of the
> anyPolicy OID in the issuer certificate.
I have the tendency to re-read my messages and always want to add
something more...sorry about that. But hereby I want to make it crystal
clear to any party.
We recognize and acknowledge (after being made aware by Frank Hecker)
that StartCom issued certificates, in July 22nd 2008 mistakenly with the
EV OID in its CA policy extension, from its Class 1 intermediate CA. We
acknowledge that at that time the EV guidelines were misinterpreted and
because of that didn't take action.
However we also want to make it clear, that StartCom hasn't intended to
issue certificates which could have been recognized by the software as
EV. StartCom was and is fully committed to the EV guidelines and follows
all requirements - including completion of the EV readiness audit before
issuance of EV certificates.
Robin and anybody else, we try to operate the StartCom CA in a very
responsible and professional way and would not have allowed such a grave
violation like the premature issuance of EV certificates. That's why I
personally perceived the allegations made as sever but also unfounded.
Since you know the operational differences and controls in place when
comparing domain validated certificates to EV certificates, you probably
can understand - that from my point of view - the allegations made by
the CAB forum were horrendous. I clearly knew that we didn't do such a
thing.
Only through Franks intervening and providing us with the relevant
information were we able to understand and take the appropriate action.
ro...@comodo.com
> On 04/17/2009 04:10 PM, ro...@comodo.com:
> > you saying that a StartCom issued EV certificate without the business
> > category attribute is not an EV certificate because it does not comply
> > with the guidelines?
>
> That's an interesting question actually. But it's certainly a deficiency
> requiring correction upon detection.
>
> > Are you saying that the liability insurance which you have in place
> > for EV applies to such a certificate because it includes the EV policy
> > OID - or are you saying the insurance does not apply to such a
> > certificate because the subject is imperfectly formed?
>
> Well, the insurance applies to all the CA business, hence the question
> is maybe irrelevant. The rest would be for the lawyers I guess...
It applies differently to your different certificates. That is why it
is important to be clear about the type of certificate issued.
Your CPS gives monetary amounts for the liability insurance for your
class 1/2/3 certificates, but for EV it refers the reader to the EV
guidelines and says "StartCom shall adhere to those requirements only
for certificates explicitly marked as EV certificates and which where
issued according to the EV guidelines."
Regards
Robin
Jean-Marc Desperrier
>> (before your audit
>> dates) your website said "Disclaimer: StartSSL Extended Validation
>> certificates won't be recognized and won't show the green address bar
>> before January 2009. Because of that, our EV certificates are now
>> available for a time-limited introductory price of only US $". Were
>> we wrong to assume from that that you were selling EV certificates in
>> advance of your audits and expecting them to gain the green bar at
>> some future point in time?
>
> Yes! Selling and issuing certificates are two different things. I guess
> there is nothing which prohibits from having subscribers pay in order to
> participate in a Beta program and wait until we are actually performing
> the validations and issue the certificates, right.?
If so, why did the site say "won't *show* the green addres bar until" as
well as "*now* available" which I really have a hard time figuring your
client could understand any other way that they would receive the cert
now, and the EV would be visible only later ?
Concretely what did the Beta program consist of ?
"Thank you for paying, please wait until january to receive a certificate" ?
This being said it, I think I can start to reconstruct what happened
here, I guess this beta program apparently has strongly upset some CA
who have then been very hard looking for a concrete proof that you had
indeed issued EV cert before hand, and who at the end only found the
certs from 22nd July 2008, not anything coming from the beta program.
Eddy Nigg
> If so, why did the site say "won't *show* the green addres bar until"
> as well as "*now* available" which I really have a hard time figuring
> your client could understand any other way that they would receive the
> cert now, and the EV would be visible only later ?
>
> Concretely what did the Beta program consist of ?
> "Thank you for paying, please wait until january to receive a
> certificate" ?
Actually it was revised to Spring 09 at some point. But yes, the Beta
program entailed to make a request and payment at that time (including
right now) for lower fees and receive the benefits later. Initially no
certificates were issued at all until the 30th of January 2009, those
which hold certificates will see the green address bar obviously only
after enablement.
>
> This being said it, I think I can start to reconstruct what happened
> here, I guess this beta program apparently has strongly upset some CA
> who have then been very hard looking for a concrete proof that you had
> indeed issued EV cert before hand, and who at the end only found the
> certs from 22nd July 2008, not anything coming from the beta program.
Entirely correct.
ro...@comodo.com
> We recognize and acknowledge (after being made aware by Frank Hecker)
> that StartCom issued certificates, in July 22nd 2008 mistakenly with the
> EV OID in its CA policy extension, from its Class 1 intermediate CA. We
> acknowledge that at that time the EV guidelines were misinterpreted and
> because of that didn't take action.
OK, thanks.
Are these correct statements of fact?
1) You issued 60 certificates from your Class 1 intermediate CA on (or
around) July 22nd 2008 which included the EV OID.
2) You have subsequently revoked all 60 certificates.
3) You have not issued any other certificates which included the EV
OID, other than those which were issued both since 31st December 2008
and in accordance with the EV guidelines.
Regards
Robin
Eddy Nigg
> OK, thanks.
>
> Are these correct statements of fact?
> 1) You issued 60 certificates from your Class 1 intermediate CA on (or
> around) July 22nd 2008 which included the EV OID.
> 2) You have subsequently revoked all 60 certificates.
> 3) You have not issued any other certificates which included the EV
> OID, other than those which were issued both since 31st December 2008
> and in accordance with the EV guidelines.
>
>
Yes, this is 100% correct. To be very precise there were 64 certificates
affected, all issued around 22nd of July 2008, all were revoked at the
18th and 19th of March 2009. StartCom hasn't issued any other
certificates with this OID before the 30th of January 2009. And StartCom
has intentionally issued the first EV certificate at the 30th of January
2009 in compliance with the EV guidelines.
Jean-Marc Desperrier
> We assumed that because the intermediate CAs which issues the end-user
> certificates doesn't have the 2.5.29.32.0 (anyPolicy) OID in its policy
> extension (they were Class 1-3 CAs), those certificates wouldn't be
> recognized anyway as EV certificates, should at any time in the future
> our EV OID be enabled with the browsers. Also important to note that
> implementation for EV was mostly pending at that time.
If I understand correctly, the problem came from the fact you thought an
OID value could be reused for a different kind of certificate when they
are not issued under the same CA ?
On one hand this raises some questions about how well you understand the
OID concept, on the other the problem has apparently been corrected as
soon once you have been aware of the situation.
So the only point that stays is "Does the fact a CA thought OID can be
reused raise enough doubts about it's technical competence to distrust
it's going to properly manage it's operations in the future" ?
I'd say there has been so many mishaps in this industry that it would be
very hard to consider this as worse than some of those we have seen in
the recent past coming from major vendors (like continuing to use MD5
without randomized serial number until early 2009).
This been said, those cert should not technically have been considered
as valid EV cert if the intermediate CA did not have anypolicy.
But given the existing practice about the policy extension, it's not
surprising at all that many software don't implements all the
verifications theoretically required when interpreting it.
And it doesn't change anything to the fact reusing an OID is a big no-no.
Jean-Marc Desperrier
> This being said, could you change the MIME type this URL sends back to
> "application/pkix-cert" instead of "application/pkcs7-mime" ?
> Since "application/pkcs7-mime" is the type you should be sending back if
> you sent a CMS instead of an X509 cert.
And it's now "application/pkix-cert". Good.
Eddy Nigg
> As a relying party, when visiting a Web site authenticated by an EV SSL
> certificate issued by Startcom, do you really think that users will
> figure out that URL? You fail to mention the EV appendix in (and its
> expecting people to find a statement buried deep down in a bug tracking
> system? You must be joking.
>
I'm going to reply only to a few comments, because other events are
going to get my attention now. All relevant policies are easily findable
and obtainable at our web site. Additionally the relevant URLs of the
policies are embedded in the policy extension:
Not Critical
1.3.6.1.4.1.23223.2:
Certification Practice Statement pointer:
http://www.startssl.com/policy.pdf
Certification Practice Statement pointer:
http://www.startssl.com/extended.pdf
>
>> The intermediate CA certificates are stored in an HSM with FIPS 140-2
>> achieved level 3 certification. Happy?
>>
> No. I was asking about "the HSM [...] which is used to store the key of
> your root CA created in 2006". By this, I mean the private key whose
> public part is identified by the
> 4e:0b:ef:1a:a4:40:5b:a5:17:69:87:30:ca:34:68:43:d0:41:ae:f2 key
> identifier (SHA-1 hash of the respective subjectPublicKey structure).
> The RSA modulus of this key (4096 bits) starts with c1:88:db:09:...,
> which should certainly make it clear what key pair I'm referring to.
>
>
And I told you to read the relevant section of our CA policy. It's right
there.
Eddy Nigg
Eddy Nigg wrote:
We assumed that because the intermediate CAs which issues the end-user
certificates doesn't have the 2.5.29.32.0 (anyPolicy) OID in its policy
extension (they were Class 1-3 CAs), those certificates wouldn't be
recognized anyway as EV certificates, should at any time in the future
our EV OID be enabled with the browsers. Also important to note that
implementation for EV was mostly pending at that time.
If I understand correctly, the problem came from the fact you thought an OID value could be reused for a different kind of certificate when they are not issued under the same CA ?
The section I'm referring to states:
(b) EV Subordinate CA Certificates
(1) Certificates issued to Subordinate CAs that are not controlled by the issuing
CA MUST contain one or more OIDs defined by the issuing CA that
explicitly identify the EV Policies that are implemented by the Subordinate
CA;
(2) Certificates issued to Subordinate CAs that are controlled by the Root CA
MAY contain the special anyPolicy OID (2.5.29.32.0).
On one hand this raises some questions about how well you understand the OID concept, on the other the problem has apparently been corrected as soon once you have been aware of the situation.
This been said, those cert should not technically have been considered as valid EV cert if the intermediate CA did not have anypolicy.
Kyle Hamilton
interpretation of the EV guidelines) was that the intermediate CA also
had to have the EV OID (not just anyPolicy) embedded, so that a
trusted EV path could be generated.
Otherwise, sub-CAs without EV authorization could issue EV
certificates. This would have an impact on GlobalSign's EV
operations, for example, as GlobalSign offers an enterprise-CA signing
service.
I'd like to see this clarified.
-Kyle H
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
Eddy Nigg
> as well as "*now* available" which I really have a hard time figuring
> your client could understand any other way that they would receive the
> cert now, and the EV would be visible only later ?
>
Jean-Marc, it might help if I give you some more information, because
StartCom applies a different concept than most - if not all - other
commercial CAs.
All subscribers of StartCom which conform to the terms and conditions
(which includes the subscriber obligations as defined in the CA policy)
are eligible for digital certificates at the appropriate level of
validation. Initially a subscriber receives during the registration
process already an S/MIME client certificate which can be used for email
signing and encryption. It has a dual use since authentication to the
StartSSL Control Panel is controlled by client certificate
authentication (with the initially issued certificate).
A subscriber may perform different validations, for example validate a
domain name, an email address, identity, organization and at last EV.
Initially all validations are Class 1 labeled. For example, a subscriber
may just perform domain validation and receive server certificates free
of charge for the web sites. There is no limit on how many certificates
a subscriber may receive - that is, domain validation and the common
name must remain unique until expiration. Class 1 certificates don't
support wild cards, multiple domains and no identity is listed.
A subscriber may perform Class 2 identity validation in order to be
eligible for certificates in this level. If the subscriber acts on
behalf of a company, he may perform in addition to that also
organization validation and have the company name listed in the Class 2
certificates. This level supports wild cards and multiple domains, the
personal name or company name must be listed in the certificate
according the performed validation. A fee is applied to every validation
step. Also here, there are no limits placed on the amount of
certificates a subscriber may receive. Subscribers validated on this
level may also receive a code signing certificate (without extra charge).
A subscriber may perform extended validation after having at least his
identity Class 2 validated. A fee is applied for this validation. This
also means that the subscriber is eligible for certificates at any time
for the appropriate level. Subscribers which were waiting for the EV
certificates didn't had to do without certificates in the meantime.
Those were simply "only" Class 2 level certificates, until the EV
validation was confirmed. Once a subscriber (which obviously is the
representative of the organization) achieved the EV certification, he is
eligible to receive EV validated certificates on behalf of the
organization. A fee is applied to every additional certificate beyond
the first one because of the added validations we have to perform per
certificate.
As you can see, subscribers for EV certificates weren't lacking working
certificates during that time. And there was no problem waiting with
approving their extended validation status either, because they could
obtain (Class 2) certificates for their servers at any time. Our
subscribers get familiar with this concept when receiving an account
with StartSSL and the processes for performing the various validations
is described. For somebody not familiar with StartCom's concept it may
be a bit surprised initially - which perhaps happened to you as well.
That's the reason why subscribers didn't had to receive EV certificates
premature.
Eddy Nigg
> My understanding of the EV guidelines (or at least Mozilla's
> interpretation of the EV guidelines) was that the intermediate CA also
> had to have the EV OID (not just anyPolicy) embedded, so that a
> trusted EV path could be generated.
>
This is apparently not the case despite "popular" believe. Even
Jean-Marc fell into this pit, but more understandable since he doesn't
implement EV... ;-)
> Otherwise, sub-CAs without EV authorization could issue EV
> certificates. This would have an impact on GlobalSign's EV
> operations, for example, as GlobalSign offers an enterprise-CA signing
> service.
>
Yes, obviously with the lack of an anchor in the issuing intermediate CA
certificate, any sub CA can issue EV certificates. For example all the
35 or so external intermediate CAs of Verizon can simply add or change
the policy OID in order to have a perfectly valid EV certificate.
Perhaps this should be revised to the way as we apparently understood
that previously and require either the EV OID or anyPolicy OID in the
intermediate CA. The EV guidelines would have to be changed to require
either OID and browser would have to be required to check it.
Alternatively Mozilla could instead add every intermediate CA
certificate which is eligible to issue EV certificates and add to it the
EV OID pointer instead doing the same for the root certificate. Like
this only the specific issuer could issue EV certificates. It would have
also another benefit, since Mozilla could enable and disable specific
issuers at will, for example when failing to provide an audit report in
time or other issues. That's far better than disabling the root.
Kyle Hamilton
recommend a suspension of the UI and EV enablement process until it's
ironed out at the CA/B Forum and updated guidelines issued.
(I'm sorry that this recommendation comes during your request for
EV-enablement, Eddy, but this is more serious than any single CA.)
I still recommend enablement of trust bits for code-signing, though.
-Kyle H
Kaspar Brand
> On 04/17/2009 07:09 PM, Kaspar Brand:
>> As a relying party, when visiting a Web site authenticated by an EV SSL
>> certificate issued by Startcom, do you really think that users will
>> figure out that URL? You fail to mention the EV appendix in (and its
>> relevance to) your "Policy& Practice Statements" document, and are
>> expecting people to find a statement buried deep down in a bug tracking
>> system? You must be joking.
>>
>
> Additionally the relevant URLs of the policies are embedded in the policy
> extension:
The issue is not how to locate the EV appendix. The issue is that your
"Policy & Practice Statements" document does not explicitly reference
the EV appendix. If an appendix just covers a few additional details,
then maybe it's acceptable to not list it explicitly in your main
document. But if that particular appendix possibly *overrules*
statements in your main policy, then it certainly needs to be explicitly
referenced in that main policy, and the main policy also needs to state
that stipulations from the EV appendix possibly take precedence. (I'm
sure your lawyer will tell you the same thing.)
>> No. I was asking about "the HSM [...] which is used to store the key of
>> your root CA created in 2006". By this, I mean the private key whose
>> public part is identified by the
>> 4e:0b:ef:1a:a4:40:5b:a5:17:69:87:30:ca:34:68:43:d0:41:ae:f2 key
>> identifier (SHA-1 hash of the respective subjectPublicKey structure).
>> The RSA modulus of this key (4096 bits) starts with c1:88:db:09:...,
>> which should certainly make it clear what key pair I'm referring to.
>>
>>
>
> And I told you to read the relevant section of our CA policy. It's right
> there.
Ok, if you don't want to answer the question here yourself, then allow
me to do that, also for the benefit of the other readers of this thread.
Here are my conclusions:
1) The private key of the Startcom root CA certificate (CN=StartCom
Certification Authority, issued on 17 September 2006) is not stored on
what is commonly known as a "hardware security module" (HSM).
2) The private key of the Startcom root CA certificate (or its two
shares, more specifically) is stored on standard commercially available
"external media devices", which are not certified to any common security
requirements standard for cryptographic modules (e.g. FIPS 140-2).
3) A passphrase is used to protect the two private key shares stored on
the "external media devices".
4) To use the private key of the root CA for a signing operation, it is
sufficient if one (1) "executive officer of StartCom" (with access to
the two key shares stored on the "external media devices") provides the
correct passphrase.
For the sake of reference, the above statements are my interpretation of
the following text in the "Policy & Practice Statements" document
(http://www.startssl.com/policy.pdf, p. 15):
> The private CA root key shall be stored in encrypted form in safety
> vaults, divided into two external media devices and stored at two
> different locations and protected by a pass phrase. Only both
> external devices may recreate the private CA root key, which is needed
> for signing actions such as issuance of Intermediate CA certificates
> and Certificate Revocation Lists.
> The signing of Intermediate Certificates and Certificate Revocation
> Lists covering the Intermediate CAs shall be performed exclusively
> by an executive officer of StartCom.
Please let me know if my conclusions are correct.
Kaspar
Kaspar Brand
>> Are these correct statements of fact?
>> 1) You issued 60 certificates from your Class 1 intermediate CA on (or
>> around) July 22nd 2008 which included the EV OID.
>> 2) You have subsequently revoked all 60 certificates.
>> 3) You have not issued any other certificates which included the EV
>> OID, other than those which were issued both since 31st December 2008
>> and in accordance with the EV guidelines.
>>
>>
>
> Yes, this is 100% correct. To be very precise there were 64 certificates
> affected, all issued around 22nd of July 2008, all were revoked at the
> 18th and 19th of March 2009. StartCom hasn't issued any other
> certificates with this OID before the 30th of January 2009.
Taking the last sentence of your statements (in its full context, NB):
what do you mean exactly by "hasn't issued *any other* [my emphasis]
certificates with this OID before the 30th of January 2009"? What OID
was added to the certificate(s) for forum.startcom.org and
blog.startcom.org, which were identified as "Web sites for checking of
EV" in the description of your request filed on 19 August 2008
(https://bugzilla.mozilla.org/show_bug.cgi?id=451298#c0)?
Even if the certificates for forum.startcom.org/blog.startcom.org "were
certificates issued to ourselves", as you previously wrote, they are
still relevant in this context (especially the question of which policy
OID you put into what certificate(s) at what time). Consider this as an
explicit request to provide both the end-entity certificates for
forum.startcom.org/blog.startcom.org and the intermediate CA certificate
as they were in use on these systems between August and December 2008,
so that the interested reader can examine them himself (either by
attaching the certs to bug 451298, or by providing URLs for retrieving
them).
Kaspar
Kaspar Brand
> Yes, obviously with the lack of an anchor in the issuing intermediate CA
> certificate, any sub CA can issue EV certificates. For example all the
> 35 or so external intermediate CAs of Verizon can simply add or change
> the policy OID in order to have a perfectly valid EV certificate.
If that is really true for the implementation in Firefox, then it's most
likely an issue with the way PSM/NSS are using libpkix (for performing
RFC 3280/5280 path validation). Possibly here:
I don't think that you'll run into this issue with MSIE, and wouldn't
consider it a problem of the EV guidelines as such.
Kaspar
Eddy Nigg
> 1) The private key of the Startcom root CA certificate (CN=StartCom
> Certification Authority, issued on 17 September 2006) is not stored on
> what is commonly known as a "hardware security module" (HSM).
>
Right. It's also rather difficult to find these days an HSM for this key
size.
> 4) To use the private key of the root CA for a signing operation, it is
> sufficient if one (1) "executive officer of StartCom" (with access to
> the two key shares stored on the "external media devices") provides the
> correct passphrase.
>
I agree that it's not obvious (and should be made perhaps clearer),
however at least one of the pieces in not accessible by one person alone
as referenced in the section before that. Nevertheless and despite not
being made entirely clear, two-person rule applies and requiring
authorization (again as in the section above). I let you guess where one
safety vault is located, not going to tell you where the other one is ;-)
Eddy Nigg
> Consider this as an
> explicit request to provide both the end-entity certificates for
> forum.startcom.org/blog.startcom.org and the intermediate CA certificate
> as they were in use on these systems between August and December 2008,
> so that the interested reader can examine them himself (either by
> attaching the certs to bug 451298, or by providing URLs for retrieving
> them).
>
OK, as such no problem with it....if this request is being the only
issue hindering StartCom's approval I'll gladly comply, otherwise it's
rather superfluous.
Eddy Nigg
> Eddy Nigg wrote:
>
> http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/security/nss/lib/certhigh/certvfypkix.c&rev=1.41&root=/cvsroot&mark=656-657#650
>
> (also note
> http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/security/nss/lib/certhigh/certvfypkix.c&rev=1.41&root=/cvsroot&mark=429,438#428)
>
> I don't think that you'll run into this issue with MSIE, and wouldn't
> consider it a problem of the EV guidelines as such.
>
Not following, perhaps you can be more specific? I don't know what the
PKIX_ProcessingParams_SetExplicitPolicyRequired function really does,
despite trying to guess from the name. And how do you think this is NOT
a problem of the EV guidelines?
Ian G
> Kaspar Brand wrote:
>> Is this request for EV enablement on some sort of fast track?
>
> As Eddy noted, we've been following a general policy of prioritizing
> EV-related requests over non-EV requests.
Is there a general principle here? Such as, expediting an "upgrade"
where already reviewed is expedited?
> Strictly speaking the Startcom request to enable the code signing bit
> could have been handled separately from the EV request, but if we can
> get both requests handled at the same time that's fine by me. If there
> are any outstanding issues with the code signing request that prevent
> processing it now, then we'll drop it back in the queue with the other
> non-EV requests.
That's fine by me.
iang
Frank Hecker
> On 17/4/09 18:31, Frank Hecker wrote:
>> As Eddy noted, we've been following a general policy of prioritizing
>> EV-related requests over non-EV requests.
>
> Is there a general principle here? Such as, expediting an "upgrade"
> where already reviewed is expedited?
No, it has more to do with promoting use of EV. When the EV guidelines
were initially published and Firefox was modified to include EV support,
I processed a number of EV requests at once (jumping them past non-EV
requests in the queue) in order to have EV-issuing CAs enabled for
Firefox 3. I done this for all EV requests since then.
Nelson Bolyard
Yeah, given that EV was a major new feature of FF 3.0, it was somewhat
embarrassing that few CAs were marked approved to issue EV certs in FF.
So, it made sense to move those EV approval requests to the head of the
list, and probably still does.
Eddy Nigg
This undermines the entire EV situation, and I **WHOLEHEARTEDLY** recommend a suspension of the UI and EV enablement process until it's ironed out at the CA/B Forum and updated guidelines issued.
In K. OTHER CONTRACTUAL COMPLIANCE of the EV guidelines, section 36 (b) Root CA Indemnification:
In cases where the Subordinate CA and the Root CA
are different legal entities and the Root CA specifically enables the Subordinate
CA to issue EV Subscriber Certificates, the Root CA SHALL also be responsible
for the performance and warranties of the Subordinate CA, for the Subordinate
CA’s compliance with these Guidelines, and for all liabilities and indemnification
obligations of the Subordinate CA under these Guidelines, as if the Root CA were
the Subordinate CA issuing the EV Certificates.
For example, this Section SHALL NOT apply to cases where a Root CA “A”,
from a different legal entity, cross-certifies Root CA “B” to enable certificates
issued by “B” to be trusted in older, non-EV-enabled browsers. The cross
certificate issued by “A” to “B” does not enable EV according to these guidelines.
Certificates issued by “B” are EV-enabled only when an EV-enabled browser can
build a certificate chain to the root certificate of “B”.
Now I wonder and wonder....how does the Root CA enable sub-ordinate and prevent cross-signed roots beyond the contractual compliance? How does the software KNOW that this sub-ordinate CA certificate or that cross-signed root CAN NOT issue EV certificates? How does NSS know that the various chained and cross-signed roots are not supposed to be EV issuers? How come that the EV OID or anyPolicy OID may be omitted (in case of directly operated root or sub-CA). How can the software differentiate between an externally operated and internally operated sub-CA? How can the software know at all with the current guidelines?
According to my understanding today, software vendors don't have any means to verify if the issuing CA certificate is entitled to issue EV certificates once a root's EV OID has been approved, and the CAs have no means to indicate, prevent, enable or disable the issuance of EV certificates from any sub-ordinate or cross-signed issuer certificate.
Additionally how do software vendors prevent the issuance of EV certificates from cross-signed roots? There might be some means, but I'm not sure if A) this is implemented, B) the software (NSS) has the capability. It's clear how to enable "B" for EV in the example above, but what if "A" is enabled?
Kaspar Brand
> On 04/18/2009 08:49 AM, Kaspar Brand:
>> 1) The private key of the Startcom root CA certificate (CN=StartCom
>> Certification Authority, issued on 17 September 2006) is not stored on
>> what is commonly known as a "hardware security module" (HSM).
>>
>
> Right. It's also rather difficult to find these days an HSM for this key
> size.
Ok, I've seen enough by now - and let that finding (and your
confirmation) speak for itself. A competent reader should hopefully be
able to make an informed decision about whether that's really a
state-of-the-art method for protecting the private key of a (potential)
EV root at the beginning of the 21st century. It's also a good indicator
to judge the quality of the Webtrust audit (for the period of 2008), and
the competence of the individuals who were carrying out this audit.
>> 4) To use the private key of the root CA for a signing operation, it is
>> sufficient if one (1) "executive officer of StartCom" (with access to
>> the two key shares stored on the "external media devices") provides the
>> correct passphrase.
>>
>
> I agree that it's not obvious (and should be made perhaps clearer),
> however at least one of the pieces in not accessible by one person alone
> as referenced in the section before that. Nevertheless and despite not
> being made entirely clear, two-person rule applies and requiring
> authorization (again as in the section above). I let you guess where one
> safety vault is located, not going to tell you where the other one is ;-)
I assume you refer to the statement "Physical access to the server
infrastructure and facilities shall be logged and signed by at least one
other witness on the four eyes principal". Just dropping the "four eyes
principal" [sic] buzzword doesn't really make it much better, IMO, and
on a related matter, let me mention that previous versions of the policy
(one of which was in effect at the time that key pair was actually
created, back in 2006) were even more sloppy in this respect; even
nonsense like "Removal of any device from this systems are strictly
prohibited and must be authorized by the CEO of SFSCA" can be found there.
So, powers of Mozilla, feel free to take your (hopefully informed)
decision regarding this request. I wouldn't be surprised if you simply
skip over the concerns raised so far, but in any case, it won't change
the decision I took for myself quite some time ago: to keep any trust
bits for the Startcom roots unset in all NSS databases I'm normally using.
Kaspar
Jean-Marc Desperrier
>> My understanding of the EV guidelines (or at least Mozilla's
>> interpretation of the EV guidelines) was that the intermediate CA also
>> had to have the EV OID (not just anyPolicy) embedded, so that a
>> trusted EV path could be generated.
>
> This is apparently not the case despite "popular" believe. Even
> Jean-Marc fell into this pit, but more understandable since he doesn't
> implement EV... ;-)
I feel I'll have to make myself clearer about what I meant. This is all
specified by the Certification Path Validation of section 6 of RFC5280 (
http://tools.ietf.org/html/rfc5280#section-6 ). It first says about
policies :
The path
validation process also determines the set of certificate policies
that are valid for this path, based on the certificate policies
extension, policy mappings extension, policy constraints extension,
and inhibit anyPolicy extension.
For shorts, I will not consider here policy mappings, policy constraints
and inhibit anyPolicy any further.
If the set of
certificate policies that are valid for this path is not empty, then
the result will be a valid policy tree of depth n, otherwise the
result will be a null valid policy tree.
Here lies the cause for the problem we have here. Policies are usually
so improperly used that almost any certification path in the wild will
end up with a null valid policy tree. So what's the implementor to do ?
If he implements the full checks from RFC5280, he doesn't get any usable
results because all the paths he sends to his algorithm go out of it
with a null valid policy tree. "Yes you put the policy OID here, but two
steps up the chain you made a mistake, so the OID doesn't count, it's
just like you had put nothing".
So it's no surprise that most implementors did not implement the full
checks, but included some options that enable shortcuts in order to
guess what the person who emitted the certificate *wanted* instead of
strictly talking what he has set.
So I'm not surprised that some implementation treat "no policy
extension" the same as "policy extension with the anyPolicy value". It's
not correct but it's not very surprising it has been done.
It's just like the fact they still accept version 1 CRL ten years after
version 2 CRL have been made a *MUST* in the RFC (I did not find time
yet to write down my detailled opinion about that yet. I'd hope Mozilla
can push toward putting an end to their use. Meanwhile we'll have to
accept them for quite a while because they are used at so many places,
and it's very hard to refuse a CA just because it uses them when it has
good operational constraints for that).
Kaspar Brand
It's nevertheless hard to follow why bug 453460 (EV enablement of an
existing root, audit report provided on 5 November 2008, status changed
to "EV - information confirmed complete" on 19 November 2008) is still
sitting in the queue, after almost five months, while Startcom's request
(audit report provided on 10 March 2009, status changed to "Information
confirmed complete" on that same day) went into public discussion just
one month after the status change. And no, I have no specific - neither
personal nor job-related - interest in "expediting" the request from bug
453460 (before anybody starts speculating about my motivation in
public), and also don't particularly care about how fast it's eventually
dealt with.
Kaspar
Kyle Hamilton
which is granted some special status by virtue of its
externally-asserted trust. GlobalSign has an organizational CA
cross-certification program that will (at this point) allow for any of
its customers to create an EV certificate. Any other EV-enabled root
program that has a cross-signature mechanism will also have the same
problem.
The only alternatives, for user security, that I can perceive here are:
1) Suspend the entire EV UI and program in Mozilla's software (NSS and
Firefox), or
2) remove EV status from roots which have a cross-certification program
either/both of which would be necessary until such time as the proper,
specified policy handling is implemented in NSS.
-Kyle H
Jean-Marc Desperrier
> the intermediate CA also
> had to have the EV OID (not just anyPolicy) embedded, so that a
> trusted EV path could be generated.
It *has*, oppposite to what begins to be suggested in this thread, to
include a certificate policies extension as shown in step (e) of
http://tools.ietf.org/html/rfc5280#section-6.1.3 :
(e) If the certificate policies extension is not present, set the
valid_policy_tree to NULL.
And as http://tools.ietf.org/html/rfc5280#section-6.1.2 specifies :
Once the tree is set to NULL, policy processing
ceases.
Which means that you *cannot* consider the EV policy value further down
the tree as valid.
But anyPolicy allows any policy to be considered valid as shown in step
2 of 6.1.3 :
(2) If the certificate policies extension includes the policy
anyPolicy [...]
The text below is very hard to understand, so I'd suggest you jump to
the more concrete example given down the paragraph :
For example, consider a valid_policy_tree with a node of
depth i-1 where the expected_policy_set is {Gold, Silver}.
Assume anyPolicy appears in the certificate policies
extension of certificate i [...]
And the ASCII schema below shows that both the Gold and Silver policies
are considered valid for node i that contains anyPolicy.
anyPolicy would no be usable if the path was initialized with
initial-any-policy-inhibit set to true as described in
http://tools.ietf.org/html/rfc5280#section-6.1.1.
But I understand the EV guideline does not require this.
> Otherwise, sub-CAs without EV authorization could issue EV
> certificates. This would have an impact on GlobalSign's EV
> operations, for example, as GlobalSign offers an enterprise-CA signing
> service.
I'd suggest some options to avoid this problem.
- Option 1 : To set that when the operation of a sub-CA is delegated to
another entity, the pathLenConstraint of that CA *must* be set to zero.
This means that this sub-CA can only issue end-entity certificate, and
never create a valid new sub-CA.
This is simple and solves a whole class of problems, including this one.
In fact, I'd say that any CA intended to be connected on-line to the
internet to issue end-user certificat should have a pathLenConstraint of
zero. Do you know this would *also* have made the "MD5 considered
harmful today" attack much, much less dangerous ?
- Option 2 : Put an explicit policy in the intermediate CA certificate.
This should be enough for the EV policy to not been considered valid if
it appears further down the chain. But what if some implementations
don't respect that ? I thought about using requireExplicitPolicy
additionnally, but this could break some scenario for implementations
that do implement the full verification and use non zero explicit_policy
to accept some technically invalid path.
So I prefer option 1. It's simpler and much better implemented.
Jean-Marc Desperrier
> As you can see, subscribers for EV certificates weren't lacking working
> certificates during that time. And there was no problem waiting with
> approving their extended validation status either, because they could
> obtain (Class 2) certificates for their servers at any time.
OK, this sets things straight about why your beta program was described
this way.
I'll think we have now a clear and satisfying answer regarding the
accusation of the beta problem being used to issue EV certificates
before StartCom was allowed to.
I think we have also a clear, whilst less satisfying, explanation about
why around 60 certificates included your EV OID by error.
But the mitigation is that no browser properly implementing EV
verification should have shown them as EV certificates.
I understand those certificates are no longer on-line, so a live testing
of which browsers have this problem is not simple.
So it would be good if the people who saw this problem could report
which browsers have it.
Eddy Nigg
> Ok, I've seen enough by now - and let that finding (and your
> confirmation) speak for itself. A competent reader should hopefully be
> able to make an informed decision about whether that's really a
> state-of-the-art method for protecting the private key of a (potential)
> EV root at the beginning of the 21st century.
>
Oh, we believe this to be a very efficient, simple method to keep the
root key from being compromised. This key has never seen a hard drive or
network card anywhere near it, is handled encrypted and in memory only
during its operations. The key parts which comprise the root key are
physically protected by various means, combined and used only when
necessary - usually once year for issuing the CRL. Survival in case of
disaster is another important consideration. That's not all, but some
important factors which make up the controls from keeping this root
compromised.
But as you mentioned earlier - the CA is free to implement the
protections and controls it deems necessary!
> to keep any trust
> bits for the Startcom roots unset in all NSS databases I'm normally using.
>
This is certainly a good recommendation for any concerned party like
yours. It's noted that you are not going to be a relying party. :-)
Eddy Nigg
> But the mitigation is that no browser properly implementing EV
> verification should have shown them as EV certificates.
>
How do you come to this conclusion? There is no requirement in the EV
guidelines to issue EV certificates from an issuer with a specific OID.
No OID is required in the issuer certificate. Otherwise those
certificate would not have posed a problem, right?
> So it would be good if the people who saw this problem could report
> which browsers have it.
I don't believe that anybody actually tested it with any browser.
Jean-Marc Desperrier
> If that is really true for the implementation in Firefox, then it's most
> likely an issue with the way PSM/NSS are using libpkix (for performing
> RFC 3280/5280 path validation). Possibly here:
>
> http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/security/nss/lib/certhigh/certvfypkix.c&rev=1.41&root=/cvsroot&mark=656-657#650
>
> (also note
> http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/security/nss/lib/certhigh/certvfypkix.c&rev=1.41&root=/cvsroot&mark=429,438#428)
>
> I don't think that you'll run into this issue with MSIE, and wouldn't
> consider it a problem of the EV guidelines as such.
*If* that's really true.
In the code that you point to, I only see the initial State Variable
"explicit_policy" being initialized to a value that makes it possible to
allow paths that don't contain a valid policy.
This allows "normal" paths to "get in" despite resulting into null valid
policy tree.
But for EV validation, you *need* to check that the policy tree you get
at the end contains the EV OID and you have to reject a null valid
policy tree, or you'd be checking nothing.
So I don't expect the initialization you're pointing to to have that
effect. In fact the code seems to implement a fully proper path
validation, and after reading it, I'd just be surprised if Firefox has
the weakness that has been described to us.
So it would be nice if robin could tell us with which browser he has
seen the problem he describes. I'm not going to prejudge which browser
is guilty here, but if we only look at the history up to now, MSIE has
much more often had bad failures due to some hacks made for the sake of
backwards compatibility than Firefox.
Jean-Marc Desperrier
> I state and maintain that this is absolutely unacceptable for any root
> which is granted some special status by virtue of its
> externally-asserted trust.
Kyle, in my message above I didn't take into account that by properly
initializing "explicit_policy", you can allow null valid policy trees
when needed, without hacking the validation algorithm.
So here we are. I'm not sure anymore they are any "good" reasons to use
a hacked validation algorithm, and so I'm not convinced they are many
broken implementation around. Therefore the very first we need is to
evaluate how many browser don't properly do this check. And if we find
out Firefox does it properly, the problem doesn't directly concern the
mozilla root program.
Jean-Marc Desperrier
> how does the Root CA enable sub-ordinate and prevent cross-signed roots
> beyond the contractual compliance? How does the software KNOW that this
> sub-ordinate CA certificate or that cross-signed root CAN NOT issue EV
> cross-signed roots are not supposed to be EV issuers?
Some extension in the cert should be set to specify this.
It would be good if the guideline were explicit about which extension it
recommends to put in the cross-certificate.
> How come that the
> EV OID or anyPolicy OID may be omitted (in case of directly operated
> root or sub-CA).
It can't.
> How can the software differentiate between an
> externally operated and internally operated sub-CA? How can the software
> know at all with the current guidelines?
A software that allows the EV or anyPolicy OID to be omitted in a sub-CA
very probably can't properly differentiate such cases.
We need to identify which softwares allow that, how exactly they are
deficient, and then either modify the guideline, or recommend that they
disable any support for EV until they are corrected.
Kyle Hamilton
<jmd...@alussinan.org> wrote:
> Kyle Hamilton a écrit :
>
>> Otherwise, sub-CAs without EV authorization could issue EV
>> certificates. This would have an impact on GlobalSign's EV
>> operations, for example, as GlobalSign offers an enterprise-CA signing
>> service.
>
> I'd suggest some options to avoid this problem.
>
> - Option 1 : To set that when the operation of a sub-CA is delegated to
> another entity, the pathLenConstraint of that CA *must* be set to zero. This
> means that this sub-CA can only issue end-entity certificate, and never
> create a valid new sub-CA.
> This is simple and solves a whole class of problems, including this one.
> In fact, I'd say that any CA intended to be connected on-line to the
> internet to issue end-user certificat should have a pathLenConstraint of
> zero. Do you know this would *also* have made the "MD5 considered harmful
> today" attack much, much less dangerous ?
No, because all the sub-CA issued from the parent, EV-enabled CA would
have to do to create a valid EV end-entity certificate would be to
include the parent's EV OID in the extensions. (If anyPolicy is
implicit, then this is The Problem.) (Note that EV certificates are
by definition end-entity certificates, so pathLenConstraint won't help
at all here.)
> - Option 2 : Put an explicit policy in the intermediate CA certificate. This
> should be enough for the EV policy to not been considered valid if it
> appears further down the chain. But what if some implementations don't
> respect that ? I thought about using requireExplicitPolicy additionnally,
> but this could break some scenario for implementations that do implement the
> full verification and use non zero explicit_policy to accept some
> technically invalid path.
Option 2 is more technically correct.
> So I prefer option 1. It's simpler and much better implemented.
...and much more fraught with peril.
-Kyle H
Jean-Marc Desperrier
> On 04/19/2009 01:58 PM, Jean-Marc Desperrier:
>> But the mitigation is that no browser properly implementing EV
>> verification should have shown them as EV certificates.
>
> How do you come to this conclusion? There is no requirement in the EV
> guidelines to issue EV certificates from an issuer with a specific OID.
> No OID is required in the issuer certificate. Otherwise those
> certificate would not have posed a problem, right?
The keyword is *properly implementing*. In one of my message today, I
quoted the text from RFC5280 that makes it *required* to have a
certificate policy extension in the certificates up the validation path
to consider the EV OID policy valid in the EV certificate. At least
anyPolicy is needed.
>> So it would be good if the people who saw this problem could report
>> which browsers have it.
>
> I don't believe that anybody actually tested it with any browser.
Then why are are they saying that your certs were valid EV certs, by
which I understand "a user could have connected to the site with a
browser and seen a green bar" ?
If there is no possible way by which an end user could have seen a green
bar when connected to those sites, then that's a major mitigation and
there's no need to discuss it as much as we do now.
And if it's possible, then the EV support of the concerned browser is
broken.
Eddy Nigg
How come that the
EV OID or anyPolicy OID may be omitted (in case of directly operated
root or sub-CA).
It can't.
EV Subordinate CA Certificates
(1) Certificates issued to Subordinate CAs that are not controlled by the issuing
CA MUST contain one or more OIDs defined by the issuing CA that
explicitly identify the EV Policies that are implemented by the Subordinate
CA;
(2) Certificates issued to Subordinate CAs that are controlled by the Root CA
MAY contain the special anyPolicy OID (2.5.29.32.0).
Doesn't this allow to have no OID at all? Or am I misinterpreting and was initially right with my assumption that EE certificates with the EV OID but not signed from an intermediate CA identified by either the EV OID too or with the anyPolicy OID should not be valid EV certificates?
The point is, that the guidelines differentiate by controlled and not controlled sub-CAs. In case of controlled sub-CAs, it doesn't say that it MUST have either the EV OID or MAY have INSTEAD the anyPolicy OID.
A software that allows the EV or anyPolicy OID to be omitted in a sub-CA very probably can't properly differentiate such cases.
We need to identify which softwares allow that, how exactly they are deficient, and then either modify the guideline, or recommend that they disable any support for EV until they are corrected.
Eddy Nigg
It's nevertheless hard to follow why bug 453460 (EV enablement of an existing root, audit report provided on 5 November 2008, status changed to "EV - information confirmed complete" on 19 November 2008) is still sitting in the queue, after almost five months, while Startcom's request (audit report provided on 10 March 2009, status changed to "Information confirmed complete" on that same day) went into public discussion just one month after the status change.
CAs are assigned priorities based on the following factors, among others:
- length of time the CA has been in the queue
- whether information gathering for the CA has been completed
- whether the request is for EV status or not
- market share of the CA
- size and importance of the CA's geographic market
- for government CAs, whether the government is national or regional
Kyle Hamilton
and start fresh with something not so fraught with overloaded and
unintended meanings. :P
-Kyle H
Jean-Marc Desperrier
> I have no specific - neither
> personal nor job-related - interest in "expediting" the request from bug
> 453460 (before anybody starts speculating about my motivation in
> public)
You have every right to be concerned about whether the evaluation
process is fair to everyone, and there is no reason why one should
speculate about that. We'll need an answer from Kathleen Wilson, but it
might be that Startcom was submitted first because the Information
Gathering Document for SwissSign needed to be updated after the CP/CPS
change and Kathleen decided that this meant a delay was needed before
starting public discussion even if it was a very minor change. Note that
SwissSign is next in line after StartCom.
Jean-Marc Desperrier
> Ok, I've seen enough by now - and let that finding (and your
> confirmation) speak for itself. A competent reader should hopefully be
> able to make an informed decision about whether that's really a
> state-of-the-art method for protecting the private key of a (potential)
> EV root
I understand this message is a request to remove that root CA from the
mozilla authorized root CA list, due to improper management of it's root
key.
Might you state your findings, and your request separately in an
independent top-level message so that it's properly and visibly
evaluated instead of been lost very down the thread of discussion about
enabling the Startcom root for EV ?
Note that this request extends to a number of considerations about the
compatibility of this method with the web-trust for CA requirements, why
an auditor deemed it compatible, whether this means that the web-trust
for CA requirements are really enough for Mozilla or should be
augmented, and how far Mozilla should push the counter examination of
already evaluated requests it receives, because many have not been as
precisely scrutinized as Startcom is now, and in some case I would not
be surprised if similar problems might not have been seen. I find it a
bit amusing in contrast that you very recently were of the opinion
Mozilla *had* to blindly accept external evaluations without doing it's
own examination process.
Nelson Bolyard
> You have every right to be concerned about whether the evaluation
> process is fair to everyone, and there is no reason why one should
> speculate about that. We'll need an answer from Kathleen Wilson, but
Fully agree.
> it might be that Startcom was submitted first because the Information
> Gathering Document for SwissSign needed to be updated after the CP/CPS
> change and Kathleen decided that this meant a delay was needed before
> starting public discussion even if it was a very minor change.
Well, if any application is waiting for something to be completed, then
it should not be in "information confirmed complete" state. I've noticed
a few cases where an application that was "confirmed complete" was found
wanting some updated info. When that happens, it should revert to
"information incomplete". This should all be logged in the bug.
Nelson Bolyard
> Eddy Nigg wrote:
>> Is there any concern or valid objection to not enable the code
>> signing bit which would require separating the discussion? Else we
>> can just skip this complaint perhaps and continue...
>
> I don't really bother about the code signing part of this request, as
> long as we're not considering *EV* code signing certs (which Mozilla
> currently doesn't support). I leave it to other readers of this newgroup
> to address this part of the request.
I personally doubt that Mozilla products will ever support code signing
any more than they do now, and in fact, I expect support to decrease.
Mozilla's leaders are philosophically opposed to code signing certs.
(Although, if Eddy's code signing certs will be free, that might turn
this around.)
There have been numerous developments in the area of code signing, but
there is absolutely NO demand for any of them from Mozilla, so the
NSS team has no plans to implement any of them. With our extremely
limited resources, the NSS team focus on the features that have real
demand.
There's also no demand from Mozilla Messaging for S/MIME. SMIME is in
Thunderbird today because it was put there a long time ago, and it still
mostly works, but it's completely clear to me that, if it wasn't already
in the source code base, it would not get added today. There are patches
that add more SMIME features to TBird, but they get NO attention from the
TBird folks.
So, in truth, I don't know why Mozilla approves any certs for anything but
SSL now, because SSL is all they really care about.
(Maybe this is the wrong forum for this discussion. I don't know.)
Jean-Marc Desperrier
> EV Subordinate CA Certificates
> (1) Certificates issued to Subordinate CAs that are not controlled by
> the issuing
> CA MUST contain one or more OIDs defined by the issuing CA that
> explicitly identify the EV Policies that are implemented by the Subordinate
> CA;
> (2) Certificates issued to Subordinate CAs that are controlled by the
>
> Doesn't this allow to have no OID at all?
I think this text is not precise enough. I think the intent was, only
when the subordinate CA is controlled by the root CA, to allow using the
special anyPolicy OID as an alternative to explicitly including the OIDs
that identify the EV Policy/Policies, but *not* to allow to have no OID
at all.
This is backed by the fact that if the EV guidelines really intended to
allow not including the certificat policy at all, then it would be
telling CA that it's OK to use a path that can not be validated with the
RFC3280 algorithm, so it would also have had to explicitly say to all
sofware makers that they need to write their validation code so that
some paths that are not valid according to the RFC *must* be accepted.
One you realize that, it's clear that interpretation doesn't make sense.