Re: cacert.org

CAcert.org, the basic situation is that, like all CAs, it has to go through some sort of audit or audit-like process. If you want to know what they're currently doing with regard to that requirement, I suggest contacting CAcert directly; I don't want to speak for them. Frank -- Frank Hecker

Why Phishing Works paper

This really should be required reading for anyone interested in anti-phishing defenses, the SSL UI, and related topics: http://www.deas.harvard.edu/~rachna/papers/why_phishing_works.pdf Frank -- Frank Hecker [EMAIL PROTECTED] ___ dev-tech-crypto

StartCom CA inclusion request

(depending on how many comments I get), and then I'll make a decision on this request. Frank -- Frank Hecker [EMAIL PROTECTED] ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: StartCom CA inclusion request

Frank Hecker wrote: I'm finally getting back to working on requests for CA for their root certificates to be included in NSS/Mozilla. (Yes, I suck for leaving this undone for so long; my apologies.) The first one I'm working on is for StartCom Ltd., bug 289077: https://bugzilla.mozilla.org

Re: StartCom CA inclusion request

Frank Hecker wrote: I'm finally getting back to working on requests for CA for their root certificates to be included in NSS/Mozilla. (Yes, I suck for leaving this undone for so long; my apologies.) The first one I'm working on is for StartCom Ltd., bug 289077: https://bugzilla.mozilla.org

Re: GRCA root cert inclusion request

Frank Hecker wrote: Continuing in my ongoing question to reduce the backlog of CA applications, I'm now soliciting final comments on the application from GRCA, bug 274106: https://bugzilla.mozilla.org/show_bug.cgi?id=274106 snip Since this request seems pretty straightforward I'm going

Re: Firmaprofesional root cert inclusion request

Frank Hecker wrote: I'm working on a number of CA requests to get their certs included in Mozilla, and I'm now soliciting comments on the application from Firmaprofesional, bug 342426: snip Since this request seems pretty straightforward I'm going to have a relatively brief comment period

Re: Swisscom root cert inclusion request

Frank Hecker wrote: Kyle Hamilton wrote: Swisscom issues CRLs how often? snip Do they have an OCSP responder? I got answers to these questions; see the bug report (342470). Frank -- Frank Hecker [EMAIL PROTECTED] ___ dev-tech-crypto mailing list

Wells Fargo root cert inclusion request

period and then I'll make my final decision. Frank -- Frank Hecker [EMAIL PROTECTED] ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Wells Fargo root cert inclusion request

Christian Barmala wrote: Frank Hecker [EMAIL PROTECTED] wrote: Wells Fargo has successfully completed a formal audit using the WebTrust criteria. Who was the auditor? KPMG. (I thought I put this on my CA certificate page, but I didn't; I'll add it now.) Frank -- Frank Hecker [EMAIL

Go Daddy 6-in1 certs and NSS?

that such certificates should work fine in Firefox and other Mozilla-based products, assuming that the names are stored in the certificate using SubjectAltName as opposed to CN. Am I correct in this supposition? Frank -- Frank Hecker [EMAIL PROTECTED

Re: Go Daddy 6-in1 certs and NSS?

names in the certificate. In any case I'm surprised that more commercial CAs aren't supporting the issuance of SSL certificates that handle some of these common situations. Frank -- Frank Hecker [EMAIL PROTECTED] ___ dev-tech-crypto mailing list dev

Re: Go Daddy 6-in1 certs and NSS?

Frank Hecker wrote: Someone brought to my attention today that Go Daddy is now offering a 6-in-1 SSL certificate where they allow you to associate multiple domain names from different TLDs with a single certificate: https://www.godaddy.com/gdshop/whatsnew/landing.asp?se=%2Bapp%5Fhdr=ci=4635

Geotrust request to add more roots

: http://www.hecker.org/mozilla/ca-certificate-list#geotrust As noted in that entry and in the bug itself, Geotrust has successfully completed a WebTrust audit and otherwise appears to be in compliance with our current policy. Therefore I plan to approve this request. Frank -- Frank Hecker [EMAIL

Re: Go Daddy 6-in1 certs and NSS?

Nelson B wrote: Frank Hecker wrote: In looking at Geotrust's request to add more root CA certs (bug 294916) I happened to notice that Geotrust offers a somewhat similar service, [snip] From the product description it appears that one domain goes in the CN attribute and the rest

Issue regarding Power Server ID certificates

misinterpreted the description at http://www.geotrust.com/products/ssl_certificates/power_server_id.asp Thanks in advance for any info you can provide on this. Frank Nelson B wrote: Frank Hecker wrote: In looking at Geotrust's request to add more root CA certs (bug 294916) I happened to notice

Re: Go Daddy 6-in1 certs and NSS?

Frank Hecker wrote: Nelson B wrote: Frank Hecker wrote: In looking at Geotrust's request to add more root CA certs (bug 294916) I happened to notice that Geotrust offers a somewhat similar service, [snip] From the product description it appears that one domain goes in the CN attribute

Re: OCSP/CRL handling in Firefox

preferences: Advanced - Security - Verification Frank -- Frank Hecker [EMAIL PROTECTED] ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto

[Fwd: PKI RD Workshop - Early Bird Registration Deadline Approaching]

My apologies for the semi-spam, but I thought that readers of this forum might be interested in this NIST-sponsored PKI-related workshop. (I'll most likely attend it myself, especially since it's not that far from where I live.) Frank -- Frank Hecker [EMAIL PROTECTED] ---BeginMessage--- 6th

Re: attribution question for using NSS/NSPR or JSS in an application

, etc., in other contexts I'm sure the NSS/NSPR/JSS developers wouldn't mind the publicity.) Frank -- Frank Hecker [EMAIL PROTECTED] ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: CAs and country restrictions

of a totalitarian state we wouldn't have such confidence, so I think the North Korean example is a red herring. Per our policy we always reserve the right to bar a CA from inclusion if we think things are hinky (to use one of Bruce Schneier's favorite terms). Frank -- Frank Hecker [EMAIL PROTECTED

Updating Mozilla CA certificate policy to address EV certificates

to post them here. In the meantime I'll work to come up with an initial draft of proposed changes to the policy text, and will post that to the bug when done. Frank -- Frank Hecker [EMAIL PROTECTED] ___ dev-tech-crypto mailing list dev-tech-crypto

Re: Updating Mozilla CA certificate policy to address EV certificates

-equivalent EV audit regime. Second, I would prefer that we use the standard CAB Forum mechanisms to try and address this issue. Frank -- Frank Hecker [EMAIL PROTECTED] ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org

Re: Updating Mozilla CA certificate policy to address EV certificates

Frank Hecker wrote: I've filed a bug against myself (399214) to update the current Mozilla CA certificate policy to address the issue of extended validation certificates. After thinking about it, I think it may be possible to do this just by adding a final paragraph to section 6

Re: Updating Mozilla CA certificate policy to address EV certificates

Eddy Nigg (StartCom Ltd.) wrote: Frank Hecker wrote: After thinking about it, I think it may be possible to do this just by adding a final paragraph to section 6 of the current policy: snip Shouldn't be this be part of section 8 as this is a criteria for CA operations (and its associated

Re: Inclusion of VeriSign EV root in Firefox 3 betas for testing

/ shows this as well. Also, you can try these in Vista/IE7 to see how they're handled there vs. XP/IE6. Frank -- Frank Hecker [EMAIL PROTECTED] ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev

Re: Inclusion of VeriSign EV root in Firefox 3 betas for testing

Frank Hecker wrote: However the general changes to be made to the policy are clear, even if the language is final, s/final/not final/ Frank -- Frank Hecker [EMAIL PROTECTED] ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https

Re: Inclusion of VeriSign EV root in Firefox 3 betas for testing

. Frank -- Frank Hecker [EMAIL PROTECTED] ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Inclusion of VeriSign EV root in Firefox 3 betas for testing

solicit requests from VeriSign and everyone else who'll be issuing EV certs, and those requests will be handled in the normal way. Frank -- Frank Hecker [EMAIL PROTECTED] ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https

Re: Updating Mozilla CA certificate policy to address EV certificates

Eddy Nigg (StartCom Ltd.) wrote: Frank Hecker wrote: snip Your implication here is that the CAB Forum EV guidelines can be used as stand-alone guidelines comparable to the other criteria referenced in section 8 (WebTrust for CAs, ETSI TS 101 456 and 102 242, and ANSI X9.79). I'm

Re: Inclusion of VeriSign EV root in Firefox 3 betas for testing

to be included. If I invite a CA to have their EV root be included (or an existing root be marked as EV-capable), and they don't respond to that invitation, then I likely won't feel any obligation to do anything about their EV root. Frank -- Frank Hecker [EMAIL PROTECTED

Re: Updating Mozilla CA certificate policy to address EV certificates

certificate extension per se. The EV policy OID is just added as separate metadata to be associated with the pre-loaded root CA certificate; there is nothing in the CA certificate itself that is specifically EV-related. Frank -- Frank Hecker [EMAIL PROTECTED

Re: Inclusion of VeriSign EV root in Firefox 3 betas for testing

, the subordinate 2 CA lacks that policy OID (or the anyPolicy OID) and so the EE cert will fail the EV test. So AFAICT there's no need for NSS to pre-load the subordinate 1 CA cert. Frank -- Frank Hecker [EMAIL PROTECTED] ___ dev-tech-crypto mailing

Re: Updating Mozilla CA certificate policy to address EV certificates

Frank Hecker wrote: OK, absent any objections my plan is to go ahead and commit this change later today or tomorrow. Done. The 1.1 release of the Mozilla CA certificate policy is now live at the standard URL: http://www.mozilla.org/projects/security/certs/policy/ Thanks to Eddy, Gerv

Re: Inclusion of VeriSign EV root in Firefox 3 betas for testing

upgrades and related changes in order to do testing of the NSS EV code (e.g., for Firefox 3 beta). Such approval does not constitute approval for permanent upgrades, which will be handled per policy as discussed above. Frank -- Frank Hecker [EMAIL PROTECTED

Re: SwissSign root CA certificate inclusion request

auditors' report on management assertions (or whatever it's called). However you can ask Melanie Raemy of SwissSign about that; just post a comment in bug 343756 and she should see it. Frank -- Frank Hecker [EMAIL PROTECTED] ___ dev-tech-crypto mailing

Re: SwissSign root CA certificate inclusion request

was (one of) the criteria used in the audit. I'm confused by your question: Is your concern that SAS/KPMG used a variant of ETSI TS 101.456, or a subset of it, or some other practice that did not actually amount to an audit according to the ETSI TS 101.456 criteria? Frank -- Frank Hecker [EMAIL

Re: SwissSign root CA certificate inclusion request

if the audit criteria encompassed both ETSI TS 101.456 and ZertES, as long as the requirements of ETSI TS 101.456 were satisfied. Frank -- Frank Hecker [EMAIL PROTECTED] ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org

Re: [Bug 343756] Request to add SwissSign root CA certificate

of the audit letter and other documents; notarized copies should suffice. Frank -- Frank Hecker [EMAIL PROTECTED] ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: SwissSign root CA certificate inclusion request

of independent confirmation is worth doing in other cases where CAs provide documents like this, especially if the document in question is the sole or primary source of information we have relating to independent audits and evaluations. Frank -- Frank Hecker [EMAIL PROTECTED

Re: TURKTRUST root CA certificate inclusion request

://bugzilla.mozilla.org/attachment.cgi?id=286696 is in PDF format I think Please don't use the CPS documents attached to the bug. The English version of the CPS is now available in PDF format directly from the TÜRKTRUST site: http://www.turktrust.com.tr/pdf/cps_third.pdf Frank -- Frank Hecker

Re: TURKTRUST root CA certificate inclusion request

comfortable. See my previous message; the English version of the current CPS is at http://www.turktrust.com.tr/pdf/cps_third.pdf Frank -- Frank Hecker [EMAIL PROTECTED] ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https

Re: Mozilla CA Certificate Policy (Version 1.1) ammendment recommendations

that one must have been performed. This is an issue worth discussing; I don't have any finished thoughts on it right now. Frank -- Frank Hecker [EMAIL PROTECTED] ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https

Re: TURKTRUST root CA certificate inclusion request

of this on the CA recommended practices wiki page, as a reminder. Frank -- Frank Hecker [EMAIL PROTECTED] ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: TURKTRUST root CA certificate inclusion request

Nelson B Bolyard wrote: Frank Hecker wrote: For the record, I am pretty sure that we have CAs already in the root list that have issued test certs under their hierarchies. IIRC the last instance of this I saw was a CA that had a subordinate CA used to testing purposes, under the root CA

Re: TURKTRUST root CA certificate inclusion request

Frank Hecker wrote: I've therefore signaled my approval of this application in bug 380635, and will proceed to file an NSS bug for inclusion of the actual root CA certs. Filed bug 410821 for inclusion of the TURKTRUST certs into NSS: https://bugzilla.mozilla.org/show_bug.cgi?id=410821

Sorting through EV root CA requests

. Next step is figuring out the basic parameters for each request. Till later... Frank -- Frank Hecker [EMAIL PROTECTED] ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: KISA root CA certificate inclusion request

by MIC in their public statement. I don't know if they used the actual WebTrust criteria themselves, or something else judged equivalent; this is worth asking about, and I have done so. Frank -- Frank Hecker [EMAIL PROTECTED] ___ dev-tech-crypto mailing

Re: Sorting through EV root CA requests

submit them now. Frank -- Frank Hecker [EMAIL PROTECTED] ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Sorting through EV root CA requests

regarding the CAs we're looking at first. Does this help answer your question? Frank -- Frank Hecker [EMAIL PROTECTED] ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: KISA root CA certificate inclusion request

certificates directly, but has subordinate CAs which do so. (As you note, this is a common setup in many countries.) That's why Gerv and I invested a fair amount of effort trying to determine what these subordinate CAs actually do. Frank -- Frank Hecker [EMAIL PROTECTED

Re: Sorting through EV root CA requests

to specify the final criteria and guidelines only, to emphasize that the drafts are obsolete and deprecated. Frank -- Frank Hecker [EMAIL PROTECTED] ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo

Re: Sorting through EV root CA requests

Eddy Nigg (StartCom Ltd.) wrote: Frank Hecker wrote: snip To make this more concrete, I'll file a bug with a proposed policy change to reflect this line of thinking. OK. Please send me the bug number for reference, thanks! https://bugzilla.mozilla.org/show_bug.cgi?id=413545 A proposed

Re: Proposed Mozilla cert policy refinements

Nelson Bolyard wrote: Yes, Sorry. Bug 413375 . See my comments in the bug. The bottom line is that IMO we need more information before we can reasonably discuss policy changes related to the issues you raise. Frank -- Frank Hecker [EMAIL PROTECTED

Re: Sorting through EV root CA requests

Frank Hecker wrote: The first step is getting a complete list of all current EV-related CA requests. I believe the following is the complete list, based on searching bugzilla: I've got several of these listed now on the pending list, as noted below; I 'll get the remainder up as soon as I

Proposed revision to Mozilla CA certificate policy for interim use of draft EV guidelines

/show_bug.cgi?id=413545 Based on comments thus far this seems to be a relatively non-controversial change, so I'm going to go ahead and make it after one final call for comments. Frank -- Frank Hecker [EMAIL PROTECTED] ___ dev-tech-crypto mailing list

Trustwave request for EV root inclusions/upgrade

previous message. Frank -- Frank Hecker [EMAIL PROTECTED] ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto

Digicert request for root upgrade to EV

time I want to start the comment period now.) Note that the WebTrust EV audit for Digicert was done under the final EV guidelines and WebTrust EV criteria, so its acceptance under our policy is not dependent on making the proposed policy change discussed in my earlier message. Frank -- Frank

QuoVadis request for root upgrade to EV

time I want to start the comment period now.) Frank -- Frank Hecker [EMAIL PROTECTED] ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Proposed revision to Mozilla CA certificate policy for interim use of draft EV guidelines

Paul Hoffman wrote: Will there be a cutoff for when Mozilla requires audits against the final guidelines instead of allowing draft guidelines? Yes, per the revised policy the cutoff date is June 30. Frank -- Frank Hecker [EMAIL PROTECTED] ___ dev

Re: Proposed revision to Mozilla CA certificate policy for interim use of draft EV guidelines

Frank Hecker wrote: I've therefore proposed a new revision 1.2 of the policy to accept all valid WebTrust EV audits, whether against the draft or final criteria and guidelines, for all CA EV applications submitted on or before June 30 of this year: https://bugzilla.mozilla.org

Re: Trustwave request for EV root inclusions/upgrade

about for long-term NSS/PSM planning. It's sort of a special case of the general problem of having NSS/PSM be able to take special actions (either built-in or user-specified) based on certificate policy values. Frank -- Frank Hecker [EMAIL PROTECTED

Re: WISeKey root CA certificate inclusion request

agreements, etc. That's another factor that I have to take into consideration; I've been and remain reluctant to hold new CA applicants to standards that aren't clearly spelled out in our policy, if we're not yet applying those same standards to older CAs.) Frank -- Frank Hecker [EMAIL

Re: WISeKey root CA certificate inclusion request

, for example, we might not impose exactly the same audit requirements as we would for other CAs.) Frank -- Frank Hecker [EMAIL PROTECTED] ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto

Go Daddy request for root upgrade to EV

Go Daddy's request, as per the mozilla.org CA certificate policy: http://www.mozilla.org/projects/security/certs/policy/ and plan to officially approve this request after a public comment period. Frank -- Frank Hecker [EMAIL PROTECTED] ___ dev

Re: Reassessment of sub-ordinated CA certificates

OID(s) included. Frank -- Frank Hecker [EMAIL PROTECTED] ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: WISeKey root CA certificate inclusion request

to that root would be a warning message of some sort. (As always, if people think something like this would be worthwhile, we can always consider funding the work.) Frank -- Frank Hecker [EMAIL PROTECTED] ___ dev-tech-crypto mailing list dev-tech-crypto

Re: Reassessment of sub-ordinated CA certificates

for the Mozilla Foundation to fund.) Frank -- Frank Hecker [EMAIL PROTECTED] ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Digicert request for root upgrade to EV

Frank Hecker wrote: Digicert has applied to upgrade an existing root CA certificate for EV use, as documented in the following bug: https://bugzilla.mozilla.org/show_bug.cgi?id=403644 and in the pending certificates list: http://www.mozilla.org/projects/security/certs/pending

Re: Reassessment of sub-ordinated CA certificates

or not this is actually being done in practice, I think the EV guidelines are pretty clear that it is not sufficient merely for the root CA to be audited; the audit requirements extend to each and every subordinate CA issuing EV certs. Frank -- Frank Hecker [EMAIL PROTECTED

Re: QuoVadis request for root upgrade to EV

Frank Hecker wrote: QuoVadis has applied to upgrade an existing root CA certificate for EV use, as documented in the following bug: https://bugzilla.mozilla.org/show_bug.cgi?id=403665 snip I have evaluated QuoVadis's request, as per the mozilla.org CA certificate policy: http

GeoTrust request for EV root inclusion

certificate referenced in bug 407168; it is not related to any other thawte CAs that might already be in the root list. Frank -- Frank Hecker [EMAIL PROTECTED] ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org

Re: GeoTrust request for EV root inclusion

. In the meantime I worked on a few other EV requests from CAs that don't have dominant market share. (More later, I have to run out for an emergency errand...) Frank -- Frank Hecker [EMAIL PROTECTED] ___ dev-tech-crypto mailing list dev-tech-crypto

Re: GeoTrust request for EV root inclusion

(Back from errand...) Frank Hecker wrote: Is your concern that the CPS is dated after the audit? First, feel free to ask in the bug what changes were made between the audit and the date of publication of the 1.0 CPS. (I'll do it as well if you don't do it first.) Don't bother, I already

Re: GeoTrust request for EV root inclusion

assuming more logic here than there actually is; I don't look as much at market share as might be justifiable. Frank -- Frank Hecker [EMAIL PROTECTED] ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo

Re: GeoTrust request for EV root inclusion

, it is a coincidence, because these are two different sets of certs. I presume you're referring to the message to m.d.planning, which was then copied to m.d.t.crypto; that message was primarily about the new VeriSign ECC roots, which are *not* going to be evaluated in time for Firefox 3.0. Frank -- Frank Hecker

Re: GeoTrust request for EV root inclusion

Frank Hecker wrote: Here's my interpretation of what happened: KPMG audited against the True businessID CPS of July 27, 2007 s/July 27, 2007/July 1, 2007/g The version number of the document is 2.7, which is probably why I made this particular error. Frank -- Frank Hecker [EMAIL PROTECTED

Re: GeoTrust request for EV root inclusion

Frank Hecker wrote: The new CPS didn't exist at the time of the audit, but it did exist at the time of the audit report. Actually, the new CPS was in fact written and approved during the audit period; see https://bugzilla.mozilla.org/show_bug.cgi?id=407168#c26 The bottom line: I think

Re: GeoTrust request for EV root inclusion

question that had a non-trivial answer. Frank -- Frank Hecker [EMAIL PROTECTED] ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto

Comodo request for EV root inclusion (COMODO Certification Authority)

. Frank -- Frank Hecker [EMAIL PROTECTED] ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto

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

Certification Authority root: COMODO EV SSL CA and COMODO EV SGC CA. These two subordinates are the issuing CAs for end entity certs. Frank -- Frank Hecker [EMAIL PROTECTED] ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https

Comodo request for EV-enabling 3 existing roots

to the other eight Comodo roots. Frank -- Frank Hecker [EMAIL PROTECTED] ___ 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

, for exactly this reason.) Frank -- Frank Hecker [EMAIL PROTECTED] ___ 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

references is basically a case of Comodo being honest and admitting that LiteSSL certs are adequate for some purposes (e.g., securing a low-value personal or small group site like my own) but not for others (e.g., running an online store). That statement strikes me as unexceptional. Frank -- Frank

Re: Comodo request for EV-enabling 3 existing roots

word here is knowingly. This language in the policy was intended to cover cases where CAs were willing and knowing accomplices to fraud. Frank -- Frank Hecker [EMAIL PROTECTED] ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https

Re: Comodo request for EV-enabling 3 existing roots

with regard to LiteSSL certs, and ended up introducing ambiguity into the CPS. However I don't think this amounts to LiteSSL certs being totally insecure and unreliable; they appear to be garden-variety domain-validated certs, no more and no less. Frank -- Frank Hecker [EMAIL PROTECTED

Re: Comodo request for EV-enabling 3 existing roots

EV intermediate CA certificates under this root and the mentioning of DV,IV etc is wrong perhaps? Yes, this is my mistake. I'll correct the entry for COMODO Certification Authority in the pending list. Frank -- Frank Hecker [EMAIL PROTECTED

Re: Comodo request for EV-enabling 3 existing roots

steps as if they were new roots. Frank -- Frank Hecker [EMAIL PROTECTED] ___ 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

be useful then people are free to contibute it or (if no one is willing or able to do it) the Mozilla Foundation could help fund its creation. Frank -- Frank Hecker [EMAIL PROTECTED] ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https

Re: Comodo request for EV-enabling 3 existing roots

Nelson B Bolyard wrote: Frank Hecker wrote, On 2008-03-18 05:17: Right now we don't have any technical mechanism to accept only EV certificates issued within a CA hierarchy, but not EV certs from within that same hierarchy. snip I suspect you meant ... to accept EV certs, but not NON-EV

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

COMODO Certification Authority, which we already use for issuing one of our brands of DV certificate. Could you identify the subordinate CA in question and the Comodo brand it's being used in conjunction with? This is information I'd like to add the pending list entry. Frank -- Frank Hecker

Project Dogtag, an open source certificate system

on this product over the years, and especially to the folks at Red Hat who finally managed to get the whole product released under open source licenses. Frank -- Frank Hecker [EMAIL PROTECTED] ___ dev-tech-crypto mailing list dev-tech-crypto

Re: thawte request for EV root inclusion

Frank Hecker wrote: thawte has applied to add a new EV root CA certificate to the Mozilla root store, as documented in the following bug: https://bugzilla.mozilla.org/show_bug.cgi?id=407163 snip I have evaluated this request, as per the mozilla.org CA certificate policy: http

Re: GeoTrust request for EV root inclusion

Frank Hecker wrote: GeoTrust has applied to add a new EV root CA certificate to the Mozilla root store, as documented in the following bug: https://bugzilla.mozilla.org/show_bug.cgi?id=407168 snip I have evaluated this request, as per the mozilla.org CA certificate policy: http

Re: Comodo request for EV-enabling 3 existing roots

cert arena, for wildcard certs or otherwise. Frank -- Frank Hecker [EMAIL PROTECTED] ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: certificate database of Thunderbird

to worry about the GPL or LGPL terms). Frank -- Frank Hecker [EMAIL PROTECTED] ___ 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

Eddy Nigg (StartCom Ltd.) wrote: We aren't talking here about a possible gain in material only (money, credit cards), but also eavesdropping and acquiring information. Breached privacy is a *LOSS* for the relying party and LOST trust in the software upon which the relying party relies,

Re: Comodo request for EV-enabling 3 existing roots

Robin Alden wrote: Issuing long-lived DV certs and wildcard DV certs may be particular practices worth our having some formal positions on, even if they're not addressed by our official policy. [Robin said...] There I have to disagree to some degree. You have a policy which tells us

Re: Comodo request for EV-enabling 3 existing roots

Robin Alden wrote: Perhaps my problem then is understanding the process at all. You seem to suggest that once our application for EV status is approved we somehow become immune to changes in your CA policy. Why do you feel that Mozilla has no control over the CAs other than at the point of

Re: Comodo request for EV-enabling 3 existing roots

Robin Alden wrote: Is there anything remaining which would now hold up approval of our CA requests? I have to go through all this and write up my final statement on the issues at hand. I think all issues have been responded to one way or another. Frank

  1   2   3   4   >