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, U
Frank Hecker wrote:
> 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 al
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),
location (Sweden, Utah) and other inf
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 f
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
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 a
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
__
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 a
> 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
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 o
Hi Robin,
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
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 f
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
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 t
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 is
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
> 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
> 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
> w
> 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.
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 inh
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 r
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 w
> >> 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 c
OK, Frank, not going to run in circles here...just a few short
replieslast 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
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
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, w
Frank Hecker:
>
> I don't disagree that in general CAs should limit cert lifetimes, for
> all sort of reasons.
I'm glad to hear that. And you are right, that there are other reasons
as well. However I'm concentrating on the reason closest possible also
in relation to the Mozilla CA policy. Prev
Eddy Nigg (StartCom Ltd.) wrote:
> 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 diffe
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
> 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
>
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
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
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
Frank Hecker:
>
> 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.
>
Your list is correct and Robin Alden has addressed all issues which were
raised. I intend to reply to each in a summarized form.
> Question 2
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 tomorro
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
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 organizatio
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 mes
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 t
* 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 browse
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 certifi
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=636&file=pdf). What are its
> relations to AddTrust AB, Swe
Robin Alden:
> 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.
>
>
Hi Robin,
Yes, we were promised that you or some other representative of Comodo
would address the questions raise
quot; - well, I'd rather answer the questions 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
CTED] 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 existing roots
Frank Hecker:
> This is a followup to my previous message about Comodo's application to
> add a new
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 thre
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 Se
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 regi
> 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 with
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
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.
> I suspect you meant "... to accept EV certs, but not NO
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 ac
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 confor
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: Ed
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 polic
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
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 Co
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 o
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 vettin
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,
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 equa
Eddy Nigg (StartCom Ltd.) wrote, On 2008-03-16 08:37:
> 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
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 par
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
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 operati
Frank Hecker:
> Eddy Nigg (StartCom Ltd.) wrote:
>
>> 3.) Here a few questions in relation to the LiteSSL CPS:
>>
>
>
>>* 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 ano
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.dom
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'v
Eddy Nigg (StartCom Ltd.) wrote:
> Rob Stradling:
>> 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 concerni
Eddy Nigg (StartCom Ltd.) wrote:
> 3.) Here a few questions in relation to the LiteSSL CPS:
>* 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
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 looki
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-object
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 po
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
Frank Hecker:
> Eddy Nigg (StartCom Ltd.) wrote:
>
>> 3.) Here a few questions in relation to the LiteSSL CPS:
>>
>
> 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
Eddy Nigg (StartCom Ltd.) wrote:
> 3.) Here a few questions in relation to the LiteSSL CPS:
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
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
>> envi
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. A
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 o
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
considerati
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:
> 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.
>>
>
> Fo
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 t
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 information on context pleas
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,
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, emai
86 matches
Mail list logo
