Comodo request for EV-enabling 3 existing roots
Frank Hecker
add a new EV root CA certificate. Comodo also has requested enabling
three existing roots, AddTrust External CA Root, UTN - DATACorp SGC, and
UTN-USERFirst-Hardware, for EV use, and also marking all three roots for
SSL, email, and code signing use, as documented in the following bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=401587
and in the pending certificates list:
http://www.mozilla.org/projects/security/certs/pending/#Comodo
(Comodo has actually requested EV-enabling all its existing roots; I'm
looking at these three roots first because they're specifically
referenced in Comodo's EV CPS.)
I have evaluated this request, as per the mozilla.org CA certificate policy:
http://www.mozilla.org/projects/security/certs/policy/
and plan to officially approve the request after a public comment period.
Note again that this request specifically refers to the AddTrust
External CA Root, UTN - DATACorp SGC, and UTN-USERFirst-Hardware roots
referenced in comment #20 to bug 401587:
https://bugzilla.mozilla.org/show_bug.cgi?id=401587#c20
I will later consider Comodo's requests related to the other eight
Comodo roots.
Frank
--
Frank Hecker
hec...@mozillafoundation.org
Eddy Nigg (StartCom Ltd.)
> Note again that this request specifically refers to the AddTrust
> External CA Root, UTN - DATACorp SGC, and UTN-USERFirst-Hardware roots
> referenced in comment #20 to bug 401587:
>
split the request up, but on the other hand I wonder if it's really that
good. Because we might see all requests in their context maybe...not sure.
Just what somewhat annoys me, is that all this roots issue all types of
certificates from DV to EV, sometimes even their intermediate CAs do
that...it's not really an issue but makes it somehow unclear, plus if
we'd want to limit this or other CAs in some way it makes it difficult
if not impossible. Supposed an intermediate CA or CA root is dedicated
for EV only, we might have much better control. Just imagine Comodo
issues a DV cert with the EV bits on....thoughts, suggestions?
Anyway, haven't looked at their requests into some more detail and
intend to do that until the weekend.
--
Regards
Signer: Eddy Nigg, StartCom Ltd. <http://www.startcom.org>
Jabber: star...@startcom.org <xmpp:star...@startcom.org>
Blog: Join the Revolution! <http://blog.startcom.org>
Phone: +1.213.341.0390
Frank Hecker
> I working up my backlog....at first I thought this to be a good idea to
> split the request up, but on the other hand I wonder if it's really that
> good. Because we might see all requests in their context maybe...not sure.
For some information on context please see below.
> Just what somewhat annoys me, is that all this roots issue all types of
> certificates from DV to EV, sometimes even their intermediate CAs do
> that...it's not really an issue but makes it somehow unclear, plus if
> we'd want to limit this or other CAs in some way it makes it difficult
> if not impossible.
As I understand it, the original plan (as worked out within the CA
Browser Forum) was for EV not to require the creation of new roots.
Instead the certificatePolicies extension was to be used to limit how
and where EV certificates could be issued within existing CA
hierarchies. This plan is reflected in section 7 of the 1.0 EV
guidelines (pages 11-12).
Under this plan, my understanding is that the original intent of Comodo,
VeriSign, and other CAs was simply to mark their existing roots for EV
use, with an associated EV policy OID (or OIDs). Then they could simply
create new EV-specific subordinate CAs, and permit those subordinate CAs
to issue EV certificates by putting the certificatePolicies extension
with the appropriate EV OID on the subordinate CAs' CA certificates.
Unfortunately this simple plan had to be abandoned because it didn't
work properly with EV-aware versions of IE on Windows. It was OK for
Windows Vista, because Vista by default doesn't include any CA certs
other than Microsoft's own certs. Thus when IE on Vista went to a new EV
site, Windows would realize it needed the root CA cert, would go out to
Microsoft to fetch it, and would get an up-to-date copy with all the
associated EV metadata.
However although Windows XP can also fetch new roots in this way, XP
already had copies of legacy roots from Comodo, VeriSign, etc., and
hence would use the out-of-date root data that didn't include the EV
OIDs. Hence Comodo, VeriSign, etc., had to create new EV-specific roots,
so XP would be forced to go out and get the new roots (and the
associated EV metadata) instead of relying on its pre-loaded data.
But creating new EV-specific roots in turn meant that old versions of
browsers (including Firefox) wouldn't recognize sites with EV certs as
being valid SSL sites at all, since they wouldn't recognize the new
roots. So Comodo, VeriSign, etc., also implemented schemes whereby the
new EV roots would be cross-signed by legacy roots, and EV SSL sites
would send cert chains that include a CA cert corresponding to the new
EV roots, but chain up to the old roots.
Finally, the cross-signing scheme meant that an EV-aware browser (or OS)
could now see two possible paths to a trust anchor: a path terminating
at the new EV root, and a path terminating at a legacy root. In order to
absolutely guarantee that EV-aware browsers recognize EV certs in all
cases, both the new EV root and the legacy root have to be marked with
the EV metadata. This compensates for any indeterminancy in the
underlying certificate path processing code that might cause browsers to
sometimes use the legacy root as a trust anchor and in other cases to
use the new EV-specific root as a trust anchor.
So, to summarize the situation as I understand it: Adding new EV roots
was basically a hack to get IE7 on XP to treat EV certs properly.
Cross-signing using legacy roots was then a hack to get older browsers
(like Firefox 2) to recognize EV SSL sites as valid SSL sites (as
opposed to getting "unknown root" errors). Marking both the new EV roots
and legacy roots with the EV OIDs was then a hack to get EV-aware
browsers like (Firefox 3) to recognize EV certs no matter which cert
chain the underlying PKI library decided to follow.
Now that you have the context, let me get back to the Comodo
application. Comodo's roots can be divided into three classes:
1. The new Comodo EV root (COMODO Certification Authority).
2. The three legacy Comodo roots that are specifically documented (i.e.,
in Comodo's EV CPS) as participating in Comodo's cross-signing scheme
and thus could be encountered as trust anchors when processing cert
chains from EV sites (AddTrust External CA Root, UTN - DATACorp SGC, and
UTN-USERFirst-Hardware).
3. All other legacy Comodo roots, which might end up being involved in
EV-related cross-signing schemes, but don't appear to be documented as
doing so right now, based on the CPSs I've reviewed.
Based on this division, I've done evaluations and preliminary approvals
for the new EV root (class 1) and the three legacy roots in class 2, but
I've postponed action on the remaining roots (class 3) until it's
clearer whether I need to approve them for EV purposes, or can wait on this.
> Supposed an intermediate CA or CA root is dedicated
> for EV only, we might have much better control. Just imagine Comodo
> issues a DV cert with the EV bits on....thoughts, suggestions?
I think we've discussed a similar issue in relation to subordinate CAs.
There's a trade-off here between maximum control and complexity. If we
wanted maximum control then we would maintain data on every CA that
issued (or could issue) end entity certificates -- basically every root
CA and every subordinate CA under those roots, without exception. Then
we could exercise very fine-grained control: We could say, this
subordinate CA (which might be 3 or 4 levels down in the hierarchy from
a given root) can do this (issue EV certs, issue email certs, whatever),
while this other subordinate CA (somewhere else in the hierarchy under
that root) can't.
However exercising this amount of control would involve lots and lots of
work on our part, and would require maintaining very large sets of
CA-related data that we would either have to ship with Firefox or build
a scheme to have Firefox automatically fetch. Quite frankly I think it's
a non-starter.
The scheme we have now trades off maximum control for implementability.
We have relatively coarse-grained controls, and then we rely on CAs to
implement more fine-grained controls (e.g., using certificatePolicies,
EKU, etc.). This means that CAs in theory could abuse the scheme (e.g.,
by issuing EV certs from subordinates not intended to be used for this
purpose). That's where we rely on auditors to verify that CAs are
operating according to their stated plans. If that turns out not to be
true in certain cases then we can look at those on a case-by-case basis
and figure out if we need to or want to take certain actions.
I can't write any more on this right now, but I hope the above addresses
at least some of the questions you had.
Rob Stradling
said, but I'd just like to add a couple of additional comments (inline) in
reply to Eddy...
On Wednesday 12 March 2008, Frank Hecker wrote:
> Eddy Nigg (StartCom Ltd.) wrote:
> > I working up my backlog....at first I thought this to be a good idea to
> > split the request up, but on the other hand I wonder if it's really that
> > good. Because we might see all requests in their context maybe...not
> > sure.
>
> For some information on context please see below.
>
> > Just what somewhat annoys me, is that all this roots issue all types of
> > certificates from DV to EV,
The Root Certificate Programs of many software providers place restrictions on
the total number of Root CA Certificates that they will accept from any one
CA organization.
In the case of Microsoft's Root Certificate Program: "Up to three roots per CA
can be accepted into the Program because each additional root negatively
impacts users by increasing download time".
http://www.microsoft.com/technet/archive/security/news/rootcert.mspx?mfr=true
Also, we have encountered a number of Root Programs for mobile/embedded
devices that restrict the number of roots to only 1 or 2 per CA.
Given that we want to embed the same Root Certificate(s) in all platforms (to
avoid, if at all possible, the need for further problem-prone
cross-certification!), we really need to have generic (rather than
purpose-specific) trust anchors.
> > sometimes even their intermediate CAs do that...
For the record, I can assure you that Comodo never issue DV and EV certs from
the same Intermediate CA.
Having just said that, there is one exception I can think of: to help Mozilla
do technical testing, we recently issued an EV certificate and a non-EV
Certificate directly from each of our Roots.
--
Rob Stradling
Senior Research & Development Scientist
Comodo - Creating Trust Online
Office Tel: +44.(0)1274.730505
Fax Europe: +44.(0)1274.730909
www.comodo.com
Comodo CA Limited, Registered in England No. 04058690
Registered Office:
3rd Floor, 26 Office Village, Exchange Quay,
Trafford Road, Salford, Manchester M5 3EQ
This e-mail and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed.
If you have received this email in error please notify the sender by replying
to the e-mail containing this attachment. Replies to this email may be
monitored by Comodo for operational or business reasons. Whilst every
endeavour is taken to ensure that e-mails are free from viruses, no liability
can be accepted and the recipient is requested to use their own virus checking
software.
Eddy Nigg (StartCom Ltd.)
> Eddy Nigg (StartCom Ltd.) wrote:
>
>> I working up my backlog....at first I thought this to be a good idea to
>> split the request up, but on the other hand I wonder if it's really that
>> good. Because we might see all requests in their context maybe...not sure.
>>
>
> For some information on context please see below.
>
There isn't much to add for me, as I agree with most/all you also said
in it what Mozilla concerns. All the rest are facts you updated us
about...But I'm going to reply to the post Rob from Comodo instead...
Eddy Nigg (StartCom Ltd.)
> Frank, thanks for your detailed explanation. I concur with everything you've
> said, but I'd just like to add a couple of additional comments (inline) in
> reply to Eddy...
>
>
> For the record, I can assure you that Comodo never issue DV and EV certs from
> the same Intermediate CA.
>
received the following comment from Frank previously concerning the
adding of the "|COMODO Certification Authority" CA certificate:
>
> By "sub roots" I presume you mean subordinate CAs. At present there are
> two subordinate CAs under the "COMODO Certification Authority" root:
> "COMODO EV SSL CA" and "COMODO EV SGC CA". These two subordinates are
> the issuing CAs for end entity certs.
>
This seems to confirm what you claim, but in this case the entry at
http://www.mozilla.org/projects/security/certs/pending/#Comodo (see the
last section) isn't correct (which was confirmed by you btw.). It states
under type "DV, IV/OV, EV".
As I understand, there are only EV intermediate CA certificates under
this root and the mentioning of DV,IV etc is wrong perhaps?
Additionally it might be useful if questions relating to your CA
operations can be directed directly to you at this list?
Eddy Nigg (StartCom Ltd.)
upgrade requests. I'd be glad if the representative of Comodo could
answer them directly.
1.) Is it possible to get a list of the currently active issuing
intermediate CA certificates of each CA root *currently* for
consideration? It would be interesting to know which of these issue EV,
both or non-EV.
2.) The audit report for non-EV operations refers to the CA operation at
Manchester. The audit report for EV refers to the CA operations at New
Jersey. One of the roots is from a company operating in Sweden, one
operating in Salt Lake City, Utah, USA and and one of Salford, GB. Can
the relations between these locations and the general operation of
Comodo and the audit reports be explained?
3.) Here a few questions in relation to the LiteSSL CPS:
* 1.12 states: "Because LiteSSL and LiteSSL Wildcard certificates
are not intended to be used in an e-commerce transaction or
environment, parties who rely on a LiteSSL or LiteSSL Wildcard
certificate do not qualify as a relying party." How can a relying
party NOT be a relying party? This is also confirmed under section
4.11.
* 4.1 states that the enrollment process MAY include check for
domain ownership. This means that the checks can be omitted?
* 2.4.7 states that LiteSSL certificates are (maybe) domain name
validated only, but also issues wild card certificates (2.4.1).
How does Comodo prevent or control misuse of wild card
certificates, specially in relation to phishing attempts?
* Does Comodo believe that such wild card certificates are issued
according to verification requirements for this special type of
certificates?
* 4.8 states a certificate validity of up to ten years and beyond. I
couldn't find any provision in case the domain name expires.
Please comment!
* Does Comodo believe that this CPS is in compliance to the Mozilla
CA policy
(http://www.mozilla.org/projects/security/certs/policy/)? The same
applies also to the Comodo CPS v3. Please comment!
Thanks for addressing my questions!
Nelson Bolyard
> 3.) Here a few questions in relation to the LiteSSL CPS:
>
> * 1.12 states: "Because LiteSSL and LiteSSL Wildcard certificates
> are not intended to be used in an e-commerce transaction or
> environment, parties who rely on a LiteSSL or LiteSSL Wildcard
> certificate do not qualify as a relying party." How can a relying
> party NOT be a relying party? This is also confirmed under section
> 4.11.
Wow! I'd say that a CA that says "You cannot rely on our certs for
eCommerce" should not be trusted for SSL by default in Mozilla products!
Of course, that's a policy issue. Frank, what do you think?
> * 4.1 states that the enrollment process MAY include check for
> domain ownership. This means that the checks can be omitted?
A good question.
> * 2.4.7 states that LiteSSL certificates are (maybe) domain name
> validated only, but also issues wild card certificates (2.4.1).
> How does Comodo prevent or control misuse of wild card
> certificates, specially in relation to phishing attempts?
Well, presumably, the wildcard certs they issue are valid for multiple
names within the domain that they validated only. The then rely on
the subject party to use the certs only in the servers that they control
in that domain. But that last statement is true of all CAs. All CAs
depend on the subject parties to control the use of the certs issued to
them, and the CAs can revoke the certs if they find that the certs have
not been adequately controlled. So, this particular part doesn't bother
me, AS LONG AS they really are domain validated.
Eddy Nigg (StartCom Ltd.)
> Well, presumably, the wildcard certs they issue are valid for multiple
> names within the domain that they validated only. The then rely on
> the subject party to use the certs only in the servers that they control
> in that domain. But that last statement is true of all CAs. All CAs
> depend on the subject parties to control the use of the certs issued to
> them, and the CAs can revoke the certs if they find that the certs have
> not been adequately controlled. So, this particular part doesn't bother
> me, AS LONG AS they really are domain validated.
>
>
aren't controllable in the same way as regular ones. A seemingly
innocent domain name can become a tool for phishing. For example
*.domain.com matches paypal.domain.com and paypal-objects.domain.com,
something a CA can not control in these circumstances (you can't assume
that a CA can adequately control wild card certificates as you mention
above). Wild card certificates shouldn't rely on domain validation
only. Even so there is no explicit provision concerning wild card
certificates in the Mozilla CA policy, section 4 is sufficient to assume
that:
We reserve the right to not include a particular CA certificate in
our software products, to discontinue including a particular CA
certificate in our products......including cases where we
believe.... would *cause undue risks to users security*, for
example, with CAs that
* knowingly issue certificates without the knowledge of the
entities whose information is referenced in the certificates; /or/
* knowingly issue certificates that appear to be intended for
fraudulent use.
Wild card certificates which are not at least identity validated may be
intended for fraudulent use. Section 4 explicitly states also that the
list above is not limited! Domain name validated wild card certificates
can be a risk to users security.
Eddy Nigg (StartCom Ltd.)
> Eddy Nigg (StartCom Ltd.) wrote, On 2008-03-15 13:27 PDT:
>
>> 3.) Here a few questions in relation to the LiteSSL CPS:
>>
>> * 1.12 states: "Because LiteSSL and LiteSSL Wildcard certificates
>> are not intended to be used in an e-commerce transaction or
>> environment, parties who rely on a LiteSSL or LiteSSL Wildcard
>> certificate do not qualify as a relying party." How can a relying
>> party NOT be a relying party? This is also confirmed under section
>> 4.11.
>>
>
> Wow! I'd say that a CA that says "You cannot rely on our certs for
> eCommerce" should not be trusted for SSL by default in Mozilla products!
ALL :-) It says, BECAUSE the certificates aren't meant to be for
e-commerce parties can not rely on it - any party - for any purpose -
--
Frank Hecker
In reference to this, it's not clear to me whether Comodo still issues
LiteSSL certificates or not. Note that the LiteSSL CPS Addendum is an
addendum to version 2.4 of the Comodo CPS. However the current CPS
version is 3.0, and that version does not mention LiteSSL except in
passing. Since www.litessl.com now redirects to www.positivessl.com, I
suspect that LiteSSL as a Comodo brand is defunct and was replaced by
PositiveSSL.
Eddy Nigg (StartCom Ltd.)
"Pending" page in first place, I just followed the links there. We
shouldn't assume anything when evaluating CAs either.
But in any case this CPS is still very much relevant EVEN if Comodo
doesn't actively issue certificates according to this CPS anymore,
because the intermediate CA certificate seems to be still valid and
seems to be mentioned in the version 3 CPS and their certificates carry
a lifetime of up to ten years and beyond.
Nevertheless the questions I asked are still valid since their version 3
CPS has the same content. I can find the relevant sections later on, the
only thing which differs as I can see is the section concerning relying
parties. I haven't gone through the other CPS yet, but I guess this is a
good opportunity doing so.
Frank Hecker
> intermediate CA certificates of each CA root *currently* for
> consideration? It would be interesting to know which of these issue EV,
> both or non-EV.
I *think* what you're looking for is in section 1.8 of the 3.0 version
of the CPS. That section lists the cert chains characteristic of
Comodo-issued (non-EV) end entity certificates, including issuing CAs
and the root CAs they chain up to. Section 1.8 of the Comodo EV CPS
contains the same type of information for EV certs. (By the way, I wish
more CAs would publish information like this.)
> 3.) Here a few questions in relation to the LiteSSL CPS:
>
> * 1.12 states: "Because LiteSSL and LiteSSL Wildcard certificates
> are not intended to be used in an e-commerce transaction or
> environment, parties who rely on a LiteSSL or LiteSSL Wildcard
> certificate do not qualify as a relying party." How can a relying
> party NOT be a relying party? This is also confirmed under section
> 4.11.
Another data point: there's actually a LiteSSL Relying Party agreement:
http://www.comodo.com/repository/docs/litessl_relying_party.html
which is referenced on the Comodo repository page:
http://www.comodo.com/repository/
The LiteSSL relying party agreement is separate from the main Comodo
relying party agreement:
http://www.comodo.com/repository/docs/relying_party.html
Also, LiteSSL is not included within the scope of the SSL Relying Party
Warranty:
http://www.comodo.com/repository/docs/SSL_relying_party_warranty.html
Prior to hearing from Comodo on this point, my guess is that Comodo was
basically stating that LiteSSL certificates were not intended to be used
for sites conducting financial transactions ("e-commerce"), and should
not be relied on in that context. The intended purpose of the LiteSSL
certs was presumably for facilitating access to non-financial data,
e.g., for personal or small group sites. (I actually got a LiteSSL cert
for my www.hecker.org site at one point, for exactly this reason.)
Frank Hecker
> Wow! I'd say that a CA that says "You cannot rely on our certs for
> eCommerce" should not be trusted for SSL by default in Mozilla products!
>
> Of course, that's a policy issue. Frank, what do you think?
It is a policy issue, and we've had this discussion before. My point has
always been that SSL certs have multiple valid uses, and enabling online
purchasing and other financial transactions ("ecommerce") was one such
valid use but not the only one. Another valid use is using SSL to
provide extra security for non-financial applications, e.g., to encrypt
authentication information (passwords) and transaction data over the
wire, and to provide a measure of protection against DNS spoofing. IMO
domain-validated certs are adequate for this purpose, and that's the
major reason I argued that they be included under our policy.
I think the statement Eddy references is basically a case of Comodo
being honest and admitting that LiteSSL certs are adequate for some
purposes (e.g., securing a low-value personal or small group site like
my own) but not for others (e.g., running an online store). That
statement strikes me as unexceptional.
Frank Hecker
> aren't controllable in the same way as regular ones. A seemingly
> innocent domain name can become a tool for phishing. For example
> *.domain.com matches paypal.domain.com and paypal-objects.domain.com,
> something a CA can not control in these circumstances (you can't assume
> that a CA can adequately control wild card certificates as you mention
> above). Wild card certificates shouldn't rely on domain validation
> only.
To play devil's advocate here: There are web hosting services that allow
customers to easily create their own subdomains under the hosting
service domain, e.g., "foo.hosting.com" where "hosting.com" is the
domain associated with the hosting service itself. If the hosting
service uses a wildcard cert to allow those subdomains to use SSL, and
allows customers to set up new subdomains with minimal oversight, how
does it help to have the wildcard cert to be identity-validated as
opposed to domain-validated? In either case people can set up domains
like paypal.hosting.com without the knowledge of the CA, since the CA is
(at best) vetting the identity of the hosting service and not the
identity of the hosting service's customer.
Also, I see no distinction in terms of security impact between someone
using a domain validated cert to set up a site like "paypal-host.com"
and someone setting up a site like "paypal.hosting.com" using a
domain-validated wildcard cert.
> Even so there is no explicit provision concerning wild card
> certificates in the Mozilla CA policy,
I presume you meant "Even though..."
> * knowingly issue certificates that appear to be intended for
> fraudulent use.
>
> Wild card certificates which are not at least identity validated may be
> intended for fraudulent use.
Indeed, and regular domain-validated certificates (e.g., for
"paypal-host.com") can also be intended for fraudulent use. (For that
matter, so can identity-validated certs, since the applicant might have
forged their identity documents.) The key word here is "knowingly". This
language in the policy was intended to cover cases where CAs were
willing and knowing accomplices to fraud.
Frank Hecker
> ALL :-) It says, BECAUSE the certificates aren't meant to be for
> e-commerce parties can not rely on it - any party - for any purpose -
> do not qualify as a relying party.
After looking again at the LiteSSL addendum and the 2.4 version of the
CPS (to which the LiteSSL addendum applies), I think what happened is as
follows: The term "relying party" has a specific definition in the 2.4
CPS, is used in specific ways throughout the 2.4 CPS, and has an
associated relying party agreement published on the Comodo site (as I
noted in a previous message).
When Comodo introduced the LiteSSL service and published the LiteSSL
addendum to the 2.4 CPS, I'm guessing that they wanted to avoid having
LiteSSL be affected by the existing 2.4 language concerning relying
parties and by the existing Comodo relying party agreement. In this
context I interpret section 1.12 of the LiteSSL addendum as meaning "...
parties who rely on a LiteSSL or LiteSSL Wildcard certificate do not
qualify as a relying party [as that term is otherwise used in the 2.4 CPS]."
I do not interpret the 1.12 language as meaning that LiteSSL cert could
not be relied on for any purpose whatsoever. As explicitly stated in
sections 2.4.1.k and 2.4.1.l of the LiteSSL addendum, LiteSSL certs were
intended for noncommercial uses not involving data of financial value,
and could presumably be relied upon for that restricted set of uses. And
as I stated earlier, Comodo actually has a LiteSSL-specific relying
party agreement.
In summary, I definitely think that Comodo could have made the LiteSSL
CPS addendum clearer; their lawyers apparently got too clever in trying
to limit Comodo's liability with regard to LiteSSL certs, and ended up
introducing ambiguity into the CPS. However I don't think this amounts
to LiteSSL certs being totally insecure and unreliable; they appear to
be garden-variety domain-validated certs, no more and no less.
Frank Hecker
> * 4.1 states that the enrollment process MAY include check for
> domain ownership. This means that the checks can be omitted?
I think this is another case of sloppy CPS language. Section 4.2.7 of
the LiteSSL addendum to the 2.4 CPS seems pretty clear that domain
ownership is validated one way or the other: either using emails sent to
a domain administrative address or by requesting additional
documentation of the applicant. I suspect the use of the word "may" in
the context of sections 2.4.1.k and 2.4.1.l was intended to mean that
the exact choice of method was at Comodo's discretion.
Frank Hecker
<snip>
>> For the record, I can assure you that Comodo never issue DV and EV
>> certs from the same Intermediate CA.
>>
> In that case we need to update our papers then. For example I've
> received the following comment from Frank previously concerning the
> adding of the "|COMODO Certification Authority" CA certificate:
>>
>> By "sub roots" I presume you mean subordinate CAs. At present there
>> are two subordinate CAs under the "COMODO Certification Authority"
>> root: "COMODO EV SSL CA" and "COMODO EV SGC CA". These two
>> subordinates are the issuing CAs for end entity certs.
>>
> This seems to confirm what you claim, but in this case the entry at
> http://www.mozilla.org/projects/security/certs/pending/#Comodo (see the
> last section) isn't correct (which was confirmed by you btw.). It states
> under type "DV, IV/OV, EV".
>
> As I understand, there are only EV intermediate CA certificates under
> this root and the mentioning of DV,IV etc is wrong perhaps?
Yes, this is my mistake. I'll correct the entry for COMODO Certification
Authority in the pending list.
Eddy Nigg (StartCom Ltd.)
> Nelson Bolyard wrote:
>
>> Wow! I'd say that a CA that says "You cannot rely on our certs for
>> eCommerce" should not be trusted for SSL by default in Mozilla products!
>>
>> Of course, that's a policy issue. Frank, what do you think?
>>
>
> It is a policy issue, and we've had this discussion before. My point has
> always been that SSL certs have multiple valid uses, and enabling online
> purchasing and other financial transactions ("ecommerce") was one such
> valid use but not the only one. Another valid use is using SSL to
> provide extra security for non-financial applications, e.g., to encrypt
> authentication information (passwords) and transaction data over the
> wire, and to provide a measure of protection against DNS spoofing. IMO
> domain-validated certs are adequate for this purpose, and that's the
> major reason I argued that they be included under our policy.
>
Absolutely, Frank! Domain validated certificates are very useful for the
intended purpose, mainly to prevent eavesdropping, protect and encrypt
data during exposure when traveling on the network, encryption of email
and client authentication. Webmail, password protected sites (blogs,
forums, administrative interfaces etc). and more...
Your site is a good example for such usage! However the CPS in question
stated that a relying party isn't a relying party :-) This sounds
funny....But even if Comodo says so, I'm not even sure if it would
uphold in court anyway. Lets move on to the next mail...
> I think the statement Eddy references is basically a case of Comodo
> being honest and admitting that LiteSSL certs are adequate for some
> purposes (e.g., securing a low-value personal or small group site like
> my own) but not for others (e.g., running an online store). That
> statement strikes me as unexceptional
--
Eddy Nigg (StartCom Ltd.)
> Eddy Nigg (StartCom Ltd.) wrote:
>
>> This particular part DOES bother you, because wild card certificates
>> aren't controllable in the same way as regular ones. A seemingly
>> innocent domain name can become a tool for phishing. For example
>> *.domain.com matches paypal.domain.com and paypal-objects.domain.com,
>> something a CA can not control in these circumstances (you can't assume
>> that a CA can adequately control wild card certificates as you mention
>> above). Wild card certificates shouldn't rely on domain validation
>> only.
>>
>
> To play devil's advocate here:
I'll try to play the devil myself...
> There are web hosting services that allow
> customers to easily create their own subdomains under the hosting
> service domain, e.g., "foo.hosting.com" where "hosting.com" is the
> domain associated with the hosting service itself.
addresses. They belong to the same family.
> If the hosting service uses a wildcard cert to allow those subdomains to use SSL, and
> allows customers to set up new subdomains with minimal oversight, how
> does it help to have the wildcard cert to be identity-validated as
> opposed to domain-validated?
Good question and here the answer: In case of any misuse or fraudulent
use - no matter what's the purpose including the scenario from above,
the CA and also relying parties would KNOW the real identity of the
domain name owner. This is the major reason why such certificates should
be higher validated then DV. I view this similar to code signing
certificates where there is no other indication such as a URL in the
addressbar or an email address. Why aren't code siging certificates just
email validated? I claim that the same applies to wild card
certificates, because they aren't controllable in the same as regular DV
certificates. The subject line and URL in the addressbar don't have to
match, but only partly!
> In either case people can set up domains
> like paypal.hosting.com without the knowledge of the CA, since the CA is
> (at best) vetting the identity of the hosting service and not the
> identity of the hosting service's customer.
>
And this is EXACTLY the core of the issue here! Should a request for
such a certificate be made (like paypal.hosting.com), the CA has first
of all the KNOWLEDGE about such a request and has the option to
intervene during and after the process of issuance of said certificate.
Not so if this is a wild card certificate and therefore the CA MUST
obtain additional information (e.g. verify the identity and/or
organization). This is a blank card which gives additional power and
trust to the subscriber. This MUST be earned by proper validation.
> Also, I see no distinction in terms of security impact between someone
> using a domain validated cert to set up a site like "paypal-host.com"
> and someone setting up a site like "paypal.hosting.com" using a
> domain-validated wildcard cert.
>
The huge difference is, that such a certificate wouldn't be issued in
first place. CAs have and should have proper measures in place to
prevent this from happening in first place. Should such a certificate
have been issued nevertheless, the CA has the KNOWLEDGE to intervene
accordingly with all the resources at its disposal BEFORE harm can be done.
My assumption is of course, that we are talking about proper
implementation of the CA business. CAs do have provisions for such
cases in their CPSs most of the time and implementations accordingly.
CAs (should) monitor the issuance of certificates even in automated
processes. This is where the difference comes in, because the same isn't
possible with wild card certificates.
> Indeed, and regular domain-validated certificates (e.g., for
> "paypal-host.com") can also be intended for fraudulent use. (For that
> matter, so can identity-validated certs, since the applicant might have
> forged their identity documents.)
Perhaps also here there is the assumption that validation is properly
done. It's obviously useless if one can just can send in the ID
documents of your friend and no additional vetting is performed. This
would be again a case for section 4 and 6 of the Mozilla CA policy!!!
> The key word here is "knowingly". This
> language in the policy was intended to cover cases where CAs were
> willing and knowing accomplices to fraud.
>
Issuing certificates which claim to be validated without such vetting
ever having performed is tantamount to KNOWINGLY and WILLINGLY
contribute to a possible fraud. I claim that issuing wild card
certificates without proper vetting as described above equals the same.
Eddy Nigg (StartCom Ltd.)
> Eddy Nigg (StartCom Ltd.) wrote:
>
>> 3.) Here a few questions in relation to the LiteSSL CPS:
>>
> <snip>
>
>> * 4.1 states that the enrollment process MAY include check for
>> domain ownership. This means that the checks can be omitted?
>>
>
> I think this is another case of sloppy CPS language.
OK, Frank, I've read your arguments concerning this particular issue. Of
course a response from Comodo themselves would have been interesting
too. Since this CPS replaces only parts of another CPS your arguments
about context and unlucky formulation are acceptable.
> Section 4.2.7 of
> the LiteSSL addendum to the 2.4 CPS seems pretty clear that domain
> ownership is validated one way or the other: either using emails sent to
> a domain administrative address or by requesting additional
> documentation of the applicant. I suspect the use of the word "may" in
> the context of sections 2.4.1.k and 2.4.1.l was intended to mean that
> the exact choice of method was at Comodo's discretion.
>
Not nitpicking on this one, the intention is apparently as you said.
Eddy Nigg (StartCom Ltd.)
inclusion and upgrade requests. I've updated the sections which received
a response from Frank and are solved from my point of view and added
some more content where deemed necessary.
1.) The audit report for non-EV operations refers to the CA operation at
Manchester. The audit report for EV refers to the CA operations at New
Jersey. One of the roots is from a company operating in Sweden, one
operating in Salt Lake City, Utah, USA and and one of Salford, GB. Can
the relations between these locations and the general operation of
Comodo and the audit reports be explained?
Additionally I would like to know to whom belongs the company LITESSL
CA, INC. and its relationship to Comodo CA Ltd. as referenced in the
audit report from KPMG
(https://cert.webtrust.org/SealFile?seal=636&file=pdf). What are its
relations to AddTrust AB, Sweden? In the audit reports no distinctions
are made between the various companies and the audit reports are
addressed only to Comodo CA Ltd.
2.) The Comodo Certification Practice Statement, Version 3.0 and other
CPS amendments state that wild card certificates are domain name
validated only (depending on product or trade mark). How does Comodo
prevent or control misuse of wild card certificates, specially in
relation to phishing attempts and other fraud, taking into consideration
that these certificates are domain validated only? Does Comodo believe
that such wild card certificates are issued according to verification
requirements for this special type of certificates?
3.) The Comodo Certification Practice Statement, Version 3.0 and other
CPS amendments state certificate validity of up to ten years and beyond.
I couldn't find any provision in case the domain name expires. It isn't
clear what happens if an identity or organization changes name, changes
address, stops its operation, dies etc. How does Comodo guaranty the
validity of these certificates throughout their lifetime?
4.) Frank, this one is for you:
Since most (if not all) CA root certificates of Comodo were inherited
from the Netscape era and never were properly evaluated by an inclusion
process and in light of the questions above, isn't a thorough review of
this CA in place in order to guaranty conformance to the Mozilla CA
policy? Because an upgrade to EV would tie this CA further into NSS I
believe that such a review should be performed prior to any other step.
I haven't invested a lot of time into this request initially (as I
haven't for other upgrade requests for EV during the comments period),
but raised enough questions which might justify such a review.
Eddy Nigg (StartCom Ltd.)
> 4.) Frank, this one is for you:
>
> Since most (if not all) CA root certificates of Comodo were inherited
> from the Netscape era and never were properly evaluated by an inclusion
> process and in light of the questions above, isn't a thorough review of
> this CA in place in order to guaranty conformance to the Mozilla CA
> policy? Because an upgrade to EV would tie this CA further into NSS I
> believe that such a review should be performed prior to any other step.
> I haven't invested a lot of time into this request initially (as I
> haven't for other upgrade requests for EV during the comments period),
> but raised enough questions which might justify such a review.
>
>
>
Oh, and it that respect I have another interesting question. Supposed a
CA issues EV certificates (audited and conforming to the relevant
criteria in every respect) but their other CA business (meaning non-EV)
would fail to conform to the Mozilla CA policy, what would happen? What
are the (technical) options and possibilities? Could a CA be trusted
when issuing EV certificates but not for other types of certificates? Or
must any EV enabled root also otherwise be enabled? What would we (have
to) do in such a case?
Nelson B Bolyard
> Nelson Bolyard:
>> [snip] All CAs
>> depend on the subject parties to control the use of the certs issued to
>> them, and the CAs can revoke the certs if they find that the certs have
>> not been adequately controlled. So, this particular part doesn't bother
>> me, AS LONG AS they really are domain validated.
>>
> aren't controllable in the same way as regular ones. A seemingly
> innocent domain name can become a tool for phishing. For example
> *.domain.com matches paypal.domain.com and paypal-objects.domain.com,
> something a CA can not control in these circumstances (you can't assume
> that a CA can adequately control wild card certificates as you mention
> above).
You say a CA can control this, but what can or should a CA do, and with
what authority?
What would you propose? That CAs disallow the issuance of certs for hosts
(or sub-domains) whose host name matches the name found in any TLD in the
.com domain?
Would you have all CAs refuse me a cert for nelson.bolyard.com because
there exists a nelson.com domain?
Would you have all CAs refuse a cert for bugzilla.mozilla.org, because
there exists a bugzilla.com?
What if the subdomain/host name existed, with a certificate first
(as is likely the case for bugzilla.com, I think)?
Would you have CAs refuse to issue certs for bugzilla.com because a CA
had already issued a cert to bugzilla.mozilla.org?
How about domain registrars? Would you have them refuse to register the
domain bugzilla.com because a cert existed for bugzilla.mozilla.org?
The only restriction of which I'm aware on domain names that domain
registrars should register or CAs should issue has to do with international
character sets, and the ability to produce a string in another character
set that LOOKS like, but is not identical to, some already registered
.com domain name. But that only applies to registering names that visually
appear to be EXACT duplicates of other extant domains.
If you would not propose to prohibit the issuance of certs for hosts whose
host names match .com TLD names, then on what other basis would you propose
to create such a prohibition? Would you have CAs refuse to issue a cert
to paypal.mozilla.org (say) on the grounds that:
- Paypal is a big company worth lots of $$$? (What's the $$ threshold?)
- Paypal's web site gives users accounts that are password protected?
- Paypal is known to be a phishing target? (What's the metric?)
- or something else? (please elaborate).
Test your answer by switching the names as follows: Would you have CAs
refuse to issue a cert to bugzilla.com because bugzilla.mozilla.org is
any of the things listed above?
Note that even the EV "guidelines" do not prohibit EV CAs from issuing
certs on any of the grounds suggested above..
> Wild card certificates shouldn't rely on domain validation
> only. Even so there is no explicit provision concerning wild card
> certificates in the Mozilla CA policy, section 4 is sufficient to assume
> that:
>
> We reserve the right to not include a particular CA certificate in
> our software products, to discontinue including a particular CA
> certificate in our products......including cases where we
> believe.... would *cause undue risks to users security*, for
> example, with CAs that
>
> * knowingly issue certificates without the knowledge of the
> entities whose information is referenced in the certificates; /or/
> * knowingly issue certificates that appear to be intended for
> fraudulent use.
Again, what is your test for "appear to be intended for fraudulent use?"
> Wild card certificates which are not at least identity validated may be
> intended for fraudulent use. Section 4 explicitly states also that the
> list above is not limited! Domain name validated wild card certificates
> can be a risk to users security.
Certificates bind a key to a name. Period, Full stop. EV certs may say
something about the owner's right to use a name, but not even EV certs
say anything about the intent or righteousness or karma of the named
party or the named domain or host.
My point is that it is pointless to attempt to prohibit issuance of
subdomain wildcard certs on the basis of DV until you establish some
clear criteria upon which CAs can (and collectively will) rightfully
deny certs for host names to well identified subscribers (cert subjects).
Nelson B Bolyard
> Frank Hecker:
>> To play devil's advocate here:
> Yes, I love real world examples! And this is such a serious issue and
> I'll try to play the devil myself...
I envision a photograph of Frank and Eddy, wearing mustaches and red
capes with horns and sporting tridents. :)
> [...] I view this similar to code signing
> certificates where there is no other indication such as a URL in the
> addressbar or an email address. Why aren't code siging certificates just
> email validated?
Well, actually, some have been issued that were validated by not much more.
The CAB Forum is working on a set of "guidelines" for EV code signing
certs. They're going beyond merely defining minimum acceptable criteria
for name validation. They're suggesting changes (or perhaps minimum
standards) to the ways in which EV signatures are applied to code, to
mitigate the problem of software signatures being invalidated when certs
expire. IMO, their proposal would greatly improve the value of code
signing, not only because of improved signer name validation but also
for forcing the industry to deal with long lived signatures.
Sadly, I don't see many signs that that Mozilla is interested or
participating in this work. I guess we're going to end up having this
Referring to the issuance of certs for names like paypal-host.com or
paypal.hosting.com, Eddy wrote:
> [...] CAs have and should have proper measures in place to
> prevent this from happening in first place.
You need to define "this" very carefully.
>> The key word here is "knowingly". This language in the policy was
>> intended to cover cases where CAs were willing and knowing accomplices
>> to fraud.
And, IMO, does not cover cases where certs were used for fraud AFTER
they were issued, if there was no foreknowledge of the intent for fraud.
This raises the question: How can DV CAs, whose issuing processes are
almost entirely automatic, have any such foreknowledge? Eddy seems to
suggest (I think) that there is some basis upon which potentially fraudulent
domain names can be denied certs on some basis not yet defined (AFAIK). I
think that, in the absence of some well defined and widely
agreed set of criteria, all DV issuers always have an out, namely,
"We had no knowledge that there was any fraudulent intent."
> Issuing certificates which claim to be validated without such vetting
> ever having performed is tantamount to KNOWINGLY and WILLINGLY
> contribute to a possible fraud. I claim that issuing wild card
> certificates without proper vetting as described above equals the same.
I don't accept that until after there is some well defined standard by
which CAs can properly judge that for themselves. Until then, CA
decisions to refuse to issue certs for certain domain names are going to
be arbitrary, and not well correlated to fraudulent intent, IMO.
Frank Hecker
I don't have much to add to Nelson's comments, so I'm just going to
summarize my opinion on the issue of wildcard certs and domain
validation: Your points about the potential for fraud are well-taken, as
is your point about having an identified entity to pursue in the event
of fraud. However as I see it these points apply equally as well to
vanilla DV certs (i.e., for a single domain name) as they do to wildcard
DV certs.
When we created our CA policy the rough consensus was that DV certs have
a valid place in the grand scheme of things. Given that, I think
wildcard DV certs are just as valid. Such certs may not be suitable for
legitimate ecommerce purposes, but that's what EV certs are for.
Eddy Nigg (StartCom Ltd.)
>> This particular part DOES bother you, because wild card certificates
>> aren't controllable in the same way as regular ones. A seemingly
>> innocent domain name can become a tool for phishing. For example
>> *.domain.com matches paypal.domain.com and paypal-objects.domain.com,
>> something a CA can not control in these circumstances (you can't assume
>> that a CA can adequately control wild card certificates as you mention
>> above).
>>
>
> You say a CA can control this, but what can or should a CA do, and with
> what authority?
>
be used for phishing attempts and other fraud. This includes cases like
real domain names (mic0s0ft.com, paypa1.com) and sub domain names
(paypal.nelson.com). The CA can do this with the same authority it can
refuse issuance of certificates for other reasons and/or according to
their policies.
Additionally CAs can visit suspected sites before and after issuance of
a certificate. They can do background research and request additional
documents (Yes, also for DV certs if needed). There are many more
options and tools CAs can implement and use.
Obviously this can't be done with wild card certificates (in cases of
sub domain names). Hence they should be higher validated.
> What would you propose? That CAs disallow the issuance of certs for hosts
> (or sub-domains) whose host name matches the name found in any TLD in the
> .com domain?
>
Huuuu? Can you explain that?
> Would you have all CAs refuse me a cert for nelson.bolyard.com because
> there exists a nelson.com domain?
>
No, did I say that? I can't see this domain above as a phishing target
nor is it a wild card certificate...
> Would you have all CAs refuse a cert for bugzilla.mozilla.org, because
> there exists a bugzilla.com?
>
No, I never said that.
> What if the subdomain/host name existed, with a certificate first
> (as is likely the case for bugzilla.com, I think)?
> Would you have CAs refuse to issue certs for bugzilla.com because a CA
> had already issued a cert to bugzilla.mozilla.org?
> How about domain registrars? Would you have them refuse to register the
> domain bugzilla.com because a cert existed for bugzilla.mozilla.org?
>
Three times no.
> The only restriction of which I'm aware on domain names that domain
> registrars should register or CAs should issue has to do with international
> character sets, and the ability to produce a string in another character
> set that LOOKS like, but is not identical to, some already registered
> .com domain name. But that only applies to registering names that visually
> appear to be EXACT duplicates of other extant domains.
>
No, but also m0zilla.com would be such a case I guess. As would be other
similar looking names.
> If you would not propose to prohibit the issuance of certs for hosts whose
> host names match .com TLD names, then on what other basis would you propose
> to create such a prohibition? Would you have CAs refuse to issue a cert
> to paypal.mozilla.org (say) on the grounds that:
>
> - Paypal is a big company worth lots of $$$? (What's the $$ threshold?)
> - Paypal's web site gives users accounts that are password protected?
> - Paypal is known to be a phishing target? (What's the metric?)
> - or something else? (please elaborate).
>
Three times yes. There are known phishing targets such as online
services as paypal, banks and other institutions. There are other tools
available to CAs (and I don't have to elaborate) which help
differentiate and find such cases. And I guess that many CAs implement
them and on a best effort basis effectively prevent issuance of such
certificates. It's the controls the CA implements for this type of
certification.
> Test your answer by switching the names as follows: Would you have CAs
> refuse to issue a cert to bugzilla.com because bugzilla.mozilla.org is
> any of the things listed above?
>
No.
> Note that even the EV "guidelines" do not prohibit EV CAs from issuing
> certs on any of the grounds suggested above..
>
>
I'm not sure, if I remember right EV does have a provision for above
cases (like obscuring domain names.) But this is beyond the point since
EV certificates ARE validated, we are talking about DV certs which
aren't and issuance is performed mainly automatically.
>> We reserve the right to not include a particular CA certificate in
>> our software products, to discontinue including a particular CA
>> certificate in our products......including cases where we
>> believe.... would *cause undue risks to users security*, for
>> example, with CAs that
>>
>> * knowingly issue certificates without the knowledge of the
>> entities whose information is referenced in the certificates; /or/
>> * knowingly issue certificates that appear to be intended for
>> fraudulent use.
>>
>
> Again, what is your test for "appear to be intended for fraudulent use?"
>
A wild card certificate can be potentionally used for fraudulent use
such a phishing. Knowingly issuing them to completely unknown identities
(anonymous) is a risk CAs shouldn't take. Nor should Mozilla sign up to
such a risk. But of course my interpretation is from my point of view,
yours might be different.
>
>> Wild card certificates which are not at least identity validated may be
>> intended for fraudulent use. Section 4 explicitly states also that the
>> list above is not limited! Domain name validated wild card certificates
>> can be a risk to users security.
>>
>
> Certificates bind a key to a name. Period, Full stop. EV certs may say
> something about the owner's right to use a name, but not even EV certs
> say anything about the intent or righteousness or karma of the named
> party or the named domain or host.
>
Correct. But they are validated. You know the name, organization,
address etc which stands behind this certificate. Fraud would have a
short way to court.
> My point is that it is pointless to attempt to prohibit issuance of
> subdomain wildcard certs on the basis of DV until you establish some
> clear criteria upon which CAs can (and collectively will) rightfully
> deny certs for host names to well identified subscribers (cert subjects).
I did that already I think. Additionally the criteria should be that
wild card certificates MUST be ID validated at least. Because this is a
wild card, card blanche, joker.....it's extra power for the subscriber
and extra risk for the CA and RP. Mozilla is an RP in that respect. I'd
say DV validated wild card certificates are an undue risk to the users
of Mozilla software (as stated in the policy). It's my argument, it's my
knowledge I'm offering you, it's my experience I share with you - judge
for yourself...
Eddy Nigg (StartCom Ltd.)
> Eddy Nigg (StartCom Ltd.) wrote:
>
>> Issuing certificates which claim to be validated without such vetting
>> ever having performed is tantamount to KNOWINGLY and WILLINGLY
>> contribute to a possible fraud. I claim that issuing wild card
>> certificates without proper vetting as described above equals the same.
>>
>
> I don't have much to add to Nelson's comments, so I'm just going to
> summarize my opinion on the issue of wildcard certs and domain
> validation: Your points about the potential for fraud are well-taken, as
> is your point about having an identified entity to pursue in the event
> of fraud.
> However as I see it these points apply equally as well to
> vanilla DV certs (i.e., for a single domain name) as they do to wildcard
> DV certs.
>
costume as envisioned by Nelson ;-) ).
Subscriber requests a certificate for paypal.domain.com.
Would such a SSL secured site for this specific domain foul many
visitors? [yes]
Does this domain name present a potential risk? [yes]
Does the CA know upfront about its potential (mis)use? [yes]
Can the CA intervene in the process before issuing a certificate for
this domain? [yes]
Can the CA visit the corresponding site and verify its content? [yes]
Can the CA revoke the certificate immediately? [yes]
However now the subscriber requests a certificate for *.domain.com:
Can such a certificate be potentially used to foul many visitors? [yes]
Can the domain name present a potential risk? [yes]
Does the CA know upfront about its potential (mis)use? [no, there is
none at this stage]
Can the CA intervene in the process before issuing a certificate for
this domain? [no, there is no reason to intervene]
Can the CA visit the corresponding site and verify its content? [no,
it doesn't know which sub domain will be potentially used and when]
Can the CA revoke the certificate immediately? [no, only after a fraud
has been committed already and brought to the attention of the CA]
The points above don't equally apply! IV reduces the risk greatly for
wild card certificates, compared to DV only.
> When we created our CA policy the rough consensus was that DV certs have
> a valid place in the grand scheme of things.
Correct, we have agreed on that already.
> Given that, I think
> wildcard DV certs are just as valid.
I don't agree, see above. They are only technically valid, but of course
you can disagree with me.
> Such certs may not be suitable for
> legitimate ecommerce purposes, but that's what EV certs are for.
IV/OV certificate may be legitimate as well. It's the standard applied
and distinction in the browser which makes them different. :-)
Eddy Nigg (StartCom Ltd.)
>
> I envision a photograph of Frank and Eddy, wearing mustaches and red
> capes with horns and sporting tridents. :)
>
>
> Sadly, I don't see many signs that that Mozilla is interested or
> participating in this work.
>
> Referring to the issuance of certs for names like paypal-host.com or
> paypal.hosting.com, Eddy wrote:
>
>
>> [...] CAs have and should have proper measures in place to
>> prevent this from happening in first place.
>>
>
> You need to define "this" very carefully.
>
Subscriber Obligations
Use XYZ issued certificates in accordance with all applicable laws and
not to
use them for illegal or immoral purposes, which includes but is not
limited to:
· threaten, discriminate or harass other individuals and entities
· make fraudulent offers of products, items, or services
· forge message headers, in part or whole, of any electronic transmission
· distribute viruses
· obtain the identity of other individuals or entities
· publish discriminating material
· use it for any unlawful activities
Circumstances for Revocation
- The information supplied may be misleading (e.g.,
paypa1.com,micr0soft.com)
- The subject has failed to comply with the rules in this policy
- The subscriber violated his/her obligations
> This raises the question: How can DV CAs, whose issuing processes are
> almost entirely automatic, have any such foreknowledge? Eddy seems to
> suggest (I think) that there is some basis upon which potentially fraudulent
> domain names can be denied certs on some basis not yet defined (AFAIK).
Yes.
> I think that, in the absence of some well defined and widely
> agreed set of criteria, all DV issuers always have an out, namely,
> "We had no knowledge that there was any fraudulent intent."
>
This might or might not be true for regular DV certs. This isn't true
when talking about wild card certificates, because they potentially can
be used for fraud. This is knowledge the CA has upfront, because of that
the CA should implement preventive measures such as identity validation.
Rob Stradling
have asked my colleague Robin Alden to join this newsgroup and answer each of
your points.
On Sunday 16 March 2008, Eddy Nigg (StartCom Ltd.) wrote:
> This is a revised version of my initial questions concerning the Comodo
> inclusion and upgrade requests. I've updated the sections which received
> a response from Frank and are solved from my point of view and added
> some more content where deemed necessary.
>
> 1.) The audit report for non-EV operations refers to the CA operation at
> Manchester. The audit report for EV refers to the CA operations at New
> Jersey. One of the roots is from a company operating in Sweden, one
> operating in Salt Lake City, Utah, USA and and one of Salford, GB. Can
> the relations between these locations and the general operation of
> Comodo and the audit reports be explained?
>
> Additionally I would like to know to whom belongs the company LITESSL
> CA, INC. and its relationship to Comodo CA Ltd. as referenced in the
> audit report from KPMG
> (https://cert.webtrust.org/SealFile?seal=636&file=pdf). What are its
> relations to AddTrust AB, Sweden? In the audit reports no distinctions
> are made between the various companies and the audit reports are
> addressed only to Comodo CA Ltd.
>
> 2.) The Comodo Certification Practice Statement, Version 3.0 and other
> CPS amendments state that wild card certificates are domain name
> validated only (depending on product or trade mark). How does Comodo
> prevent or control misuse of wild card certificates, specially in
> relation to phishing attempts and other fraud, taking into consideration
> that these certificates are domain validated only? Does Comodo believe
> that such wild card certificates are issued according to verification
> requirements for this special type of certificates?
>
> 3.) The Comodo Certification Practice Statement, Version 3.0 and other
> CPS amendments state certificate validity of up to ten years and beyond.
> I couldn't find any provision in case the domain name expires. It isn't
> clear what happens if an identity or organization changes name, changes
> address, stops its operation, dies etc. How does Comodo guaranty the
> validity of these certificates throughout their lifetime?
>
> 4.) Frank, this one is for you:
>
> Since most (if not all) CA root certificates of Comodo were inherited
> from the Netscape era and never were properly evaluated by an inclusion
> process and in light of the questions above, isn't a thorough review of
> this CA in place in order to guaranty conformance to the Mozilla CA
> policy? Because an upgrade to EV would tie this CA further into NSS I
> believe that such a review should be performed prior to any other step.
> I haven't invested a lot of time into this request initially (as I
> haven't for other upgrade requests for EV during the comments period),
> but raised enough questions which might justify such a review.
--
Rob Stradling
Senior Research & Development Scientist
Comodo - Creating Trust Online
Office Tel: +44.(0)1274.730505
Fax Europe: +44.(0)1274.730909
www.comodo.com
Comodo CA Limited, Registered in England No. 04058690
Registered Office:
3rd Floor, 26 Office Village, Exchange Quay,
Trafford Road, Salford, Manchester M5 3EQ
This e-mail and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed.
If you have received this email in error please notify the sender by replying
to the e-mail containing this attachment. Replies to this email may be
monitored by Comodo for operational or business reasons. Whilst every
endeavour is taken to ensure that e-mails are free from viruses, no liability
can be accepted and the recipient is requested to use their own virus checking
software.
Frank Hecker
>
> Since most (if not all) CA root certificates of Comodo were inherited
> from the Netscape era and never were properly evaluated by an inclusion
> process and in light of the questions above, isn't a thorough review of
> this CA in place in order to guaranty conformance to the Mozilla CA
> policy?
To quote myself from comment #20 of bug 401587:
https://bugzilla.mozilla.org/show_bug.cgi?id=401587#c20
"NOTE 2: Although all these roots are already in NSS, in the interests
of thoroughness I'll repeat all the evaluation steps as if they were new
roots."
Frank Hecker
> CA issues EV certificates (audited and conforming to the relevant
> criteria in every respect) but their other CA business (meaning non-EV)
> would fail to conform to the Mozilla CA policy, what would happen? What
> are the (technical) options and possibilities? Could a CA be trusted
> when issuing EV certificates but not for other types of certificates? Or
> must any EV enabled root also otherwise be enabled? What would we (have
> to) do in such a case?
Right now we don't have any technical mechanism to accept only EV
certificates issued within a CA hierarchy, but not EV certs from within
that same hierarchy. It's possible to imagine such a mechanism, but it
would require additional code at the NSS or PSM level. If there's a
general feeling that such a mechanism would be useful then people are
free to contibute it or (if no one is willing or able to do it) the
Mozilla Foundation could help fund its creation.
Eddy Nigg (StartCom Ltd.)
> Hi Eddy. I'm not the right person to answer your questions about our CPS. I
> have asked my colleague Robin Alden to join this newsgroup and answer each of
> your points.
>
Thank you Rob, I'm looking forward to the replies of Robin Alden.
Eddy Nigg (StartCom Ltd.)
> Eddy Nigg (StartCom Ltd.) wrote:
>
>> Oh, and it that respect I have another interesting question. Supposed a
>> CA issues EV certificates (audited and conforming to the relevant
>> criteria in every respect) but their other CA business (meaning non-EV)
>> would fail to conform to the Mozilla CA policy, what would happen? What
>> are the (technical) options and possibilities? Could a CA be trusted
>> when issuing EV certificates but not for other types of certificates? Or
>> must any EV enabled root also otherwise be enabled? What would we (have
>> to) do in such a case?
>>
>
> Right now we don't have any technical mechanism to accept only EV
> certificates issued within a CA hierarchy, but not EV certs from within
> that same hierarchy. It's possible to imagine such a mechanism,
had to option doing so instead an all or nothing approach which might be
wrong.
> but it
> would require additional code at the NSS or PSM level.
> If there's a general feeling that such a mechanism would be useful then people are
> free to contibute it or (if no one is willing or able to do it) the
> Mozilla Foundation could help fund its creation.
>
every respect. Now, we might end up never be in such a situation, but
who knows...what do you think? Wait until we'd be forced to? Or
implement anyway (if possible)?
Nelson B Bolyard
> Right now we don't have any technical mechanism to accept only EV
> certificates issued within a CA hierarchy, but not EV certs from within
> that same hierarchy.
I think there must be a word missing from that sentence.
As it reads, it says "... to accept <thing A> but not <thing A>."
I suspect you meant "... to accept EV certs, but not NON-EV certs, from
the same CA hierarchy." Is that what you meant?
> It's possible to imagine such a mechanism, but it
> would require additional code at the NSS or PSM level.
NSS offers methods to ask "Is this a valid cert (regardless of EV)" and
"Is this a valid EV cert"? With those two methods, it is possible for a
user of NSS (such as PSM) to achieve the result that (I *think*) you
described (EV or non-EV certs accepted exclusively, subordinate to some
root) But I do not understand under what circumstances such a thing would
be desired.
How would the browser decide when to invoke this rule?
How would the browser discern a CA hierarchy in which both EV and non-EV
certs are accepted from one in which only EV (or only non-EV) certs were
to be accepted?
> If there's a general feeling that such a mechanism would be useful then
> people are free to contibute it or (if no one is willing or able to do
> it) the Mozilla Foundation could help fund its creation.
/Nelson
Frank Hecker
> Frank Hecker wrote, On 2008-03-18 05:17:
>
>> Right now we don't have any technical mechanism to accept only EV
>> certificates issued within a CA hierarchy, but not EV certs from within
>> that same hierarchy.
> I suspect you meant "... to accept EV certs, but not NON-EV certs, from
> the same CA hierarchy." Is that what you meant?
Yes, sorry about that.
> NSS offers methods to ask "Is this a valid cert (regardless of EV)" and
> "Is this a valid EV cert"? With those two methods, it is possible for a
> user of NSS (such as PSM) to achieve the result that (I *think*) you
> described (EV or non-EV certs accepted exclusively, subordinate to some
> root) But I do not understand under what circumstances such a thing would
> be desired.
I'll let Eddy speak for himself, but I believe he's thinking of a
scenario where we (Mozilla) or the user (a power user, to be sure) would
decide that we trust CA Foo to issue EV certs, but we or the user think
they have unacceptable practices on non-EV certs (like issuing wildcard
DV certs, for example, which Eddy objects to). Then Eddy's idea is that
we (or the user) would configure Firefox et.al. to accept EV certs from
the hierarchy rooted at CA Foo's root, but to reject any other (i.e.,
non-EV) certs issued in the same hierarchy.
> How would the browser decide when to invoke this rule?
> How would the browser discern a CA hierarchy in which both EV and non-EV
> certs are accepted from one in which only EV (or only non-EV) certs were
> to be accepted?
I'm not proposing we do this, but consider the following: We have a new
"EV SSL trust bit" to accompany the existing SSL trust bit and the
existing EV policy OID mechanism. For a given end-entity SSL
certificate, we do path processing and checking of any policy OIDs
present, and determine whether the cert is a valid EV cert or not. If
it's an EV cert then we check to verify that the EV SSL trust bit is
on., and reject it if not. If it's a non-EV cert then we check the
regular SSL trust bit instead.
Eddy Nigg (StartCom Ltd.)
> I'll let Eddy speak for himself, but I believe he's thinking of a
> scenario where we (Mozilla) or the user (a power user, to be sure) would
> decide that we trust CA Foo to issue EV certs, but we or the user think
> they have unacceptable practices on non-EV certs (like issuing wildcard
> DV certs, for example, which Eddy objects to). Then Eddy's idea is that
> we (or the user) would configure Firefox et.al. to accept EV certs from
> the hierarchy rooted at CA Foo's root, but to reject any other (i.e.,
> non-EV) certs issued in the same hierarchy.
>
or the current evaluation of Comodo. We simply could determine that CA
Foo doesn't conform to the Mozilla Ca policy for non-EV certs, but their
EV issuance are perfectly in line with the Mozilla CA policy (and the
CAB EV criteria). In this case we should enable EV, and not allow non-EV
certs for this root as you explain below correctly.
> I'm not proposing we do this, but consider the following: We have a new
> "EV SSL trust bit" to accompany the existing SSL trust bit and the
> existing EV policy OID mechanism. For a given end-entity SSL
> certificate, we do path processing and checking of any policy OIDs
> present, and determine whether the cert is a valid EV cert or not. If
> it's an EV cert then we check to verify that the EV SSL trust bit is
> on., and reject it if not. If it's a non-EV cert then we check the
> regular SSL trust bit instead.
>
> Frank
>
>
--
Andrews, Rick
> > Eddy Nigg (StartCom Ltd.) wrote:
> >
I'd also like to add my two cents from some time spent studying
"confusable" domain names that could be used for fraud. The solution,
IMO, if one can be crafted, must be done upstream at domain name
registration time. If a domain name has been lawfully purchased, and
none of the CA's vetting fails (company is legit, company owns the
domain name, etc.) the CA has no grounds for refusing to issue a cert.
It would be like a car salesman refusing to sell me a car because he
thought I was going to use it in a crime.
-Rick
--
Rick Andrews __o Phone: 650-426-3401
VeriSign, Inc. _ \>,_ Fax: 650-426-5195
487 E. Middlefield Rd. ...(_)/ (_) URL: www.verisign.com
Mountain View, CA 94043 email: rand...@verisign.com
Eddy Nigg (StartCom Ltd.)
> I'd also like to add my two cents from some time spent studying
> "confusable" domain names that could be used for fraud. The solution,
> IMO, if one can be crafted, must be done upstream at domain name
> registration time.
This is from our perspective wishful thinking! Many registrars sell just
about anything they can no matter what. Neither do they perform any
background checking. CAs don't have any control over that and
don't/shouldn't rely on information found at registrars. Nor do all
registrars have policies in place to prevent the registration of such
domain names in first place (some do have trade mark related policies).
> If a domain name has been lawfully purchased, and
> none of the CA's vetting fails (company is legit, company owns the
> domain name, etc.) the CA has no grounds for refusing to issue a cert.
>
Which means(as in your example above) that the CA has performed enough
background research in order to clearly identify the subscriber. The
issue at hand is about domain validated certificates generally and
domain validated wild card certificates in particular where control of
the sub domain doesn't exist from the CA perspective.
> It would be like a car salesman refusing to sell me a car because he
> thought I was going to use it in a crime.
>
Rick, I'm sure Verisign would flatly refuse a certificate for paypa1.com
or paypal.domain.com. Nor do I believe that Verisign issues unvalidated
(DV only) wild card certs in first place. CAs aren't really comparable
to car vendors, but rather to the authority approving the car for public
consumption and/or issuing the licenses in order to drive the car. Just
think about it... ;-)
Eddy Nigg (StartCom Ltd.)
Specifically to the CPS at
http://www.comodo.com/repository/09_22_2006_Certification_Practice_Statement_v.3.0.pdf
2.4.3 a) section for code signing certificates refers to section 4.2.1
(Validation Practices)
Going to section 4.2.1:
- Unlucky formulation of "4.2.1 Secure Server Certificates Validation
Process" (Code Signing versus Server Certs).
- Subsection 1 doesn't apply I guess.
- Subsection 2 says:
The applicant is an accountable legal entity, whether an
organization or an individual.
• Validated by requesting official company documentation, such as
Business License, Articles of Incorporation, Sales License or other
relevant documents.
• For non-corporate applications, documentation such as bank statement,
copy of passport, copy of driving license or other relevant documents.
Further it says:
The above assertions are _*reviewed through an automated process*_,
manual review of
supporting documentation and reference to third party official
databases.
Scrolling further down to 4.2.8 (applies to Code Signing Certificate /
Time Stamping Certificate):
Code Signing Certificates and Time Stamping Certificates are
processed by a Comodo validation officer in accordance with the
process outlined in section 4.2.1 of this CPS.
OK, I was at 4.2.1 already, Comodo received and reviewed the material
received and referenced to third party sources.
Comodo may employ the data held by IdAuthority to expedite the
validation process. _*If application data matches the records*_ held
by IdAuthority, _*manual validation intervention is not required*_.
In the event that the application data does not match the
pre-validated records, the application is processed manually by a
Comodo validation officer in accordance with the process outlined in
section 4.2.1 of this CPS.
Again I'm pointed to 4.2.1...
IdAuthority = "contains records of over 5 million unique legal entities
sourced from a combination of publicly available resources. Where
possible, _*the directory will be used to confirm the identity of a
certificate applicant*_. If the directory cannot be used to sufficiently
validate a certificate applicant, further validation processes will be
used. These may include an out of bands validation of the applicant’s
submitted information."
I'm missing here an important step in these validation procedure. Can
Comodo explain how it establishes the connection between the applicant
and the documents received on one side and through its automated
process, its own database of information and third party databases on
the other side? Please point me to the exact reference in the CPS since
I most likely missed it.
(Please note that "Code Signing" serves as an example and may apply to
other types of certificates as well according to the CPS).
Eddy Nigg (StartCom Ltd.)
> This is a followup to my previous message about Comodo's application to
> add a new EV root CA certificate. Comodo also has requested enabling
> three existing roots, AddTrust External CA Root, UTN - DATACorp SGC, and
> UTN-USERFirst-Hardware, for EV use, and also marking all three roots for
> SSL, email, and code signing use, as documented in the following bug:
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=401587
>
> and in the pending certificates list:
>
> http://www.mozilla.org/projects/security/certs/pending/#Comodo
>
> I have evaluated this request, as per the mozilla.org CA certificate policy:
>
> http://www.mozilla.org/projects/security/certs/policy/
>
> and plan to officially approve the request after a public comment period.
>
The public comment period is officially up and I'd like to make the
following statement:
In light of Franks entry at bug
https://bugzilla.mozilla.org/show_bug.cgi?id=401587#c20 NOTE #2 [1]
- and due to the fact that Comodo hasn't replied to most
questions/inquiries;
- and due to the fact that Comodo has a high market share (second in
size as claimed by Comodo themselves) and hence the risks for Mozilla
and its users might be of a much bigger scale [2];
- and due to the fact that I have found reasons enough to believe that
their low-assurance certification might present a risk to Mozilla and
its users , specially also because I haven't received sufficient answers
or none at all, to refute my findings;
I suggest the following at this stage:
Adding an entry at the bug that
- requests officially a statement and answering of the issues which have
been raised [3];
- request to actively address the issues which are deemed to be a risk
for Mozilla and its users after receiving their answers and after
evaluating them;
and refrain from adding and/or updating their CA certificates at NSS
until we have reasons enough to believe that all issues have been solved
to our satisfaction, specially also because all their roots issue any
type of certificates from DV to EV, hence separation isn't possible at
this stage
and refrain from further advancing of their inclusion/upgrade request
(of the others roots which are potentially up for upgrade to EV status).
[1] Although all these roots are already in NSS, in the interests of
thoroughness I'll repeat all the evaluation steps as if they were new roots.
[2] Success also brings with it greater responsibilities, which is
specially true for this industry.
[3] I'd be glad to gather all the points raised and summarize and
formulate them for this task if this is of any help.
Robin Alden
I'm sorry I haven't got around to answering your questions until
now.
You wrote:
> 1.) The audit report for non-EV operations refers to the CA operation at
> Manchester. The audit report for EV refers to the CA operations at New
> Jersey. One of the roots is from a company operating in Sweden, one
> operating in Salt Lake City, Utah, USA and and one of Salford, GB. Can
> the relations between these locations and the general operation of
> Comodo and the audit reports be explained?
The WebTrust Audit covers most aspects of our operation as a CA. The
auditors visit any part of our operation which they deem to be involved in
our CA operation.
The Manchester office is our UK based validation operation. It handles both
EV and OV validation.
The New Jersey office is our US based validation operation. It too handles
both EV and OV validation.
We have one more validation operation which handles OV validation only and
which is also audited each year as part of the webtrust audit.
The AddTrust root was purchased by Comodo from the ScandTrust organization
in Malmo
_______________________________________________
dev-tech-crypto mailing list
dev-tec...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
Robin Alden
I'm sorry I haven't got around to answering your questions until
now.
You wrote:
> 1.) The audit report for non-EV operations refers to the CA operation at
> Manchester. The audit report for EV refers to the CA operations at New
> Jersey. One of the roots is from a company operating in Sweden, one
> operating in Salt Lake City, Utah, USA and and one of Salford, GB. Can
> the relations between these locations and the general operation of
> Comodo and the audit reports be explained?
The WebTrust Audit covers most aspects of our operation as a CA. The
auditors visit any part of our operation which they deem to be involved in
our CA operation.
The Manchester office is our UK based validation operation. It handles both
EV and OV validation.
The New Jersey office is our US based validation operation. It too handles
both EV and OV validation.
We have one more validation operation which handles OV validation only and
which is also audited each year as part of the webtrust audit.
The AddTrust root was purchased by Comodo from the ScandTrust organization
in Malmö, Sweden. They had acquired the root (and continued the protection
of the key material, etc.) when they took over the AddTrust operation.
The four UserTrust roots became available to Comodo when UserTrust became a
Comodo Group Company.
In both of the above cases the key material was removed from its original
sites of operation (in Sweden and Salt Lake City, respectively) and
trafserred into Comodo's data centres and backup centres.
The roots you see with Comodo's name in, or mentioning a Salford address,
are roots for which we have generated the keys ourselves.
As to your request to "refrain from further advancing of their
inclusion/upgrade request" - well, I'd rather answer the questions in this
forum, if possible.
Regards
Robin Alden
Comodo CA Limited.
Eddy Nigg (StartCom Ltd.)
> As to your request to "refrain from further advancing of their
> inclusion/upgrade request" - well, I'd rather answer the questions in this
> forum, if possible.
>
>
Yes, we were promised that you or some other representative of Comodo
would address the questions raised, here directly. It's not a
requirement of course, since the bug entry serves as the authority, but
it's perhaps more convenient if you could provide the answers in this
forum and we could discuss everything upcoming here.
Thanks for the answers you already provided.
Robin Alden
You asked:
> Additionally I would like to know to whom belongs the company LITESSL
> CA, INC. and its relationship to Comodo CA Ltd. as referenced in the
> audit report from KPMG
> (https://cert.webtrust.org/SealFile?seal=636&file=pdf). What are its
> relations to AddTrust AB, Sweden? In the audit reports no distinctions
> are made between the various companies and the audit reports are
> addressed only to Comodo CA Ltd.
Comodo CA Ltd. is the company undergoing the audit. It is the only company
to which the WebTrust Audit applies.
Comodo CA Ltd. operates a number of different certificate brands. LiteSSL
is one such brand.
LiteSSL CA Inc. is wholly controlled by Comodo CA Limited.
There is no ongoing relationship with AddTrust AB, Sweden. I'm not even
sure if AddTrust AB still exists as a company. I think AddTrust may exist
now only as a brand of ScandTrust AB. Sweden - although Comodo does have the
right to continue using the root CA certificates which we purchased from
them and which bear the AddTrust name.
Robin Alden
Robin Alden
You said:
> 2.) The Comodo Certification Practice Statement, Version 3.0 and other
> CPS amendments state that wild card certificates are domain name
> validated only (depending on product or trade mark). How does Comodo
> prevent or control misuse of wild card certificates, specially in
> relation to phishing attempts and other fraud, taking into consideration
> that these certificates are domain validated only? Does Comodo believe
> that such wild card certificates are issued according to verification
> requirements for this special type of certificates?
I have seen some other discussion of this issue in these threads, but I will try and clarify our position.
Any validation we do is to the highest level ownable domain name. I appreciate that’s not a very exact term, but I mean that for a .com domain name we validate foo.com, for a .co.uk domain name we validate foo.co.uk.
We restrict the wildcard character in the domain name to be the leading sub-domain. – e.g. *.foo.com, *.foo.co.uk.
We do not apply any post-issuance checks on domain names for which the certificate.
E.g. If we find a certificate is being used at ebay.foo.com we would not *automatically* take action on that certificate – unless we become aware (either through our own inspection or by notification from a third party) that fraud is likely.
If any fraudulent use of any of our certificates (wildcard or not, EV or not) is discovered we will revoke that certificate. We are permitted to do that by the subscriber agreement to which our subscribers indicate their agreement when they purchase certificates from us.
We agree that wildcard certificates pose more problems than non-wildcard certificates – but Wildcard certificate products exist today and we are not minded to unilaterally withdraw them.
We helped to found the CAB forum and continue to support it to improve the overall security of SSL certificates. We hope that one day all certificates will be EV, but until that day we feel we must be allowed to compete with order CAs issuing wildcard products.
Regards
Robin Alden
Comodo
Florian Weimer
> The CAs should prevent issuance of certificates which are suspected to
> be used for phishing attempts and other fraud. This includes cases like
> real domain names (mic0s0ft.com, paypa1.com) and sub domain names
> (paypal.nelson.com).
Is there any CA which is part of the browser PKI which actually does
this?
For instance, the site <https://secure.eurosoftmarket.com/> is clearly
fraudulent, but it's received a certificate from Equifax. I'm sure
there are similar examples for all major CAs.
Eddy Nigg (StartCom Ltd.)
> * Eddy Nigg:
>
>
>> The CAs should prevent issuance of certificates which are suspected to
>> be used for phishing attempts and other fraud. This includes cases like
>> real domain names (mic0s0ft.com, paypa1.com) and sub domain names
>> (paypal.nelson.com).
>>
>
> Is there any CA which is part of the browser PKI which actually does
> this?
>
>
"Geotrust has a rigorous process in place to check for phishy
certificate requests that relies on algorithms which check cert requests
for certain words, misspellings or phrases that may indicate a phisher
is involved."
Incidentally as you can read in the article, the system failed and a
certificate was issued wrongfully.
Also StartCom has a similar system deployed which performs various
checks - including check with third party sources, before the issuance
of any certificate and post checks are performed as well. I guess these
are not the only examples. I happened to read enough CPSs of CAs which
mention this explicitly for reasons of non-issuance and/or revocation of
certificates.
[1]
http://blog.washingtonpost.com/securityfix/2006/02/the_new_face_of_phishing_1.html
Frank Hecker
>
> Adding an entry at the bug that
> - requests officially a statement and answering of the issues which have
> been raised [3];
As far as I can tell, here are the most recent questions you've raised
(first four in a message dated March 16, the last one in a message dated
March 18):
1. Questions re a) location(s) of Comodo operations, b) corporate
relationship of LiteSSL to Comodo, b) corporate relationship of AddTrust
AB to Comodo.
2. Question re wildcard SSL certificates issued when only domain
validation is done.
3. Question re what happens for certificates with long lifetimes when
the certificate holder goes out of business, changes name, etc.
4. Question to me re the scope of the review of the application to
upgrade existing Comodo roots for EV.
5. Question re verification procedures for code signing certificates
(section 4.2.1 and 4.2.8, as referenced by section 2.4.3 of the 3.0
Comodo CPS).
> - request to actively address the issues which are deemed to be a risk
> for Mozilla and its users after receiving their answers and after
> evaluating them;
Robin Alden has already responded to questions 1.a, 1.b, and 1.c. I
don't see any outstanding issues relating to these questions.
Question 2 (wildcard SSL DV certs) I comment on below.
I'm not exactly sure how question 3 (relating to long-lived certs) is
relevant. Presumably the concern is either a) that someone else (i.e.,
other than the original cert holder) could (re)use certs and domains
abandoned by their owners, or b) for renamed businesses, any
organizational info in the cert is no longer true, or c) just a general
concern that it's bad practice to have valid certs for no longer valid
businesses and/or domains.
From my point of view, renaming of a business, termination of a
business, having a domain name expire, are all things that could happen
whether the cert lifetime is one year or longer. Our policy doesn't
contain any prohibition against cert lifetimes longer than a year, so
the only way our policy is relevant to this question is if we want to
judge longer-lived certs as a security risk in general. But as a
security risk this seems to be addressed already by subscribers'
obligation (under subscriber agreements) to protect their own private
keys, and CAs' ability to revoke certs if they become aware of any problems.
Question 4 was a question to me, not Comodo, and I've already answered it.
Question 5 (code signing verification) is outstanding. I haven't yet had
a chance to review the CPS language in detail, so I won't comment on it
further here.
Now back to question 2 (wildcard DV certs):
As I've previously noted, our policy is silent on the subject of
wildcard certs (DV or otherwise), so any application of our policy to
the question has to fall back on general concerns about security. For
these general security concerns to be relevant, I think the security
risks associated with wildcard DV certs have to be great enough to
outweigh the impact on legitimate uses of any proposed ban on wildcard
DV certs (i.e., requiring subscribers to prove identity before getting a
wildcard cert). (This basically replicates the previous discussions on
whether to allow DV certs or not; in the end we decided that legitimate
uses of DV certs outweighed the potential risks.)
I don't think this case has been made. Certainly there are legitimate
uses for wildcard DV certs: Just as regular DV certs can be used to
secure non-ecommerce transactions for personal or small group sites
(e.g., www.hecker.org), wildcard DV certs could be used for cases where
individuals or small groups want to SSL-enable multiple subdomains under
their domains (e.g., smtp.hecker.org, imap.hecker.org) without having to
pay for individual certs for each subdomain. There are even legitimate
uses for SSL-enabled subdomains that reference names of other
businesses, for example paypal-tips.hecker.org or
paypal-team.hecker.org; the former might be a third-party help site
maintained as a wiki with SSL-protected authentication, the latter a
collaboration site for a small business that's a vendor to PayPal.
If we mandate that CAs issuing wildcard SSL certs must verify the
identity of cert holders (beyond just verifying domain
ownership/control), then in essence we're imposing a financial burden on
all such legitimate uses of wildcard certs; IV/OV/EV certs are
significantly more expensive than DV certs, and buying individual DV
certs for each subdoman is significantly more expensive than buying a
wildcard cert for the whole domain. And to the extent that imposing such
burden causes people not to SSL-enable their subdomain sites at all,
such a mandate also raises security risks; for example, people using
such sites over public wifi networks will have increased risks of others
sniffing passwords and other sensitive data.
Is this negative impact on legitimate uses justified by the actual
security threat of wildcard DV certs? To my knowledge nobody in this
discussion has thus far presented any actual evidence that issuance of
wildcard DV certs has led to significant levels of fraud or other
security problems. For that matter, I'm not aware of any evidence that
issuance of DV certs in general has led to significant levels of fraud
or other problems; so from my point of view regular DV certs and
wildcard DV certs are roughly equivalent in this regard. In the absence
of any such evidence we're left with hypothetical scenarios that such
and such bad things might happen (e.g., setting up phishing sites at
paypal.foo.com, ebay.foo.com, etc.), and calls for CAs to take
pre-emptive actions to prevent such hypothetical bad things.
Based on the arguments presented thus far, I just don't believe that the
security risk of wildcard DV certs justifies the impact on legitimate
uses of banning wildcard DV certs entirely (or, more correctly, not
including roots for CAs that issue them). To the extent that problems do
occur, there are existing procedures like cert revocation that can help
address them. To echo Bruce Scheier, we don't want to focus over much on
prevention when detection and response may be adequate to address the
actual risk.
I understand the desire to see CAs take more proactive actions, like
doing automated checks on domain names submitted for DV cert
applications. And if such checks have a minimal impact on legitimate
uses I have no problem at all with CAs doing them. However I do have a
problem with mandating CA checks (including identity checks) and other
actions that have a non-trivial impact just because they're claimed to
be "good practice". DV certs (wildcard or otherwise) are what they are;
their purpose is not to facilitate ecommerce or inspire trust in end
users. If we want to promote ecommerce and help end users then we
already have a vehicle by which to do that, namely EV certs and their
associated browser UI (a UI that's deliberately different than tradition
UI used for DV/IV/OV certs). I don't see a compelling need to introduce
elements of identity verification into the DV cert arena, for wildcard
certs or otherwise.
Robin Alden
You said:
> 3.) The Comodo Certification Practice Statement, Version 3.0 and
> other CPS amendments state certificate validity of up to ten years
> expires. It isn't clear what happens if an identity or organization
> changes name, changes address, stops its operation, dies etc. How
> does Comodo guaranty the validity of these certificates throughout
> their lifetime?
The only certificates we issue for 10 years are DV certificates.
We do not currently repeat any of the validation checks during a
certificate's lifetime for any of our certificate types.
If a subscribing entity changes name, address, or ceases operation they are
obliged (by the subscriber agreement) to inform us.
If we become aware that any of the details held in the certificate become
invalid then, as stated in the CPS (version 3.0 section 4.13), we may revoke
the certificate. We would rather see a certificate with incorrect details
pulled and replaced with one with the correct details (which we will often
provide free of charge) but if that does not happen we will revoke.
We have certainly thought about the case where an organization ceases to
operate, or a domain name changes hands, and when we follow the cases
through where the subscriber does not inform us they do not strike us as
being of high risk. There is some risk of fraud, certainly, but it is not
high up the list of ways we see people using SSL certificates to commit
fraud.
Robin Alden
You said:
> - Unlucky formulation of "4.2.1 Secure Server Certificates Validation
> Process" (Code Signing versus Server Certs).
> - Subsection 1 doesn't apply I guess.
Subsection 1 did not apply for code signing certificates for a long time, but for the last few months we have been doing a subsection 1 validation check on the domain name used in the applicant email address (which is also the one that usually goes in the subject of the code signing certificate). We are acutely aware of the growing prevalence of the use of code-signing certificate in malware of all sorts.
We have various other checks in this area which we apply in addition to those explicitly mentioned in the CPS. I appreciate that doesn't help you much because we wouldn't disclose them publicly, but they are disclosed to our WebTrust auditors during our audits and we would probably be prepared to discuss them further with Mozilla (and other browser / OS providers) under NDA.
We also have means whereby we are able to spot the misuse of our code-signing certificates at an early stage. We revoke code-signing certificates and push new CRLs out at very short notice when we become aware of fraud / malware involving them.
> - Subsection 2 says:
>
> The applicant is an accountable legal entity, whether an
> organization or an individual.
> • Validated by requesting official company documentation, such as
> Business License, Articles of Incorporation, Sales License or other
> relevant documents.
> • For non-corporate applications, documentation such as bank
> statement,
> copy of passport, copy of driving license or other relevant
> documents.
>
> Further it says:
>
> The above assertions are _*reviewed through an automated process*_,
> manual review of
> supporting documentation and reference to third party official
> databases.
That's good general stuff which would cover almost anything we wanted to do with it really!
The only automated processes which occur now are to avoid the unnecessary duplication of validation work. To try and clarify that a little, when we undertake some validation work we give that information a lifetime. If we check the existence of a legal domain, or domain ownership, we will not repeat that work if the same organization buys another certificate within some prescribed timescale. Obviously if they buy for a different domain then we have to validate the new domain - but we can rely on the validation work done for the earlier purchase for the validation of the legal entity.
> Scrolling further down to 4.2.8 (applies to Code Signing Certificate /
> Time Stamping Certificate):
>
> Code Signing Certificates and Time Stamping Certificates are
> processed by a Comodo validation officer in accordance with the
> process outlined in section 4.2.1 of this CPS.
>
> OK, I was at 4.2.1 already, Comodo received and reviewed the material
> received and referenced to third party sources.
>
> Comodo may employ the data held by IdAuthority to expedite the
> validation process. _*If application data matches the records*_
> held
> by IdAuthority, _*manual validation intervention is not required*_.
> In the event that the application data does not match the
> pre-validated records, the application is processed manually by a
> Comodo validation officer in accordance with the process outlined
> in
> section 4.2.1 of this CPS.
I'm afraid that the important word there with relation to our current validation procedures is "may". "Comodo *may* employ the data held by IdAuthority". We don't any more. We found that it ceased to be cost effective to keep the quality of the information in the IdAuthority database at a high enough level that we could use it as a source of validation information.
>
> Again I'm pointed to 4.2.1...
>
> IdAuthority = "contains records of over 5 million unique legal entities
> sourced from a combination of publicly available resources. Where
> possible, _*the directory will be used to confirm the identity of a
> certificate applicant*_. If the directory cannot be used to
> sufficiently
> validate a certificate applicant, further validation processes will be
> used. These may include an out of bands validation of the applicant’s
> submitted information."
>
> I'm missing here an important step in these validation procedure. Can
> Comodo explain how it establishes the connection between the applicant
> and the documents received on one side and through its automated
> process, its own database of information and third party databases on
> the other side? Please point me to the exact reference in the CPS since
> I most likely missed it.
I know you will find this disappointing, but I'm going to point you back to 4.2.1 again. Any internal databases that we refer to for validation information are just snapshots in time of the same information we gather for 4.2.1. IdAuthority (when it was in use as a source of validation information) was just a bulk snapshot of information that we would have gathered for 4.2.1.
The 3rd party databases mentioned are the domain registries (for Whois records) or the jurisdictions of incorporation (for evidence of legal existence and correctness of address details, etc, of the legal entity).
Regards
Robin Alden
Comodo CA Ltd.
Eddy Nigg (StartCom Ltd.)
you've touched everything so far). Thanks to Frank for your reply as
well. Please give me some time to evaluate all your answers, thoughts
and suggestions and prepare a decent reply. Most likely I'll be ready to
post tomorrow back to the list.
Eddy Nigg (StartCom Ltd.)
>
> Robin Alden has already responded to questions 1.a, 1.b, and 1.c. I
> don't see any outstanding issues relating to these questions.
>
raised. I intend to reply to each in a summarized form.
> Question 2 (wildcard SSL DV certs) I comment on below.
>
> I'm not exactly sure how question 3 (relating to long-lived certs) is
> relevant.
> Presumably the concern is either a) that someone else (i.e.,
> other than the original cert holder) could (re)use certs and domains
> abandoned by their owners, or b) for renamed businesses, any
> organizational info in the cert is no longer true, or c) just a general
> concern that it's bad practice to have valid certs for no longer valid
> businesses and/or domains.
>
a check is performed to guaranty to a reasonable extend, that only the
owner (or from the owner assigned person) can request a certificate for
a specific domain name. This in order to prevent a MITM attack and
eavesdropping. Mozilla requires that, in order to let users of its
software securely rely on it for the intended purpose. One could
describe this to be the mission of the Mozilla CA policy and the work we
are doing here.
Back to our issue about very-long-lived certificates:
One can purchase a popular or less popular domain name, request a
certificate for N years, let the domain name expire after one year, wait
to have it picked up by somebody else. Now, this site can be spoofed at
will and a MITM is possible (the very same thing Mozilla tries to
prevent in first place).
But let me give you a real-world example, first hand...
Please visit
http://toolbar.netcraft.com/site_report?url=http://www.startssl.com and
find that this domain name belonged to somebody in Korea some four years
ago or less. Just the thought about somebody in Korea having a
certificate still valid for one of our major domain names makes me
shiver. This person could effectively spoof our web site. This is NOT
funny! This is a risk to a big number of users trusting us and Mozilla!
> From my point of view, renaming of a business, termination of a
> business, having a domain name expire, are all things that could happen
> whether the cert lifetime is one year or longer.
It is reasonable to assume that domain names have a period after
expiration when they aren't sold, but held up for the original owner to
be extended. It is also reasonable to believe, that even should a
certificate have been issued at some time, it will expire within a
reasonable amount of time. One can reasonable assume, that after the
passing of some time, no legitimate certificates does exist in the wrong
hands.
> Our policy doesn't
> contain any prohibition against cert lifetimes longer than a year, so
> the only way our policy is relevant to this question is if we want to
> judge longer-lived certs as a security risk in general.
Absolutely. This is exactly the case!
> But as a
> security risk this seems to be addressed already by subscribers'
> obligation (under subscriber agreements) to protect their own private
> keys, and CAs' ability to revoke certs if they become aware of any problems.
>
First of all, the first part of this sentence is completely irrelevant,
because the current domain name owner and eventual visitors to that site
are at risk and not the person which previously held that domain name
(and also still holds a certificate). Second, should the CA become aware
of it (which I highly doubt in our case), that would be faaaar tooo
late. Under certain circumstances, this could go on undetected for a
long time, if at all!
Now I suggest you evaluate this situation once again! I'm not saying one
year is the limit (so it should be the suggested best practice), but
because domain validated certificates are already the lowest possible
validation level and with it are bearing the highest risk in every
respect, we shouldn't allow anything beyond two years or so. Certainly
nothing higher than 3 years.
>
> As I've previously noted, our policy is silent on the subject of
> wildcard certs (DV or otherwise), so any application of our policy to
> the question has to fall back on general concerns about security.
Agreed.
> For
> these general security concerns to be relevant, I think the security
> risks associated with wildcard DV certs have to be great enough to
> outweigh the impact on legitimate uses of any proposed ban on wildcard
> DV certs (i.e., requiring subscribers to prove identity before getting a
> wildcard cert).
I think this to be reasonable and responsible in every respect.
Considering that wild card certificates are most of the time also sold
for a much higher fee compared to regular certificates, this is a
service CAs should perform. Generally I'm against having the "money"
argument involved at all when considering a criteria for the issuance of
certificates, but I suppose that the CAs in question really can afford
to perform a higher validation and also provide some value for their
certificate. Hey, we'll be helping them to have a better product - and
obviously this would have to be applied evenly onto all CAs.
> (This basically replicates the previous discussions on
> whether to allow DV certs or not; in the end we decided that legitimate
> uses of DV certs outweighed the potential risks.)
>
And I'm completely in agreement with this what regular DV certs concerns!
> I don't think this case has been made. Certainly there are legitimate
> uses for wildcard DV certs: Just as regular DV certs can be used to
> secure non-ecommerce transactions for personal or small group sites
> (e.g., www.hecker.org), wildcard DV certs could be used for cases where
> individuals or small groups want to SSL-enable multiple subdomains under
> their domains (e.g., smtp.hecker.org, imap.hecker.org) without having to
> pay for individual certs for each subdomain. There are even legitimate
> uses for SSL-enabled subdomains that reference names of other
> businesses, for example paypal-tips.hecker.org or
> paypal-team.hecker.org; the former might be a third-party help site
> maintained as a wiki with SSL-protected authentication, the latter a
> collaboration site for a small business that's a vendor to PayPal.
>
I agree with the later part, but I request from you once again to try to
see the difference between having issued a legitimate domain validated
certificate to paypal-tips.hecker.org (and this after the CA has made
some extra checks with Mr. Hecker, because this is the responsibility
the CA has taken upon itself by issuing this type of certificates, even
with the risk of loosing its profit on this specific certificate,
because the security of the relying parties is simply more important,
something a CA should be interested foremost in first place) and a
domain validated wild card certificate which can be used for
paypal.hecker.org, in which case the CA doesn't know for which sub
domain name the certificate will be used.
How different however if the CA validated Mr. Hecker before issuing his
wild card certificate. We all will sleep much better because of that.
> If we mandate that CAs issuing wildcard SSL certs must verify the
> identity of cert holders (beyond just verifying domain
> ownership/control), then in essence we're imposing a financial burden on
> all such legitimate uses of wildcard certs;
Frank, now I'm having crocodile-sized tears rolling down my cheeks :'(
First of all, they are sold usually anyway for a much higher amount,
second this argument is completely irrelevant to the users security
which is at risk here.
> IV/OV/EV certs are
> significantly more expensive than DV certs, and buying individual DV
> certs for each subdoman is significantly more expensive than buying a
> wildcard cert for the whole domain.
It depends! Find a CA which issues them cheaper then...Wild card
certificates are usually more expensive then IV validated certificates,
but this is not the point here at all...find the best deal for the value
the CA gives you, simple as that. Mozilla doesn't have any financial
responsibilities neither with CAs not with subscribers. It has a
responsibility for its users.
> And to the extent that imposing such
> burden causes people not to SSL-enable their subdomain sites at all,
> such a mandate also raises security risks;
>
Yes? But certificates valid for ten years are not? Unrelated to that,
the next release of Firefox does counter this behavior effectively,
which in itself is Mozilla's share of lowering that risk.
Incidentally I feel in this discussion, that this team is effectively
undermining the efforts others are making in improving security in
relation to certificates. What a joke, to make it almost impossible for
users to circumvent any type of SSL errors (which includes invalid sub
domains, etc) and allowing domain validated wild card certificates with
a validity of up to ten years issued by one of the major CAs. Common!
The two simply don't go together! This is completely counterproductive
and apparently we haven't seen the wind of change yet....
> Based on the arguments presented thus far, I just don't believe that the
> security risk of wildcard DV certs justifies the impact on legitimate
> uses of banning wildcard DV certs entirely (or, more correctly, not
> including roots for CAs that issue them).
Of course, updating the Mozilla CA policy is a tool in our hand, should
we agree this to be useful, not including a CA could be another. But we
could help them address this and other issues in a joint effort.
>
> I understand the desire to see CAs take more proactive actions, like
> doing automated checks on domain names submitted for DV cert
> applications. And if such checks have a minimal impact on legitimate
> uses I have no problem at all with CAs doing them.
Why should you? You should encourage it...
> However I do have a
> problem with mandating CA checks (including identity checks) and other
> actions that have a non-trivial impact just because they're claimed to
> be "good practice". DV certs (wildcard or otherwise) are what they are;
> their purpose is not to facilitate ecommerce or inspire trust in end
> users. If we want to promote ecommerce and help end users then we
> already have a vehicle by which to do that, namely EV certs and their
> associated browser UI (a UI that's deliberately different than tradition
> UI used for DV/IV/OV certs). I don't see a compelling need to introduce
> elements of identity verification into the DV cert arena, for wildcard
> certs or otherwise.
>
Because you and I believe that domain validated certificates do have a
legitimate place in this landscape, we should also take care, that they
remain effective as possible. The negative impact of misuse of this type
of certification will be the end of DV certificates altogether. This is
what I care about the same as I care about the relying parties. DV certs
are very useful for the intended purpose. Wild card certificates however
shouldn't be part of it. Neither should certificates with a validity of
ten years and this includes ANY type of certificate (DV/IV/OV/EV)!
Specially the later would be a serious blow to Mozilla's standing on
security and its responsibilities for its users!
Eddy Nigg (StartCom Ltd.)
First of all thank you for your honest answers, I appreciate that and
the time you invested! This is going to be a summarized response of all
your posts and answers.
Robin Alden:
>
> The only certificates we issue for 10 years are DV certificates.
> We do not currently repeat any of the validation checks during a
> certificate's lifetime for any of our certificate types.
>
The behavior of Comodo in this respect is really surprising! Supposed
you would issue certificates with longer validity only to entities which
were thorough verified and validated, I could offer some understanding.
But by issuing *domain validated* certificate for up to *ten years*,
without revalidation is completely irresponsible and borders on gross
negligent.
In comparison, there are intermediate CA certificates in use by CAs
which are in NSS which have a shorter lifetime even than that in order
to lower the risks! One can assume that this type of CA certificates are
adequately secured and don't rely on domain names which might stop to
exist and change owners (willingly and unwillingly).
> We have certainly thought about the case where an organization ceases to
> operate, or a domain name changes hands, and when we follow the cases
> through where the subscriber does not inform us they do not strike us as
> being of high risk. There is some risk of fraud, certainly, but it is not
> high up the list of ways we see people using SSL certificates to commit
> fraud.
This issue has come up with other CAs as well, but apparently any of
them offering certificates for longer validity, require the subscriber
to re-validate their domain. As far as I know, you are the only CA doing
that (which is included in NSS) and in that respect an argument (which
you used elsewhere), that the competition is doing it as well, is not
relevant.
The risk exists and I gave a real show-case to a reply to Frank
yesterday (most likely you've read it too). If this is made possible,
than why validate a domain at all? As you agreed with me, there is a
risk of fraud, it just requires somewhat more patience and money for a
sophisticated attacker, but detection is accordingly also much more
difficult. And it defeats the very purpose of domain validated
certificates.
> We restrict the wildcard character in the domain name to be the
> leading sub-domain. – e.g. *.foo.com, *.foo.co.uk.
>
Good.
>
> E.g. If we find a certificate is being used at ebay.foo.com we would
> not **automatically** take action on that certificate – unless we
> become aware (either through our own inspection or by notification
> from a third party) that fraud is likely.
>
May I suggest to implement an automatic check for certificates which
could be potentially used for phishing and other fraud, including
certificates which are obviously for financial institution? Revocation
of a certificate after detection through your inspection is not as good
as possible prevention of the issuance in first place. Considering the
size of your CA and the difficulty of controlling automated issuance, I
would expect it from you and I'm rather surprised not to find any
provision in that respect.
>
> We agree that wildcard certificates pose more problems than
> non-wildcard certificates – but Wildcard certificate products exist
> today and we are not minded to unilaterally withdraw them.
>
Which I never, ever suggest at all. However I would expect that Comodo
does perform additional steps, to ensure that misuse of wild card
certificates is prevented, or at least the risk lowered. This can be
done by validating the identity of the subscriber for example. You may
find other effective ways for doing the same. I'd be glad to learn about
any implementation of your CA in regards lowering the risk for wild card
certificates.
>
> We helped to found the CAB forum and continue to support it to improve
> the overall security of SSL certificates.
>
I'm afraid, but in my opinion your CA does exactly the opposite. I'm
glad that you support the CAB forum, however your CPSs aren't convincing
at all what your non-EV business concerns.
>
> We hope that one day all certificates will be EV, but until that day
> we feel we must be allowed to compete with order CAs issuing wildcard
> products.
>
About which I agree with you. Non-EV and wild card certificates are an
important part of existing PKIs, however you also bear a responsibility!
Considering that you claim to be #2 in this industry, you aren't doing a
great service to our industry nor can I see how your CA is actively
trying to improve the standing and security of PKI in general, and for
Mozilla and its users in particular.
> The WebTrust Audit covers most aspects of our operation as a CA.
Most or all?
> The
> auditors visit any part of our operation which they deem to be involved in
> our CA operation.
> The Manchester office is our UK based validation operation. It handles both
> EV and OV validation.
> The New Jersey office is our US based validation operation. It too handles
> both EV and OV validation.
> We have one more validation operation which handles OV validation only and
> which is also audited each year as part of the webtrust audit.
>
Is it possible to receive a statement from your auditor in that respect?
Because this isn't what your audit reports and confirmations are saying.
Perhaps we are also missing some audit reports at all...
> The AddTrust root was purchased by Comodo from the ScandTrust organization
> in Malmö, Sweden. They had acquired the root (and continued the protection
> of the key material, etc.) when they took over the AddTrust operation.
> The four UserTrust roots became available to Comodo when UserTrust became a
> Comodo Group Company.
> In both of the above cases the key material was removed from its original
> sites of operation (in Sweden and Salt Lake City, respectively) and
> trafserred into Comodo's data centres and backup centres.
> The roots you see with Comodo's name in, or mentioning a Salford address,
> are roots for which we have generated the keys ourselves.
>
This is an issue for Frank. It has been previously raised here at the
mailing list (not be me btw) and there might be a problem with it.
Personally I think that if the company to which the root was issued,
stopped its operation and/or ceased to exist, or if the details within a
certificates (including root certificates) are not correct anymore, they
should be revoked. Instead an updated certificate should be issued with
the correct information included. Alternatively the same keys could be
reused. We require this conditional for end users, but certainly should
be true as well for CA roots. This is proper handling of PKI certificate
life cycle, something which auditors confirm. As a matter of fact, I
believe that we have CA roots in NSS which have untrue and wrong
information in the subject line.
> Concerning code signing:
> We have various other checks in this area which we apply in addition to those explicitly mentioned in the CPS. I appreciate that doesn't help you much because we wouldn't disclose them publicly, but they are disclosed to our WebTrust auditors during our audits and we would probably be prepared to discuss them further with Mozilla (and other browser / OS providers) under NDA.
>
I think that statement from you is just fine (expect if proven otherwise).
> We also have means whereby we are able to spot the misuse of our code-signing certificates at an early stage. We revoke code-signing certificates and push new CRLs out at very short notice when we become aware of fraud / malware involving them.
>
Very good!
> The only automated processes which occur now are to avoid the
> unnecessary duplication of validation work. To try and clarify that a
> little, when we undertake some validation work we give that
> information a lifetime. If we check the existence of a legal domain,
> or domain ownership, we will not repeat that work if the same
> organization buys another certificate within some prescribed timescale.
What is this timescale? Current + ten years? (I guess not, but what does
it really mean?)
I understood your explanation on your use of internal databases and
third party sources. Your answers satisfy my questions in that respect.
Eddy Nigg (StartCom Ltd.)
After reviewing the request of Comodo and receiving sufficient answers
from Robin Alden (of Comodo) concerning the inclusion and update request
of the various Comodo CA roots currently under discussion and after
hearing (and replying to) the arguments you posted as well, I would like
to inform that I remain opposed to your opinion (as I understand it)
based on my knowledge and understanding.
I object to the inclusion of the Comodo CA roots (as this is a general
review as mentioned in the bug) on the grounds that the current
implementations as outlined in the various CP/CPS documents of Comodo
pose a risk to Mozilla and its users as relying parties.
In particular I object adding any CA root which issues domain validated
certificate with validities of ten years. The possible attack vectors
(MITM) are clearly real and pose a risk to any relying party, as
explained in my other posts on that matter.
Additionally I suggest to review our standing (of the Mozilla CA policy)
what wild card certificates concerns. The implementations of Comodo pose
in my opinion a possible risk to relying parties, specially in respect
of possible phishing attempts and other fraud.
I also suggest to consult with other experts in this field and with the
legal department of Mozilla concerning CA root certificates of which the
organization to which the root was issued as stopped its operations
and/or deceased to exist altogether. This includes also getting advice
concerning CA roots of which the details within the certificates are not
correct and true anymore.
I suggest to work with Comodo to solve this issues in a joint effort and
under the mutual understanding from both sides to provide reasonable
secure digital certification to Mozilla and other relying parties.
***********
This was the official statement, now the less official part:
Should my objection be ignored (which is your perfect right), I'll do my
utmost and by any relevant means at my disposal to reverse such a
decision. As an operator of a certification authority it's my
responsibility to prevent de-valuation of our own efforts and possible
de-valuation of this industry at large. As a member of the Mozilla
community it's my responsibility to contribute my knowledge and effort,
in order to keep NSS and the various Mozilla software a tool upon which
its users can rely on and with that further improving the use of the
Internet at large.
I've found, in the unique way Mozilla as a foundation and a community
project operates, a vehicle where I can directly influence and
contribute to the efforts of both the company I work for and to Mozilla.
Personally I believe in my mission and intend to make fully use of the
opportunity offered to me by Mozilla.
Frank Hecker
Eddy Nigg (StartCom Ltd.) wrote:
> One can purchase a popular or less popular domain name, request a
> certificate for N years, let the domain name expire after one year, wait
> to have it picked up by somebody else. Now, this site can be spoofed at
> will and a MITM is possible (the very same thing Mozilla tries to
> prevent in first place).
OK, I better understand what your concern is now. But note that this
scenario would not actually require the attacker to wait for a year.
They could simply use "domain tasting" to register a domain name, get a
cert for it, then hand back the domain after 5 days (or whatever it is)
for a refund.
So to the extent that this is a threat, it's really a threat against DV
certificates in general, even those with one year expirations.
Robin Alden
> >
> > The only certificates we issue for 10 years are DV certificates.
> > We do not currently repeat any of the validation checks during a
> > certificate's lifetime for any of our certificate types.
> >
>
> The behavior of Comodo in this respect is really surprising! Supposed
> you would issue certificates with longer validity only to entities which
> were thorough verified and validated, I could offer some understanding.
> But by issuing *domain validated* certificate for up to *ten years*,
> without revalidation is completely irresponsible and borders on gross
> negligent.
>
I disagree. With a DV certificate the only thing that we are warranting is
that the key holder controls the domain. There are no organizational
details in certificate - only the domain name in the common name.
[Robin said...]
Fraud how? For DV, we validate domain control. If a company goes bust and
passes the domain on to someone else then that new person could get a DV
certificate for the domain. In fact it will be a lot easier for them to get
a new DV certificate for the domain from us than to try and get the private
key of the old one from a defunct server.
To use the certificate you must be in possession of the private key and
(because of the validation) be in control of the domain.
Or are you suggesting that the risk you are addressing is of someone
choosing a defunct domain with a Comodo DV certificate (that we did not
become aware of and revoke) and getting hold of the private key of the
certificate from a server (from ebay or by theft or whatever) and then using
that certificate to mount a man-in-the-middle attack on the new owners of
the domain?
Why go to that effort? DV certificates are easy to get. That is a valid
criticism against DV.
DV products exist today - that is a fact. The browsers (in this case
Mozilla) have been content for us to issue DV certificates. Sure, a longer
duration certificate carries higher risk than a short one. We'd also accept
that a wildcard carries somewhat more risk than a single domain certificate,
but where is the line to be drawn?
Also, why draw the line retrospectively and at this moment in time? Should
Mozilla's policy on this not be published and clear for us to follow, rather
than ad-hoc?
>
> > We restrict the wildcard character in the domain name to be the
> > leading sub-domain. – e.g. *.foo.com, *.foo.co.uk.
> >
> Good.
> >
> > E.g. If we find a certificate is being used at ebay.foo.com we would
> > not **automatically** take action on that certificate – unless we
> > become aware (either through our own inspection or by notification
> > from a third party) that fraud is likely.
> >
> May I suggest to implement an automatic check for certificates which
> could be potentially used for phishing and other fraud, including
> certificates which are obviously for financial institution? Revocation
> of a certificate after detection through your inspection is not as good
> as possible prevention of the issuance in first place. Considering the
> size of your CA and the difficulty of controlling automated issuance, I
> would expect it from you and I'm rather surprised not to find any
> provision in that respect.
[Robin said...]
It is in our interest to know about as many SSL protected domains out there
on the internet as possible. We do actively look for them.
The snag is that with wildcard domains there really are an awful lot of
possibilities to search for. We are looking for needles in haystacks. If
we could get a zone transfer for the DNS server hosting domain.com (to pick
up all the existing sub-domains) then our life would be made simple and we
would certainly check them all, but that just doesn't work.
> >
> > We agree that wildcard certificates pose more problems than
> > non-wildcard certificates – but Wildcard certificate products exist
> > today and we are not minded to unilaterally withdraw them.
> >
> Which I never, ever suggest at all. However I would expect that Comodo
> does perform additional steps, to ensure that misuse of wild card
> certificates is prevented, or at least the risk lowered. This can be
> done by validating the identity of the subscriber for example. You may
> find other effective ways for doing the same. I'd be glad to learn about
> any implementation of your CA in regards lowering the risk for wild card
> certificates.
[Robin said...]
I agree that wildcard certificates are somewhat higher risk than single
domain certificates.
We are always looking for ways to improve our products, but we are also
influenced by commercial considerations in this matter.
We could perform EV validation for every DV certificate we sold. It would
increase the quality of the issued certificate base. Sadly it would have
the side effect that we would go out of business because we would be
accepting high costs for validating each certificate which we then sell as a
low price product (because it offers a low level of assurance).
I know you want us to ignore what everyone else does, but commercially it
would not make sense for us to pull out of that particular market segment
and leave it to a competitor.
Don't block us as an individual CA. Publish (as Mozilla) a list of policies
we must follow. That allows us to make a decision as to whether we want to
be in the root program or not. Also, apply those policies across the board.
If you were to block one CA but allow other CAs in to the root program which
operate the same policy the blocked CA must take some action to defend its
market position. What would you have that be?
> >
> > We helped to found the CAB forum and continue to support it to improve
> > the overall security of SSL certificates.
> >
> I'm afraid, but in my opinion your CA does exactly the opposite. I'm
> glad that you support the CAB forum, however your CPSs aren't convincing
> at all what your non-EV business concerns.
> >
> > We hope that one day all certificates will be EV, but until that day
> > we feel we must be allowed to compete with order CAs issuing wildcard
> > products.
> >
> About which I agree with you. Non-EV and wild card certificates are an
> important part of existing PKIs, however you also bear a responsibility!
> Considering that you claim to be #2 in this industry, you aren't doing a
> great service to our industry nor can I see how your CA is actively
> trying to improve the standing and security of PKI in general, and for
> Mozilla and its users in particular.
[Robin said...]
We are a commercial CA. We are driven by two forces.
On one side there are the requirements of the Browser (& OS) platforms.
E.g. They say we must be webtrust for CAs compliant (or equivalent) so we
are. If there are other published requirements we will follow them - or
expect not to have our roots embedded if we do not follow them.
On the other hand there is the commercial pressure on us to compete in the
market place. We cannot drop ranges of products that are offered by our
competitors. We agree that the SSL products out there need to be improved,
but that improvement must come across the board - and the way to do that is
to introduce new standards (such as EV) and promote their adoption.
Likewise the old standards (such as DV) must, in an ideal world, be phased
out - but in a planned approach which has been agreed by an appropriate
forum. The CAB Forum may be that forum - but a Browser (& OS) only forum
would be capable of a similar approach - although we'd like to think they
would accept some input from CAs too. I appreciate that Mozilla is at
liberty to make any decisions on it's CA acceptance policy that it sees fit,
but again the policies should be clear and stated in advance. Persuasion
and cajoling to change standards or withdraw products should not need to
happen at the level of an individual CA's application to have a root
certificate embedded (or its trust status changed).
>
> > The WebTrust Audit covers most aspects of our operation as a CA.
> Most or all?
[Robin said...]
It covers anything and everything that they feel (OR we feel) is relevant to
WebTrust.
Do we operate a green disposal policy for recyclable materials? - Yes.
Is that examined by the auditors? - No, because WebTrust does not address
it.
> > The
> > auditors visit any part of our operation which they deem to be involved
> in
> > our CA operation.
> > The Manchester office is our UK based validation operation. It handles
> both
> > EV and OV validation.
> > The New Jersey office is our US based validation operation. It too
> handles
> > both EV and OV validation.
> > We have one more validation operation which handles OV validation only
> and
> > which is also audited each year as part of the webtrust audit.
> >
>
> Is it possible to receive a statement from your auditor in that respect?
> Because this isn't what your audit reports and confirmations are saying.
> Perhaps we are also missing some audit reports at all...
[Robin said...]
You are missing a lot of information that is available to the auditors.
Much of the information about the structure of our business is kept out of
the public domain. You won't find our organization chart on our website.
You won't find network diagrams there either.
We are a commercial organization and we are not a public company. We share
the information with our auditors, they issue us with a statement of
compliance to the standards we are required to achieve. Exactly the same
type of thing happens with a financial audit. The Auditor does not document
everything he knows about the company, he examines all the available (to
him) information and makes statements about that information. Those
statements are made available to 3rd parties, but the underlying information
remains confidential.
[Robin said...]
We could conceivably issue new certificates for those root CAs to which you
object, but the thing we can't do is change the common name or the CA key
because a CA is defined as being a pairing of common name and key pair. If
we change the name then it is a different CA. If we change the key then it
is a different CA. Changing either would be equivalent to us throwing the
CA away.
We can issue new CAs and have them signed by the old CAs - but in fact this
is what we do with most of our products now. We issue many certificates via
intermediate CA certificates (whose subjects do not refer to legacy
entities).
Our main use for the UserTrust and AddTrust roots is to cross-sign other CAs
which we rely on where possible, falling back on the cross-signing to
inherit trust only where needed - usually on older platforms.
You will certainly shake things up if you remove all root CA certificates
whose subjects are no longer accurate. Our customers whose certificates
stop working will be decidedly miffed, I feel sure. Or did you have some
less drastic measure in mind, perhaps?
>
> > Concerning code signing:
> > We have various other checks in this area which we apply in addition to
> those explicitly mentioned in the CPS. I appreciate that doesn't help you
> much because we wouldn't disclose them publicly, but they are disclosed to
> our WebTrust auditors during our audits and we would probably be prepared
> to discuss them further with Mozilla (and other browser / OS providers)
> under NDA.
> >
> I think that statement from you is just fine (expect if proven otherwise).
>
> > We also have means whereby we are able to spot the misuse of our code-
> signing certificates at an early stage. We revoke code-signing
> certificates and push new CRLs out at very short notice when we become
> aware of fraud / malware involving them.
> >
>
> Very good!
>
> > The only automated processes which occur now are to avoid the
> > unnecessary duplication of validation work. To try and clarify that a
> > little, when we undertake some validation work we give that
> > information a lifetime. If we check the existence of a legal domain,
> > or domain ownership, we will not repeat that work if the same
> > organization buys another certificate within some prescribed timescale.
>
> What is this timescale? Current + ten years? (I guess not, but what does
> it really mean?)
[Robin said...]
No, not 10 years. I can't disclose the figure without checking with our
board, but it is a conservative figure which offers some benefit to us in
the level of reduction of validation effort while limiting the risk to the
validation process. It is a figure which is discussed each year with our
auditors and they have never raised it as a matter of concern.
What is Mozilla's policy on this matter? I am happy to give a commitment
that I will give an honest answer as to whether we meet it.
>
> I understood your explanation on your use of internal databases and
> third party sources. Your answers satisfy my questions in that respect.
>
>
[Robin said...]
Regards
Robin
Eddy Nigg (StartCom Ltd.)
> Don't have time for a long response, but I do have one comment below.
>
> Eddy Nigg (StartCom Ltd.) wrote:
>
>> One can purchase a popular or less popular domain name, request a
>> certificate for N years, let the domain name expire after one year, wait
>> to have it picked up by somebody else. Now, this site can be spoofed at
>> will and a MITM is possible (the very same thing Mozilla tries to
>> prevent in first place).
>>
>
> OK, I better understand what your concern is now. But note that this
> scenario would not actually require the attacker to wait for a year.
> They could simply use "domain tasting" to register a domain name, get a
> cert for it, then hand back the domain after 5 days (or whatever it is)
> for a refund.
>
Of course, smart CAs also make some checking on the validity of the
domain name, i.e. check the whois records accordingly. CAs have various
tools to protect themselves and the relying parties.
> So to the extent that this is a threat, it's really a threat against DV
> certificates in general, even those with one year expirations.
>
>
This is correct! But please read again what I posted:
It is reasonable to assume that domain names have a period after
expiration when they aren't sold, but held up for the original owner to
be extended. It is also reasonable to believe, that even should a
certificate have been issued at some time, *it will expire within a
reasonable amount of time*. One can reasonable assume, that *after the
passing of some time, no legitimate certificate does exist in the wrong
hands.*
A certificate with a lifetime of one year isn't an *ongoing threat of
possibly ten years* to come. There is a huge difference!
Supposed that a domain which was owned by someone else, isn't going to
end up within a very short time in the hands of a different owner, nor
that a sensitive web site (as for example with the startssl.com domain
name) which would prove to be a worthy candidate for such an attack, is
setup within a very short time, it is reasonable to assume that the
limitation of a certificate to a life time to one year will sufficiently
protect and prevent a MITM attack on said web site.
My argument is with reasons and within accepted boundaries of domain
validated certificates. Again, certificates with somewhat longer
validity should be handled accordingly (with additional validations
perhaps), but since domain validation is already the *lowest barrier* of
entry, they should be controlled accordingly with a *reasonable limited
validity*. Ten years is NOT reasonable! It borders on intent and gross
negligence!
Frank Hecker
> A certificate with a lifetime of one year isn't an *ongoing threat of
> possibly ten years* to come. There is a huge difference!
>
> Supposed that a domain which was owned by someone else, isn't going to
> end up within a very short time in the hands of a different owner, nor
> that a sensitive web site (as for example with the startssl.com domain
> name) which would prove to be a worthy candidate for such an attack, is
> setup within a very short time, it is reasonable to assume that the
> limitation of a certificate to a life time to one year will sufficiently
> protect and prevent a MITM attack on said web site.
I don't disagree that in general CAs should limit cert lifetimes, for
all sort of reasons. However I'm going to disagree with you here about
the risk assessment. I think an argument from economics is more
appropriate here:
In the attack you're describing the attacker is basically betting on the
possibility that a given domain name registered today (say, "foo.com")
will be used by someone in the future. At that future time the attacker
can do some DNS spoofing to redirect "foo.com" to his own site, which
has a still-valid DV cert for "foo.com", issued to the attacker at some
point in the past when the attacker controlled the domain. Thus the MITM
protections of the DV scheme fail and the attacker is free to commit fraud.
The price of the bet is the cost of registering the domain "foo.com" and
getting a DV certificate for it. (There might be other costs as well,
but for the purposes of this argument we can ignore them, since they
won't change the overall result.) The expected gain from the bet is the
typical amount realizable from attacking a real foo.com site, multiplied
by the probability that the "foo.com" domain name will be reused. The
expected profit is then the expected gain minus the cost.
For example, suppose that the cost of the "foo.com" domain and a 1-year
DV certificate for it is $30, and there's a 0.1% (0.001) probability
that "foo.com" will be reused by someone else during the validity period
of the certificate, and hence will be attackable in the manner
described. If the amount realizable from an attack against "foo.com" is
$50,000, then the expected gain from betting on "foo.com" ahead of time
will be $50 ($50,000 times 0.001). The expected profit is then $20 ($50
minus $30).
How does this analysis change if the cert has a longer validity period?
Clearly the probability of the domain "foo.com" being reused increases,
and hence the expected gain. (For example, we can assume as a first
approximation that the probability of "foo.com" being reused over a
10-year period is ten times the probability of it being reused in the
first year.) However the cost also increases (since 10-year certs cost
more than 1-year certs), and roughly in the same proportion. Thus the
expected profit associated using a 10-year certificate for this attack
is not significantly different than the expected profit from using a
1-year cert. Since it's the expected profit that determines the risk of
attack (the higher the expected profit, the higher the risk),
(Note that the above is an oversimplification. For one thing, 10-year
certs are typically sold at a discounted per-year price; e.g., a 10-year
cert might only be 7 times the price of a 1-year cert rather than 10
times that price. However at the same time, from the attacker's point of
view a gain received 5 or 10 years from now is worth less than a gain
received in the next year, and so the expected gain has to be discounted
appropriately as well. Without doing the detailed math I expect that
these two effects will roughly cancel out, and the expected profit in
present value terms will still be roughly the same.)
> My argument is with reasons and within accepted boundaries of domain
> validated certificates. Again, certificates with somewhat longer
> validity should be handled accordingly (with additional validations
> perhaps), but since domain validation is already the *lowest barrier* of
> entry, they should be controlled accordingly with a *reasonable limited
> validity*. Ten years is NOT reasonable! It borders on intent and gross
> negligence!
As I wrote above, I think there are good reasons for limiting the
lifetime of certificates (DV or otherwise), and there are also other
mechanisms by which CAs could offer multi-year discounts (for example,
they could have subscribers pay up front for, say, a 10-year cert, and
then issue 1-year certs renewable without charge for the next nine years).
However as I've noted previously we don't specifically address cert
lifetimes in our current policy, and given the economics I'm not
convinced longer cert lifetimes in and of themselves drive up risk, at
least in terms of your proposed attack scenario.
Eddy Nigg (StartCom Ltd.)
>
> I don't disagree that in general CAs should limit cert lifetimes, for
> all sort of reasons.
as well. However I'm concentrating on the reason closest possible also
in relation to the Mozilla CA policy. Prevention of an MITM attack is
pretty much referenced in said policy.
> However I'm going to disagree with you here about
> the risk assessment.
> In the attack you're describing the attacker is basically betting on the
> possibility that a given domain name registered today (say, "foo.com")
> will be used by someone in the future. At that future time the attacker
> can do some DNS spoofing to redirect "foo.com" to his own site, which
> has a still-valid DV cert for "foo.com", issued to the attacker at some
> point in the past when the attacker controlled the domain. Thus the MITM
> protections of the DV scheme fail and the attacker is free to commit fraud.
>
> The price of the bet is the cost of registering the domain "foo.com" and
> getting a DV certificate for it. (There might be other costs as well,
> but for the purposes of this argument we can ignore them, since they
> won't change the overall result.) The expected gain from the bet is the
> typical amount realizable from attacking a real foo.com site, multiplied
> by the probability that the "foo.com" domain name will be reused.
> The expected profit is then the expected gain minus the cost.
>
credit cards), but also eavesdropping and acquiring information.
Breached privacy is a *LOSS* for the relying party and LOST trust in the
software upon which the relying party relies, which can't be measured by
a financial gain (profit) only.
> For example, suppose that the cost of the "foo.com" domain and a 1-year
> DV certificate for it is $30, and there's a 0.1% (0.001) probability
> that "foo.com" will be reused by someone else during the validity period
> of the certificate, and hence will be attackable in the manner
> described. If the amount realizable from an attack against "foo.com" is
> $50,000, then the expected gain from betting on "foo.com" ahead of time
> will be $50 ($50,000 times 0.001). The expected profit is then $20 ($50
> minus $30).
>
the eventual price of such an attack and apparently you seem to agree
that this attack vector is real and an MITM possible. It's just a
question of price and time. Nor is any expected profit anything you can
judge. Classified information is sometimes more valuable than you can
imagine. Your calculation is funny at best and I can turn it around just
as easily. There are domains available for less then 5 bucks and stolen
information more valuable than you and I can ever pay....
But seriously! I've never read in any CPS anywhere that the price of a
domain name (and a certificate for that matter) is a measure applied by
a CA. It's simply not a criteria a CA deals with, but measures such as
checks on domain name ownership, validity period of the domain name
(identity validation for higher validated certificates), re-validation
and limitation of the certificate lifetime etc are.
> How does this analysis change if the cert has a longer validity period?
>
Very obviously, a domain name can literally not be used again for any
serious purpose if there is the potential of a valid and legitimate
certificate in the hands of a previous owner (and potential attacker).
Please read this sentence twice, three times load ;-)
> Clearly the probability of the domain "foo.com" being reused increases,
> and hence the expected gain. (For example, we can assume as a first
> approximation that the probability of "foo.com" being reused over a
> 10-year period is ten times the probability of it being reused in the
> first year.) However the cost also increases (since 10-year certs cost
> more than 1-year certs), and roughly in the same proportion. Thus the
> expected profit associated using a 10-year certificate for this attack
> is not significantly different than the expected profit from using a
> 1-year cert. Since it's the expected profit that determines the risk of
> attack (the higher the expected profit, the higher the risk),
>
No, your argument doesn't stick! The costs are not a hurdle nor do you
have any clues about the potential damage. (it doesn't matter which
warranties a CA gives you (in the case of this CA absolutely none -
nada), the potential damage to breached privacy isn't something we can
value in terms of money, but is a loss in the trust we are trying to
build and sustain)
However a certificate with a lifetime of ten years in the hands of a
party not owning the domain name is a potential threat for TEN LONG
YEARS to the current owner and the visitors of that site. Not only is
the potential of this domain name being acquired during that time
ten-fold and multiplied, the window of opportunity is wide open compared
to a certificate with a lifetime of one year only with. The attacker can
act at will, without pressure in time plan the attack carefully, wait
for the best opportunity and decide when he will gain most.
But most important, this is a constant unlimited threat which no one
knows when this threat is going to strike. This is a very uncomfortable
situation for a domain holder and his visitors, it's even worse for
Mozilla as a relying party to know, that there are right now
certificates out there in the hands of the wrong people!!!!
> As I wrote above, I think there are good reasons for limiting the
> lifetime of certificates (DV or otherwise), and there are also other
> mechanisms by which CAs could offer multi-year discounts (for example,
> they could have subscribers pay up front for, say, a 10-year cert, and
> then issue 1-year certs renewable without charge for the next nine years).
>
I absolutely agree with you and some CAs are apparently doing exactly that.
> However as I've noted previously we don't specifically address cert
> lifetimes in our current policy, and given the economics I'm not
> convinced longer cert lifetimes in and of themselves drive up risk, at
> least in terms of your proposed attack scenario
It has nothing to do with economics, but a lot to do with the knowledge
that when I visit a web site with Firefox which has a legitimate
certificate, that the site I'm visiting belongs to the right guy. This
is what DV certs are all about, this is what they guaranty and this is
the lowest barrier and condition of the Mozilla CA policy.
- As a member of this team
- and as a user and relying part of this software
- and as a distributor of this software
- and as an operator of a CA which has its root in this software...
...I have to insist that Mozilla makes sure to a reasonable extend that
users of its software receive the legitimate and basic right to privacy
and security in relation to digital certification. With domain validated
certificates with a validity of up to ten years without being
re-validated, this basic right can't be guarantied (and not even
reasonable assumed).
Frank Hecker
> credit cards), but also eavesdropping and acquiring information.
> Breached privacy is a *LOSS* for the relying party and LOST trust in the
> software upon which the relying party relies, which can't be measured by
> a financial gain (profit) only.
I understand what you're saying, but in the end we have to weight
security risks in some way, and using an economic analysis is IMO a
reasonable way to do that. To say that you can't put a price on
something is in essence to stop discussion and foreclose analysis. We
implicitly put a price on stuff like breached privacy and lost trust all
the time, by saying that certain measures to protect privacy and
maintain trust are worth the investment and others are not. If privacy
and trust were truly priceless then we would be obligated to spend as
much money as possible to protect them, to the exclusion of any other
considerations.
> Frank, first of all your argument is lame, because you are talking about
> the eventual price of such an attack and apparently you seem to agree
> that this attack vector is real and an MITM possible.
Is it a conceivable attack? Yes. Is it a likely attack? It's hard to
tell; it's not one that to my knowledge has ever been encountered. But
IMO if this attack ever does occur with measurable frequency and become
a serious threat in actuality (not just in theory) it will be because it
is profitable for someone. That's why I feel justified in looking at
this from an economic point of view.
But I would note that to the extent that "this attack vector is real and
an MITM possible", this is the case for any DV certs, even 1-year certs.
> It's just a
> question of price and time. Nor is any expected profit anything you can
> judge.
Strictly speaking I don't need to judge the profit; I just need to judge
the probability and the cost. My point is that as the cert lifetime
grows longer, the probability of an attack (and thus any expected
economic gain from it) increases along with it, but the cost of an
attack increases roughly in proportion, since the attacker would need to
purchase more expensive certs. This implies that the expected profit in
both cases is roughly the same, independent of what that actual profit
number happens to be.
> But seriously! I've never read in any CPS anywhere that the price of a
> domain name (and a certificate for that matter) is a measure applied by
> a CA.
You're correct, the price of a certificate has nothing to do with the
function of a CA and how it goes about its business. However the price
of a cert is quite relevant to the analysis of potential attacks. To use
an extreme example, if obtaining an SSL cert cost at least $100,000 then
there probably wouldn't be many attacks in real-life involving attackers
purchasing certs. They'd find cheaper ways to attack systems.
> Very obviously, a domain name can literally not be used again for any
> serious purpose if there is the potential of a valid and legitimate
> certificate in the hands of a previous owner (and potential attacker).
> Please read this sentence twice, three times load ;-)
I have indeed read it, now please read this in return :-) As long as
domain names can be re-registered to different owners, there is always
this potential to some degree. It doesn't matter whether the cert
lifetime is 10 years, 1 year, or 1 week. If I purchase a domain name
today, it's possible that someone registered this domain a few days ago,
got a cert for it, returned the domain name for a refund, and is now
ready to attack. Thus if we take your statement literally then the
implication is that we should never use a DV cert with any domain
whatsoever, period, full stop.
> It has nothing to do with economics, but a lot to do with the knowledge
> that when I visit a web site with Firefox which has a legitimate
> certificate, that the site I'm visiting belongs to the right guy. This
> is what DV certs are all about, this is what they guaranty and this is
> the lowest barrier and condition of the Mozilla CA policy.
And I'm telling you that if we take your argument at face value then
there is no absolute guarantee, because this attack is theoretically
possible for any cert lifetime longer than a day or so. So we have to
fall back on judging relative risk, and that is what I've been trying to
do in my analysis.
Frank
Eddy Nigg (StartCom Ltd.)
Sorry that I'm relying to you only now.
Robin Alden:
>> The behavior of Comodo in this respect is really surprising! Supposed
>> you would issue certificates with longer validity only to entities which
>> were thorough verified and validated, I could offer some understanding.
>> But by issuing *domain validated* certificate for up to *ten years*,
>> without revalidation is completely irresponsible and borders on gross
>> negligent.
>>
>>
> [Robin said...]
> I disagree. With a DV certificate the only thing that we are warranting is
> that the key holder controls the domain.
Between us, even this isn't true exactly , or at least I'm not sure if
your CA warrants anything in the domain validated settings... But this
isn't the point at all, but the fact, that your certificates are issued
for a very long time without re-validating and confirming continued
ownership of the domain name. This is the problem here.
>
>>
>> The risk exists and I gave a real show-case to a reply to Frank
>> yesterday (most likely you've read it too). If this is made possible,
>> than why validate a domain at all? As you agreed with me, there is a
>> risk of fraud, it just requires somewhat more patience and money for a
>> sophisticated attacker, but detection is accordingly also much more
>> difficult. And it defeats the very purpose of domain validated
>> certificates.
>>
> [Robin said...]
> Fraud how? For DV, we validate domain control.
Let me explain as I continue to answer below...
> If a company goes bust and
> passes the domain on to someone else then that new person could get a DV
> certificate for the domain.
You seem to ignore the fact, that the original owner of the domain name
still holds a certificate with a validity of potentially close to ten
years. The previous owner can at will perform a MITM attack with a
completely legitimate certificate.
> Or are you suggesting that the risk you are addressing is of someone
> choosing a defunct domain with a Comodo DV certificate (that we did not
> become aware of and revoke)
Yes, and the new owner of this web site and the visitors of this web
site can fall victim to an MITM attack.
> and getting hold of the private key of the
> certificate from a server (from ebay or by theft or whatever) and then using
> that certificate to mount a man-in-the-middle attack on the new owners of
> the domain?
>
No, it has nothing to do with a key compromise.
> Why go to that effort? DV certificates are easy to get. That is a valid
> criticism against DV.
>
I'm absolutely not against domain validated certificates and they have a
rightful place in the landscape of this infrastructure. However I'm
completely against issuance of domain validated certificates to any
longer period which isn't reasonable and beyond the expected ownership
period of said domain name.
> DV products exist today - that is a fact. The browsers (in this case
> Mozilla) have been content for us to issue DV certificates. Sure, a longer
> duration certificate carries higher risk than a short one.
Thank you for confirming this.
> We'd also accept
> that a wildcard carries somewhat more risk than a single domain certificate,
> but where is the line to be drawn?
>
I'll be glad to evaluate this line together with you and other members
of this community. I have drawn my line and provided a concrete
proposal. We may discuss this and find the best solution for all.
> Also, why draw the line retrospectively and at this moment in time?
Because your CA is a candidate for inclusion and upgrade into the NSS
store and as a matter of fact re-evaluated as if your CA never had any
roots in NSS (See this comment in the bug entry:
https://bugzilla.mozilla.org/show_bug.cgi?id=401587#c20
If we don't speak up now, we can't blame anybody else later.
> Should Mozilla's policy on this not be published and clear for us to follow, rather
> than ad-hoc?
>
The Mozilla CA policy is clear in that respect in various points,
starting with the first paragraph:
1. We will determine which CA certificates are included in software
products distributed through mozilla.org, *based on the benefits
and risks of such inclusion to typical users of those products.*
2. We will make such decisions through *a public process*, based on
objective and verifiable criteria as described below.
3.
4. We reserve the right to not include a particular CA certificate in
our software products, to discontinue including a particular CA
certificate in our products, /or/ to modify the "trust bits" for a
particular CA certificate included in our products, at any time
and for any reason. This includes (*but is not limited to*) cases
where we believe that including a CA certificate (or setting its
"trust bits" in a particular way) *would cause undue risks to
users' security*, for example, with CAs that
Further at section 6:
* prior to issuing certificates, verify certificate signing requests
in a manner that we deem acceptable for the stated purpose(s) of
the certificates;
* otherwise operate in accordance with published criteria that we
deem acceptable
The other sections go into some more details. Additionally there is the
objective of this policy as explained in the initial sections to prevent
undue risk to the users security.
I agree with you that we can and should refine the Mozilla CA policy to
some extend, something which has been done already once (to allow EV
upgrades) and to all of my knowledge we at Mozilla will work on that as
soon as possible and if necessary (Frank, is that correct?)
>
>
> [Robin said...]
> It is in our interest to know about as many SSL protected domains out there
> on the internet as possible. We do actively look for them.
> The snag is that with wildcard domains there really are an awful lot of
> possibilities to search for. We are looking for needles in haystacks. If
> we could get a zone transfer for the DNS server hosting domain.com (to pick
> up all the existing sub-domains) then our life would be made simple and we
> would certainly check them all, but that just doesn't work.
>
Robin, I'm glad that it's *you* who made this statement and I couldn't
have it formulated better - I absolutely agree with you. And *exactly
because of that*, wild card certificates should (must) be at least
identity validated. Because CAs can't control wild card certificates in
the same way as regular certificates and because of the "card blanche"
this certificates offer to the subscriber, a CA must implement
additional measures beyond merely validating the domain name (for
example by validating the identity of the subscriber).
>
>> Which I never, ever suggest at all. However I would expect that Comodo
>> does perform additional steps, to ensure that misuse of wild card
>> certificates is prevented, or at least the risk lowered. This can be
>> done by validating the identity of the subscriber for example. You may
>> find other effective ways for doing the same. I'd be glad to learn about
>> any implementation of your CA in regards lowering the risk for wild card
>> certificates.
>>
> [Robin said...]
> I agree that wildcard certificates are somewhat higher risk than single
> domain certificates.
>
Thanks!
> We are always looking for ways to improve our products, but we are also
> influenced by commercial considerations in this matter.
>
Sure, I understand that, but it can't be the only consideration. For
Mozilla and its users, the relying party matters most. It should be in
your interest too.
> We could perform EV validation for every DV certificate we sold.
No, I believe this to be an overkill. Proper domain validation for
regular certificates are sufficient, for wild card certificates regular
identity validation as you perform already at your CA should be
sufficient too in my opinion.
> I know you want us to ignore what everyone else does, but commercially it
> would not make sense for us to pull out of that particular market segment
> and leave it to a competitor.
>
No, I never suggested that nor would I do that...
> Don't block us as an individual CA.
This is not the intention of Mozilla or me! I suggest that we work
together on solving the issues which came up with your request
> Publish (as Mozilla) a list of policies we must follow.
Yes.
> Also, apply those policies across the board.
>
Absolutely! More than that, I suggest to you (and any other interest
party) to join that effort. If you know about CAs which present the same
risk as your CA does currently (in my point of view), than provide that
information. It will help us at Mozilla to better evaluate the situation
and help us to improve the software in relation to SSL certificates.
> If you were to block one CA but allow other CAs in to the root program which
> operate the same policy the blocked CA must take some action to defend its
> market position. What would you have that be?
>
No way! Only in case said CA simply doesn't conform to the Mozilla CA
policy and isn't willing to make the required adjustments, said CA can
not be included. I agree with you that this must be evenly applied.
>
>
>> About which I agree with you. Non-EV and wild card certificates are an
>> important part of existing PKIs, however you also bear a responsibility!
>> Considering that you claim to be #2 in this industry, you aren't doing a
>> great service to our industry nor can I see how your CA is actively
>> trying to improve the standing and security of PKI in general, and for
>> Mozilla and its users in particular.
>>
> [Robin said...]
> We are a commercial CA. We are driven by two forces.
> On one side there are the requirements of the Browser (& OS) platforms.
> E.g. They say we must be webtrust for CAs compliant (or equivalent) so we
> are. If there are other published requirements we will follow them - or
> expect not to have our roots embedded if we do not follow them.
>
Excellent!
> On the other hand there is the commercial pressure on us to compete in the
> market place. We cannot drop ranges of products that are offered by our
> competitors. We agree that the SSL products out there need to be improved,
> but that improvement must come across the board
I agree with you!
> Likewise the old standards (such as DV) must, in an ideal world, be phased
> out
No, as I said previously, DV certs have their rightful place and are
excellent for the intended purpose. But we must also do that with
responsibility and take into consideration its limitations. Issuing such
certificates for up to ten years without re-validating and/or wild card
certificates without any additional verifications are irresponsible
actions in my opinion. Specially the former.
> I appreciate that Mozilla is at
> liberty to make any decisions on it's CA acceptance policy that it sees fit,
> but again the policies should be clear and stated in advance. Persuasion
> and cajoling to change standards or withdraw products should not need to
> happen at the level of an individual CA's application to have a root
> certificate embedded (or its trust status changed).
>
There are things which the current CA policy doesn't cover explicitly,
but in more general formulation. Supposed tomorrow a CA introduces a
scheme about which the editors of the Mozilla CA policy haven't thought
about, but pose a potential risk to Mozilla and its users, I would take
care to make the community aware of the problem and have this evaluated
accordingly.
This makes perfect sense in my opinion.
> [Robin said...]
> It covers anything and everything that they feel (OR we feel) is relevant to
> WebTrust.
> Do we operate a green disposal policy for recyclable materials? - Yes.
> Is that examined by the auditors? - No, because WebTrust does not address
> it.
>
>
OK!
>
> [Robin said...]
> You are missing a lot of information that is available to the auditors.
> Much of the information about the structure of our business is kept out of
> the public domain. You won't find our organization chart on our website.
> You won't find network diagrams there either.
> We are a commercial organization and we are not a public company. We share
> the information with our auditors, they issue us with a statement of
> compliance to the standards we are required to achieve. Exactly the same
> type of thing happens with a financial audit. The Auditor does not document
> everything he knows about the company, he examines all the available (to
> him) information and makes statements about that information. Those
> statements are made available to 3rd parties, but the underlying information
> remains confidential.
>
Which is as expected and perfectly acceptable. My question however was,
if your auditor could confirm all the locations to which the audits
apply? Since you operate at various locations, I'd like to know if the
audit covers all your operations at all locations or not.
I think this is something about which we need to gather more information
in every respect. I'm certain that if this is confirmed to be a problem,
we'll have the possibility to find a common understanding and approach
this accordingly. I'm not sure why you think that you can't change the
common name. Apparently the key pairs could be reused, but the
certificates content changed - the very purpose of such an exercise. But
there could be more ideas on solving it and I think we can invest the
needed time to approach this correctly, should such a decision be taken.
>
>
>> What is this timescale? Current + ten years? (I guess not, but what does
>> it really mean?)
>>
> [Robin said...]
> No, not 10 years. I can't disclose the figure without checking with our
> board, but it is a conservative figure which offers some benefit to us in
> the level of reduction of validation effort while limiting the risk to the
> validation process. It is a figure which is discussed each year with our
> auditors and they have never raised it as a matter of concern.
>
I think this answer satisfies my question.
Eddy Nigg (StartCom Ltd.)
replies....last try....
Frank Hecker:
> I understand what you're saying, but in the end we have to weight
> security risks in some way, and using an economic analysis is IMO a
> reasonable way to do that. To say that you can't put a price on
> something is in essence to stop discussion and foreclose analysis. We
> implicitly put a price on stuff like breached privacy and lost trust all
> the time, by saying that certain measures to protect privacy and
> maintain trust are worth the investment and others are not. If privacy
> and trust were truly priceless then we would be obligated to spend as
> much money as possible to protect them, to the exclusion of any other
> considerations.
>
Yes, yes and yes, everything should be *reasonable*!
>
>> Frank, first of all your argument is lame, because you are talking about
>> the eventual price of such an attack and apparently you seem to agree
>> that this attack vector is real and an MITM possible.
>>
>
> Is it a conceivable attack? Yes. Is it a likely attack?
I'm not sure, but it's a threat which exist for a very long time in this
case. This is my problem here. The threat doesn't diminish after a
*reasonable* amount of time. The same you might ask about MITM attacks
in general. I can't point to any I know about, but we know it's possible
and that's why we are all here.
> But I would note that to the extent that "this attack vector is real and
> an MITM possible", this is the case for any DV certs, even 1-year certs.
>
Yes, but the threat declines after one year. This is a *reasonable*
amount of time and something controllable to some extend.
> Strictly speaking I don't need to judge the profit; I just need to judge
> the probability and the cost. My point is that as the cert lifetime
> grows longer, the probability of an attack (and thus any expected
> economic gain from it) increases along with it, but the cost of an
> attack increases roughly in proportion, since the attacker would need to
> purchase more expensive certs.
Until a CA decides to issues such certificate for said period without an
increase in price - and than what? Which risk assessment is now correct?
> You're correct, the price of a certificate has nothing to do with the
> function of a CA and how it goes about its business. However the price
> of a cert is quite relevant to the analysis of potential attacks. To use
> an extreme example, if obtaining an SSL cert cost at least $100,000 then
> there probably wouldn't be many attacks in real-life involving attackers
> purchasing certs. They'd find cheaper ways to attack systems.
>
LOL
Yes you are right in this respect and I wouldn't worry that much about
the lifetime of such a certificate :-)
>
>> Very obviously, a domain name can literally not be used again for any
>> serious purpose if there is the potential of a valid and legitimate
>> certificate in the hands of a previous owner (and potential attacker).
>> Please read this sentence twice, three times load ;-)
>>
>
> I have indeed read it, now please read this in return :-) As long as
> domain names can be re-registered to different owners, there is always
> this potential to some degree. It doesn't matter whether the cert
> lifetime is 10 years, 1 year, or 1 week. If I purchase a domain name
> today, it's possible that someone registered this domain a few days ago,
> got a cert for it, returned the domain name for a refund, and is now
> ready to attack. Thus if we take your statement literally then the
> implication is that we should never use a DV cert with any domain
> whatsoever, period, full stop.
>
Yes Frank you are right, but I have the feeling that I'm failing to
bring the correct message over to you...
A threat for the period of one week is something one can take into
consideration and handle. Even the period of one year of such a threat
might be *reasonable*. But the same thread for ten years is not. Me, as
the new domain name owner, can circumvent and plan accordingly if such
certs are limited to a *reasonable* validity. I can't handle ten years.
>
> And I'm telling you that if we take your argument at face value then
> there is no absolute guarantee, because this attack is theoretically
> possible for any cert lifetime longer than a day or so. So we have to
> fall back on judging relative risk, and that is what I've been trying to
> do in my analysis.
>
>
Yes, we agree on that completely. That's why I'm asking for something
which is *reasonable*. Ten years of domain validated certs are not
*reasonable*.
Robin Alden
> >> without revalidation is completely irresponsible and borders on
> gross
> >> negligent.
> >>
> > [Robin said...]
> > I disagree. With a DV certificate the only thing that we are
> warranting is
> > that the key holder controls the domain.
>
> Between us, even this isn't true exactly , or at least I'm not sure if
> your CA warrants anything in the domain validated settings... But this
> isn't the point at all, but the fact, that your certificates are issued
> for a very long time without re-validating and confirming continued
> ownership of the domain name. This is the problem here.
>
It seems to boil down to this question.
Q1) What is the maximum duration of certificate of each type in question
that Mozilla's policy accepts?
> > Why go to that effort? DV certificates are easy to get. That is a
> valid
> > criticism against DV.
> >
>
> I'm absolutely not against domain validated certificates and they have
> a
> rightful place in the landscape of this infrastructure. However I'm
> completely against issuance of domain validated certificates to any
> longer period which isn't reasonable and beyond the expected ownership
> period of said domain name.
[Robin said...]
See Q1.
>
> > DV products exist today - that is a fact. The browsers (in this case
> > Mozilla) have been content for us to issue DV certificates. Sure, a
> longer
> > duration certificate carries higher risk than a short one.
>
> Thank you for confirming this.
>
> > We'd also accept
> > that a wildcard carries somewhat more risk than a single domain
> certificate,
> > but where is the line to be drawn?
> >
>
> I'll be glad to evaluate this line together with you and other members
> of this community. I have drawn my line and provided a concrete
> proposal. We may discuss this and find the best solution for all.
[Robin said...]
Sure, so we need a documented answer for Q1.
> > Also, why draw the line retrospectively and at this moment in time?
>
> Because your CA is a candidate for inclusion and upgrade into the NSS
> store and as a matter of fact re-evaluated as if your CA never had any
> roots in NSS (See this comment in the bug entry:
> https://bugzilla.mozilla.org/show_bug.cgi?id=401587#c20
>
> If we don't speak up now, we can't blame anybody else later.
>
[Robin said...]
A fair point, and perhaps that is a whole other problem. Our CA *does* have
roots in NSS.
Is this:
a) an abstract discussion to help Mozilla crystallize the details of its CA
policy,
b) a discussion about what changes to CA behaviour Mozilla would like to see
(and may insist on) from some point in time, or
c) a trial to determine whether our CAs should be removed from Mozilla
products?
We have certainly strayed from my point of entry into this process which was
to ask to have these 3 existing roots enabled for EV.
> > Should Mozilla's policy on this not be published and clear for us to
> follow, rather
> > than ad-hoc?
> >
>
> The Mozilla CA policy is clear in that respect in various points,
> starting with the first paragraph <snip>
>
> The other sections go into some more details. Additionally there is the
> objective of this policy as explained in the initial sections to
> prevent undue risk to the users security.
>
> I agree with you that we can and should refine the Mozilla CA policy to
> some extend, something which has been done already once (to allow EV
> upgrades) and to all of my knowledge we at Mozilla will work on that as
> soon as possible and if necessary (Frank, is that correct?)
>
[Robin said...]
The CA Policy is there, I agree, but I think we meet the objective criteria
it provides. "Preventing undue risk" sounds subjective to me.
>
> >
> >
> > [Robin said...]
> > It is in our interest to know about as many SSL protected domains out
> there
> > on the internet as possible. We do actively look for them.
> > The snag is that with wildcard domains there really are an awful lot
> of
> > possibilities to search for. We are looking for needles in
> haystacks. If
> > we could get a zone transfer for the DNS server hosting domain.com
> (to pick
> > up all the existing sub-domains) then our life would be made simple
> and we
> > would certainly check them all, but that just doesn't work.
> >
>
> Robin, I'm glad that it's *you* who made this statement and I couldn't
> have it formulated better - I absolutely agree with you. And *exactly
> because of that*, wild card certificates should (must) be at least
> identity validated. Because CAs can't control wild card certificates in
> the same way as regular certificates and because of the "card blanche"
> this certificates offer to the subscriber, a CA must implement
> additional measures beyond merely validating the domain name (for
> example by validating the identity of the subscriber).
>
[Robin said...]
So you suggest we may not issue wildcard DV certificates. It is at least a
concrete point for discussion. Which of the "objective and verifiable
criteria" in the CA Policy does wildcard DV fail to meet?
That gives us:
Q2) Are wildcard DV certificates permitted?
> > Publish (as Mozilla) a list of policies we must follow.
> Yes.
>
> > Also, apply those policies across the board.
> >
>
> Absolutely! More than that, I suggest to you (and any other interest
> party) to join that effort. If you know about CAs which present the
> same
> risk as your CA does currently (in my point of view), than provide that
> information. It will help us at Mozilla to better evaluate the
> situation
> and help us to improve the software in relation to SSL certificates.
[Robin said...]
Surely this should be a discussion about whether we meet Mozilla's policy.
Unless you are proposing a public beauty competition between the CAs with a
view to knock out the bottom few? We are confident we won't come last.
>
> > If you were to block one CA but allow other CAs in to the root
> program which
> > operate the same policy the blocked CA must take some action to
> defend its
> > market position. What would you have that be?
> >
>
> No way! Only in case said CA simply doesn't conform to the Mozilla CA
> policy and isn't willing to make the required adjustments, said CA can
> not be included. I agree with you that this must be evenly applied.
>
[Robin said...]
We are driven by commercial considerations (as well as by higher motives
:-)) to follow the requirements of the major browser/OS platforms, including
Mozilla. We have no wish to do anything that does not follow the Mozilla CA
policy. I think we will always try to drive Mozilla to document that policy
sufficiently precisely that our compliance with it may be judged by us
before we even present something for judgement by Mozilla.
> > Likewise the old standards (such as DV) must, in an ideal world, be
> phased
> > out
>
> No, as I said previously, DV certs have their rightful place and are
> excellent for the intended purpose. But we must also do that with
> responsibility and take into consideration its limitations. Issuing
> such
> certificates for up to ten years without re-validating and/or wild card
> certificates without any additional verifications are irresponsible
> actions in my opinion. Specially the former.
>
[Robin said...]
Q1) What is the maximum duration of certificate of each type in question
that Mozilla's policy accepts?
Q2) Are wildcard DV certificates permitted?
> > I appreciate that Mozilla is at
> > liberty to make any decisions on it's CA acceptance policy that it
> sees fit,
> > but again the policies should be clear and stated in advance.
> Persuasion
> > and cajoling to change standards or withdraw products should not need
> to
> > happen at the level of an individual CA's application to have a root
> > certificate embedded (or its trust status changed).
> >
>
> There are things which the current CA policy doesn't cover explicitly,
> but in more general formulation. Supposed tomorrow a CA introduces a
> scheme about which the editors of the Mozilla CA policy haven't thought
> about, but pose a potential risk to Mozilla and its users, I would take
> care to make the community aware of the problem and have this evaluated
> accordingly.
>
> This makes perfect sense in my opinion.
[Robin said...]
Sure, but those are the reasons to update your CA policy. Mozilla defines
its policy. We follow the policy. My interest here (I think) is to get a
judgement as to whether we follow the policy.
> > [Robin said...]
> > You are missing a lot of information that is available to the
> > auditors.
<snip>
> Which is as expected and perfectly acceptable. My question however was,
> if your auditor could confirm all the locations to which the audits
> apply? Since you operate at various locations, I'd like to know if the
> audit covers all your operations at all locations or not.
>
[Robin said...]
I'm happy to state that the audit does cover all of the locations which are
involved in our CA operations.
Comodo CA Limited does a few things other than run a CA, and those non-CA
activities are not covered by the "WebTrust for CAs" audit.
I'm sure the auditors could confirm that too, if I asked them to, and they
would be very happy to send me the bill for doing so.
[Robin said...]
We can't change the common name because the common name occurs (as the
issuer name) in every certificate issued by the CA. If they don't match
then the certificate chain won't show as being trusted. (That's
implementation dependant, but it's a good 1st order approximation.) As you
suggest, there will be ways around it, but I think they all involve
retaining the original CA certificate as a trust anchor.
I think that's looking like Q3:
Q3) Is it Mozilla's policy to remove root CA certificates from its products
where the subject information in the certificate no longer accurately
reflects the legal owner of the CA?
Regards
Robin
Eddy Nigg (StartCom Ltd.)
procedural matters and let me ask you a few questions:
- We are not seeking to cause any harm to Comodo or unilaterally remove
the roots from NSS. However can we seek the cooperation on the issues
which were raised and is Comodo willing to address this issues in good
faith?
- Apparently you agree that the major issues we've raised, indeed pose a
higher risk to the relying parties. Can we work together in order to
improve your products to the extend that both sides can live with it and
based on reasonable terms? This would improve the overall quality of all
certificates issued by CAs which are included in NSS, which would result
in further strengthening of digital certification in general and in
Mozilla software in particular. It would improve also your standing in
this industry!
- Any conclusions through this process and any update to the Mozilla CA
policy would be evenly applied upon all CAs included in NSS.
Additionally, other software vendors, most notably Microsoft could adopt
them as well, resulting in a major improvement of our industry. Under
this condition, would you be willing to seriously address the issues,
make and amend changes to your CPS and implement the changes at your CA?
The issues which should be addressed are certificates with a longer
validity and domain validated wild card certificates. I would like to
make the following suggestions, that
- domain validated certificates which are valid for more than 24 month,
must be re-validated every year thereafter (starting after 24 month).
Should revalidation fail, the certificate shall be suspended until the
subscriber has done so successfully or revoked. This would leave your
product intact and you could continue to issue them as you do today,
however would introduce additional validations during the life time of
the certificate.
- domain validated wild card certificates would undergo an additional
identity validation. The certificates content itself doesn't have to be
changed compared to what you do today (if you prefer), but you would
guaranty through your CPS that you perform this additional validation.
Are these suggestions reasonable in your point of view and would this be
acceptable to the management of Comodo? Could Comodo commit and agree to
such an implementation, provided that this will be evenly applied upon
all CAs currently in NSS? If not, can you please provide an alternative,
solving the issues at hand and explain what Comodo would be willing to
implement instead?
Eddy Nigg (StartCom Ltd.)
Robin Alden:
> [Robin said...]
> A fair point, and perhaps that is a whole other problem. Our CA *does* have
> roots in NSS.
>
This is correct. However your CA roots are considered legacy roots which
were inherited from the Netscape era. Many critics have rightly pointed
to the fact, that these legacy roots never underwent a review nor proper
inclusion process. This is the reason why Frank made your request for
upgrade conditional and a general inclusion request as if this were new
roots. Your CA doesn't enjoy immunity because you have these legacy
roots in NSS, nor does any other CA have that privilege, no matter if
legacy or not.
> Is this:
> a) an abstract discussion to help Mozilla crystallize the details of its CA
> policy,
>
No! Mozilla does have a CA policy and defined procedures on how CAs are
included into NSS. This also includes a public discussion where relevant
issues with the "to-be-included" CA can be raised. I made use of this
right and raised my objection to the inclusion of your CA into NSS under
the current circumstances. No decision has been made so far however.
> b) a discussion about what changes to CA behaviour Mozilla would like to see
> (and may insist on) from some point in time, or
>
No! Mozilla has the right to not include a particular CA certificate in
its software products, to discontinue including a particular CA
certificate in its products, /or/ to modify the "trust bits" for a
particular CA certificate included in its products, *at any time and for
any reason*. This includes (but is not limited to) cases where we
believe that including a CA certificate would cause *undue risks to
users' security*...
(c) Copyright of the Mozilla CA policy
> c) a trial to determine whether our CAs should be removed from Mozilla
> products?
>
No, it's the process of considering the inclusion of your CA roots and
upgrade to EV status. This is not a trial, as Mozilla has refused the
inclusion of CAs already entirely in the past or made the inclusion
conditional to certain aspects to their CPS and implementation. It has
nothing to do with your CA per se, this is due process of the inclusion
process.
> We have certainly strayed from my point of entry into this process which was
> to ask to have these 3 existing roots enabled for EV.
>
See above (first section) why this isn't the case! Additionally, to all
of my knowledge, other CAs had to undergo the very same process as well
and your situation isn't unique!
Paul Hoffman
>- We are not seeking to cause any harm to Comodo or unilaterally remove
>the roots from NSS. However can we seek the cooperation on the issues
>which were raised and is Comodo willing to address this issues in good
>faith?
Why just Comodo? They are not the only CA that has some of the
features that you seem to dislike, Eddy.
At the very minimum, changing the subject line of the thread would
make it clear that the discussion is about a consideration of
changing the rules for everyone, not just Comodo.
Frank Hecker
>
> Robin Alden:
>> [Robin said...] A fair point, and perhaps that is a whole other
>> problem. Our CA *does* have
>> roots in NSS.
>>
>
> This is correct. However your CA roots are considered legacy roots which
> were inherited from the Netscape era. Many critics have rightly pointed
> to the fact, that these legacy roots never underwent a review nor proper
> inclusion process. This is the reason why Frank made your request for
> upgrade conditional and a general inclusion request as if this were new
> roots. Your CA doesn't enjoy immunity because you have these legacy
> roots in NSS, nor does any other CA have that privilege, no matter if
> legacy or not.
I don't have time to respond to each and every point in this whole
discussion, but I did want to respond to this one. As Eddy notes, we
have a lot of roots in Mozilla that were inherited from the old Netscape
days. We now have a formal policy by which we evaluate requests from new
CAs, including new CAs issuing EV certs, and I thought it was unfair to
evaluate only new CAs and forever exempt old CAs from similar scrutiny.
Thus as the opportunity arises I've been trying to go back and look at
old roots. Requests by various CAs to enable old roots for EV use
presented just such an opportunity to not just look at the EV-related
aspects of the CAs but also to review how other aspects of the CAs
stacked up vis-a-vis our CA policy, and let people in the Mozilla
community (which means potentially anyone) to make comments and
suggestions relating to particular CA requests. This is just the way we
work; we're not Microsoft or Apple, we're a public project and we have
public processes.
Doing such reviews and allowing such comments does not imply that I'm
going to be pulling old roots out of NSS and Firefox. It also does not
imply that I'm going to hold up EV-related requests until CAs address
all comments and adopt all suggestions, or until we decide whether our
policy needs revising and how to revise. This is particularly true where
the issues involve CA practices related to non-EV certs, since those
issues will not be affected one way or another by our enabling CAs for EV.
However I think it's perfectly reasonable for us (Mozilla in general) to
formally call out CA practices that may not be explicitly addressed by
our policy, and that may not affect my decisions under the policy, but
that we consider to be problematic in one way or another, and to
publicly encourage CAs to modify them in various suggested ways. Issuing
long-lived DV certs and wildcard DV certs may be particular practices
worth our having some formal positions on, even if they're not addressed
by our official policy.
Frank
Robin Alden
>
> However I think it's perfectly reasonable for us (Mozilla in general)
> to
> formally call out CA practices that may not be explicitly addressed by
> our policy, and that may not affect my decisions under the policy, but
> that we consider to be problematic in one way or another, and to
> publicly encourage CAs to modify them in various suggested ways.
[Robin said...]
Fair enough. We welcome open discussions about these things, as I hope I
have demonstrated.
> Issuing
> long-lived DV certs and wildcard DV certs may be particular practices
> worth our having some formal positions on, even if they're not
> addressed
> by our official policy.
[Robin said...]
There I have to disagree to some degree.
You have a policy which tells us what we must do to qualify for root
inclusion.
Are you saying that you have some other things which aren't in the policy
which we must do too? We'd really rather they were included in your policy
- even if your policy just refers out to them.
A policy needs to be something I can examine as a whole, not something that
reveals - like a fractal - more complexity and detail every time I probe it.
Regards
Robin Alden
Comodo CA Limited
Robin Alden
>
> Robin Alden:
> > [Robin said...]
> > A fair point, and perhaps that is a whole other problem. Our CA
> *does* have
> > roots in NSS.
> >
>
> This is correct. However your CA roots are considered legacy roots
> which
> were inherited from the Netscape era. Many critics have rightly pointed
> to the fact, that these legacy roots never underwent a review nor
> proper
> inclusion process. This is the reason why Frank made your request for
> upgrade conditional and a general inclusion request as if this were new
> roots. Your CA doesn't enjoy immunity because you have these legacy
> roots in NSS, nor does any other CA have that privilege, no matter if
> legacy or not.
I never suggested we wanted immunity. I asked why you are only now defining
policy in this matter.
>
> > Is this:
> > a) an abstract discussion to help Mozilla crystallize the details of
> its CA
> > policy,
> >
>
> No! Mozilla does have a CA policy and defined procedures on how CAs are
> included into NSS. This also includes a public discussion where
> relevant
> issues with the "to-be-included" CA can be raised. I made use of this
> right and raised my objection to the inclusion of your CA into NSS
> under
> the current circumstances. No decision has been made so far however.
[Robin said...]
I acknowledge your right to discuss it and to raise objections, but surely
the discussion is to about whether we meet the criteria in the CA policy -
and perhaps going so far as to say what we must change so that we do meet
the criteria in the policy. Surely Mozilla has to publish its policy on
what its requirements are. I struggle to believe that Mozilla wants to
negotiate product details with every CA it takes roots from.
>
> > b) a discussion about what changes to CA behaviour Mozilla would like
> to see
> > (and may insist on) from some point in time, or
> >
>
> No! Mozilla has the right to not include a particular CA certificate in
> its software products, to discontinue including a particular CA
> certificate in its products, /or/ to modify the "trust bits" for a
> particular CA certificate included in its products, *at any time and
> for
> any reason*. This includes (but is not limited to) cases where we
> believe that including a CA certificate would cause *undue risks to
> users' security*...
>
> (c) Copyright of the Mozilla CA policy
[Robin said...]
Granted, but as a commercial organization Mozilla also has to apply the same
standards to all CAs. If you said that Mozilla embeds roots after
negotiation with the individual CA then that would be one thing, but the CA
policy says something different. Yes, you could discontinue a root for "any
reason", but if you do not apply the same reasoning to other CAs then you
lay yourself open to claims of unfairness. Surely you would incorporate
that "reason" into your CA policy for all to follow. If your objections are
not ones that are to be included in the CA policy then I have to question
the process as a whole.
>
> > c) a trial to determine whether our CAs should be removed from
> Mozilla
> > products?
> >
>
> No, it's the process of considering the inclusion of your CA roots and
> upgrade to EV status. This is not a trial, as Mozilla has refused the
> inclusion of CAs already entirely in the past or made the inclusion
> conditional to certain aspects to their CPS and implementation. It has
> nothing to do with your CA per se, this is due process of the inclusion
> process.
[Robin said...]
And it is the nature of the inclusion process that I am beginning to
question.
Your CA policy says "We will make such decisions [about inclusion] through a
public process, based on objective and verifiable criteria as described [in
the CA policy]".
>From my point of view outside Mozilla I read your CA policy and complied
with it.
Now you have some more criteria which aren't in the policy. That makes the
game considerably harder for me to prepare for.
>
> > We have certainly strayed from my point of entry into this process
> which was
> > to ask to have these 3 existing roots enabled for EV.
> >
> See above (first section) why this isn't the case! Additionally, to all
> of my knowledge, other CAs had to undergo the very same process as well
> and your situation isn't unique!
[Robin said...]
I disagree. We *have* strayed far from the starting point. Frank was clear
why he chose to treat our request as if it were for initial inclusion and I
can see his reasoning. It still leaves us a long way from where we thought
we started.
>From Frank's most recent reply I accept the reason for the consideration of
all aspects of our operation, but perhaps that separation should be made
more clear between those matters we are discussing here which are relevant
to the EV enabling of our roots within (what we hope to be) a short
timescale and those matters which pertain to the future direction of DV
which we are prepared to discuss but which are not intrinsically linked to
the EV issue.
Robin Alden
> procedural matters and let me ask you a few questions:
>
> the roots from NSS. However can we seek the cooperation on the issues
> which were raised and is Comodo willing to address this issues in good
> faith?
Mozilla, provided that the same standard applies at the same time to all
CAs.
>
> - Apparently you agree that the major issues we've raised, indeed pose
> a
> higher risk to the relying parties. Can we work together in order to
> improve your products to the extend that both sides can live with it
> and
> based on reasonable terms? This would improve the overall quality of
> all
> certificates issued by CAs which are included in NSS, which would
> result
> in further strengthening of digital certification in general and in
> Mozilla software in particular. It would improve also your standing in
> this industry!
[Robin said...]
I didn't agree that any of the issues you raised were major ones. I do
agree that there are a variety of levels of risk provided by the product
ranges we have discussed.
We are keen that levels of risk are reduced across the industry and we are
always happy to talk about how that can be achieved. I do not see how the
withdrawal or modification of some of our products in isolation accomplishes
that overall reduction in risk. Amend your policy so that it fully
expresses your requirements and then apply that policy to all CAs.
> - Any conclusions through this process and any update to the Mozilla CA
> policy would be evenly applied upon all CAs included in NSS.
[Robin said...] Excellent.
> Additionally, other software vendors, most notably Microsoft could
> adopt
> them as well, resulting in a major improvement of our industry. Under
> this condition, would you be willing to seriously address the issues,
> make and amend changes to your CPS and implement the changes at your
> CA?
[Robin said...] As I mentioned before, we are commercially obliged to have
our root CAs present in the major browser and OS platforms. In the absence
of other authority it is those browsers and OS platforms that set the
standards we have to follow. Since no single browser has the entire market
cornered we are obliged to meet the union of all of the standards set by all
of the browsers.
We are prepared to comply with Mozilla's CA Policy. We are prepared to
enter into and assist with discussions with Mozilla about changes they may
wish to make to their policy. We are also prepared to do the same with any
other commercially important Browsers and OS platforms.
>
>
> The issues which should be addressed are certificates with a longer
> validity and domain validated wild card certificates. I would like to
> make the following suggestions, that
>
> - domain validated certificates which are valid for more than 24 month,
> must be re-validated every year thereafter (starting after 24 month).
> Should revalidation fail, the certificate shall be suspended until the
> subscriber has done so successfully or revoked. This would leave your
> product intact and you could continue to issue them as you do today,
> however would introduce additional validations during the life time of
> the certificate.
>
> - domain validated wild card certificates would undergo an additional
> identity validation. The certificates content itself doesn't have to be
> changed compared to what you do today (if you prefer), but you would
> guaranty through your CPS that you perform this additional validation.
>
>
> Are these suggestions reasonable in your point of view and would this
> be
> acceptable to the management of Comodo? Could Comodo commit and agree
> to
> such an implementation, provided that this will be evenly applied upon
> all CAs currently in NSS? If not, can you please provide an
> alternative,
> solving the issues at hand and explain what Comodo would be willing to
> implement instead?
>
[Robin said...]
I'm not the first guy you need to get to agree that your suggestions are
reasonable.
Mozilla should amend its CA policy if it believes there is something that it
does not currently address and then apply that new policy to all CAs.
The proscription of SSL products, or of details of their implementation, is
something that should reasonably be discussed collectively with the CAs and
the browsers. Can I suggest that the CAB Forum would be one place in which
the matter could usefully be discussed? Mozilla is already able to propose
such matters for discussion there through Jonathan Nightingale.
Eddy Nigg (StartCom Ltd.)
> At 2:55 PM +0200 3/26/08, Eddy Nigg (StartCom Ltd.) wrote:
>
>> - We are not seeking to cause any harm to Comodo or unilaterally remove
>> the roots from NSS. However can we seek the cooperation on the issues
>> which were raised and is Comodo willing to address this issues in good
>> faith?
>>
>
> features that you seem to dislike, Eddy.
>
I didn't single out Comodo,considering the fact that other CAs have just
weeks ago gone through the same process. I have reviewed all other CAs
and raised questions and concerns concerning them if needed. At none of
the CAs I've encountered the things Comodo does and it's my duty to
speak up on this matter!
> At the very minimum, changing the subject line of the thread would
> make it clear that the discussion is about a consideration of
> changing the rules for everyone, not just Comodo.
>
I have already mentioned that an eventual change in the Mozilla CA
policy will have to be effective on all CAs. But I'd be really
interested to know which other CA does issue *DOMAIN* *VALIDATED*
certificate for a life-time of *TEN* years and also issues *DOMAIN*
*VALIDATED* *WILD* *CARD* certificates without any additional
verifications - and also these for a life-time of *TEN* years?
Robin from Comodo claims to know such CAs, maybe you know some too? In
that case I request kindly to back it up and point us to the relevant
CPS of the affected CAs. As of now this is an issue which concerns
Comodo and its evaluation here.
Frank Hecker
>> Issuing
>> long-lived DV certs and wildcard DV certs may be particular practices
>> worth our having some formal positions on, even if they're not
>> addressed
>> by our official policy.
> [Robin said...]
> There I have to disagree to some degree.
> You have a policy which tells us what we must do to qualify for root
> inclusion.
> Are you saying that you have some other things which aren't in the policy
> which we must do too?
No. I'm simply stating that there are CA-related issues which may not
warrant us having a formal policy on, but which we may have an opinion
on that we want to express.
To take another example: our policy doesn't address the issue of whether
CAs issue end entity certs directly from roots as a standard practice,
as opposed to having roots issue CA certs to subordinates and then
having the subordinates issue end entity certs. Some people think that
root private keys should always be stored offline, and that it's a bad
practice from a security standpoint to use them in conjunction with an
online cert-issuing operation, even if the root key is on a hardware device.
I don't see us making it a formal condition of our policy that CAs use
only offline roots, and rejecting CAs that issue end entity certs
directly from roots. However it's quite possible that we may want to
publicly encourage CAs to migrate to use of offline roots, and perhaps
to maintain publicly available information on which CAs issue directly
from roots and which don't. We can also of course do such lobbying
within groups like the CAB Forum, and we will. However I don't believe
that precludes our discussing and taking positions on these issues in
the context of our public forums and web sites.
Frank
Paul Hoffman
>As long as
>domain names can be re-registered to different owners, there is always
>this potential to some degree. It doesn't matter whether the cert
>lifetime is 10 years, 1 year, or 1 week.
Exactly right. A CA re-affirms the binding between the public key and
the identified party when it makes sense to. Some CAs think it makes
sense every year; others every ten years. In the private PKI realm,
there are CAs that re-affirm the binding daily.
>If I purchase a domain name
>today, it's possible that someone registered this domain a few days ago,
>got a cert for it, returned the domain name for a refund, and is now
>ready to attack. Thus if we take your statement literally then the
>implication is that we should never use a DV cert with any domain
>whatsoever, period, full stop.
Right.
> > It has nothing to do with economics, but a lot to do with the knowledge
>> that when I visit a web site with Firefox which has a legitimate
>> certificate, that the site I'm visiting belongs to the right guy. This
>> is what DV certs are all about, this is what they guaranty and this is
>> the lowest barrier and condition of the Mozilla CA policy.
>
>And I'm telling you that if we take your argument at face value then
>there is no absolute guarantee, because this attack is theoretically
>possible for any cert lifetime longer than a day or so. So we have to
>fall back on judging relative risk, and that is what I've been trying to
>do in my analysis.
...and if Mozilla wants to set a time period for CAs to re-affirm the
binding, it should also look at relative risk as well.
Eddy Nigg (StartCom Ltd.)
>> - We are not seeking to cause any harm to Comodo or unilaterally remove
>> the roots from NSS. However can we seek the cooperation on the issues
>> which were raised and is Comodo willing to address this issues in good
>> faith?
>>
> Mozilla, provided that the same standard applies at the same time to all
> CAs.
>
I think this is the general understanding.
>
>> - Apparently you agree that the major issues we've raised, indeed pose
>> a
>> higher risk to the relying parties. Can we work together in order to
>> improve your products to the extend that both sides can live with it
>> and
>> based on reasonable terms? This would improve the overall quality of
>> all
>> certificates issued by CAs which are included in NSS, which would
>> result
>> in further strengthening of digital certification in general and in
>> Mozilla software in particular. It would improve also your standing in
>> this industry!
>>
> [Robin said...]
> I didn't agree that any of the issues you raised were major ones.
As long as somebody else potentially has a legitimate certificate for
*my* domain name because of *your* CA, this risk is for me a major one.
I should be assured that nobody besides *me* has a legitimate
certificate two years after I purchased the domain. This might be fine
with you that other people have certificates for your domain names, it's
not fine with me.
> I do agree that there are a variety of levels of risk provided by the product
> ranges we have discussed.
> We are keen that levels of risk are reduced across the industry and we are
> always happy to talk about how that can be achieved. I do not see how the
> withdrawal or modification of some of our products in isolation accomplishes
> that overall reduction in risk. Amend your policy so that it fully
> expresses your requirements and then apply that policy to all CAs.
>
As a market leader you should be comfortable to lead the way and make
your contribution without some other authority telling you what to do.
This makes the difference between a leader and a follower.
>
> [Robin said...] As I mentioned before, we are commercially obliged to have
> our root CAs present in the major browser and OS platforms. In the absence
> of other authority it is those browsers and OS platforms that set the
> standards we have to follow. Since no single browser has the entire market
> cornered we are obliged to meet the union of all of the standards set by all
> of the browsers.
> We are prepared to comply with Mozilla's CA Policy.
Well, you don't have to, if you don't want to...
> We are prepared to
> enter into and assist with discussions with Mozilla about changes they may
> wish to make to their policy. We are also prepared to do the same with any
> other commercially important Browsers and OS platforms.
>
I think your input could be valuable and you are invited to join any
effort in that respect. Mozilla is a community project and you can be
part of this community.
>
> [Robin said...]
> I'm not the first guy you need to get to agree that your suggestions are
> reasonable.
> Mozilla should amend its CA policy if it believes there is something that it
> does not currently address and then apply that new policy to all CAs.
> The proscription of SSL products, or of details of their implementation, is
> something that should reasonably be discussed collectively with the CAs and
> the browsers. Can I suggest that the CAB Forum would be one place in which
> the matter could usefully be discussed? Mozilla is already able to propose
> such matters for discussion there through Jonathan Nightingale.
>
>
No, because the CAB forum is for EV certificates and has failed to
address many other pressuring issues, IMO. Additionally the CAB forum is
a closed, interest forum of CAs and some software vendors, unaccessible
to the public and/or smaller software vendors and CAs. Nobody knows what
Jonathan does at the CAB forum eithe, nor do we know what the CAB forum
does at all.
Eddy Nigg (StartCom Ltd.)
> From Frank's most recent reply I accept the reason for the consideration of
> all aspects of our operation, but perhaps that separation should be made
> more clear between those matters we are discussing here which are relevant
> to the EV enabling of our roots within (what we hope to be) a short
> timescale and those matters which pertain to the future direction of DV
> which we are prepared to discuss but which are not intrinsically linked to
> the EV issue.
>
I think that there is only a technical problem, should Mozilla decide
that your EV business is completely acceptable, but consider your non-EV
business not. I indeed believe that your CA is entitled to receive EV
status for the roots which were audited for that and I also believe that
there are some problematic points with your non-EV policies.
I think that your willingness to address the DV related issues and find
an acceptable solution could only confirm your seriousness. Such a
commitment would be certainly viewed as a positive step and remove
opposition to the proposed upgrade.
The problem I'm seeing right now is, which isn't a problem of yours per
se, that if Mozilla approves the upgrade to EV status, your CA roots
will receive further anchors in the software, making it even more
difficult to receive the cooperation I'm seeking on the issues, not
speaking about any possible "sanction" pretty useless. Currently EV
status implies the roots to be also trusted for regular certificates
which is a limitation of NSS.
Effectively, because Frank has called this to be a general review and
inclusion of your CA roots and after having your CA approved, there
wouldn't be many reasons for you to make any changes whatsoever, except
in case Frank would make the approval conditional in some form. More
than that, after this process completes, your CA roots are accepted in
NSS not as legacy roots from the Netscape era, but as roots which
performed a thorough inclusion process based on the Mozilla CA policy.
Robin Alden
> The problem I'm seeing right now is, which isn't a problem of yours per
> se, that if Mozilla approves the upgrade to EV status, your CA roots
> will receive further anchors in the software, making it even more
> difficult to receive the cooperation I'm seeking on the issues, not
> speaking about any possible "sanction" pretty useless. Currently EV
> status implies the roots to be also trusted for regular certificates
> which is a limitation of NSS.
>
Perhaps my problem then is understanding the process at all. You seem to
suggest that once our application for EV status is approved we somehow
become immune to changes in your CA policy. Why do you feel that Mozilla
has no control over the CAs other than at the point of approval of a change?
The CA Policy says otherwise.
Or are you saying that your (collective) influence over CA policy is not
what you might hope for but that you can get concessions from individual CAs
at the point of approval?
If I agree to accept a restriction on a product of ours, can you explain the
method that propagates that restriction to the other CAs?
Regards
Robin
Robin Alden
> No. I'm simply stating that there are CA-related issues which may not
> warrant us having a formal policy on, but which we may have an opinion
> on that we want to express.
>
> To take another example: our policy doesn't address the issue of whether
> CAs issue end entity certs directly from roots as a standard practice,
> as opposed to having roots issue CA certs to subordinates and then
> having the subordinates issue end entity certs. Some people think that
> root private keys should always be stored offline, and that it's a bad
> practice from a security standpoint to use them in conjunction with an
> online cert-issuing operation, even if the root key is on a hardware
> device.
>
> I don't see us making it a formal condition of our policy that CAs use
> only offline roots, and rejecting CAs that issue end entity certs
> directly from roots. However it's quite possible that we may want to
> publicly encourage CAs to migrate to use of offline roots, and perhaps
> to maintain publicly available information on which CAs issue directly
> from roots and which don't. We can also of course do such lobbying
> within groups like the CAB Forum, and we will. However I don't believe
> that precludes our discussing and taking positions on these issues in
> the context of our public forums and web sites.
>
We accept that Mozilla has valid and carefully considered points of view on
issues relating to CA behaviour.
I like your example of using intermediate CAs because it is a goal we share
and something we push where we can, although there are commercial reasons
that we still do not do it across the board.
We accept the quality of the advice, and are grateful that it is not
something you enforce in your policy.
Taking Eddy's issues on DV certificates, we can agree that his points tend
to reduce risk. We could even try and promote those views in other forums
where we interact with browsers and CAs. What we don't really want to do is
commit to limiting our DV products while other CAs don't see the same
limits. Either leave it as a "stated position" which would leave us room to
promote it where we can but also to continue to compete on an equal footing
in that market sector - or make it a stated part of your CA policy which
will oblige all CAs to comply. Either of those options is fine with us, but
don't ask us to accept (or to volunteer) unilateral restrictions because as
a commercial organization we can't accept them.
Regards
Robin
Eddy Nigg (StartCom Ltd.)
Robin Alden:
>
> [Robin said...]
> Perhaps my problem then is understanding the process at all. You seem to
> suggest that once our application for EV status is approved we somehow
> become immune to changes in your CA policy. Why do you feel that Mozilla
> has no control over the CAs other than at the point of approval of a change?
>
Robin, this is a very good question, I'm glad you asked and let me
explain. Please note, that this is now somewhat off-topic to your
inclusion request and concerns more the internal "affairs" of Mozilla.
As of today, never has a CA root been removed from NSS, not even ones
which aren't in use anymore. A policy is being defined just now, which
would give certain powers to developers in order to remove roots which
are simply not needed anymore or have an obvious flaw.
The approach of Mozilla (through Frank) has always been to work with CAs
to address the issues (if any), something I completely support! However
there is a psychological barrier perhaps which would make it very hard
to remove a CA root which has been approved in the past. Specially a
root of a CA your size, is realistically almost untouchable thereafter
(this is a real world point of view, not a policy). Not even legacy
roots which could be viewed as problematic were ever touched or
considered for a review. Just now this opportunity arrived with the
upgrade request for EV (which too affects only some CAs).
It's much easier to deny inclusion to NSS for new CA roots and smaller
CAs (and/or request changes to the affected bits of said CA), then
having a CA root from a major CA removed from NSS.
> The CA Policy says otherwise.
>
This is correct and Mozilla certainly has the authority to do so.
However this would have to be a very sever issue in order that such an
action would be even considered, certainly not for issues such as I have
touched here. It doesn't makes it right, it's just a fact.
> Or are you saying that your (collective) influence over CA policy is not
> what you might hope for but that you can get concessions from individual CAs
> at the point of approval?
>
Yes, there is something to it. For various reasons, including (I think)
because of lacking manpower, CAs are reviewed on an individual basis as
they come up for inclusion. Therefore the best chance to insist on a
certain quality of certificate issuance by said CA, is when they are
considered for inclusion (and/or upgrade to EV). There were already
issues in the past, which weren't explicitly mentioned in the Mozilla CA
policy, but nevertheless affected the decision for inclusion (making the
requests pending to more reviews on the matter and/or pending changes to
the CPS of the affected bits).
> If I agree to accept a restriction on a product of ours, can you explain the
> method that propagates that restriction to the other CAs?
Yes! Supposed that because of my objections and issues I've raised,
Comodo commits to changes to its policies and implementations, I could
take this as a precedent for other CAs and insist and apply the same
changes as well **. This is specially true because of the size of your
CA and market share, this would give it extra weight as I see it.
Let me assure you, that I'm very much seeking first and foremost your
cooperation on that matter. I very much prefer a dialog than dictate.
But the fact, that I did object for the reasons I stated and supposed
you accept certain restrictions on your products, this would be the best
tool for me, to have them evenly applied to all other CAs, not to
mention a possible update to the Mozilla CA policy.
** Disclaimer: This wouldn't happen at day one, but during a reasonable
period, CAs could be approach and the changes could be applied upon all
CAs affected. In such a case I would commit myself to review CAs which
potentially could be affected by that and make Mozilla aware of it and
request said changes.
Frank Hecker
> Perhaps my problem then is understanding the process at all. You seem to
> suggest that once our application for EV status is approved we somehow
> become immune to changes in your CA policy. Why do you feel that Mozilla
> has no control over the CAs other than at the point of approval of a change?
> The CA Policy says otherwise.
> Or are you saying that your (collective) influence over CA policy is not
> what you might hope for but that you can get concessions from individual CAs
> at the point of approval?
>
> If I agree to accept a restriction on a product of ours, can you explain the
> method that propagates that restriction to the other CAs?
Let me clarify some more from a Mozilla Foundation point of view, since
it's our policy, and I'm the one implementing it. (I may be responding
here more to some of your earlier comments, I'm beginning to lose track
of all the posts about this topic.)
In terms of getting "concessions" from individual CAs: In the past we
have held up approval of CA requests until we could be satisfied that
CAs were in compliance with specifically-called-out requirements of our
policy. For example, in a number of cases it wasn't clear at all from a
CA's CPS what kind of applicant validation they did for given types of
certificates. IIRC in at least one or two other cases we had CAs that
had verification procedures that didn't appear to meet our bare minimum
requirements, and we asked them to make improvements as a condition of
approval. (An example would be a CA that issued individual certs usable
for S/MIME email, but did not appear to actually verify that the
individual controlled the email address named in the cert.)
I don't consider the above to be asking for concessions, I see it as
simply asking CAs to do what pretty much any CA should do, in order to
meet the explicitly called-out requirements of our policy--requirements
that I consider consistent with standard CA industry practices.
There are other cases where CAs engage in practices concerning which we
didn't or don't have explicit policy requirements. Past and present
examples include issuing end entity certs directly from roots, issuing
multiple classes of certificates under a single root's hierarchy, having
too many roots (for some definition of "too many"), issuing DV certs
with lifetimes that are too long (for some definition of "too long"),
issuing wildcard DV certs, having subordinate CAs that aren't externally
audited, and so on. Lots of Mozilla community members (not just Eddy)
have argued one way or the other on these issues, including claiming
that one or more of these practices are security risks, urging that we
deny particular CA requests on that basis, advocating that we change our
policy to outlaw these practices, and so on.
My opinion is that resolution of these issues is better done outside the
context of any particular CA request, as part of a more general
discussion of revisions to our policy. Then we can look at the issues in
the context of the CA industry as a whole (not just commercial CAs, but
any CA whose root might be preloaded into Mozilla, including government
and nonprofit CAs), and make better decisions about what if anything our
policy should say about the practices in question.
However these individual CA reviews have proved useful for turning up
new issues we should consider, and I think they're worthwhile for that
reason alone, in addition to the other purposes they serve. Also, as I
think Eddy noted, there are few if any other open public forums for
looking at CA-related issues like these that are of potential interest
to any developers and users who rely on CAs in one way or another. Maybe
in the future the CAB Forum will evolve into an organization open to all
interested parties (e.g., like the standards bodies that exist in other
areas), and then we can move these more general discussions and lobbying
efforts to that forum. But until that happens we (Mozilla in general)
can't simply hash things in private discussions in the CAB Forum or
elsewhere; we're a nonprofit organization with a public benefit purpose,
and public participation is key to the way we operate.
Frank
Robin Alden
> have held up approval of CA requests until we could be satisfied that
> CAs were in compliance with specifically-called-out requirements of our
> policy. For example, in a number of cases it wasn't clear at all from a
> CA's CPS what kind of applicant validation they did for given types of
> certificates. IIRC in at least one or two other cases we had CAs that
> had verification procedures that didn't appear to meet our bare minimum
> requirements, and we asked them to make improvements as a condition of
> approval. (An example would be a CA that issued individual certs usable
> for S/MIME email, but did not appear to actually verify that the
> individual controlled the email address named in the cert.)
Fair enough.
>
> I don't consider the above to be asking for concessions, I see it as
> simply asking CAs to do what pretty much any CA should do, in order to
> meet the explicitly called-out requirements of our policy--requirements
> that I consider consistent with standard CA industry practices.
That's fine. We are keen to comply with the CA policy because we want our
CA requests to be approved.
>
> There are other cases where CAs engage in practices concerning which we
> didn't or don't have explicit policy requirements. Past and present
> examples include issuing end entity certs directly from roots, issuing
> multiple classes of certificates under a single root's hierarchy, having
> too many roots (for some definition of "too many"), issuing DV certs
> with lifetimes that are too long (for some definition of "too long"),
> issuing wildcard DV certs, having subordinate CAs that aren't externally
> audited, and so on. Lots of Mozilla community members (not just Eddy)
> have argued one way or the other on these issues, including claiming
> that one or more of these practices are security risks, urging that we
> deny particular CA requests on that basis, advocating that we change our
> policy to outlaw these practices, and so on.
>
> My opinion is that resolution of these issues is better done outside the
> context of any particular CA request, as part of a more general
> discussion of revisions to our policy. Then we can look at the issues in
> the context of the CA industry as a whole (not just commercial CAs, but
> any CA whose root might be preloaded into Mozilla, including government
> and nonprofit CAs), and make better decisions about what if anything our
> policy should say about the practices in question.
We are quite happy to keep the issues raised under discussion past the point
that our current rounds of CA requests are accepted. None of the issues
raised are spurious.
Our main current objection to them is on grounds of maintaining a level
commercial playing field among all CAs (in the Mozilla root program).
> However these individual CA reviews have proved useful for turning up
> new issues we should consider, and I think they're worthwhile for that
> reason alone, in addition to the other purposes they serve. Also, as I
> think Eddy noted, there are few if any other open public forums for
> looking at CA-related issues like these that are of potential interest
> to any developers and users who rely on CAs in one way or another. Maybe
> in the future the CAB Forum will evolve into an organization open to all
> interested parties (e.g., like the standards bodies that exist in other
> areas), and then we can move these more general discussions and lobbying
> efforts to that forum. But until that happens we (Mozilla in general)
> can't simply hash things in private discussions in the CAB Forum or
> elsewhere; we're a nonprofit organization with a public benefit purpose,
> and public participation is key to the way we operate.
[Robin said...]
I acknowledge the value of the process.
Is there anything remaining which would now hold up approval of our CA
requests?
Regards
Robin
Eddy Nigg (StartCom Ltd.)
> [Robin said...]
> commercial playing field among all CAs (in the Mozilla root program).
>
in NSS, are commercial CAs. Most, if not all CAs, don't perform the
practices your CA apparently does and which I view as a heightened risk.
That's also the reason why this issue has come up with your requests at
this time. Because of my involvement with the NSS team, I had the chance
to read enough CPSs from a wide range of CAs in order to positively
confirm that.
In that respect it's your CA which introduces an unfair balance in the
commercial playing field. But should I encourage now to have all other
CAs adopt your risky behavior? At various occasions you referred to your
commercial obligations, but what about your other obligations to the
industry and to the relying parties, Mozilla being one of them? Most, if
not all other CAs present in NSS, are aware of their responsibilities
and duties beyond the commercial aspect and your CA is in the very
minority! Lets maintain an even and fair level in every respect, which
would call out for your CA to adjust!
Frank Hecker
> Is there anything remaining which would now hold up approval of our CA
> requests?
I have to go through all this and write up my final statement on the
issues at hand. I think all issues have been responded to one way or
another.
Frank
Robin Alden
> > [Robin said...]
> > Our main current objection to them is on grounds of maintaining a level
> > commercial playing field among all CAs (in the Mozilla root program).
> >
> Robin, just for your knowledge that most if not all CAs which have roots
> in NSS, are commercial CAs. Most, if not all CAs, don't perform the
> practices your CA apparently does and which I view as a heightened risk.
> That's also the reason why this issue has come up with your requests at
> this time. Because of my involvement with the NSS team, I had the chance
> to read enough CPSs from a wide range of CAs in order to positively
> confirm that.
>
> In that respect it's your CA which introduces an unfair balance in the
> commercial playing field. But should I encourage now to have all other
> CAs adopt your risky behavior? At various occasions you referred to your
> commercial obligations, but what about your other obligations to the
> industry and to the relying parties, Mozilla being one of them? Most, if
> not all other CAs present in NSS, are aware of their responsibilities
> and duties beyond the commercial aspect and your CA is in the very
> minority! Lets maintain an even and fair level in every respect, which
> would call out for your CA to adjust!
If I understand you correctly you are saying that considering lack of
evidence to the contrary you believe that Comodo is solely responsible for
lowering the standard of DV certificate issuance in these two respects?
You are probably more familiar with our competitors CPSs than I am so
perhaps you can explain to me how certificates such as the ones at
https://www.beileysoftware.com/fm.html (10 year DV),
and
https://iah.unc.edu (10 year wildcard DV)
relate to the matter in hand?
We are keen to meet Mozilla's requirements and we certainly will not
knowingly let our standards be below those of the rest of the market.
I genuinely hope that you are correct in this matter and that my
understanding is wrong, because if we can raise the standard of the DV
marketplace as a whole by modifying our own policy we will do so.
On the other hand, I will not be able to act to raise our standards if our
competitors are not obliged to reach the same standard.
Regards
Robin
Eddy Nigg (StartCom Ltd.)
> [Robin said...]
> If I understand you correctly you are saying that considering lack of
> evidence to the contrary you believe that Comodo is solely responsible for
> lowering the standard of DV certificate issuance in these two respects?
>
> You are probably more familiar with our competitors CPSs than I am so
> perhaps you can explain to me how certificates such as the ones at
> https://www.beileysoftware.com/fm.html (10 year DV),
> and
> https://iah.unc.edu (10 year wildcard DV)
> relate to the matter in hand?
>
I will acquire the needed information in order to confirm their issuance
requirements. As far as I know, GoDaddy requires revalidation of their
long-term certificates and I'm going to update you and the list on that
matter (of both CAs from above). Pointers such as these are useful and
if you have more from other CAs please feel free to forward this
information to me.
> We are keen to meet Mozilla's requirements and we certainly will not
> knowingly let our standards be below those of the rest of the market.
>
Excellent!
> I genuinely hope that you are correct in this matter and that my
> understanding is wrong, because if we can raise the standard of the DV
> marketplace as a whole by modifying our own policy we will do so.
>
I couldn't ask for more!
> On the other hand, I will not be able to act to raise our standards if our
> competitors are not obliged to reach the same standard.
>
I understand that completely! Lets first confirm the issuance procedures
and requirements of other CAs, you (or anybody else) suspects of being
within the same range as yours and also evaluate with Frank (and others)
about a possible approach on that matter. I promise to follow up latest
at Monday morning on the two CAs from above (and other CAs if requested).
> Regards
> Robin
>
Thank you for your cooperation so far!
Eddy Nigg (StartCom Ltd.)
Both certificates from the links below are issued by GoDaddy. Both
GoDaddy and Comodo CPS have similar requirements in the subscriber
obligation and/or reasons for revocations:
Starfield (GoDaddy)
2.2.1.4 (iv) the Subscriber failed to stop using a Starfield
Certificate after the information contained in
such Starfield Certificate changed or after circumstances changed so
that the information
contained in such Starfield Certificate became misleading or inaccurate;
Comodo
5.15 Subscriber Obligations
Alert Comodo or a Comodo RA if at any stage whilst the certificate
is valid, any information originally submitted has changed since it
had been submitted to Comodo.
Cease using a Comodo certificate if any information in it becomes
misleading obsolete or invalid.
I contacted a representative of GoDaddy and have not received any reply
so far (it's weekend). The question is the same as with Comodo, about
which steps are implemented concerning re-validation of long-living
certificates. Both your CAs are represented in the CAB forum and issue
EV certificates. For now I'm not aware of any other CA which issues
certificates for this life-span (ten years).
Eddy Nigg (StartCom Ltd.):
Eddy Nigg (StartCom Ltd.)
additional points which you haven't addressed at all:
The first is about having CA roots with wrong details in NSS, like
companies which effectively don't exist anymore (AddTrust AB, UTN),
location (Sweden, Utah) and other information irrelevant and incorrect.
The second is about the audit statements which refer to a specific part
and location of the CA business, like New Jersey.
You didn't make any statements concerning these two points (I think). Do
you mind commenting on it?
Frank Hecker
> This is a followup to my previous message about Comodo's application to
> add a new EV root CA certificate. Comodo also has requested enabling
> three existing roots, AddTrust External CA Root, UTN - DATACorp SGC, and
> UTN-USERFirst-Hardware, for EV use, and also marking all three roots for
> SSL, email, and code signing use, as documented in the following bug:
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=401587
<snip>
> I have evaluated this request, as per the mozilla.org CA certificate
> policy:
>
> http://www.mozilla.org/projects/security/certs/policy/
>
> and plan to officially approve the request after a public comment period.
The public comment period ended last week, but we had some additional
discussions around various Comodo-related issues, most notably the
wildcard DV cert issue and the long-lived DV cert issue. Although I
acknowledge that there were/are valid concerns associated with those
issues, in the end I made a judgment call that they didn't rise to a
level that would justify my rejecting Comodo's request or delaying
approval. I've therefore given my final approval to this request and
filed bugs 426575 against PSM:
https://bugzilla.mozilla.org/show_bug.cgi?id=426575
Frank
--
Frank Hecker
hec...@mozillafoundation.org
Frank Hecker
> additional points which you haven't addressed at all:
>
> The first is about having CA roots with wrong details in NSS, like
> companies which effectively don't exist anymore (AddTrust AB, UTN),
> location (Sweden, Utah) and other information irrelevant and incorrect.
To the extent that this information is in the certificates themselves,
we can't change it. I guess we could look at changing the "friendly
names" which NSS uses to refer to the certs, but that might be confusing
for people who actually look at the root list in the various versions of
Firefox. I think there's also an issue with how the certs get displayed
in the Firefox certificate manager display window, based on what the
cert contents are; I recall a comment from Kai (I think) about this in a
bug I looked at recently, but can't recall the bug number or what the
exact issue was.
> The second is about the audit statements which refer to a specific part
> and location of the CA business, like New Jersey.
I didn't think this was a material issue with respect to Comodo's
overall compliance with the EV guidelines, and so left it out of my
considerations.