Re: About 's future...

lists.w3.org/Archives/Public/www-tag/2015Sep/thread.html > [3] https://code.google.com/p/chromium/issues/detail?id=514767 > [4] https://bugzilla.mozilla.org/show_bug.cgi?id=1024871 > -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online Office Tel

Re: What's My Chain Cert?

source for when we get those emails that say "my cert isn't working in Firefox - why?" Thanks to Andrew of SSLMate for putting the site together. Gerv -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online -- dev-tech-crypto mailing list

Re: Updates to the Server Side TLS guide

udFlare's Universal SSL uses ECDSA certs exclusively, so as of a few weeks ago there are now _a lot_ of ECDSA certs in the wild. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: New wiki page on certificate revocation plans

[1] https://wiki.mozilla.org/CA:ImprovingRevocation [2] https://www.imperialviolet.org/2012/02/05/crlsets.html -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: SHA-256 support

al-requirements-version-2-0.aspx [2] http://csrc.nist.gov/publications/fips/fips180-4/fips-180-4.pdf -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: id-ce-nameConstraints (2.5.29.30) in the real world

ZbPXYWg6f8bbMA== -END CERTIFICATE- -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online Office Tel: +44.(0)1274.730505 Office Fax: +44.(0)1274.730909 www.comodo.com COMODO CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor

Re: id-ce-nameConstraints (2.5.29.30) in the real world

netheless, that IPv6 omission means that this CA certificate is unfortunately _not_ considered technically constrained according to the Mozilla CA Certificate Inclusion Policy. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online -- dev-tech-crypto mail

Re: id-ce-nameConstraints (2.5.29.30) in the real world

to visit https://www.sonderbewilligungen.admin.ch. Kaspar -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Proposal to Change the Default TLS Ciphersuites Offered by Browsers

ST ignore those cipher suites, and process the remaining ones as usual." -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Proposal to Change the Default TLS Ciphersuites Offered by Browsers

7;t he talking about http://en.wikipedia.org/wiki/Dual_EC_DRBG#Controversy ? No, he actually said he doesn't trust any ECC, but on the other hand said that we should probably move to at least 500 bit ECC. Kurt -- Rob Stradling Senior Research & Development Scientist COMODO - Creati

Re: Proposal to Change the Default TLS Ciphersuites Offered by Browsers

NSA has manipulated them through their relationships with industry." Does that affect your proposal? Wasn't he talking about http://en.wikipedia.org/wiki/Dual_EC_DRBG#Controversy ? No, he actually said he doesn't trust any ECC, but on the other hand said that we should probably move t

Re: Proposal to Change the Default TLS Ciphersuites Offered by Browsers

webserver wants to prefer ECDSA over RSA, then it can override the browser-supplied cipher-suite order. e.g. http://httpd.apache.org/docs/2.4/mod/mod_ssl.html#sslhonorcipherorder -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online Office Tel: +44.(0)1274.73

Re: Proposal to Change the Default TLS Ciphersuites Offered by Browsers

On 16/08/13 16:18, Ryan Sleevi wrote: On Fri, August 16, 2013 6:36 am, Rob Stradling wrote: On 15/08/13 18:15, Chris Richardson wrote: I believe this plan would have poor side effects. For example, if Apple ships clients with a broken ECDSA implementation [0], a server cannot detect detect

Re: Proposal to Change the Default TLS Ciphersuites Offered by Browsers

NSS/PSM) -- dev-tech-crypto mailing list dev-tech-crypto@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 Office Fax: +44.(0)1274.730909 www.comod

Re: Introductions - want to contribute to NSS developer friendliness

x27;s Agreement, but you don't need committer privileges in order to create a bug on Bugzilla, attach a patch, etc). -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.

Re: Root Certificates in Firefox OS (was Re: NSS in Firefox OS)

On 18/04/13 13:54, Rob Stradling wrote: On 20/10/12 18:33, Brian Smith wrote: B2G (Firefox OS) does use NSS. Brian, I presume that Firefox OS trusts NSS's "Built-in" Root Certificates [1], but what (if anything) does Firefox OS do for EV SSL? Does Firefox OS import PSM'

Root Certificates in Firefox OS (was Re: NSS in Firefox OS)

s? [2] Thanks. [1] https://mxr.mozilla.org/mozilla-central/source/security/nss/lib/ckfw/builtins/certdata.txt [2] https://mxr.mozilla.org/mozilla-central/source/security/manager/ssl/src/nsIdentityChecking.cpp -- Rob Stradling Senior Research & Development Scientist COMODO - Creating T

Re: Is there an ETA yet for when Firefox will use libpkix by default?

ting one of these two patches ASAP! On 11/06/12 15:25, Rob Stradling wrote: On 09/06/12 06:03, Wan-Teh Chang wrote: Rob, Please fix the bug in the "old" certificate verification library. Thanks. Are you going to use the approach outlined by Nelson in bug 479508 and bug 482153? > &

Re: Is there an ETA yet for when Firefox will use libpkix by default?

2. I tried removing one of the affected UTN root-certificates and then adding the relevant AddTrust->UTN cross-certificate as a built-in. This didn't work either, presumably because the UTN root-certificate was for some reason still listed as a Software Security Device.

Is there an ETA yet for when Firefox will use libpkix by default?

ry and then ii) petition Mozilla and the NSS team to accept my patch and ship it in Firefox 14 or sooner. Thanks. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Google about to fix the CRL download mechanism in Chrome

ermediate revocation checking? (I'd expect the size of this data to be well under 100K !) -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Google about to fix the CRL download mechanism in Chrome

On 09/02/12 13:10, Gervase Markham wrote: On 09/02/12 12:54, Rob Stradling wrote: We've calculated that there are currently ~53,000 revoked Server Authentication certs that were issued by Comodo's CA systems, each with a serial number of 16 bytes (+ a leading zero byte if required

Re: Google about to fix the CRL download mechanism in Chrome

the union of all those CRLs be huge, even if they strip off certain reason codes? -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online Office Tel: +44.(0)1274.730505 Office Fax: +44.(0)1274.730909 www.comodo.com COMODO CA Limited, Registered in England No. 0

Re: For discussion: MECAI: Mutually Endorsing CA Infrastructure

AFAIK, such configurations are not widespread today, but this would change if/when ECC certs start to be used more widely. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto

OCSP-in-DNS (was Re: For discussion: MECAI: Mutually Endorsing CA Infrastructure)

consider addressing some of these issues. Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: TLS server keys in DNS: client policy proposal

but they are still useful (e.g. the CA may subsequently detect that the key or hash algorithm used in the certificate is weak). Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists

Re: Domain-validated name-constrained CA certificates?

ld notes from Nelson. AFAIK, this extension is still supported by NSS, but having said that I wouldn't be surprised if Nelson replies to this message with words to the effect of "that extension is deprecated, so please don't use it any more!" Rob Stradling Senior Research &a

Re: Basic ECC in NSS 3.12.4 with NSPR 4.8

09 18:49:57 Frank Hecker wrote: > David Stutzman wrote: > > Rob Stradling wrote: > >> A question for the NSS devs: > >> Is there any reason why NSS couldn't be changed to assume > >> "NSS_ENABLE_ECC=1" by default? > > > > Yes... > > htt

Re: Basic ECC in NSS 3.12.4 with NSPR 4.8

On Tuesday 03 November 2009 14:29:43 Rob Stradling wrote: > On Tuesday 03 November 2009 13:42:14 David Stutzman wrote: > > Hi David. > > Gentoo's NSS package supports ECC because I asked them to enable it: > http://bugs.gentoo.org/247221 > > I don't think it

Re: Basic ECC in NSS 3.12.4 with NSPR 4.8

on't take this as complaining...just trying to put the info out > there and understand the what's and why's. I appreciate all the hard > work you do. > > Dave > > PS Nelson, I've been trying to email you directly and haven't been > getting any response

Re: Making OCSP soft fail smarter

> Here's a straw man: > > OK: > 200 response with OK > No response (network problems) > > Not OK: > 200 response with revocation > 400 response (OCSP responder actively denying response) > 500 response (OCSP responder broken) > > What do people think? Putting 400 and

Re: Roots that are identical except for signature algorithm and serial number

g dates > for the old roots. Rationale: This ensures that NSS will > deterministically select the newer root in cases where there is a choice > to be made. (Does this include the case when Firefox, etc., receive a > full cert chain that includes the old root?) > > Is the above a co

Re: client certificates unusable?

#x27;s an interesting thought. I've just posted a message to the CA/Browser Forum mailing list to suggest that the Forum could invite server software vendors to participate. If anything happens, I'll report back here. -- Rob Stradling Senior Research & Development Scientist Com

Re: Cert expiry with Key Continuity Management

ply be ignored. On Monday 19 January 2009 22:07:46 Nelson B Bolyard wrote: > Rob Stradling wrote, On 2009-01-14 03:24 PST: > > To the NSS developers: If there existed a standardized certificate > > extension in which a CA could put additional signatures using different > > alg

Re: Cert expiry with Key Continuity Management

On Tuesday 13 January 2009 15:47:22 Paul Hoffman wrote: > At 3:31 PM + 1/13/09, Rob Stradling wrote: > >Why "almost every piece of PKIX validating software" ? > > > >I think it would be worth it if, at a minimum... > > - the majority of CAs added t

Re: Cert expiry with Key Continuity Management

licy could be updated to require CAs to implement it? On Tuesday 13 January 2009 14:50:32 Paul Hoffman wrote: > At 9:55 AM +0000 1/13/09, Rob Stradling wrote: > >Thanks Ben. Perhaps it's time to have another go at canvassing support > > for the idea. In 2006, the PKIX WG didn

Re: Cert expiry with Key Continuity Management

09 09:39:06 Ben Bucksch wrote: > On 13.01.2009 09:48, Rob Stradling wrote: > > I made a similar suggestion to ietf.pkix in October 2006. See... > > http://www.imc.org/ietf-pkix/mail-archive/msg01964.html > > ...and the rest of that thread, including... > > http://www.im

Re: Cert expiry with Key Continuity Management

e to introduce such a thing now, it could help us all in the future when we need to move from SHA-1 to SHA-2, or from SHA-1/SHA-2 to SHA-3, etc. -- Rob Stradling Senior Research & Development Scientist Comodo - Creating Trust Online Office Tel: +44.(0)1274.730505 Fax Europe: +44.(0)1274.7309

Re: Suggestion: Announce date for MD5 signature deactivation

gt; That list is not going to be long, but it *will* be valuable. > > OK, I'm not sure if this is/was the intention of Frank and the > objectives of the Mozilla CA Policy. > > Nevertheless I suggest to start the work for a possible change to the > policy in order to addres

Re: Suggestion: Announce date for MD5 signature deactivation

s proposal of a "retroactive change to its (Mozilla's) > > acceptance policy in the pile" in order to curtail the use of MD5 by CAs > > who have *already* been accepted by Mozilla. > > > > Are you saying that Mozilla could change the Potentially Problema

Re: Cert expiry with Key Continuity Management

y point wasn't *because* of Verisign, but *even* Verisign does it ;-) OK. -- 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. 040

Re: Suggestion: Announce date for MD5 signature deactivation

d then use "non-compliance" to anything on that page as grounds for pulling a previously approved Root Certificate from the trust pile? On Monday 12 January 2009 11:26:03 Eddy Nigg wrote: > On 01/12/2009 01:08 PM, Rob Stradling: > > Eddy, I apologize if I'm misinterpreting you

Re: Cert expiry with Key Continuity Management

On Monday 12 January 2009 12:10:17 Eddy Nigg wrote: > On 01/12/2009 01:20 PM, Rob Stradling: > > The "Entrust.net Secure Server Certification Authority" is used for > > legacy ubiquity only. Entrust and SecureTrust (aka Trustwave) have > > different EV

Re: Cert expiry with Key Continuity Management

On Monday 12 January 2009 11:00:59 Eddy Nigg wrote: > On 01/12/2009 12:45 PM, Rob Stradling: > > "and required by EV" ? > > > > Eddy, the EV Guidelines impose certain requirements on Intermediate CAs > > *when* they are used, but AFAIK they don't mand

Re: Suggestion: Announce date for MD5 signature deactivation

gt; Just a by-note on this one...It doesn't have to be in the CA Policy, but > may be also in some by-laws or as we have it currently in the > "problematic practices". This document is presented to every CA for a > while already, so the CAs know about it, even if it's not

Re: Cert expiry with Key Continuity Management

> the possibility that you have out of band information that the key is > > not compromised and that you should be able to access the site. > > Yes, I view an expired certificate differently than a revoked one. There > are indeed situations which require to access a site

Re: OCSP bypass in recent demo/exploit

xtensions. Only 8 out of the 125 roots > >in nssckbi have them. > > Now *that* is sad. I was hoping for closer to 50%. It does not make my > argument wrong, just pretty moot. > > --Paul Hoffman > ___ > dev-tech-crypto mailin

Re: CAs and external entities (resellers, outsourcing)

ures. Reseller != RA. > > As such, I believe that it would be good to improve the Mozilla CA > Policy and work towards better definitions and requirements. Even if the > validation aspect is clearly defined and *required*, we might exclude > certain practices outright. There are of

Re: Words from Comodo?

v > > ___ > dev-tech-crypto mailing list > dev-tech-crypto@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-tech-crypto -- Rob Stradling Senior Research & Development Scientist Comodo - Creating Trust Online Office Tel

Re: MD5 irretrievably broken

__ > dev-tech-crypto mailing list > dev-tech-crypto@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: +4

Re: Words from Comodo?

"minimum standards for domain validation" initiative mentioned by that Reg article. -- 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 E

Re: SECOM Trust EV root inclusion request

ing to postpone further consideration of the request. This > will allow time to try to get the issues resolved, after which we can > start a new public discussion period. > > Frank -- Rob Stradling Senior Research & Development Scientist Comodo - Creating Trust Online Offi

Re: Creating a Global User-level CA/Trust Infrastructure forSecureMessaging

; > The Mozilla CA policy is my domain...indeed are there CAs which perform > "key escrow" without the consent of the user (or without the user having > explicitly asked beforehand)? -- Rob Stradling Senior Research & Development Scientist Comodo - Creating Trust Online O

Re: Microtec CA inclusion request

t it is awkward to have an OCSP AIA extension > in a root certificate. > > Regards, > > István > ___________ > dev-tech-crypto mailing list > dev-tech-crypto@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-tech-crypto -- Rob

Re: SSL servers sending out multiple cert chains?

ozilla.org link above mentions a number of good advantages w.r.t. activating the EV UI in Internet Explorer 7. I'd be more than happy to answer any further questions. > Regards, > /Nelson > _______ > dev-tech-crypto mailing list >

Re: Microtec CA inclusion request

erstand why anyone would check the revocation status > of a trust anchor via CRL or OCSP. > > Regards, > > István > ___ > dev-tech-crypto mailing list > dev-tech-crypto@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-t

Re: Microtec CA inclusion request

s or OCSP authorityInfoAccess extensions for > which no operational CRL or OCSP service exists. > > Micorsec doesn't provide an operational OCSP responder when used in > conjunction with AIA service URI. Over to Frank. -- Rob Stradling Senior Research & Development Scienti

Re: Microtec CA inclusion request

On Monday 06 October 2008 08:53:01 Rob Stradling wrote: > IINM, FF3 by default has the "When an OCSP connection fails, treat the > certificate as invalid" tickbox set to *disabled*, meaning that most users > won't see browser warnings.  Therefore, IMHO, if Microsec don&

Re: Microsec CA inclusion request

uch as those on a ship)." > This first public comment period will be for one week, and then I'll > make a preliminary determination regarding this request. > > Frank > > [1] Fun fact: Within Hungary names are normally given in "Eastern order" > (i.e., like C

Re: questions on root creation

odule." Here's the FIPS 140-2 cert: http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm#997 Of course, Windows XP/SP1/SP2 and Windows 2000 still don't support anything stronger than SHA-1, so we're still stuck with using RSA-with-SHA1 in order to maintain comp

Re: UTN-USERFirst-Object - "Can't verify signature

look for that cert in the Authorities tab, and see if it is in the > "Builtin Object Token" or the "Software Security Device". > Also, look in the tab for "your certificates" and see if your code signing > cert is listed there. > Then repeat these steps with FF3 and see

Re: Comodo ECC CA inclusion/EV request

On Saturday 19 July 2008 19:30:51 Paul Hoffman wrote: > 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-2

Re: Comodo ECC CA inclusion/EV request

ficate 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

Re: Decline in firefox usage due to lacking CA certificates

On Thursday 17 July 2008 16:50:50 Frank Hecker wrote: > Rob Stradling wrote: > > Frank, in Bug #421946 Comment #15 you said: > > "I'll proceed with the first public comment period once I figure out > > where this request sits in the queue relative to other similar r

Re: Decline in firefox usage due to lacking CA certificates

On Thursday 17 July 2008 13:33:04 Frank Hecker wrote: > Rob Stradling wrote: > > Frank, is there any reason why you can't have multiple candidate CAs > > having their "public discussion periods" simultaneously? > > No reason at all; Thanks Frank. That's

Re: Decline in firefox usage due to lacking CA certificates

ve multiple candidate CAs having their "public discussion periods" simultaneously? Having watched this list for a number of months, I think I'm right in saying that you're only allowing one at a time...in which case, how is having "more people now working on CA-rela

Re: Debian Weak Key Problem

ailing list > dev-tech-crypto@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, R

Re: Modulus length (was Re: Draft CA information checklist)

/TLS handshakes. With this approach, Mozilla could even continue to accept new 1024-bit Root Certificate submissions for the next few years (not that I'm advocating that, of course!) > Gerv > ___ > dev-tech-crypto mailing list > d

Re: Modulus length (was Re: Draft CA information checklist)

that key anyway, and I would expect it to adhere to the > CPS espoused by that key -- but that's how it was explained.) > > -Kyle H > > 2008/6/5 Eddy Nigg (StartCom Ltd.) <[EMAIL PROTECTED]>: > > Rob Stradling: > > > > Sorry Rob, yes I missed that one. But w

Re: Modulus length (was Re: Draft CA information checklist)

On Thursday 05 June 2008 12:59:13 Eddy Nigg (StartCom Ltd.) wrote: > Rob Stradling: > >> Additionally, most of the times the old and the new root will be both > >> present in NSS for some time in order to allow a smooth transition, > >> until the old root is being

Re: Modulus length (was Re: Draft CA information checklist)

On Thursday 05 June 2008 12:05:42 Eddy Nigg (StartCom Ltd.) wrote: > Rob Stradling: > >> Rob, in the past, any time that we have suggested that a CA issue a new > >> root CA cert for any reason, even if only to change something minor, > >> we've received

Re: Modulus length (was Re: Draft CA information checklist)

dea is worth considering? > > Definitely worth considering. > ___ > dev-tech-crypto mailing list > dev-tech-crypto@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-tech-crypto -- Rob Stradling Senior Research & Development Sc

Re: Modulus length (was Re: Draft CA information checklist)

On Wednesday 04 June 2008 21:32:17 Nelson B Bolyard wrote: > Rob Stradling wrote, On 2008-06-04 04:45: > > 2. Give each affected CA the opportunity to submit a replacement > > 1024-bit RSA Root Certificate for inclusion in new versions of Mozilla > > software. Each of t

Re: Modulus length (was Re: Draft CA information checklist)

___ > > 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.o

Re: Modulus length (was Re: Draft CA information checklist)

not work with 4096 bit > root. > > Ciao, Michael. > ___ > dev-tech-crypto mailing list > dev-tech-crypto@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-tech-crypto -- Rob Stradling Senior Research & Development S

Re: Comodo request for EV root inclusion (COMODO Certification Authority)

On Wednesday 19 March 2008, Eddy Nigg (StartCom Ltd.) wrote: > Rob Stradling: > > Now, Frank has said "At present there are two subordinate CAs under > > the "COMODO Certification Authority" root: "COMODO EV SSL CA" and "COMODO > > EV SGC CA&q

Re: Comodo request for EV root inclusion (COMODO Certification Authority)

?id=401587#c16 > > The details at the "Pending" page have been updated by Frank concerning > this CA root. There are no objections to adding this root, but please > note that this root will only issue EV certificates * and should be > enabled for EV only, provided if and

Re: Comodo request for EV-enabling 3 existing roots

gh review of > this CA in place in order to guaranty conformance to the Mozilla CA > policy? Because an upgrade to EV would tie this CA further into NSS I > believe that such a review should be performed prior to any other step. > I haven't invested a lot of time into this req

Re: Comodo request for EV-enabling 3 existing roots

t; > The scheme we have now trades off maximum control for implementability. > We have relatively coarse-grained controls, and then we rely on CAs to > implement more fine-grained controls (e.g., using certificatePolicies, > EKU, etc.). This means that CAs in theory could abuse t