Eddy Nigg (StartCom Ltd.) wrote:
Even though the Comodo request has been approved, I wonder about two
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),
As I promised to come back to you, here what I gathered so far.
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
Eddy,
[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,
Robin Alden:
[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
Robin Alden wrote:
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
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
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
Robin Alden wrote:
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
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.
Robin, I have a request to make. Lets put aside for a minute the
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
Robin, just to answer this one...
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
Robin, just to answer this one...
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
Eddy Nigg (StartCom Ltd.) wrote:
Robin, just to answer this one...
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
Robin Alden wrote:
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
Robin Alden:
- 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?
[Robin said...] We are willing to address issues which
Robin Alden:
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
Eddy,
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
Frank,
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
Hi Robin,
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
Hi Frank,
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
Frank Hecker:
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
Eddy Nigg (StartCom Ltd.) wrote:
We aren't talking here about a possible gain in material only (money,
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,
Hi Robin,
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
in this
forum, if possible.
Regards
Robin Alden
Comodo CA Limited.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Eddy Nigg
(StartCom Ltd.)
Sent: 24 March 2008 02:38
To: Frank Hecker
Cc: dev-tech-crypto@lists.mozilla.org
Subject: Re: Comodo request for EV-enabling 3
Eddy,
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=636file=pdf). What are its
relations to AddTrust AB, Sweden?
* 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
Eddy,
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
Florian Weimer:
* 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
Eddy Nigg (StartCom Ltd.) wrote:
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];
As far as I can tell, here are the most recent questions you've raised
(first four in a message
Eddy,
You said:
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
Eddy,
You said:
- Unlucky formulation of 4.2.1 Secure Server Certificates Validation
Process (Code Signing versus Server Certs).
I agree. 4.2.1 could do with a different sub-title, given its frequent re-use.
- Subsection 1 doesn't apply I guess.
Subsection 1 did not apply for code
Thanks to Robin from Comodo to address all issues I've raised (I think
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
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
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.
On Sunday 16 March 2008, Eddy Nigg (StartCom Ltd.) wrote:
This is a revised version of my initial questions concerning the
Eddy Nigg (StartCom Ltd.) wrote:
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
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,
Rob Stradling:
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.
--
Regards
Signer: Eddy
Frank Hecker:
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
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 think there must be a word missing from that sentence.
As it reads, it says ... to
Nelson B Bolyard wrote:
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.
snip
I suspect you meant ... to accept EV certs, but not NON-EV
Frank Hecker:
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
Frank Hecker:
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
Andrews, Rick:
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
More questions for Comodo:
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
Eddy Nigg (StartCom Ltd.) wrote, On 2008-03-15 14:59:
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
Nelson B Bolyard:
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,
Nelson B Bolyard:
I envision a photograph of Frank and Eddy, wearing mustaches and red
capes with horns and sporting tridents. :)
LOL
Sadly, I don't see many signs that that Mozilla is interested or
participating in this work.
So wake them up...
Referring to the issuance of certs
Eddy Nigg (StartCom Ltd.) wrote:
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.
I *think* what you're looking for is in
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
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
Eddy Nigg (StartCom Ltd.) wrote:
Ohoommm...it doesn't say not to rely for e-commerce, but not to rely AT
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
Eddy Nigg (StartCom Ltd.) wrote:
Rob Stradling:
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
Frank Hecker:
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
Frank Hecker:
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
Frank Hecker:
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
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
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
I have the following questions concerning the Comodo inclusion and
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
Nelson Bolyard:
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
Nelson Bolyard:
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,
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...
On Wednesday 12 March 2008, Frank Hecker wrote:
Eddy Nigg (StartCom Ltd.) wrote:
I working up my backlogat first I
Frank Hecker:
Eddy Nigg (StartCom Ltd.) wrote:
I working up my backlogat 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
Rob Stradling:
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...
Hi Rob,
For the record, I can assure you that Comodo never issue DV and EV certs from
the same
Frank Hecker:
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:
I working up my backlogat first I thought this to be a good idea to
split the request up, but
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,
65 matches
Mail list logo
