Comodo ECC CA inclusion/EV request
Frank Hecker
Comodo to add the Comodo ECC Certification Authority root certificate to
Mozilla and enable it for EV use. This is bug 421946, and Kathleen has
produced an information document attached to the bug.
https://bugzilla.mozilla.org/show_bug.cgi?id=421946
There's a summary of the information also available at
http://www.mozilla.org/projects/security/certs/pending/#Comodo
Some points worth mentioning about this request:
* This is a new root. Initially it will have a subordinate CA used for
issuing EV SSL certs, but as I understand it Comodo will potentially use
the hierarchy under this root for other types of certs (both EV and
non-EV) -- in a sense it's the ECC equivalent to the new Comodo
Certification Authority root recently added to Mozilla.
* In the CRL section of the information document Kathleen has a sentence
"EV certificates issued from the ECC root". That's a typo (and in fact
the CRL referenced just below that sentence is not for the root but for
the EV SSL subordinate CA.) No end entity certs (EV or otherwise) are or
will be issued directly from the Comodo ECC Certification Authority
root; issuance of end entity certs would be done through subordinate CAs
corresponding to the various types of certs, consistent with exist
Comodo practice.
* Also, the "flag problematic practices" section at the end of the info
document has the sentence fragment "Issuing end entity certs directly
from root rather than using an offline root and issuing certs through a
subordinate CA". That's just the reference to checking for the practice.
Kathleen forgot to add "(no)" or "(not an issue)" afterwards; see the
above item.
This first public comment period will be for one week, and then I'll
make a preliminary determination regarding this request.
Frank
--
Frank Hecker
hec...@mozillafoundation.org
Paul Hoffman
Frank Hecker
> Has anyone validated the ECC paramters they used?
Not that I'm aware. There's a test site with a Comodo-issued ECC cert at
https://comodoecccertificationauthority-ev.comodoca.com/
and the Comodo ECC root CA cert itself is available at
http://crt.comodoca.com/COMODOECCCertificationAuthority.crt
Are those sufficient input to do validation against, or do we need
further information?
Wan-Teh Chang
> Has anyone validated the ECC paramters they used?
They use the NIST P-384 curve (secp384r1), which is in NSA Suite B.
Wan-Teh
Wan-Teh Chang
Frank,
Those are sufficient. In your summary of information for CAs, you
should replace "Modulus (key length)" by "EC parameters (named curve)"
for ECC roots.
Wan-Teh
Frank Hecker
> In your summary of information for CAs, you
> should replace "Modulus (key length)" by "EC parameters (named curve)"
> for ECC roots.
I've revised the information checklist to reflect your comments; see
item 2.6:
http://wiki.mozilla.org/CA:Information_checklist
Please let me know if this is accurate, or needs further revision.
Wan-Teh Chang
<hec...@mozillafoundation.org> wrote:
> Wan-Teh Chang wrote:
>> In your summary of information for CAs, you
>> should replace "Modulus (key length)" by "EC parameters (named curve)"
>> for ECC roots.
>
> I've revised the information checklist to reflect your comments; see
> item 2.6:
>
> http://wiki.mozilla.org/CA:Information_checklist
>
> Please let me know if this is accurate, or needs further revision.
Yes, that is accurate. Thanks!
You can add "Curve" before "P-256", as in "NIST Curve P-256 or P-384".
Wan-Teh
Paul Hoffman
>Paul Hoffman wrote:
> > Has anyone validated the ECC paramters they used?
>
>Not that I'm aware.
I think that's unfortunate. It is easy for all of us to test the
parameters for RSA certs, but few of us have software for testing ECC
certs.
>There's a test site with a Comodo-issued ECC cert at
>
> https://comodoecccertificationauthority-ev.comodoca.com/
...which no browser will let me into. :-)
>and the Comodo ECC root CA cert itself is available at
>
> http://crt.comodoca.com/COMODOECCCertificationAuthority.crt
Yup, I got that from the bug report.
>Are those sufficient input to do validation against, or do we need
>further information?
They are not sufficient by theselves. See below.
At 9:57 AM -0700 7/18/08, Wan-Teh Chang wrote:
>On Thu, Jul 17, 2008 at 8:54 PM, Paul Hoffman <phof...@proper.com> wrote:
> > Has anyone validated the ECC paramters they used?
>
>They use the NIST P-384 curve (secp384r1), which is in NSA Suite B.
Wang-Teh: did you check that they actually used that curve with some
software? Or did you simply see that OID in their cert? If you used
software, which? Is the crypto library in the checking software the
same as Comodo used to create the cert or genetically different?
It would be nice to know that the signature on the certificate
validates, and that the curve they claim they are using is in fact
the curve that verifies with the signature.
At 10:05 AM -0700 7/18/08, Wan-Teh Chang wrote:
>Those are sufficient.
...only if they have been verified. If someone trusted has verified
them, that's great; if not, we should do that.
Frank Hecker
> At 9:27 AM -0400 7/18/08, Frank Hecker wrote:
>> Paul Hoffman wrote:
>> > Has anyone validated the ECC paramters they used?
>>
>> Not that I'm aware.
>
> I think that's unfortunate. It is easy for all of us to test the
> parameters for RSA certs, but few of us have software for testing ECC
> certs.
Are there NSS, OpenSSL, or other open source utilities available for
this purpose? Could you point me to more information on this topic?
>> There's a test site with a Comodo-issued ECC cert at
>>
>> https://comodoecccertificationauthority-ev.comodoca.com/
>
> ...which no browser will let me into. :-)
For Firefox at least that's because we haven't added the root CA cert
yet, though there might be additional reasons relating to the OCSP
responder (see the bug for more info). I was able to add a security
exception for this site and then could access it successfully (using
Firefox 3.0.1 on OS X), however it's not clear to what extent Firefox
was able to validate the cert signature. (Firefox still gives me a
"certificate did not verify for unknown reasons" message.)
Wan-Teh Chang
>
>>There's a test site with a Comodo-issued ECC cert at
>>
>> https://comodoecccertificationauthority-ev.comodoca.com/
>
>
>>
>> http://crt.comodoca.com/COMODOECCCertificationAuthority.crt
Paul, you can verify the EC parameters of that root CA cert as follows.
1. Use Firefox 2 or 3 on any platform. (IE7 on Windows Vista should
also work, but I didn't test it.)
2. Import that root CA cert.
3. Visit the test site:
https://comodoecccertificationauthority-ev.comodoca.com/
4. Verify that the browser validates the test site's cert successfully.
5. View the cert chain and examine the Subject Public Key Info of the
root CA cert.
I hope you trust the ECC implementation in NSS.
Wan-Teh
Paul Hoffman
>Paul Hoffman wrote:
>> At 9:27 AM -0400 7/18/08, Frank Hecker wrote:
>>> Paul Hoffman wrote:
>>> > Has anyone validated the ECC paramters they used?
>>>
>>> Not that I'm aware.
>>
>> I think that's unfortunate. It is easy for all of us to test the
>> parameters for RSA certs, but few of us have software for testing ECC
>> certs.
>
>Are there NSS, OpenSSL, or other open source utilities available for
>this purpose?
I don't know, but I take it you don't either. Hopefully others on
this list might.
FWIW, the latest version of OpenSSL (0.98h) won't:
# openssl x509 -in COMODOECCCertificationAuthority.crt -out
COMODOECCCertificationAuthority.pem -inform der -outform pem
# openssl verify COMODOECCCertificationAuthority.pem
COMODOECCCertificationAuthority.pem: /C=GB/ST=Greater
Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO ECC Certification
Authority
error 18 at 0 depth lookup:self signed certificate
/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO
ECC Certification Authority
error 7 at 0 depth lookup:certificate signature failure
57046:error:0D0C50A1:asn1 encoding routines:ASN1_item_verify:unknown
message digest algorithm:a_verify.c:141:
>Could you point me to more information on this topic?
NIST FIPS 186-3 is the standard, and it has the parameters for the
curve that Comodo says they are using.
> >> There's a test site with a Comodo-issued ECC cert at
>>>
>>> https://comodoecccertificationauthority-ev.comodoca.com/
>>
>> ...which no browser will let me into. :-)
>
>For Firefox at least that's because we haven't added the root CA cert
>yet, though there might be additional reasons relating to the OCSP
>responder (see the bug for more info). I was able to add a security
>exception for this site and then could access it successfully (using
>Firefox 3.0.1 on OS X), however it's not clear to what extent Firefox
>was able to validate the cert signature. (Firefox still gives me a
>"certificate did not verify for unknown reasons" message.)
That is a bad sign, yes?
It seems unwise for us to approve a trust anchor we can't even
verify. I am quite sure we will eventually be able to verify it (or a
corrected version if Comodo made a mistake), but having an error in
the first ECDSA certificate we put in our trusted root pile will be
bad publicity both for Mozilla and for ECDSA.
Paul Hoffman
>On Fri, Jul 18, 2008 at 1:58 PM, Paul Hoffman <phof...@proper.com> wrote:
>>
>>>
>>> https://comodoecccertificationauthority-ev.comodoca.com/
>>
>>
>>>
> >> http://crt.comodoca.com/COMODOECCCertificationAuthority.crt
>
>
>1. Use Firefox 2 or 3 on any platform. (IE7 on Windows Vista should
>also work, but I didn't test it.)
>
>2. Import that root CA cert.
... restart FF (at least 3)...
>
>3. Visit the test site:
>https://comodoecccertificationauthority-ev.comodoca.com/
>
>4. Verify that the browser validates the test site's cert successfully.
>
>5. View the cert chain and examine the Subject Public Key Info of the
>root CA cert.
Thanks, that works fine.
>I hope you trust the ECC implementation in NSS.
I do, but not unconditionally. If Comodo had used NSS to create the
cert, there could have been an error that you did not detect. I am
much happier that it verifies on both Firefox and IE because they use
different ECC libraries.
Thanks!
Rob Stradling
> At 6:18 PM -0400 7/18/08, Frank Hecker wrote:
> >Paul Hoffman wrote:
> >> At 9:27 AM -0400 7/18/08, Frank Hecker wrote:
> >>> Paul Hoffman wrote:
> >>> > Has anyone validated the ECC paramters they used?
> >>>
> >>> Not that I'm aware.
> >>
> >> I think that's unfortunate. It is easy for all of us to test the
> >> parameters for RSA certs, but few of us have software for testing ECC
> >> certs.
> >
> >Are there NSS, OpenSSL, or other open source utilities available for
> >this purpose?
>
> this list might.
>
> FWIW, the latest version of OpenSSL (0.98h) won't:
I think that the ECDSA signature algorithms will only be supported in OpenSSL
0.9.9 (not yet released) and above.
Try a recent openssl-SNAP-2008mmdd.tar.gz from ftp://ftp.openssl.org/snapshot
instead.
> # openssl x509 -in COMODOECCCertificationAuthority.crt -out
> COMODOECCCertificationAuthority.pem -inform der -outform pem
> # openssl verify COMODOECCCertificationAuthority.pem
> COMODOECCCertificationAuthority.pem: /C=GB/ST=Greater
> Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO ECC Certification
> Authority
> error 18 at 0 depth lookup:self signed certificate
> /C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO
> ECC Certification Authority
> error 7 at 0 depth lookup:certificate signature failure
> 57046:error:0D0C50A1:asn1 encoding routines:ASN1_item_verify:unknown
>
> message digest algorithm:a_verify.c:141:
> >Could you point me to more information on this topic?
>
> NIST FIPS 186-3 is the standard, and it has the parameters for the
> curve that Comodo says they are using.
>
> > >> There's a test site with a Comodo-issued ECC cert at
> >>>
> >>> https://comodoecccertificationauthority-ev.comodoca.com/
> >>
> >> ...which no browser will let me into. :-)
> >
> >For Firefox at least that's because we haven't added the root CA cert
> >yet, though there might be additional reasons relating to the OCSP
> >responder (see the bug for more info). I was able to add a security
> >exception for this site and then could access it successfully (using
> >Firefox 3.0.1 on OS X), however it's not clear to what extent Firefox
> >was able to validate the cert signature. (Firefox still gives me a
> >"certificate did not verify for unknown reasons" message.)
>
> That is a bad sign, yes?
>
> It seems unwise for us to approve a trust anchor we can't even
> verify. I am quite sure we will eventually be able to verify it (or a
> corrected version if Comodo made a mistake), but having an error in
> the first ECDSA certificate we put in our trusted root pile will be
> bad publicity both for Mozilla and for ECDSA.
> _______________________________________________
> dev-tech-crypto mailing list
> dev-tec...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-crypto
--
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.
Paul Hoffman
>I think that the ECDSA signature algorithms will only be supported in OpenSSL
>0.9.9 (not yet released) and above.
>
>Try a recent openssl-SNAP-2008mmdd.tar.gz from ftp://ftp.openssl.org/snapshot
>instead.
Will do.
Non-mandatory question: what software/hardware did Comodo use to
generate the key pair? What did you use to validate it?
As Mozilla (hopefully) starts seeing more ECDSA certs, having some
common tools would be very useful for all of us.
Nelson B Bolyard
Frank Hecker wrote, On 2008-07-18 15:18:
> Paul Hoffman wrote:
>> At 9:27 AM -0400 7/18/08, Frank Hecker wrote:
>>> Paul Hoffman wrote:
>>> > Has anyone validated the ECC paramters they used?
>>>
>>> Not that I'm aware.
>> I think that's unfortunate. It is easy for all of us to test the
>> parameters for RSA certs, but few of us have software for testing ECC
>> certs.
>
> Are there NSS, OpenSSL, or other open source utilities available for
> this purpose? Could you point me to more information on this topic?
Yes, NSS does this for every ECC signature it verifies. NSS recognizes
a finite set of curves, and verifies that the base point is on the curve
as a part of signature verification.
Nelson B Bolyard
Paul Hoffman wrote, On 2008-07-18 20:00:
>> 2. Import that root CA cert.
>
> .... restart FF (at least 3)...
should not be necessary. Might be necessary to see the cert in the UI,
due to possible UI issues, but is not required in NSS.
>> I hope you trust the ECC implementation in NSS.
>
> I do, but not unconditionally. If Comodo had used NSS to create the
> cert, there could have been an error that you did not detect. I am
> much happier that it verifies on both Firefox and IE because they use
> different ECC libraries.
The ECC code is FIPS validated, for what it's worth.
Nelson B Bolyard
Nelson B Bolyard wrote:
>
> Frank Hecker wrote, On 2008-07-18 15:18:
>>> At 9:27 AM -0400 7/18/08, Frank Hecker wrote:
>>>> Paul Hoffman wrote:
>>>> > Has anyone validated the ECC paramters they used?
>>>>
>>>> Not that I'm aware.
>>> I think that's unfortunate. It is easy for all of us to test the
>>> parameters for RSA certs, but few of us have software for testing ECC
>>> certs.
>> Are there NSS, OpenSSL, or other open source utilities available for
>> this purpose? Could you point me to more information on this topic?
>
> a finite set of curves, and verifies that the base point is on the curve
> as a part of signature verification.
>
point in the public key. It's possible that NSS does this for ECDSA,
but not for ECDH. :-/
Jean-Marc Desperrier
> At 3:24 PM -0700 7/18/08, Wan-Teh Chang wrote:
>> On Fri, Jul 18, 2008 at 1:58 PM, Paul Hoffman <phof...@proper.com>
>> wrote:
>>>> There's a test site with a Comodo-issued ECC cert at
>>>> https://comodoecccertificationauthority-ev.comodoca.com/
>>> ...which no browser will let me into. :-)
> happier that it verifies on both Firefox and IE because they use
> different ECC libraries.
Doe this mean you have been able to connect with IE7 under Vista ?
I just tested I'm able to connect with an openssl 0.9.9 snapshot, I have
a copy of gnutls so I tried that also, but it seems they don't support
ECC yet, even in the development version.
Paul Hoffman
>> At 3:24 PM -0700 7/18/08, Wan-Teh Chang wrote:
>>> On Fri, Jul 18, 2008 at 1:58 PM, Paul Hoffman <phof...@proper.com>
>>> wrote:
>>>>> There's a test site with a Comodo-issued ECC cert at
>>>>> https://comodoecccertificationauthority-ev.comodoca.com/
>>>> ...which no browser will let me into. :-)
>>>>[....] I am much
>> happier that it verifies on both Firefox and IE because they use
>> different ECC libraries.
>
>Doe this mean you have been able to connect with IE7 under Vista ?
Yep!
Rob Stradling
> At 11:04 AM +0100 7/19/08, Rob Stradling wrote:
> >I think that the ECDSA signature algorithms will only be supported in
> > OpenSSL 0.9.9 (not yet released) and above.
> >
> >Try a recent openssl-SNAP-2008mmdd.tar.gz from
> > ftp://ftp.openssl.org/snapshot instead.
>
> Will do.
>
> Non-mandatory question: what software/hardware did Comodo use to
> generate the key pair?
Our ECC key pair was generated on a Utimaco SafeGuard CryptoServer (FIPS 140-2
Level 3/4).
http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/1401val2007.htm#811
> What did you use to validate it?
I would hope that, before the FIPS 140-2 certification was granted, Utimaco
and/or NIST ensured that the Utimaco HSMs were only capable of generating
valid ECC key pairs.
After generating our ECC key pair, issuing the COMODO ECC Certification
Authority root certificate, and issuing a test EV SSL Server Certificate, we
checked...
- that "openssl x509" in the latest OpenSSL-0.9.9 snapshot was able to parse
the root certificate without complaining about anything.
- that the certificate viewer in Windows Vista was able to view the root
certificate without complaining about anything. (We of course had to
manually add the root certificate to the Windows Trusted Root Store).
- that IE7/Vista, Firefox 2/3 on several OSes, and "openssl s_client" were
able to connect to the
https://comodoecccertificationauthority-ev.comodoca.com test site without
complaining about anything. (We of course had to manually add the root
certificate to the Windows and Mozilla Trusted Root Stores).
> As Mozilla (hopefully) starts seeing more ECDSA certs, having some
> common tools would be very useful for all of us.
Nelson has said:
"Yes, NSS does this for every ECC signature it verifies. NSS recognizes a
finite set of curves, and verifies that the base point is on the curve as a
part of signature verification."
Perhaps NSS's "checkcert" command-line utility would or should do the
necessary checks?
Frank Hecker
> I am now opening the first public discussion period for a request from
> Comodo to add the Comodo ECC Certification Authority root certificate to
> Mozilla and enable it for EV use. This is bug 421946, and Kathleen has
> produced an information document attached to the bug.
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=421946
>
> There's a summary of the information also available at
>
> http://www.mozilla.org/projects/security/certs/pending/#Comodo
The first comment period has closed, and I've made a preliminary
decision to approve this request, per comment #17 in bug 421946. The
second public coment period now begins, after which I'll make a final
decision.
Eddy Nigg
As per your comment in
https://bugzilla.mozilla.org/show_bug.cgi?id=421946#c17 you state that
no problematic
practices associated with this CA, but I found that in section 2.4.1
domain validated wild cards are issued, which is listed in
http://wiki.mozilla.org/CA:Problematic_Practices#Wildcard_DV_SSL_certificates
But I'm not sure which type the ECC certificates belong to (which letter
under section 2.4.1) in which case e) might not apply. Oh and f) is also
interesting ;-), I wonder how many "localhost" certificates were issued
so far...
This CP/CPS also covers certificates with a validity of 10 years which
is again listed in
http://wiki.mozilla.org/CA:Problematic_Practices#Long-lived_DV_certificates
Also here, I had difficulty to confirm if this applies to the ECC certs
or not. Maybe Rob can clarify this here?
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
Jabber: star...@startcom.org
Blog: https://blog.startcom.org
Robin Alden
> (to Frank Hecker)
> As per your comment in
> https://bugzilla.mozilla.org/show_bug.cgi?id=421946#c17 you
> state that no problematic practices associated with this CA,
> but I found that in section 2.4.1 domain validated wild cards
> are issued, which is listed in
>
http://wiki.mozilla.org/CA:Problematic_Practices#Wildcard_DV_SSL_certificate
s
>
> But I'm not sure which type the ECC certificates belong to
> (which letter under section 2.4.1) in which case e) might not
> apply.
We would like to be able to apply any of these to our ECC root. Initially I
would imagine we will position certificates with ECC keys as being a
high-end product and will not include DV certificates of any kind in the
product range, but we would like to retain the ability to issue ECC DV
certificates (including wildcards) at least until we establish that the
market no longer requires them.
> Oh and f) is also interesting ;-), I wonder how many
> "localhost" certificates were issued so far...
[Robin said...]
Not many! We do issue quite a number for organizations to use internally on
other names, though.
E.g. if we have a server on our corporate intranet called wiki.comodo then I
might want a certificate to allow me to use https://wiki.comodo. I can't
buy an SSL certificate from one of our range of Internet SSL certificates
because I can't pass the domain validation step. Hence we have a different
product range which, rather than validating domain ownership, validates that
the domain name is not usable on the internet.
>
> This CP/CPS also covers certificates with a validity of 10
> years which is again listed in
>
http://wiki.mozilla.org/CA:Problematic_Practices#Long-lived_DV_certificates
> Also here, I had difficulty to confirm if this applies to
> the ECC certs or not. Maybe Rob can clarify this here?
[Robin said...]
We would like to be able to apply any of these to our ECC root. Initially I
would imagine we will position certificates with ECC keys as being a
high-end product and will not include DV certificates of any kind in the
product range, but we would like to retain the ability to issue long-lived
ECC DV certificates at least until we establish that the market no longer
requires them.
Regards
Robin
Robin Alden
> Eddy Nigg wrote:-
> > Oh and f) is also interesting ;-), I wonder how many
> > "localhost" certificates were issued so far...
> Not many! We do issue quite a number for organizations to use internally
> on
> other names, though.
> E.g. if we have a server on our corporate intranet called wiki.comodo then
> I
> might want a certificate to allow me to use https://wiki.comodo. I can't
> buy an SSL certificate from one of our range of Internet SSL certificates
> because I can't pass the domain validation step. Hence we have a
> different
> product range which, rather than validating domain ownership, validates
> that
> the domain name is not usable on the internet.
I'd like to revise my answer there since I had a few wires crossed.
f) refers to an SSL product which is limited in such a way that it isn't
generally usable on the public internet. We offer no warranty on the
product, and the main part of the domain validation is to ensure that the
domain name in the certificate is not a valid internet name or, if the
certificate is for an explicit IP address, that the IP address is not
internet routable.
We do issue quite a number of these certificates, especially for use within
enterprise organizations.
We don't issue many to localhost in particular but we have issued some!
Regards
Robin
Frank Hecker
> As per your comment in
> https://bugzilla.mozilla.org/show_bug.cgi?id=421946#c17 you state that
> no problematic
> practices associated with this CA, but I found that in section 2.4.1
> domain validated wild cards are issued, which is listed in
> http://wiki.mozilla.org/CA:Problematic_Practices#Wildcard_DV_SSL_certificates
My understanding is that this root and it hierarchy at present are not
being used for DV certs, but Comodo could do so in future, per the
existing CPS. We went through the issue of Comodo DV certs on a previous
request; if you recall, my final determination was that the practices of
issuing wildcard DV certs and long-lived DV certs, though potentially
problematic, were not in my opinion sufficient to justify denying the
request. That's my position in this case as well.
Eddy Nigg
> f) refers to an SSL product which is limited in such a way that it isn't
> generally usable on the public internet. We offer no warranty on the
> product, and the main part of the domain validation is to ensure that the
> domain name in the certificate is not a valid internet name or, if the
> certificate is for an explicit IP address, that the IP address is not
> internet routable.
>
> We do issue quite a number of these certificates, especially for use within
> enterprise organizations.
> We don't issue many to localhost in particular but we have issued some!
>
Apparently you seem to do all the things a serious CA shouldn't :-)
Don't take it personal, but issuing certificates for "localhost"? I
meant it rather as a joke...
In my opinion, Intranets should secure them either by an internal CA or
by using an internal network domain instead of using hostnames. For
example the internal network could be represented as intern.domain.com,
whereas a certificate would be issued to server.intern.domain.com. The
DNS could be served by an internal as well as an external DNS server and
point to the internal private IP addresses.
An attack on hostnames is rather easy and I guess no validation is
performed nor uniqueness is guarantied either.
Eddy Nigg
My point was that Comodo does issue certificates according to the
problematic practices listed in our document. Not only that, it does
more than one of those practices. You stated in the bug however that
Comodo doesn't issue certificates according to the "Problematic Practices"!
I have no illusion about your expected decision since we went through
this not long ago....just wanted to set the facts strait!
Eddy Nigg
> f) refers to an SSL product which is limited in such a way that it isn't
> generally usable on the public internet. We offer no warranty on the
> product, and the main part of the domain validation is to ensure that the
> domain name in the certificate is not a valid internet name or, if the
> certificate is for an explicit IP address, that the IP address is not
> internet routable.
>
> We do issue quite a number of these certificates, especially for use within
> enterprise organizations.
> We don't issue many to localhost in particular but we have issued some!
>
Thanks Rob for this information. I want to raise here a concern about
this practice. I view hostname based certificates not something public
CAs should be involved since with little knowledge an attack on those
sites is rather easy to perform. Considering that NO validations are
performed nor that the hostnames have to be unique (considering that you
mentioned that you issue SOME certificates for "localhost", which is
more than one), I suspect this to be in contradiction to the Mozilla CA
Policy:
In http://www.mozilla.org/projects/security/certs/policy/ section 7
explicitly states:
"for a certificate to be used for SSL-enabled servers, the CA takes
reasonable measures to verify that the entity submitting the certificate
signing request has registered the domain(s) referenced in the
certificate or has been authorized by the domain registrant to act on
the registrant's behalf"
Uniqueness of the common name field is not mentioned explicit in the
Mozilla CA policy, but nevertheless it's industry standard that CN
fields are unique per issuer (for server certificates). Now, issuing
certificates for hostnames AND no uniqueness is required, I few the risk
even higher (since the same issuer might issue the same certificates,
one which might be used for such an attack). Please note that there is
NO validation performed, meaning anybody literally can get a certificate
as would be used somewhere else...
Disclaiming any warranty doesn't cut I think...than why issue them in
first place?
Now, I suggest to Frank to review this matter seriously and to evaluate
the risk which might be involved with hostname based certificates.
Robin Alden
It does state exactly that, and its fine and dandy as far as it goes.
It does not say exactly what a "domain" is in this context.
Is it the intention to prohibit trusted SSL certificates for IP addresses?
Is it the intention to prohibit trusted SSL certificates for private host
names which are not resolvable through DNS on the public internet?
>
> Uniqueness of the common name field is not mentioned explicit in the
> Mozilla CA policy
[Robin said...]
Good. Then we don't need to consider it here.
>, but nevertheless it's industry standard that CN
> fields are unique per issuer (for server certificates).
[Robin said...]
It's not standard in my industry. Serial numbers, yes, common names, no.
> Now, issuing
> certificates for hostnames AND no uniqueness is required, I few the risk
> even higher (since the same issuer might issue the same certificates,
> one which might be used for such an attack). Please note that there is
> NO validation performed, meaning anybody literally can get a certificate
> as would be used somewhere else...
>
> Disclaiming any warranty doesn't cut I think...than why issue them in
> first place?
[Robin said...]
I don't understand the premise on which you made that statement. You must
be aware why people choose to use trusted SSL certificates.
The warranty we offer with our certificates is outside the scope of the
inclusion request, of course, but it relates to losses incurred by relying
parties in e-commerce transactions. We don't expect anyone to use a
certificate for a private host name to protect an e-commerce site.
>
> Now, I suggest to Frank to review this matter seriously and to evaluate
> the risk which might be involved with hostname based certificates.
>
[Robin said...]
Sure.
Robin
Frank Hecker
> My point was that Comodo does issue certificates according to the
> problematic practices listed in our document. Not only that, it does
> more than one of those practices. You stated in the bug however that
> Comodo doesn't issue certificates according to the "Problematic Practices"!
A fair point. My comment was based on the fact that Comodo isn't
currently issuing DV certs under the ECC root, and there's no firm
schedule for when they might do so. However you are correct that Comodo
reserves the right to do so under the scope of the existing CPS, and Rob
and Robin have stated that Comodo will expand the use of this root at
some point.
Eddy Nigg
> Eddy Nigg said:
>> In http://www.mozilla.org/projects/security/certs/policy/ section 7
>> explicitly states:
>>
>> "for a certificate to be used for SSL-enabled servers, the CA takes
>> reasonable measures to verify that the entity submitting the certificate
>> signing request has registered the domain(s) referenced in the
>> certificate or has been authorized by the domain registrant to act on
>> the registrant's behalf"
> [Robin said...]
> It does state exactly that, and its fine and dandy as far as it goes.
> It does not say exactly what a "domain" is in this context.
Well, we all know what a domain is....
> Is it the intention to prohibit trusted SSL certificates for IP addresses?
I think an IP address is almost on the same level as a domain name, but
even here there can be problems. For example if you are willing to
validate dynamic assigned IP addresses, than this can be actively
exploited obviously. An assigned IP may belong to somebody else within a
few hours difference only and then what?
> Is it the intention to prohibit trusted SSL certificates for private host
> names which are not resolvable through DNS on the public internet?
They can be easily replaced by real domain names as in my previous
example (server.intern.domain.com). In my opinion there is no
justification to use (and secure) hostname based servers.
> It's not standard in my industry. Serial numbers, yes, common names, no.
In other words, Comodo would issue multiple certificates for the very
same domain name? You could have multiple valid certificates for
www.mozilla.com?
And with your case of hostnames, we can have multiple certificates like
server1 owned by different subscribers? That's interesting...
Jean-Marc Desperrier
> [...]
> In other words, Comodo would issue multiple certificates for the very
> same domain name? You could have multiple valid certificates for
> www.mozilla.com?
It's an actually useful option. You may want the multiple servers that
will answer for www.mozilla.com to not share the same private key.
> And with your case of hostnames, we can have multiple certificates like
> server1 owned by different subscribers? That's interesting...
That part is of course much more dubious. But if you consider hostname
only servers to be acceptable, there's little ground to say multiple
subscrivers can't have one with the same name. Even if you'd decide to
try to enforce that, there's no way to restrein another CA that emits
hostname only certificat to issue the same one.
Eddy Nigg
>
> That part is of course much more dubious. But if you consider hostname
> only servers to be acceptable, there's little ground to say multiple
> subscrivers can't have one with the same name. Even if you'd decide to
> try to enforce that, there's no way to restrein another CA that emits
> hostname only certificat to issue the same one.
>
Well, that's true for any certificate, also FQDN based ones. But from
the same issuer? Different subscribers? Same CN value?
Robin Alden
> From: Eddy Nigg
> Sent: Wednesday, August 06, 2008 9:12 PM
> To: dev-tec...@lists.mozilla.org
> Subject: Re: Comodo ECC CA inclusion/EV request
>
> Robin Alden:
> > Eddy Nigg said:
> >> In http://www.mozilla.org/projects/security/certs/policy/ section 7
> >> explicitly states:
> >>
> >> "for a certificate to be used for SSL-enabled servers, the CA takes
> >> reasonable measures to verify that the entity submitting the
> certificate
> >> signing request has registered the domain(s) referenced in the
> >> certificate or has been authorized by the domain registrant to act on
> >> the registrant's behalf"
> > [Robin said...]
> > It does state exactly that, and its fine and dandy as far as it goes.
> > It does not say exactly what a "domain" is in this context.
>
> Well, we all know what a domain is....
>
Sure, but CAs issue certificates to IP addresses too (as we discuss below)
yet the policy does not allow for the possibility. Either the policy is
imprecise, or it is being flouted by the CAs that issue certificates for IP
addresses.
> > Is it the intention to prohibit trusted SSL certificates for IP
> addresses?
>
> I think an IP address is almost on the same level as a domain name, but
> even here there can be problems. For example if you are willing to
> validate dynamic assigned IP addresses, than this can be actively
> exploited obviously. An assigned IP may belong to somebody else within a
> few hours difference only and then what?
[Robin said...]
We do not consider dynamic IP addresses when validating IP addresses. We
look for static registration of an IP block. Ideally we want to see the
applicant registered as the owner of the block containing the IP address
being requested. Failing that we will accept written confirmation
(directly) from the block owner confirming that the IP address in question
is delegated to the applicant.
>
> > Is it the intention to prohibit trusted SSL certificates for private
> host
> > names which are not resolvable through DNS on the public internet?
>
> They can be easily replaced by real domain names as in my previous
> example (server.intern.domain.com). In my opinion there is no
> justification to use (and secure) hostname based servers.
[Robin said...]
I'm sure that some of our customers would argue over how easy it is to
replace these hostnames with FQDNs, but on reflection we do accept that the
use of what we are calling hostnames here could provide for an increased
risk that such a certificate could be used in a MITM attack, especially with
the (topical) possibilities of practical DNS poisoning attacks meaning that
there is an increased chance of an attacker being able to direct a reference
to a server by what appears to be an internal hostname to an external
server. Although not subject to the same threat of attacks on DNS we would
also include non-internet routable IP addresses as being of increased risk.
We therefore give a commitment that we will not issue any certificates which
are signed by, or benefit from cross-signing by, or otherwise inherit trust
from the ECC root which is the subject of this application that would
otherwise be allowed by the provisions of section 2.4.1 (f) of our main CPS.
Frank, would you consider these practices of issuing certificates to
hostnames* and also of issuing to non-internet routable IP addresses as
being something to add to your problematic practices list?
* here we mean "hostnames" to be any domain name whose ownership or intended
resolution cannot be discovered through the public domain registration and
DNS system.
>
> > It's not standard in my industry. Serial numbers, yes, common names,
no.
>
> In other words, Comodo would issue multiple certificates for the very
> same domain name? You could have multiple valid certificates for
> www.mozilla.com?
[Robin said...]
Yes, we would. Jean-Marc identified one case where it is desirable.
There are also cases when a server has been wiped (and so they private key
lost) and must be re-installed.
>
> And with your case of hostnames, we can have multiple certificates like
> server1 owned by different subscribers? That's interesting...
[Robin said...]
We are no longer requesting this facility for this root certificate.
>
> --
> Regards
>
> Signer: Eddy Nigg, StartCom Ltd.
[Robin said...]
OK Eddy, it looks like you got us to move on an aspect of policy! We will
also review the provision of Intranet certificates (as provided for by
section 2.4.1 f of our CPS) from our other roots.
Regards
Robin Alden
Comodo CA Ltd.
Kyle Hamilton
>
> In other words, Comodo would issue multiple certificates for the very
> same domain name? You could have multiple valid certificates for
> www.mozilla.com?
Technically, there is absolutely nothing wrong with this. Multiple
IPs can reverse to the same name, and the same name can forward to
multiple IPs. There's absolutely no reason why different IPs serving
the same name (www.mozilla.com) would have to use the same private key
or certificate.
-Kyle H
Frank Hecker
> Sure, but CAs issue certificates to IP addresses too (as we discuss below)
> yet the policy does not allow for the possibility. Either the policy is
> imprecise, or it is being flouted by the CAs that issue certificates for IP
> addresses.
You're correct, this is a gap in our policy, which assumes the more
typical case of an SSL certificate being tied to a domain name. We can
discuss revising the policy later, but for now I think it's reasonable
to say that issuing an SSL certificate tied to an IP address is OK as
long as the following is true:
* the IP address is public, i.e., reachable from the public Internet
* the subscriber owns/controls the IP address on a permanent basis,
i.e., it's a static IP address assigned to the subscriber by the
subscriber's ISP (either a standalone address or part of a
subscriber-controlled block of addresses)
This is basically the current policy with "public static IP address"
standing in place of "domain". As with domains, there are natural
extensions to this case, most notably an SSL cert with multiple IP
addresses included using SubjAltName; in this case the CA would do the
verification for all the IP addresses referenced in the cert.
(To others with more knowledge of this than I: Is there a notion of an
"IP wildcard" cert, i.e., an SSL cert with a wildcard like 1.2.3.*,
where the cert would be recognized as valid for an server with IP
address in that range? If so, the implications for policy seem pretty
straightforward: the CA should verify that the subscriber controls the
entire IP address range.)
> We do not consider dynamic IP addresses when validating IP addresses. We
> look for static registration of an IP block. Ideally we want to see the
> applicant registered as the owner of the block containing the IP address
> being requested. Failing that we will accept written confirmation
> (directly) from the block owner confirming that the IP address in question
> is delegated to the applicant.
IMO this meets the proposed policy requirements I outlined above.
> I'm sure that some of our customers would argue over how easy it is to
> replace these hostnames with FQDNs, but on reflection we do accept that the
> use of what we are calling hostnames here could provide for an increased
> risk that such a certificate could be used in a MITM attack, especially with
> the (topical) possibilities of practical DNS poisoning attacks meaning that
> there is an increased chance of an attacker being able to direct a reference
> to a server by what appears to be an internal hostname to an external
> server. Although not subject to the same threat of attacks on DNS we would
> also include non-internet routable IP addresses as being of increased risk.
> We therefore give a commitment that we will not issue any certificates which
> are signed by, or benefit from cross-signing by, or otherwise inherit trust
> from the ECC root which is the subject of this application that would
> otherwise be allowed by the provisions of section 2.4.1 (f) of our main CPS.
Thanks, this addresses an issue I was concerned about.
> Frank, would you consider these practices of issuing certificates to
> hostnames* and also of issuing to non-internet routable IP addresses as
> being something to add to your problematic practices list?
Yes, I'll do that. (Incidentally, I'm now calling it the "potentially
problematic practices" list, because there's a lack of consensus on the
extent to which some of these practices are problems in general.)
>> In other words, Comodo would issue multiple certificates for the very
>> same domain name? You could have multiple valid certificates for
>> www.mozilla.com?
> [Robin said...]
> Yes, we would. Jean-Marc identified one case where it is desirable.
> There are also cases when a server has been wiped (and so they private key
> lost) and must be re-installed.
I don't think it is realistic or appropriate to mandate that all
currently valid certs issued by a CA have unique FQDNs associated with
them; in other words, I think that having multiple certs with the same
FQDN is not and of itself indicative of a problem.
(I should also add that there's a similar case that's fairly common and
unremarkable, where a CA issues a wildcard cert for, e.g.,
*.example.com, and also a cert for a specific domain otherwise
encompassed in the wildcard, e.g., foo.example.com. As with the case of
multiple certs with the same FQDN, here too we have the theoretical
possibility of having one cert/private key pair that could be
substituted for another without a typical user noticing.)
To the best of my knowledge we've now covered all the outstanding issues
for this request, and we're past the end of the second comment period.
I'm going to proceed now to render a final decision. More later...
Frank Hecker
We're past the end of the second comment period, and based on all the
comments up to now I'm now ready to make a final decision.
Of the additional issues that came up in the second comment period, a
couple (wildcard DV certs and long-lived certs) I've already dealt with
in a prior request, one (multiple certs with the same FQDN) I don't see
as a reason for rejection of the request (per my previous message), and
one (certs with hostnames and private IP addresses) I consider now moot
based on the previous public statement/commitment by Comodo. Also, I've
given my opinion that issuance of certs for static public IP addresses,
though not strictly speaking addressed in our policy, is in fact
consistent with the intent of our policy assuming ownership/control of
the addresses is verified.
Based on the resolution of these issues I'm therefore officially
approving the Comodo request to add the Comodo ECC Certification
Authority root certificate to NSS and to enable it in PSM for EV use.
I have filed bug 450427 against NSS and bug 450429 against PSM for the
actual changes:
https://bugzilla.mozilla.org/show_bug.cgi?id=450427
https://bugzilla.mozilla.org/show_bug.cgi?id=450429
Eddy Nigg
>> I think an IP address is almost on the same level as a domain name, but
>> even here there can be problems. For example if you are willing to
>> validate dynamic assigned IP addresses, than this can be actively
>> exploited obviously. An assigned IP may belong to somebody else within a
>> few hours difference only and then what?
> [Robin said...]
> We do not consider dynamic IP addresses when validating IP addresses. We
> look for static registration of an IP block. Ideally we want to see the
> applicant registered as the owner of the block containing the IP address
> being requested. Failing that we will accept written confirmation
> (directly) from the block owner confirming that the IP address in question
> is delegated to the applicant.
Robin, it would be good that your CP/CPS would make that clear as well.
The policy which you mentioned above is in my opinion sufficient for the
purpose of IP addresses.
>
> Frank, would you consider these practices of issuing certificates to
> hostnames* and also of issuing to non-internet routable IP addresses as
> being something to add to your problematic practices list?
I think we should do that...
>
> * here we mean "hostnames" to be any domain name whose ownership or intended
> resolution cannot be discovered through the public domain registration and
> DNS system.
Exactly.
> Yes, we would. Jean-Marc identified one case where it is desirable.
> There are also cases when a server has been wiped (and so they private key
> lost) and must be re-installed.
So what prevents you from revoking the affected certificate and issue a
new one? Considering that the server was "wiped" for whatever reason,
revoking this certificate would make sense if the "whipping" wasn't
intentional (crash, mistake, etc). I think that the right action should
be to revoke it.
If the "whipping" was intentional, the subscriber could have backed up
and reused the same certificate.
>> And with your case of hostnames, we can have multiple certificates like
>> server1 owned by different subscribers? That's interesting...
> [Robin said...]
> We are no longer requesting this facility for this root certificate.
Good :-)
> [Robin said...]
> OK Eddy, it looks like you got us to move on an aspect of policy! We will
> also review the provision of Intranet certificates (as provided for by
> section 2.4.1 f of our CPS) from our other roots.
Excellent Robin! I have a small backlog here, though I understand that
your request is already approved. But I'm glad that we can improve
certain aspects together with one of the leaders of this industry...
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
Frank Hecker
> Robin Alden wrote:
<snip>
>> Frank, would you consider these practices of issuing certificates to
>> hostnames* and also of issuing to non-internet routable IP addresses as
>> being something to add to your problematic practices list?
>
> Yes, I'll do that.
Done:
As usual, others should feel free to make revisions as appropriate; it
*is* a wiki after all.
Eddy Nigg
>
> Yes, I'll do that. (Incidentally, I'm now calling it the "potentially
> problematic practices" list, because there's a lack of consensus on the
> extent to which some of these practices are problems in general.)
>
Frank, where is the lack of consensus exactly? Are you referring to bug
449610? If yes, I think that Wan-Teh misunderstood the "problematic
practice" issue initially and that the opposition from Nelson is rather
based on the argument in regards to the UI, which isn't a policy decision.
I'm against the weakening of the "Problematic Practices" page if
possible, since it's still not an approved policy, but rather some
guideline. Degrading it to "Potentially" makes it even less effective...
...or perhaps we can discuss this here first...
I saw that Kathleen is already asking new applicants for CA cert
inclusions those questions from the "Problematic Practices" which I
think to be quite effective. This might also lead to some of those
practices to be part of the Mozilla CA Policy...
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
Frank Hecker
> Frank Hecker:
>> Yes, I'll do that. (Incidentally, I'm now calling it the "potentially
>> problematic practices" list, because there's a lack of consensus on the
>> extent to which some of these practices are problems in general.)
>
> Frank, where is the lack of consensus exactly?
IIRC the reason I changed the wording to "potentially problematic" was
that some of the practices weren't necessarily "problematic" in all
contexts, at least IMO. Thus, for example, distributing private keys
using PKCS#12 is not necessarily a problem, rather it's a problem if the
CA doesn't exercise proper care in how the keys are distributed.
The issue here may be in how we interpret the word "problematic". I was
interpreting the term "problematic" to be simply a fancy way of saying
"this *is* a problem", as opposed to "potentially problematic", which to
me means "this *could be* a problem".
> I saw that Kathleen is already asking new applicants for CA cert
> inclusions those questions from the "Problematic Practices" which I
> think to be quite effective.
Yes, I encouraged Kathleen to collect that information, so we could get
a better idea as to how widespread these practices are, and where they
might constitute real problems. (I was also trying to anticipate any
concerns you might express :-)
Eddy Nigg
> Eddy Nigg wrote:
>
> IIRC the reason I changed the wording to "potentially problematic" was
> that some of the practices weren't necessarily "problematic" in all
> contexts, at least IMO. Thus, for example, distributing private keys
> using PKCS#12 is not necessarily a problem, rather it's a problem if the
> CA doesn't exercise proper care in how the keys are distributed.
All clear!
> Yes, I encouraged Kathleen to collect that information, so we could get
> a better idea as to how widespread these practices are, and where they
> might constitute real problems. (I was also trying to anticipate any
> concerns you might express :-)
:-)