Re: (nss-3.12.6) unable to engage FIPS mode: "security library: invalid arguments."

[Robin H. Johnson]

On Sun, Jun 13, 2010 at 03:08:07PM -0700, Nelson B Bolyard wrote:
> On 2010-06-13 13:02 PDT, Robin H. Johnson wrote:
> > On Sun, Jun 13, 2010 at 02:02:39AM -0700, Nelson B Bolyard wrote:
> >>> The root of the problem is that the shared libraries can change
> >>> POST-install, as needed for ELF signing, split-debug and prelinking. The
> >>> ELF signing is a catch-22. Either I have to run shlibsign afterwards, or
> >>> I have to not sign those files, and leave them open to potential
> >>> compromise.
> >> Rerun shlibsign.  It's fast and easy.
> > As an intermediate related question, is there a standalone verification
> > tool for the CHK files
> > 
> > shlibsign -V -i  seems to just sign again, not verify.
> Yes.  modutil is that test tool.  You already know how to use it.
> Just drop the -force argument.
I should have clarified, that I want to verify without any disk writes,
nor assuming a pre-setup database.

# modutil -chkfips true
modutil: function failed: security library: bad database.

Just exactly that the chk files are valid, and nothing else.

-- 
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail : robb...@gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: (nss-3.12.6) unable to engage FIPS mode: "security library: invalid arguments."

[Robin H. Johnson]

On Sun, Jun 13, 2010 at 02:02:39AM -0700, Nelson B Bolyard wrote:
> > The root of the problem is that the shared libraries can change
> > POST-install, as needed for ELF signing, split-debug and prelinking. The
> > ELF signing is a catch-22. Either I have to run shlibsign afterwards, or
> > I have to not sign those files, and leave them open to potential
> > compromise.
> Rerun shlibsign.  It's fast and easy.
As an intermediate related question, is there a standalone verification
tool for the CHK files

shlibsign -V -i  seems to just sign again, not verify.

> > Running shlibsign does remedy the problem.
> > 
> > However, this entire matter could be remedied if some more useful error
> > had been returned instead of 'Invalid Arguments'. Something to indicate
> > that the library checksums no longer matched.
> It's open source.  Patches are invited.
Ok, I'll take that up.

-- 
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail : robb...@gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85


pgptVek32QP0X.pgp
Description: PGP signature
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: (nss-3.12.6) unable to engage FIPS mode: "security library: invalid arguments."

[Robin H. Johnson]

On Sat, Jun 12, 2010 at 02:11:14PM -0700, Nelson B Bolyard wrote:
> You have a problem with a distribution of NSS that is not identical to the
> NSS as built from the upstream NSS source repository.  Mozilla's NSS team
> supports NSS as it comes from the builds from the upstream NSS source
> repository.  Mozilla's NSS team does not attempt to keep track of all the
> changes made to NSS by every downstream Linux distro.  If the upstream NSS
> works, but some downstream distribution does not, then the differences are
> due to changes outside of the control of Mozilla's NSS team, and primary
> support for those problems (that are unique to a downstream distribution)
> must come from the suppliers of that downstream distribution.
LOOK at the links I provided, there are ZERO changes to the actual
source code.

There is an additional file packaged for pkgconfig support, and we
compile with -fno-strict-aliasing.

> 
> It is true that virtually every Linux distribution modifies NSS sources
> significantly and distributes a downstream flavor of NSS that differs from
> the upstream version in a number of ways.
> 
> For some distros, the differences are so minor that you can simply download
> the upstream NSS sources, build them yourself, and use the resultant
> binaries as a replacement for the binaries that came with the distribution,
> and it all works fine.
> 
> For other distros, they've made changes on such a large scale, such as
> renaming the functions, renaming the shared libraries and splitting up the
> shared libraries so that they no longer all live in the same directory, that
> a vanilla build of NSS from upstream sources simply will not work with
> programs that were built to work with that distro's NSS libraries.  If your
> distro is one of those, then you'll have no choice but to get help from the
> maintainers of that distro.
NONE of the above is the case, as I noted in previous emails. The C
source is absolutely stock.

> It may be that, in your case, the problem is as simple as this: the distro
> did not include the ".chk" files that are generated during the NSS build
> process, or it put them in the wrong directory or gave them the wrong file
> names, so that NSS cannot find them.  Or they may have changed the shared
> libraries, but not regenerated the .chk files.  If that is the case, and the
> distro HAS distributed NSS's shlibsign program, then you may be able
> to remedy this yourself by generating replacements for the missing (or old)
> .chk files using shlibsign.  Instructions on how to use shlibsign may be
> found at
> http://www.mozilla.org/projects/security/pki/nss/tech-notes/tn6.html
Ok, this helped tremendously.

The root of the problem is that the shared libraries can change
POST-install, as needed for ELF signing, split-debug and prelinking. The
ELF signing is a catch-22. Either I have to run shlibsign afterwards, or
I have to not sign those files, and leave them open to potential
compromise.

Running shlibsign does remedy the problem.

However, this entire matter could be remedied if some more useful error
had been returned instead of 'Invalid Arguments'. Something to indicate
that the library checksums no longer matched.

-- 
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail : robb...@gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85


pgp2rACleeKNf.pgp
Description: PGP signature
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: (nss-3.12.6) unable to engage FIPS mode: "security library: invalid arguments."

[Robin H. Johnson]

On Sat, Jun 12, 2010 at 12:15:07PM -0700, Matt McCutchen wrote:
> On Jun 12, 2:25 pm, Nelson B Bolyard  wrote:
> > On 2010-06-10 22:59 PDT, Robin H. Johnson wrote:
> > > The testcase has been run on Arch and Fedora now, and both of those
> > > cases it works fine.
> > Does that mean this problem is resolved?
> As I read, it is not; it was reported on Gentoo Linux.
No, it still exists on Gentoo, and I haven't been able to reproduce it
anywhere else.

Build script:
http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/dev-libs/nss/nss-3.12.6-r1.ebuild?revision=1.7&view=markup
Patches:
http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/dev-libs/nss/files/

-- 
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail : robb...@gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: (nss-3.12.6) unable to engage FIPS mode: "security library: invalid arguments."

[Robin H. Johnson]

On Fri, Jun 11, 2010 at 05:59:27AM +, Robin H. Johnson wrote:
> On Thu, Jun 10, 2010 at 10:45:03PM +0000, Robin H. Johnson wrote:
> > Testcase 2:
> > (see attached minimal C code, based on posts to the list and used in the
> > modutils source AND Mozilla).
> Bah, forgot the actual file.
> 
> The testcase has been run on Arch and Fedora now, and both of those
> cases it works fine.

Ah, no, this list is stripping my code.

//-
//compile: gcc nss-fipstest.c $(pkg-config --cflags nss) $(pkg-config --libs 
nss) -o nss-fipstest
#include 
#include 
#include 
/* Define to the default location of the NSS configuration directory. */
#define DEFAULT_CONFIG_DIR "/etc/pki/nssdb"
int main(int argc, char **argv) {
const char* configdir = DEFAULT_CONFIG_DIR;
int status;
status = NSS_NoDB_Init(configdir);
if (status != SECSuccess) {
fprintf(stderr, "Error initializing NSS.\n");
return status;
}
  // The way to toggle FIPS mode in NSS is extremely obscure.
  // Basically, we delete the internal module, and voila it
  // gets replaced with the opposite module, ie if it was
  // FIPS before, then it becomes non-FIPS next.
  SECMODModule *internal;

  // This function returns us a pointer to a local copy of
  // the internal module stashed in NSS.  We don't want to
  // delete it since it will cause much pain in NSS.
  internal = SECMOD_GetInternalModule();
  if (!internal) {
  fprintf(stderr, "Failed to get internal module\n");
  return 1;
  }

  fprintf(stderr, "Got internal module: %s\n", internal->commonName);
  SECStatus srv = SECMOD_DeleteInternalModule(internal->commonName);
  if (srv != SECSuccess) {
  fprintf(stderr, "Failed to delete internal module (%s)\n", 
internal->commonName);
  return 1;
  }

  return 0;
}
//-

-- 
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail : robb...@gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85


pgpb1XBtRyxwO.pgp
Description: PGP signature
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: (nss-3.12.6) unable to engage FIPS mode: "security library: invalid arguments."

[Robin H. Johnson]

On Thu, Jun 10, 2010 at 10:45:03PM +, Robin H. Johnson wrote:
> Testcase 2:
> (see attached minimal C code, based on posts to the list and used in the
> modutils source AND Mozilla).
Bah, forgot the actual file.

The testcase has been run on Arch and Fedora now, and both of those
cases it works fine.

-- 
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail : robb...@gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85


pgpe2R3lhYEfZ.pgp
Description: PGP signature
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

(nss-3.12.6) unable to engage FIPS mode: "security library: invalid arguments."

[Robin H. Johnson]

I was trying to package up the hmaccalc application from Fedora so we can have
it in Gentoo as well, and noticed that it was failing when it tried to engage
FIPS mode.

Doing some backtracing, it seems FIPS isn't enabling at all on my system, as
the DeleteInternalModule call is returning INVALID_ARGS.

Testcase 1:
# d=/tmp/fips M="modutil -dbdir $d" ; mkdir -p $d ; $M -create -force
# $M -chkfips  true  ; $M -fips true -force ; $M -chkfips  true
FIPS mode disabled.
security library: invalid arguments.
ERROR: Unable to switch FIPS modes.
FIPS mode disabled.
# $M -rawlist ; $M -list
 name="NSS Internal PKCS #11 Module" parameters="configdir=/tmp/fips
certPrefix= keyPrefix= secmod=secmod.db flags=readOnly " NSS="trustOrder=75
cipherOrder=100
slotParams={0x0001=[slotFlags=RSA,RC4,RC2,DES,DH,SHA1,MD5,MD2,SSL,TLS,AES,Camellia,SEED,RANDOM
askpw=any timeout=30 ] }  Flags=internal,critical"


Listing of PKCS #11 Modules
---
  1. NSS Internal PKCS #11 Module
 slots: 2 slots attached
status: loaded

 slot: NSS Internal Cryptographic Services
token: NSS Generic Crypto Services

 slot: NSS User Private Key and Certificate Services
token: NSS Certificate DB
---

Testcase 2:
(see attached minimal C code, based on posts to the list and used in the
modutils source AND Mozilla).

Build params:
USE_64=1
NSPR_INCLUDE_DIR=`nspr-config --includedir`
NSPR_LIB_DIR=`nspr-config --libdir`
BUILD_OPT=1
NSS_USE_SYSTEM_SQLITE=1
NSDISTMODE=copy
NSS_ENABLE_ECC=1
XCFLAGS="${CFLAGS}"
FREEBL_NO_DEPEND=1

The only patches applied in Gentoo add some pkconfig bits, 

-- 
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail : robb...@gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85


pgpold6im0x1N.pgp
Description: PGP signature
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

RE: Suggestion: Announce date for MD5 signature deactivation

[Robin Alden]

> -Original Message-
> On 1/9/09 12:51 PM, Johnathan Nightingale wrote:
> 
> >  - Do the work to arm ourselves so that when we are confident pulling
> > the trigger, we can actually do so with minimal changes (in case it
> > happens in a point release, for instance)
> >  - Establish our feelings around how much of the net we are comfortable
> > invalidating if we kill an algorithm
> >  - Establish a timeline we think is compatible with that
>
> Benjamin Smedberg wrote:
> Is it possible to disable the MD5 algorigthm for EV certificate chains
> sooner than for regular (DV) certificate chains? Or even disable SHA1 for
> EV
> chains and require SHA-256?
> 

MD5 is already not an option for EV SSL certs.  The only place MD5 is
permitted is in the (EV) root certificate, and (as has been written about
recently on dev-tech-crypto) the trust anchor is protected by other means
than its signature.

Regards
Robin

___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: CAs and external entities (resellers, outsourcing)

[robin]

On Jan 1, 12:59 am, Eddy Nigg wrote:
> Robin, could you provide some clarifications and your opinion concerning
> the post I made titled "Facts about Comodo Resellers and RAs" in
> particular in relation to the CP and CP statements here:
>
> http://groups.google.com/group/mozilla.dev.tech.crypto/msg/416aa6f5b5610ccf

Eddy,
   That thread has a lot going on and I don't propose to try to
address it all.  However, I will address your reading of our CPS in an
attempt to bring some degree of clarity.
If I correctly understood your referenced post, you asserted that:
1) Comodo outsources validation to its (non RA) resellers.
2) That the outsourcing of validation to anyone is in direct conflict
with section 4.2.7 of the PositiveSSL CPS.

#1 is incorrect.
You refer to section 1.10.2 of the main CPS as evidence for your
assertion, but that section specifically refers to our main RA class
of partners, which we denominate "Web Host Resellers".

#2 is also incorrect.
The PositiveSSL CPS is an addendum to the main CPS and should be
considered in conjunction with the main CPS and its other addenda.
You refer to section 4.2.7 of the PositiveSSL CPS in particular,
noting that is says ".. Comodo checks that the Subscriber has control
over the Domain name ..".
But consider it together with the rest of the main CPS.  Section 4.2.7
(of the PositiveSSL CPS) is a new subsection to be added to section
4.2 "Application Validation" in the main CPS.  Section 4.2 as a whole
(in the main CPS) talks throughout of "Comodo checks..", "Comodo
validates..", etc, but note also the preceeding sections of the main
CPS, 4.1, and 4.1.1 which set out exactly who is to do the
validation.  Sections 4.1 and 4.1.1 make clear who is to do the
certificate application processing.  Taking sections 4.1 and 4.1.1
into consideration makes it clear that the validation to be performed
in section 4.2 may, in fact, be done either by Comodo or by its
appointed RAs.
Sections 1.10, 2.2, 2.8, 3.9.3, 4.13.1, 5.15, 5.18, and 5.26 of the
main CPS also further serve to define the interaction of RAs in the
processing of certificate applications.

Regards
Robin Alden
Comodo
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Unbelievable!

[robin]

On Dec 24, 2:13 am, "Paul C. Bryan"  wrote:
> On Dec 23, 5:56 pm, ro...@comodo.com wrote:
> Some questions:
>
> 1. Does Comodo take full responsibility for the actions of its
> resellers? If so, how should the repercussions of such failures be to
> Comodo?
Comodo accepts responsibility for the work of its RAs in the
validation that they do leading to the issuance of certificates under
our root certificates.

>
> 2. Are resellers subject to the same audits that Comodo presumably had
> to undergo to get its root certs added to Mozilla? Who performs, and
> who verifies such audits? How often are they performed?
No, the RAs are not subject to the same audits as Comodo.  Comodo
undergoes an annual external audit to maintain our Webtrust
certification for CAs.
http://www.cica.ca/download.cfm?ci_id=45239&la_id=1&re_id=0
https://cert.webtrust.org/ViewSeal?id=804

>
> 3. Are you willing to openly, continually disclose your list of
> resellers, the frequency of audits, audit methodology, and actual
> audit reports so that third parties can evaluate whether Comodo is
> trustworthy as a CA?
That is a question combined with an assertion.
To the question: on a unilateral basis, no, Comodo wouldn't reveal
that level of detail of our internal operation.  If all CAs were
required to provide the information, either to retain Webtrust
certification or to gain or retain access to the root program of a
major browser or other platform, then we would reconsider.
To the assertion that this is a pre-requisite for a CA to be
trustworthy: I am not aware that it is Mozilla's policy to require
this information to be disclosed.
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Unbelievable!

[robin]

On Dec 25, 4:49 pm, Frank Hecker  wrote:
> Michael Ströder wrote:
> > Could you please define a time-frame within Comodo MUST react?
>
> Comodo (in the person of Robin Alden) has already made a reply:
>
> http://groups.google.com/group/mozilla.dev.tech.crypto/msg/b24e70ea2c396bb5
>
> The question is, what else do what want Comodo to do in this case? They
> still have some certificates unaccounted for in terms of verifying the
> validation, and certainly I'd like to hear the status of that as soon as
> possible. Beyond that? It's somewhat of an open question.
>
Frank,
 We have finished our initial investigation on the certificates
issued by Certstar.

Of the 111 orders that had been placed through Certstar there remain
13 orders for which we have still not been able to gather adequate
evidence of the applicant having domain control.  We have therefore,
regrettably, revoked the certificates on those orders.

Of those 13 orders, 2 were placed by Eddy, for startcom.org and
www.mozilla.com, as he has already described.  As we previously
stated, the certificate for www.mozilla.com was revoked shortly after
it was issued.

Of the remaining 11 orders we do not have any reason to believe that
any were placed fraudulently and had we not set such a short timescale
to effect the (re-)validation and had it not been over this Holiday
season we believe that we would have been able to achieve validation
of domain control for all 11.

Certstar have passed to us all of their records for these customers
and we will ensure that they are contacted for 2 purposes:
a) to check if it would have been possible to complete the re-
validation
b) to offer a replacement certificate.
Some of the orders have either been charged-back or refunded.  We have
to accept the possibility that some of those customers will not assist
us in re-validation.

Regards
Robin Alden
Comodo
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Unbelievable!

[robin]

On Dec 23, 5:09 am, Frank Hecker  wrote:
> There are two general reasons for pulling a root, to address a clear and
> present danger to Mozilla users, and to punish a CA and deter others. My
> concern right now is with the former. I see at least three issues in
> relation to that:
>
> 1. Issuance of further non-validated certs by this reseller. Comodo
> seems to have addressed this by suspending the reseller's ability to get
> certs issued. (I can testify that this is the case, as I tried to
> duplicate Eddy's feat earlier today and got my uploaded CSR rejected.)
>
> 2. Potential problems with certs already sold through this reseller.
> Comodo should investigate this and take action if needed. (This need not
> necessarily require revoking all certificates associated with the
> reseller; for example, the existing certs and their associated domains
> could be re-validated, the registered domain owners could be notified of
> the potential for bogus certs floating around, etc.)
>
Frank,
We are in the process of reviewing all of the certificates that have
been issued where Certstar served as a RA for Comodo. Fortunately they
have only been involved in the validation of 111 certificates.  As I
previously mentioned as soon as we discovered the error with the
Mozilla.com certificate we suspended Certicom’s RA privileges.
Certstar’s RA activities remain suspended.

At this point it appears that the Mozilla and Startcom certificates
were an anomaly, the result of the automatic DCV mechanism being
bypassed by accident.  Certstar’s account will remain suspended until
we are satisfied that the certificates issued for Mozilla and Startcom
were as Certstar maintains, the result of unintentional mistakes that
have been corrected with safeguards in place to prevent a
reoccurrence. Should Comodo decide to reinstate Certstar as an RA we
will review each certificate request until we are satisfied that
Certstar has been adequately trained and that yesterday’s mistake
cannot be duplicated.

Comodo has been able to verify that 73 of the 111 orders processed by
Certstar were processed pursuant to the requirements of our CPS and
our webhost RA terms and conditions.  We should have our review of the
remaining 38 certificates completed by tomorrow evening.  If we are
unable to verify any validation, we will revoke the applicable
certificate.


> 3. Potential problems with other Comodo resellers. I'm not going to tell
> Comodo how to operate its reseller network, but they certainly should
> take a look at whether and where this might be a problem with other
> resellers, and how they could revamp their systems to reduce potential
> problems with resellers.
>
Comodo takes it responsibility to supervise RAs very seriously and we
actively audit their performance. While it is not practical to audit
100% of their work, we audit a representative sample.  In the past we
have discovered only a few isolated incidents where our sub CAs or RAs
failed to follow the applicable guidelines.  When this has occurred we
have suspended the account, performed additional audit activities and
where appropriate revoked certificates. We are confident that our
existing system works well and are constantly looking for ways to
improve it.

We apologize for Certstar’s mistake and assure you that we will
redouble our self-auditing efforts to insure the problem does not
repeat itself.

Regards
Robin Alden
Comodo
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

RE: Unbelievable!

[Robin Alden]

Eddy, 

As I noted in my prior correspondence, Comodo has undertaken an internal
review of the Certstar reseller account.  We have informed CertStar that
their email violates their contractual obligation to refrain from sending
unsolicited emails and that their email could be interpreted as misleading
and confusing to the customer.  During our review, we discovered that
Certstar had apparently issued a certificate to mozilla.com without
validating control of the domain.  We immediately revoked the certificate
(prior to your posting) and have suspended Certstar's reseller activities
until our investigation has been completed.  Please let me know if you have
any further problems.  

Regards
Robin Alden
Comodo

> -Original Message-
> From: dev-tech-crypto-bounces+robin=comodo@lists.mozilla.org
> [mailto:dev-tech-crypto-bounces+robin=comodo@lists.mozilla.org] On
> Behalf Of Eddy Nigg
> Sent: Tuesday, December 23, 2008 1:34 AM
> To: dev-tech-crypto@lists.mozilla.org
> Subject: Re: Unbelievable!
> 
> On 12/23/2008 03:15 AM, Robin Alden:
> > Eddy,
> > That reseller's ability to sell Comodo certificates has been
> > suspended while we investigate why they are apparently not fulfilling
> their
> > contractual obligations to us.
> 
> How can you outsource such a critical part as domain control validation
> to a reseller is a complete mystery to me! Your controls (if any) have
> completly failed.
> 
> And apparently if the fish stinks at the tail, chances that the head is
> rotten too are pretty high.
> 
> > We revoked your certificate for mozilla.com.
> >
> 
> I suggest to revoke ALL certificates from this reseller and perform an
> urgent review of your policies and implementations in relation to
> resellers at all. Other steps might be needed as well, you know better
> than me.
> 
> 
> --
> Regards
> 
> Signer: Eddy Nigg, StartCom Ltd.
> Jabber: start...@startcom.org
> Blog: https://blog.startcom.org
> ___
> dev-tech-crypto mailing list
> dev-tech-crypto@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-crypto

___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

RE: Unbelievable!

[Robin Alden]

Eddy,
That reseller's ability to sell Comodo certificates has been
suspended while we investigate why they are apparently not fulfilling their
contractual obligations to us.
We revoked your certificate for mozilla.com.

Regards
Robin Alden
Comodo

> -Original Message-
> From: dev-tech-crypto-bounces+robin=comodo@lists.mozilla.org
> [mailto:dev-tech-crypto-bounces+robin=comodo@lists.mozilla.org] On
> Behalf Of Eddy Nigg
> Sent: Monday, December 22, 2008 10:25 PM
> To: dev-tech-crypto@lists.mozilla.org
> Subject: Unbelievable!
> 
> https://blog.startcom.org/?p=145
> 
> --
> Regards
> 
> Signer: Eddy Nigg, StartCom Ltd.
> Jabber: start...@startcom.org
> Blog: https://blog.startcom.org
> ___
> dev-tech-crypto mailing list
> dev-tech-crypto@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-crypto

___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

RE: Comodo ECC CA inclusion/EV request

[Robin Alden]

> -Original Message-
> From: Eddy Nigg
> Sent: Wednesday, August 06, 2008 9:12 PM
> To: dev-tech-crypto@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
> 
[Robin said...] 
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.

___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

RE: Comodo ECC CA inclusion/EV request

[Robin Alden]

Eddy Nigg said:-
> Robin Alden:
> > 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"
[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.
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

___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

RE: Comodo ECC CA inclusion/EV request

[Robin Alden]

Robin Alden wrote:-
> Eddy Nigg wrote:-
> > 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.
[Robin said...] 
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

___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

RE: Comodo ECC CA inclusion/EV request

[Robin Alden]

Eddy Nigg wrote:-
> (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. 
[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 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

___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

RE: Comodo request for EV-enabling 3 existing roots

[Robin Alden]

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, don't perform the
> practices your CA apparently does and which I view as a heightened risk.
> That's also the reason why this issue has come up with your requests at
> this time. Because of my involvement with the NSS team, I had the chance
> to read enough CPSs from a wide range of CAs in order to positively
> confirm that.
> 
> In that respect it's your CA which introduces an unfair balance in the
> commercial playing field. But should I encourage now to have all other
> CAs adopt your risky behavior? At various occasions you referred to your
> commercial obligations, but what about your other obligations to the
> industry and to the relying parties, Mozilla being one of them? Most, if
> not all other CAs present in NSS, are aware of their responsibilities
> and duties beyond the commercial aspect and your CA is in the very
> minority! Lets maintain an even and fair level in every respect, which
> would call out for your CA to adjust!
[Robin said...] 
If I understand you correctly you are saying that considering lack of
evidence to the contrary you believe that Comodo is solely responsible for
lowering the standard of DV certificate issuance in these two respects?

You are probably more familiar with our competitors CPSs than I am so
perhaps you can explain to me how certificates such as the ones at
https://www.beileysoftware.com/fm.html  (10 year DV),
and 
https://iah.unc.edu (10 year wildcard DV)
relate to the matter in hand?

We are keen to meet Mozilla's requirements and we certainly will not
knowingly let our standards be below those of the rest of the market.

I genuinely hope that you are correct in this matter and that my
understanding is wrong, because if we can raise the standard of the DV
marketplace as a whole by modifying our own policy we will do so.  
On the other hand, I will not be able to act to raise our standards if our
competitors are not obliged to reach the same standard.

Regards
Robin

___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

RE: Comodo request for EV-enabling 3 existing roots

[Robin Alden]

> In terms of getting "concessions" from individual CAs: In the past we
> have held up approval of CA requests until we could be satisfied that
> CAs were in compliance with specifically-called-out requirements of our
> policy. For example, in a number of cases it wasn't clear at all from a
> CA's CPS what kind of applicant validation they did for given types of
> certificates. IIRC in at least one or two other cases we had CAs that
> had verification procedures that didn't appear to meet our bare minimum
> requirements, and we asked them to make improvements as a condition of
> approval. (An example would be a CA that issued individual certs usable
> for S/MIME email, but did not appear to actually verify that the
> individual controlled the email address named in the cert.)
[Robin said...] 
Fair enough.
> 
> I don't consider the above to be asking for concessions, I see it as
> simply asking CAs to do what pretty much any CA should do, in order to
> meet the explicitly called-out requirements of our policy--requirements
> that I consider consistent with standard CA industry practices.
[Robin said...] 
That's fine.  We are keen to comply with the CA policy because we want our
CA requests to be approved.
> 
> There are other cases where CAs engage in practices concerning which we
> didn't or don't have explicit policy requirements. Past and present
> examples include issuing end entity certs directly from roots, issuing
> multiple classes of certificates under a single root's hierarchy, having
> too many roots (for some definition of "too many"), issuing DV certs
> with lifetimes that are too long (for some definition of "too long"),
> issuing wildcard DV certs, having subordinate CAs that aren't externally
> audited, and so on. Lots of Mozilla community members (not just Eddy)
> have argued one way or the other on these issues, including claiming
> that one or more of these practices are security risks, urging that we
> deny particular CA requests on that basis, advocating that we change our
> policy to outlaw these practices, and so on.
> 
> My opinion is that resolution of these issues is better done outside the
> context of any particular CA request, as part of a more general
> discussion of revisions to our policy. Then we can look at the issues in
> the context of the CA industry as a whole (not just commercial CAs, but
> any CA whose root might be preloaded into Mozilla, including government
> and nonprofit CAs), and make better decisions about what if anything our
> policy should say about the practices in question.
[Robin said...] 
We are quite happy to keep the issues raised under discussion past the point
that our current rounds of CA requests are accepted.  None of the issues
raised are spurious.  
Our main current objection to them is on grounds of maintaining a level
commercial playing field among all CAs (in the Mozilla root program).

> However these individual CA reviews have proved useful for turning up
> new issues we should consider, and I think they're worthwhile for that
> reason alone, in addition to the other purposes they serve. Also, as I
> think Eddy noted, there are few if any other open public forums for
> looking at CA-related issues like these that are of potential interest
> to any developers and users who rely on CAs in one way or another. Maybe
> in the future the CAB Forum will evolve into an organization open to all
> interested parties (e.g., like the standards bodies that exist in other
> areas), and then we can move these more general discussions and lobbying
> efforts to that forum. But until that happens we (Mozilla in general)
> can't simply hash things in private discussions in the CAB Forum or
> elsewhere; we're a nonprofit organization with a public benefit purpose,
> and public participation is key to the way we operate.
[Robin said...] 
I acknowledge the value of the process.

Is there anything remaining which would now hold up approval of our CA
requests?

Regards
Robin

___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

RE: Comodo request for EV-enabling 3 existing roots

[Robin Alden]

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 roots as a standard practice,
> as opposed to having roots issue CA certs to subordinates and then
> having the subordinates issue end entity certs. Some people think that
> root private keys should always be stored offline, and that it's a bad
> practice from a security standpoint to use them in conjunction with an
> online cert-issuing operation, even if the root key is on a hardware
> device.
> 
> I don't see us making it a formal condition of our policy that CAs use
> only offline roots, and rejecting CAs that issue end entity certs
> directly from roots. However it's quite possible that we may want to
> publicly encourage CAs to migrate to use of offline roots, and perhaps
> to maintain publicly available information on which CAs issue directly
> from roots and which don't. We can also of course do such lobbying
> within groups like the CAB Forum, and we will. However I don't believe
> that precludes our discussing and taking positions on these issues in
> the context of our public forums and web sites.
> 
[Robin said...] 
We accept that Mozilla has valid and carefully considered points of view on
issues relating to CA behaviour.
I like your example of using intermediate CAs because it is a goal we share
and something we push where we can, although there are commercial reasons
that we still do not do it across the board.
We accept the quality of the advice, and are grateful that it is not
something you enforce in your policy.

Taking Eddy's issues on DV certificates, we can agree that his points tend
to reduce risk.  We could even try and promote those views in other forums
where we interact with browsers and CAs.  What we don't really want to do is
commit to limiting our DV products while other CAs don't see the same
limits.  Either leave it as a "stated position" which would leave us room to
promote it where we can but also to continue to compete on an equal footing
in that market sector - or make it a stated part of your CA policy which
will oblige all CAs to comply.  Either of those options is fine with us, but
don't ask us to accept (or to volunteer) unilateral restrictions because as
a commercial organization we can't accept them.

Regards
Robin

___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

RE: Comodo request for EV-enabling 3 existing roots

[Robin Alden]

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 about any possible "sanction" pretty useless. Currently EV
> status implies the roots to be also trusted for regular certificates
> which is a limitation of NSS.
> 
[Robin said...] 
Perhaps my problem then is understanding the process at all.  You seem to
suggest that once our application for EV status is approved we somehow
become immune to changes in your CA policy.  Why do you feel that Mozilla
has no control over the CAs other than at the point of approval of a change?
The CA Policy says otherwise.
Or are you saying that your (collective) influence over CA policy is not
what you might hope for but that you can get concessions from individual CAs
at the point of approval?

If I agree to accept a restriction on a product of ours, can you explain the
method that propagates that restriction to the other CAs? 

Regards
Robin

___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

RE: Comodo request for EV-enabling 3 existing roots

[Robin Alden]

> 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 willing to address this issues in good
> faith?
[Robin said...] We are willing to address issues which are of concern to
Mozilla, provided that the same standard applies at the same time to all
CAs.  

> 
> - Apparently you agree that the major issues we've raised, indeed pose
> a
> higher risk to the relying parties. Can we work together in order to
> improve your products to the extend that both sides can live with it
> and
> based on reasonable terms? This would improve the overall quality of
> all
> certificates issued by CAs which are included in NSS, which would
> result
> in further strengthening of digital certification in general and in
> Mozilla software in particular. It would improve also your standing in
> this industry!
[Robin said...] 
I didn't agree that any of the issues you raised were major ones.  I do
agree that there are a variety of levels of risk provided by the product
ranges we have discussed.
We are keen that levels of risk are reduced across the industry and we are
always happy to talk about how that can be achieved.  I do not see how the
withdrawal or modification of some of our products in isolation accomplishes
that overall reduction in risk.  Amend your policy so that it fully
expresses your requirements and then apply that policy to all CAs.

> - Any conclusions through this process and any update to the Mozilla CA
> policy would be evenly applied upon all CAs included in NSS.
[Robin said...] Excellent.

> Additionally, other software vendors, most notably Microsoft could
> adopt
> them as well, resulting in a major improvement of our industry. Under
> this condition, would you be willing to seriously address the issues,
> make and amend changes to your CPS and implement the changes at your
> CA?
[Robin said...] As I mentioned before, we are commercially obliged to have
our root CAs present in the major browser and OS platforms.  In the absence
of other authority it is those browsers and OS platforms that set the
standards we have to follow.  Since no single browser has the entire market
cornered we are obliged to meet the union of all of the standards set by all
of the browsers.
We are prepared to comply with Mozilla's CA Policy.  We are prepared to
enter into and assist with discussions with Mozilla about changes they may
wish to make to their policy.  We are also prepared to do the same with any
other commercially important Browsers and OS platforms.  

> 
> 
> The issues which should be addressed are certificates with a longer
> validity and domain validated wild card certificates. I would like to
> make the following suggestions, that
> 
> - domain validated certificates which are valid for more than 24 month,
> must be re-validated every year thereafter (starting after 24 month).
> Should revalidation fail, the certificate shall be suspended until the
> subscriber has done so successfully or revoked. This would leave your
> product intact and you could continue to issue them as you do today,
> however would introduce additional validations during the life time of
> the certificate.
> 
> - domain validated wild card certificates would undergo an additional
> identity validation. The certificates content itself doesn't have to be
> changed compared to what you do today (if you prefer), but you would
> guaranty through your CPS that you perform this additional validation.
> 
> 
> Are these suggestions reasonable in your point of view and would this
> be
> acceptable to the management of Comodo? Could Comodo commit and agree
> to
> such an implementation, provided that this will be evenly applied upon
> all CAs currently in NSS? If not, can you please provide an
> alternative,
> solving the issues at hand and explain what Comodo would be willing to
> implement instead?
> 
[Robin said...] 
I'm not the first guy you need to get to agree that your suggestions are
reasonable.
Mozilla should amend its CA policy if it believes there is something that it
does not currently address and then apply that new policy to all CAs.  
The proscription of SSL products, or of details of their implementation, is
something that should reasonably be discussed collectively with the CAs and
the browsers.  Can I suggest that the CAB Forum would be one place in which
the matter could usefully be discussed?  Mozilla is already able to propose
such matters for discussion there through Jonathan Nightingale.

Regards
Robin Alden
Comodo CA Limited

___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

RE: Comodo request for EV-enabling 3 existing roots

[Robin Alden]

> 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 from the Netscape era. Many critics have rightly
> pointed
> > to the fact, that these legacy roots never underwent a review nor
> proper
> > inclusion process. This is the reason why Frank made your request for
> > upgrade conditional and a general inclusion request as if this were
> new
> > roots. Your CA doesn't enjoy immunity because you have these legacy
> > roots in NSS, nor does any other CA have that privilege, no matter if
> > legacy or not.
> 
> I don't have time to respond to each and every point in this whole
> discussion, but I did want to respond to this one. As Eddy notes, we
> have a lot of roots in Mozilla that were inherited from the old
> Netscape
> days. We now have a formal policy by which we evaluate requests from
> new
> CAs, including new CAs issuing EV certs, and I thought it was unfair to
> evaluate only new CAs and forever exempt old CAs from similar scrutiny.
> 
> Thus as the opportunity arises I've been trying to go back and look at
> old roots. Requests by various CAs to enable old roots for EV use
> presented just such an opportunity to not just look at the EV-related
> aspects of the CAs but also to review how other aspects of the CAs
> stacked up vis-a-vis our CA policy, and let people in the Mozilla
> community (which means potentially anyone) to make comments and
> suggestions relating to particular CA requests. This is just the way we
> work; we're not Microsoft or Apple, we're a public project and we have
> public processes.
> 
> Doing such reviews and allowing such comments does not imply that I'm
> going to be pulling old roots out of NSS and Firefox. It also does not
> imply that I'm going to hold up EV-related requests until CAs address
> all comments and adopt all suggestions, or until we decide whether our
> policy needs revising and how to revise. This is particularly true
> where
> the issues involve CA practices related to non-EV certs, since those
> issues will not be affected one way or another by our enabling CAs for
> EV.
[Robin said...] Thanks.  That clarification is a big help.

> 
> However I think it's perfectly reasonable for us (Mozilla in general)
> to
> formally call out CA practices that may not be explicitly addressed by
> our policy, and that may not affect my decisions under the policy, but
> that we consider to be problematic in one way or another, and to
> publicly encourage CAs to modify them in various suggested ways.
[Robin said...] 
Fair enough.  We welcome open discussions about these things, as I hope I
have demonstrated.

> Issuing
> long-lived DV certs and wildcard DV certs may be particular practices
> worth our having some formal positions on, even if they're not
> addressed
> by our official policy.
[Robin said...] 
There I have to disagree to some degree.  
You have a policy which tells us what we must do to qualify for root
inclusion.
Are you saying that you have some other things which aren't in the policy
which we must do too?  We'd really rather they were included in your policy
- even if your policy just refers out to them.
A policy needs to be something I can examine as a whole, not something that
reveals - like a fractal - more complexity and detail every time I probe it.

Regards
Robin Alden
Comodo CA Limited


___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

RE: Comodo request for EV-enabling 3 existing roots

[Robin Alden]

> 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 rightly pointed
> to the fact, that these legacy roots never underwent a review nor
> proper
> inclusion process. This is the reason why Frank made your request for
> upgrade conditional and a general inclusion request as if this were new
> roots. Your CA doesn't enjoy immunity because you have these legacy
> roots in NSS, nor does any other CA have that privilege, no matter if
> legacy or not.
[Robin said...] 
I never suggested we wanted immunity.  I asked why you are only now defining
policy in this matter.

> 
> > Is this:
> > a) an abstract discussion to help Mozilla crystallize the details of
> its CA
> > policy,
> >
> 
> No! Mozilla does have a CA policy and defined procedures on how CAs are
> included into NSS. This also includes a public discussion where
> relevant
> issues with the "to-be-included" CA can be raised. I made use of this
> right and raised my objection to the inclusion of your CA into NSS
> under
> the current circumstances. No decision has been made so far however.
[Robin said...] 
I acknowledge your right to discuss it and to raise objections, but surely
the discussion is to about whether we meet the criteria in the CA policy -
and perhaps going so far as to say what we must change so that we do meet
the criteria in the policy.  Surely Mozilla has to publish its policy on
what its requirements are.  I struggle to believe that Mozilla wants to
negotiate product details with every CA it takes roots from.

> 
> > b) a discussion about what changes to CA behaviour Mozilla would like
> to see
> > (and may insist on) from some point in time, or
> >
> 
> No! Mozilla has the right to not include a particular CA certificate in
> its software products, to discontinue including a particular CA
> certificate in its products, /or/ to modify the "trust bits" for a
> particular CA certificate included in its products, *at any time and
> for
> any reason*. This includes (but is not limited to) cases where we
> believe that including a CA certificate would cause *undue risks to
> users' security*...
> 
> (c) Copyright of the Mozilla CA policy
[Robin said...] 
Granted, but as a commercial organization Mozilla also has to apply the same
standards to all CAs.  If you said that Mozilla embeds roots after
negotiation with the individual CA then that would be one thing, but the CA
policy says something different.  Yes, you could discontinue a root for "any
reason", but if you do not apply the same reasoning to other CAs then you
lay yourself open to claims of unfairness.  Surely you would incorporate
that "reason" into your CA policy for all to follow.  If your objections are
not ones that are to be included in the CA policy then I have to question
the process as a whole.

> 
> > c) a trial to determine whether our CAs should be removed from
> Mozilla
> > products?
> >
> 
> No, it's the process of considering the inclusion of your CA roots and
> upgrade to EV status. This is not a trial, as Mozilla has refused the
> inclusion of CAs already entirely in the past or made the inclusion
> conditional to certain aspects to their CPS and implementation. It has
> nothing to do with your CA per se, this is due process of the inclusion
> process.
[Robin said...] 
And it is the nature of the inclusion process that I am beginning to
question.
Your CA policy says "We will make such decisions [about inclusion] through a
public process, based on objective and verifiable criteria as described [in
the CA policy]".
>From my point of view outside Mozilla I read your CA policy and complied
with it.  
Now you have some more criteria which aren't in the policy.  That makes the
game considerably harder for me to prepare for.

> 
> > We have certainly strayed from my point of entry into this process
> which was
> > to ask to have these 3 existing roots enabled for EV.
> >
> See above (first section) why this isn't the case! Additionally, to all
> of my knowledge, other CAs had to undergo the very same process as well
> and your situation isn't unique!
[Robin said...] 
I disagree.  We *have* strayed far from the starting point.  Frank was clear
why he chose to treat our request as if it were for initial inclusion and I
can see his reasoning.  It still leaves us a long way from where we thought
we started.
>From Frank's most recent reply I accept the reason for the consid

RE: Comodo request for EV-enabling 3 existing roots

[Robin Alden]

> >> But by issuing *domain validated* certificate for up to *ten years*,
> >> without revalidation is completely irresponsible and borders on
> gross
> >> negligent.
> >>
> > [Robin said...]
> > I disagree.  With a DV certificate the only thing that we are
> warranting is
> > that the key holder controls the domain.
> 
> Between us, even this isn't true exactly , or at least I'm not sure if
> your CA warrants anything in the domain validated settings... But this
> isn't the point at all, but the fact, that your certificates are issued
> for a very long time without re-validating and confirming continued
> ownership of the domain name. This is the problem here.
> 
[Robin said...] 
It seems to boil down to this question.  
Q1) What is the maximum duration of certificate of each type in question
that Mozilla's policy accepts?

> > Why go to that effort?  DV certificates are easy to get.  That is a
> valid
> > criticism against DV.
> >
> 
> I'm absolutely not against domain validated certificates and they have
> a
> rightful place in the landscape of this infrastructure. However I'm
> completely against issuance of domain validated certificates to any
> longer period which isn't reasonable and beyond the expected ownership
> period of said domain name.
[Robin said...] 
See Q1.

> 
> > DV products exist today - that is a fact.  The browsers (in this case
> > Mozilla) have been content for us to issue DV certificates.  Sure, a
> longer
> > duration certificate carries higher risk than a short one.
> 
> Thank you for confirming this.
> 
> >   We'd also accept
> > that a wildcard carries somewhat more risk than a single domain
> certificate,
> > but where is the line to be drawn?
> >
> 
> I'll be glad to evaluate this line together with you and other members
> of this community. I have drawn my line and provided a concrete
> proposal. We may discuss this and find the best solution for all.
[Robin said...] 
Sure, so we need a documented answer for Q1.

> > Also, why draw the line retrospectively and at this moment in time?
> 
> Because your CA is a candidate for inclusion and upgrade into the NSS
> store and as a matter of fact re-evaluated as if your CA never had any
> roots in NSS (See this comment in the bug entry:
> https://bugzilla.mozilla.org/show_bug.cgi?id=401587#c20
> 
> If we don't speak up now, we can't blame anybody else later.
> 
[Robin said...] 
A fair point, and perhaps that is a whole other problem.  Our CA *does* have
roots in NSS.  
Is this:
a) an abstract discussion to help Mozilla crystallize the details of its CA
policy, 
b) a discussion about what changes to CA behaviour Mozilla would like to see
(and may insist on) from some point in time, or
c) a trial to determine whether our CAs should be removed from Mozilla
products?
We have certainly strayed from my point of entry into this process which was
to ask to have these 3 existing roots enabled for EV.

> > Should Mozilla's policy on this not be published and clear for us to
> follow, rather
> > than ad-hoc?
> >
> 
> The Mozilla CA policy is clear in that respect in various points,
> starting with the first paragraph   
> 
> The other sections go into some more details. Additionally there is the
> objective of this policy as explained in the initial sections to
> prevent undue risk to the users security.
> 
> I agree with you that we can and should refine the Mozilla CA policy to
> some extend, something which has been done already once (to allow EV
> upgrades) and to all of my knowledge we at Mozilla will work on that as
> soon as possible and if necessary (Frank, is that correct?)
> 
[Robin said...] 
The CA Policy is there, I agree, but I think we meet the objective criteria
it provides.  "Preventing undue risk" sounds subjective to me.

> 
> >
> >
> > [Robin said...]
> > It is in our interest to know about as many SSL protected domains out
> there
> > on the internet as possible.  We do actively look for them.
> > The snag is that with wildcard domains there really are an awful lot
> of
> > possibilities to search for.  We are looking for needles in
> haystacks.  If
> > we could get a zone transfer for the DNS server hosting domain.com
> (to pick
> > up all the existing sub-domains) then our life would be made simple
> and we
> > would certainly check them all, but that just doesn't work.
> >
> 
> Robin, I'm glad that it's *you* who made this statement and I couldn't
> have it formulated better - I absolutely agree with you. And *exactly
> because of that*, wild card certifica

RE: Comodo request for EV-enabling 3 existing roots

[Robin Alden]

> Robin Alden:
> >
> > The only certificates we issue for 10 years are DV certificates.
> > We do not currently repeat any of the validation checks during a
> > certificate's lifetime for any of our certificate types.
> >
> 
> The behavior of Comodo in this respect is really surprising! Supposed
> you would issue certificates with longer validity only to entities which
> were thorough verified and validated, I could offer some understanding.
> But by issuing *domain validated* certificate for up to *ten years*,
> without revalidation is completely irresponsible and borders on gross
> negligent.
> 
[Robin said...] 
I disagree.  With a DV certificate the only thing that we are warranting is
that the key holder controls the domain.  There are no organizational
details in certificate - only the domain name in the common name.

> In comparison, there are intermediate CA certificates in use by CAs
> which are in NSS which have a shorter lifetime even than that in order
> to lower the risks! One can assume that this type of CA certificates are
> adequately secured and don't rely on domain names which might stop to
> exist and change owners (willingly and unwillingly).
> 
> > We have certainly thought about the case where an organization ceases to
> > operate, or a domain name changes hands, and when we follow the cases
> > through where the subscriber does not inform us they do not strike us as
> > being of high risk.  There is some risk of fraud, certainly, but it is
> not
> > high up the list of ways we see people using SSL certificates to commit
> > fraud.
> This issue has come up with other CAs as well, but apparently any of
> them offering certificates for longer validity, require the subscriber
> to re-validate their domain. As far as I know, you are the only CA doing
> that (which is included in NSS) and in that respect an argument (which
> you used elsewhere), that the competition is doing it as well, is not
> relevant.
> 
> The risk exists and I gave a real show-case to a reply to Frank
> yesterday (most likely you've read it too). If this is made possible,
> than why validate a domain at all? As you agreed with me, there is a
> risk of fraud, it just requires somewhat more patience and money for a
> sophisticated attacker, but detection is accordingly also much more
> difficult. And it defeats the very  purpose of domain validated
> certificates.
[Robin said...] 
Fraud how?  For DV, we validate domain control.  If a company goes bust and
passes the domain on to someone else then that new person could get a DV
certificate for the domain.  In fact it will be a lot easier for them to get
a new DV certificate for the domain from us than to try and get the private
key of the old one from a defunct server.
To use the certificate you must be in possession of the private key and
(because of the validation) be in control of the domain.

Or are you suggesting that the risk you are addressing is of someone
choosing a defunct domain with a Comodo DV certificate (that we did not
become aware of and revoke) and getting hold of the private key of the
certificate from a server (from ebay or by theft or whatever) and then using
that certificate to mount a man-in-the-middle attack on the new owners of
the domain?
Why go to that effort?  DV certificates are easy to get.  That is a valid
criticism against DV.  
DV products exist today - that is a fact.  The browsers (in this case
Mozilla) have been content for us to issue DV certificates.  Sure, a longer
duration certificate carries higher risk than a short one.  We'd also accept
that a wildcard carries somewhat more risk than a single domain certificate,
but where is the line to be drawn?
Also, why draw the line retrospectively and at this moment in time?  Should
Mozilla's policy on this not be published and clear for us to follow, rather
than ad-hoc?

> 
> > We restrict the wildcard character in the domain name to be the
> > leading sub-domain. – e.g. *.foo.com, *.foo.co.uk.
> >
> Good.
> >
> > E.g. If we find a certificate is being used at ebay.foo.com we would
> > not **automatically** take action on that certificate – unless we
> > become aware (either through our own inspection or by notification
> > from a third party) that fraud is likely.
> >
> May I suggest to implement an automatic check for certificates which
> could be potentially used for phishing and other fraud, including
> certificates which are obviously for financial institution? Revocation
> of a certificate after detection through your inspection is not as good
> as possible prevention of the issuance in first place. Considering the
> size of your CA and the difficulty of controlling automated issuance, I
> would expect it from you and I'm

RE: Comodo request for EV-enabling 3 existing roots

[Robin Alden]

 Please point me to the exact reference in the CPS since
> I most likely missed it.
I know you will find this disappointing, but I'm going to point you back to 
4.2.1 again.  Any internal databases that we refer to for validation 
information are just snapshots in time of the same information we gather for 
4.2.1.  IdAuthority (when it was in use as a source of validation information) 
was just a bulk snapshot of information that we would have gathered for 4.2.1.
The 3rd party databases mentioned are the domain registries (for Whois records) 
or the jurisdictions of incorporation (for evidence of legal existence and 
correctness of address details, etc, of the legal entity).

Regards
Robin Alden
Comodo CA Ltd.

___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

RE: Comodo request for EV-enabling 3 existing roots

[Robin Alden]

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 
> changes name, changes address, stops its operation, dies etc. How 
> does Comodo guaranty the validity of these certificates throughout 
> their lifetime?

The only certificates we issue for 10 years are DV certificates.
We do not currently repeat any of the validation checks during a
certificate's lifetime for any of our certificate types.

If a subscribing entity changes name, address, or ceases operation they are
obliged (by the subscriber agreement) to inform us.  
If we become aware that any of the details held in the certificate become
invalid then, as stated in the CPS (version 3.0 section 4.13), we may revoke
the certificate.  We would rather see a certificate with incorrect details
pulled and replaced with one with the correct details (which we will often
provide free of charge) but if that does not happen we will revoke.

We have certainly thought about the case where an organization ceases to
operate, or a domain name changes hands, and when we follow the cases
through where the subscriber does not inform us they do not strike us as
being of high risk.  There is some risk of fraud, certainly, but it is not
high up the list of ways we see people using SSL certificates to commit
fraud. 

Regards
Robin Alden
Comodo CA Limited

___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

RE: Comodo request for EV-enabling 3 existing roots

[Robin Alden]

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 certificates, specially in 

> relation to phishing attempts and other fraud, taking into consideration 

> that these certificates are domain validated only? Does Comodo believe 

> that such wild card certificates are issued according to verification 

> requirements for this special type of certificates?

 

I have seen some other discussion of this issue in these threads, but I will 
try and clarify our position.

Any validation we do is to the highest level ownable domain name.  I appreciate 
that’s not a very exact term, but I mean that for a .com domain name we 
validate foo.com, for a .co.uk domain name we validate foo.co.uk.

We restrict the wildcard character in the domain name to be the leading 
sub-domain. – e.g. *.foo.com, *.foo.co.uk.

 

We do not apply any post-issuance checks on domain names for which the 
certificate.  

E.g. If we find a certificate is being used at ebay.foo.com we would not 
*automatically* take action on that certificate – unless we become aware 
(either through our own inspection or by notification from a third party) that 
fraud is likely.

 

If any fraudulent use of any of our certificates (wildcard or not, EV or not) 
is discovered we will revoke that certificate.  We are permitted to do that by 
the subscriber agreement to which our subscribers indicate their agreement when 
they purchase certificates from us.

 

We agree that wildcard certificates pose more problems than non-wildcard 
certificates – but Wildcard certificate products exist today and we are not 
minded to unilaterally withdraw them.  

We helped to found the CAB forum and continue to support it to improve the 
overall security of SSL certificates.  We hope that one day all certificates 
will be EV, but until that day we feel we must be allowed to compete with order 
CAs issuing wildcard products.

 

Regards
Robin Alden

Comodo

___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

RE: Comodo request for EV-enabling 3 existing roots

[Robin Alden]

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, Sweden? In the audit reports no distinctions 
> are made between the various companies and the audit reports are 
> addressed only to Comodo CA Ltd.

Comodo CA Ltd. is the company undergoing the audit.  It is the only company
to which the WebTrust Audit applies.

Comodo CA Ltd. operates a number of different certificate brands.  LiteSSL
is one such brand.
LiteSSL CA Inc. is wholly controlled by Comodo CA Limited.

There is no ongoing relationship with AddTrust AB, Sweden.  I'm not even
sure if AddTrust AB still exists as a company.  I think AddTrust may exist
now only as a brand of ScandTrust AB. Sweden - although Comodo does have the
right to continue using the root CA certificates which we purchased from
them and which bear the AddTrust name.

Robin Alden

___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

RE: Comodo request for EV-enabling 3 existing roots

[Robin Alden]

Eddy,
I'm sorry I haven't got around to answering your questions until
now.

You wrote:
> 1.) The audit report for non-EV operations refers to the CA operation at 
> Manchester. The audit report for EV refers to the CA operations at New 
> Jersey. One of the roots is from a company operating in Sweden, one 
> operating in Salt Lake City, Utah, USA and and one of Salford, GB. Can 
> the relations between these locations and the general operation of 
> Comodo and the audit reports be explained?

The WebTrust Audit covers most aspects of our operation as a CA.  The
auditors visit any part of our operation which they deem to be involved in
our CA operation.
The Manchester office is our UK based validation operation.  It handles both
EV and OV validation.
The New Jersey office is our US based validation operation.  It too handles
both EV and OV validation.
We have one more validation operation which handles OV validation only and
which is also audited each year as part of the webtrust audit.

The AddTrust root was purchased by Comodo from the ScandTrust organization
in Malmö, Sweden.  They had acquired the root (and continued the protection
of the key material, etc.) when they took over the AddTrust operation.
The four UserTrust roots became available to Comodo when UserTrust became a
Comodo Group Company.
In both of the above cases the key material was removed from its original
sites of operation (in Sweden and Salt Lake City, respectively) and
trafserred into Comodo's data centres and backup centres.
The roots you see with Comodo's name in, or mentioning a Salford address,
are roots for which we have generated the keys ourselves.

As to your request to "refrain from further advancing of their
inclusion/upgrade request" - well, I'd rather answer the questions in this
forum, if possible.

Regards
Robin Alden
Comodo CA Limited.

-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 existing roots

Frank Hecker:
> This is a followup to my previous message about Comodo's application to 
> add a new EV root CA certificate. Comodo also has requested enabling 
> three existing roots, AddTrust External CA Root, UTN - DATACorp SGC, and
> UTN-USERFirst-Hardware, for EV use, and also marking all three roots for 
> SSL, email, and code signing use, as documented in the following bug:
>
>https://bugzilla.mozilla.org/show_bug.cgi?id=401587
>
> and in the pending certificates list:
>
>http://www.mozilla.org/projects/security/certs/pending/#Comodo
>
> I have evaluated this request, as per the mozilla.org CA certificate
policy:
>
>http://www.mozilla.org/projects/security/certs/policy/
>
> and plan to officially approve the request after a public comment period.
>   
The public comment period is officially up and I'd like to make the 
following statement:

In light of Franks entry at bug 
https://bugzilla.mozilla.org/show_bug.cgi?id=401587#c20 NOTE #2 [1]

- and due to the fact that Comodo hasn't replied to most 
questions/inquiries;
- and due to the fact that Comodo has a high market share (second in 
size as claimed by Comodo themselves) and hence the risks for Mozilla 
and its users might be of a much bigger scale [2];
- and due to the fact that I have found reasons enough to believe that 
their low-assurance certification might present a risk to Mozilla and 
its users , specially also because I haven't received sufficient answers 
or none at all, to refute my findings;

I suggest the following at this stage:

Adding an entry at the bug that
- requests officially a statement and answering of the issues which have 
been raised [3];
- request to actively address the issues which are deemed to be a risk 
for Mozilla and its users after receiving their answers and after 
evaluating them;

and refrain from adding and/or updating their CA certificates at NSS 
until we have reasons enough to believe that all issues have been solved 
to our satisfaction, specially also because all their roots issue any 
type of certificates from DV to EV, hence separation isn't possible at 
this stage

and refrain from further advancing of their inclusion/upgrade request 
(of the others roots which are potentially up for upgrade to EV status).


[1]  Although all these roots are already in NSS, in the interests of 
thoroughness I'll repeat all the evaluation steps as if they were new roots.
[2] Success also brings with it greater responsibilities, which is 
specially true for this industry.
[3] I'd be glad to gather all the points raised and summarize and 
formulate them for this task if this is of any help.

-- 
Regards 
 
Signer: Eddy Nigg, StartCom Ltd. <ht

RE: Comodo request for EV-enabling 3 existing roots

[Robin Alden]

Eddy,
I'm sorry I haven't got around to answering your questions until
now.

You wrote:
> 1.) The audit report for non-EV operations refers to the CA operation at 
> Manchester. The audit report for EV refers to the CA operations at New 
> Jersey. One of the roots is from a company operating in Sweden, one 
> operating in Salt Lake City, Utah, USA and and one of Salford, GB. Can 
> the relations between these locations and the general operation of 
> Comodo and the audit reports be explained?

The WebTrust Audit covers most aspects of our operation as a CA.  The
auditors visit any part of our operation which they deem to be involved in
our CA operation.
The Manchester office is our UK based validation operation.  It handles both
EV and OV validation.
The New Jersey office is our US based validation operation.  It too handles
both EV and OV validation.
We have one more validation operation which handles OV validation only and
which is also audited each year as part of the webtrust audit.

The AddTrust root was purchased by Comodo from the ScandTrust organization
in Malmo

-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 existing roots

Frank Hecker:
> This is a followup to my previous message about Comodo's application to 
> add a new EV root CA certificate. Comodo also has requested enabling 
> three existing roots, AddTrust External CA Root, UTN - DATACorp SGC, and
> UTN-USERFirst-Hardware, for EV use, and also marking all three roots for 
> SSL, email, and code signing use, as documented in the following bug:
>
>https://bugzilla.mozilla.org/show_bug.cgi?id=401587
>
> and in the pending certificates list:
>
>http://www.mozilla.org/projects/security/certs/pending/#Comodo
>
> I have evaluated this request, as per the mozilla.org CA certificate
policy:
>
>http://www.mozilla.org/projects/security/certs/policy/
>
> and plan to officially approve the request after a public comment period.
>   
The public comment period is officially up and I'd like to make the 
following statement:

In light of Franks entry at bug 
https://bugzilla.mozilla.org/show_bug.cgi?id=401587#c20 NOTE #2 [1]

- and due to the fact that Comodo hasn't replied to most 
questions/inquiries;
- and due to the fact that Comodo has a high market share (second in 
size as claimed by Comodo themselves) and hence the risks for Mozilla 
and its users might be of a much bigger scale [2];
- and due to the fact that I have found reasons enough to believe that 
their low-assurance certification might present a risk to Mozilla and 
its users , specially also because I haven't received sufficient answers 
or none at all, to refute my findings;

I suggest the following at this stage:

Adding an entry at the bug that
- requests officially a statement and answering of the issues which have 
been raised [3];
- request to actively address the issues which are deemed to be a risk 
for Mozilla and its users after receiving their answers and after 
evaluating them;

and refrain from adding and/or updating their CA certificates at NSS 
until we have reasons enough to believe that all issues have been solved 
to our satisfaction, specially also because all their roots issue any 
type of certificates from DV to EV, hence separation isn't possible at 
this stage

and refrain from further advancing of their inclusion/upgrade request 
(of the others roots which are potentially up for upgrade to EV status).


[1]  Although all these roots are already in NSS, in the interests of 
thoroughness I'll repeat all the evaluation steps as if they were new roots.
[2] Success also brings with it greater responsibilities, which is 
specially true for this industry.
[3] I'd be glad to gather all the points raised and summarize and 
formulate them for this task if this is of any help.

-- 
Regards 
 
Signer: Eddy Nigg, StartCom Ltd. 
Jabber: [EMAIL PROTECTED] 
Blog:   Join the Revolution! 
Phone:  +1.213.341.0390
 

___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto