Re: cert extension: authority key identifier (AKI)

at it ships in its products? If so, you should post this question in the dev-security-policy list. Note that Daniel asked me about this first, and I couldn't remember where this issue fell with respect to policy vs. technology. So I was the one who suggested he post here. Frank -- Frank

Re: Basic ECC in NSS 3.12.4 with NSPR 4.8

or until Certicom further loosens the license language (which depends on its own business interests, of course). Frank -- Frank Hecker hec...@mozillafoundation.org -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Basic ECC in NSS 3.12.4 with NSPR 4.8

tinguish between ECC and (e.g.) RSA, AES, etc., and have permitted export of open source encryption code since 2000 or so. Frank -- Frank Hecker hec...@mozillafoundation.org -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Rus GOST 89

ne else. In the US the original developer may not even be credited, unless that was specifically provided for in the agreement. (Other countries have a "moral rights" concept that changes this somewhat.) Frank -- Frank Hecker hec...@mozillafoundation.org -- dev-tech-crypto mai

Re: Rus GOST 89

assignment are to have a single copyright holder for the purposes of enforcing the copyright (the FSF case) and to be able to relicense the entire work under a different license (the MySQL AB case). Frank -- Frank Hecker hec...@mozillafoundation.org -- dev-tech-crypto mailing list dev-tech-crypto

Re: Rus GOST 89

genuine interest in supporting GOST and someone willing and able to do the implementation. Frank -- Frank Hecker hec...@mozillafoundation.org -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Extrace Mozilla trusted certs into PEM files?

hread/791684fa7b490e96# Also, like the list above this list is generated from an XML file. Frank -- Frank Hecker hec...@mozillafoundation.org -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto

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

from including the SHA-256 root is pretty small. Frank -- Frank Hecker hec...@mozillafoundation.org -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto

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

, would it not? Frank -- Frank Hecker hec...@mozillafoundation.org -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto

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

advice, this answers the question as far as I'm concerned. Frank -- Frank Hecker hec...@mozillafoundation.org -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Firefox 3.5

ext 3.0.x release (3.0.11, I believe). Frank -- Frank Hecker hec...@mozillafoundation.org -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto

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

. (Does this include the case when Firefox, etc., receive a full cert chain that includes the old root?) Is the above a correct reading of your comments? Frank -- Frank Hecker hec...@mozillafoundation.org -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.o

Re: Pending roots and EV enablements

Frank -- Frank Hecker hec...@mozillafoundation.org -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Pending roots and EV enablements

, and we're still awaiting an answer. Maybe Frank can make something good happen there. Unfortunately I don't have any real power with respect to what goes into Firefox 3.5 :-( However I will do what I can. Frank -- Frank Hecker hec...@mozillafoundation.org -- dev-tech-crypto mailin

Re: Fwd: Has any public CA ever had their certificate revoked?

hus having the root "revoked"? Frank -- Frank Hecker hec...@mozillafoundation.org -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Current algorithm support for Firefox?

albiii wrote: Please get Mozillla's Window Snider involved. That powerhouse of convincing attitude can make anything happen ! :-) Note that Window no longer works for Mozilla: http://blog.mozilla.com/security/2008/12/10/leaving-mozilla/ Frank -- Frank Hecker hec...@mozillafoundatio

Re: Microsec Root Inclusion Request Round 2

arian localization team to double-check the translation. However they are volunteers, and I do not want to burden them by asking them to check the entire CPS translation. Frank -- Frank Hecker hec...@mozillafoundation.org -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org

Re: [Fwd: Warning: Your SSL Certificate on trust-value.com is expiring soon. Upgrade to 2048-bit today]

ngage in. If you and others disagree with that philosophy then you all are free to try to convince the appropriate people https://wiki.mozilla.org/Module_Owners_Activities_Modules#Governance_Submodule:__Module_Ownership_System to override my views on the matter. Frank -- Frank Hecker hec...@m

Re: [Fwd: Warning: Your SSL Certificate on trust-value.com is expiring soon. Upgrade to 2048-bit today]

s.google.com/group/netscape.public.mozilla.crypto/msg/45e7135322b15f4c So, consistent with my position back then, I am *not* in favor of our imposing a policy requirement that CAs (or their resellers) not engage in spamming. It's not directly relevant to a CA's performance as a CA. Fra

Re: ComSign Root Inclusion Request

Humphrey of Seneca and ask him to add this to the candidate student project list he's creating. Frank -- Frank Hecker hec...@mozillafoundation.org -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: ComSign Root Inclusion Request

commitment yet to support CIDP. So it is best for CAs if their CRLDP extension references a URI for a full CRL, not a partitioned CRL. Frank -- Frank Hecker hec...@mozillafoundation.org -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: ComSign Root Inclusion Request

, are they doing partitioned CRLs like Hongkong Post? Or is the CRL a full CRL? Frank -- Frank Hecker hec...@mozillafoundation.org -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Hongkong Post Root Inclusion Request

ioned CRL. Please correct me if I'm wrong. Frank -- Frank Hecker hec...@mozillafoundation.org -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Hongkong Post Root Inclusion Request

certificates continue to be recognized in Firefox, etc. Frank -- Frank Hecker hec...@mozillafoundation.org -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Hongkong Post Root Inclusion Request

no support/unknown status or full support/known status). The third scenario was introduced by RFC 5280. Frank -- Frank Hecker hec...@mozillafoundation.org -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Hongkong Post Root Inclusion Request

#x27;ve already had the treatment of the CIDP extension in CRLs as one example, and I think we've concluded that that particular difference is not an issue. (I agree with Nelson that the 5280 language on non-support of CIDP is flawed and can be safely ignored.) Frank

Re: Hongkong Post Root Inclusion Request

Nelson B Bolyard wrote: Frank Hecker wrote, On 2009-02-20 16:53: "However, implementations that do not support this extension MUST either treat the status of any certificate *not listed on this CRL* as unknown or locate another CRL that does not contain any unrecog

Re: Hongkong Post Root Inclusion Request

7;ll post as a followup to your earlier post about RFC 5280. I'm looking forward to reading your comments on this. As I wrote, I don't yet fully understand this particular section of RFC 5280. Frank -- Frank Hecker hec...@mozillafoundation.org -- dev-tech-crypto mailing list dev-tech

Re: Hongkong Post Root Inclusion Request

Nelson B Bolyard wrote: Frank Hecker wrote, On 2009-02-23 11:30: I have no problem with NSS ignoring CRLs with CIDP extensions in the context of CRLDP support; however I think that (e.g.) Firefox should not treat this as an error but should proceed as if no CRL were ever seen. (I think it'

Re: Hongkong Post Root Inclusion Request

't speak for the NSS developers, however speaking personally I see no reason to drop support for manual import of CRLs. Frank -- Frank Hecker hec...@mozillafoundation.org -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Return of i18n attacks with the help of wildcard certificates

As. Gerv Markham was pretty heavily involved in the IDN issues with domain name registrars. I've copied him on this in hopes he can add more information. Frank -- Frank Hecker hec...@mozillafoundation.org -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.o

Re: Hongkong Post Root Inclusion Request

were not present at all. That seems to be the approach you've taken. That would seem to be consistent with the strict wording of the RFC, unless there's something else in the RFC to the contrary. Frank -- Frank Hecker hec...@mozillafoundation.org -- dev-tech-crypto mailing list dev

Re: Hongkong Post Root Inclusion Request

Frank Hecker wrote: Option 4: Hongkong Post makes no changes to either its CRLs or its end entity certs, and NSS ignores partitioned CRLs encountered in CRL DP processing. In this option Hongkong Post would make no changes whatsoever to its current practices. NSS would fetch the partitioned

Re: Hongkong Post Root Inclusion Request

oading the full CRL manually -- in other words, it would maintain the same situation we're in now in the absence of CRL DP support in NSS. Your thoughts? Frank -- Frank Hecker hec...@mozillafoundation.org -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Hongkong Post Root Inclusion Request

Jean-Marc Desperrier wrote: Frank Hecker wrote: [...] Am I right that someone who wished to check revocation status on EE certs in Firefox could just download the full CRL and use that? [...] The right word is indeed *could*. The address of that CRL *does not* appear inside the certificate

Re: Hongkong Post Root Inclusion Request

? (In other words, if we were to include the Hongkong Post root in NSS then there's no possibility of NSS throwing errors unless someone tries to use the partitioned CRLs.) Frank -- Frank Hecker hec...@mozillafoundation.org -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla

Re: Hongkong Post Root Inclusion Request

tation of partitioned CRLs unless we see many other CAs using them. I think implementation of partitioned CRLs is already blocked by insufficient developer resources, independent of what our policy might say on the matter. Frank -- Frank Hecker hec...@mozillafoundation.org -- dev-

Re: Certigna Root Inclusion Request

for us. If everybody agree with, we can send you the fair portion of CPS in english and our auditor will confirm you the genuineness of the document. To repeat what I wrote elsewhere: This plan is acceptable to us. Fran -- Frank Hecker hec...@mozillafoundation.org -- dev-tech-crypto mailing

Re: Certigna Root Inclusion Request

from the CPS that was referenced in your audit. Kathleen, as I understand it, Yannick Leplard of Certigna has proposed doing option 2 above, and that would be acceptable to us as far as I'm concerned. Frank -- Frank Hecker hec...@mozillafoundation.org -- dev-tech-crypto mailing list dev

Re: Certigna Root Inclusion Request

y has published a useful set of guidelines for how to properly redact Microsoft Work documents published as PDF files: http://www.fas.org/sgp/othergov/dod/nsa-redact.pdf -- Frank Hecker hec...@mozillafoundation.org -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org

Re: Certigna Root Inclusion Request

rom the CPS. Frank -- Frank Hecker hec...@mozillafoundation.org -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Certigna Root Inclusion Request

manual" that is internal-only. Frank -- Frank Hecker hec...@mozillafoundation.org -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Certigna Root Inclusion Request

David E. Ross wrote: On 2/10/2009 12:06 PM, Frank Hecker wrote: If you cannot publish the CPS because it contains private information, I suggest as an alternative that you provide some sort of official Certigna document that summarizes the portions of the CPS that are of most interest to us

Re: Public CPS Requirement [Was: Certigna Root Inclusion Request]

Eddy Nigg wrote: On 02/10/2009 10:06 PM, Frank Hecker: If you cannot publish the CPS because it contains private information, I suggest as an alternative that you provide some sort of official Certigna document that summarizes the portions of the CPS that are of most interest to us (i.e., those

Re: Quorum requirements for approval of CAs?

es, please feel free. -- Frank Hecker hec...@mozillafoundation.org -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Certigna Root Inclusion Request

ibble about whether particular measures are "reasonable" or not. However traditionally the major concerns we've had were with CAs that did not have any CPS or CP language at all about verifying email addresses. Frank -- Frank Hecker hec...@mozillafoundation.org -- dev-tech-crypto m

Re: Certigna Root Inclusion Request

document that summarizes the portions of the CPS that are of most interest to us (i.e., those relating to validation of subcriber information). Frank -- Frank Hecker hec...@mozillafoundation.org -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo

Re: Hongkong Post Root Inclusion Request

agree, especially for the non-EV case. Use of CRLs is going to continue to be widespread for some time to come, so I think we really have no choice but to invest in better CRL support (including putting Mozilla funding into this if needed). Frank -- Frank Hecker hec...@mozillafoundation.org -

Re: Application of client certificates on a US government website

ricted community like tax preparers, but I think the chances of any nationwide certificate use by all taxpayers are very low given the failure of past efforts (like those of the USPS) to establish a general US government-to-citizen PKI. Frank -- Frank Hecker hec...@mozillafoundation.org -- dev-

Re: Quorum requirements for approval of CAs?

nt of Mozilla (i.e., not employees or contractors of MoCo, MoFo, etc.). -- Frank Hecker hec...@mozillafoundation.org -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Quorum requirements for approval of CAs?

who commented. Frank -- Frank Hecker hec...@mozillafoundation.org -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Quorum requirements for approval of CAs?

r post. Frank -- Frank Hecker hec...@mozillafoundation.org -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Proposal to split this list

threads. Given the problems we've had in getting this group up and running, I'd prefer to wait a few more days before we start switching policy-related discussions over to it. Frank -- Frank Hecker hec...@mozillafoundation.org -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Policy: revoke on private key exposure

Eddy Nigg wrote: On 02/05/2009 04:05 AM, Frank Hecker: * In the near term I think we should make it a recommended practice that CAs should revoke certificates whose private keys are known to be compromised, as well as certificates for which subscriber verification is known to be invalid. Well

Re: Policy: revoke on private key exposure

a CPS said something like "Causes for certificate revocation include ... compromise of the private key". This leaves it somewhat unclear whether the CA can unilaterally revoke or not. Frank -- Frank Hecker hec...@mozillafoundation.org -- dev-tech-crypto mailing list dev-tech-crypto@l

Re: Policy: revoke on private key exposure

, but that's just my view. Actually if Kathleen can take over the bulk of the CA request processing then I think I would have time for dealing with some of these policy issues. The only unsustainable thing is having me be on the critical path for CA evaluation. Frank -- Frank Hecker hec..

Re: Policy: revoke on private key exposure

cases we need to worry about, which is one reason why I'd like us to first get some experience with what CAs are actually putting in their CPSs. Frank -- Frank Hecker hec...@mozillafoundation.org -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Policy: revoke on private key exposure

7;t see it as necessary, since the facts were known to all.) Frank -- Frank Hecker hec...@mozillafoundation.org -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Proposal to split this list

ring there. OK, thanks for the info. I guess we'll just wait for this to resolve itself, then we can verify that the new group is operating properly (and the mailing list also) and then make an announcement in m.d.t.crypto and m.d.security. Frank -- Frank Hecker hec...@mozillafoundation.

Re: Proposal to split this list

mplies that the new group is up and running, while I can't find it either in Thunderbird (i.e., via NNTP) or on the Google Groups site. Frank -- Frank Hecker hec...@mozillafoundation.org -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Full Disclosure!

te any larger problem of incompetence or maliciousness. Frank -- Frank Hecker hec...@mozillafoundation.org -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Policy: revoke on private key exposure

in NSS or PSM to blacklist certs which we think are suspect even if the CA does not? Frank -- Frank Hecker hec...@mozillafoundation.org -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: SECOM Trust EV root inclusion request

ry to bug 394419 and then ping me for final approval? Frank -- Frank Hecker hec...@mozillafoundation.org -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: DSV/S-TRUST root inclusion request

nd encouraging S-TRUST to move to a scheme where they use a longer-lived root for these certs. Kathleen, could you post a summary to bug 370627, and then ping me for final approval? Frank -- Frank Hecker hec...@mozillafoundation.org -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla

Re: DCSSI Root Inclusion Request

and nothing warranted a comment from my side either. Green light on. I've reviewed the material as well and I agree that this should go forward. Frank -- Frank Hecker hec...@mozillafoundation.org -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: DCSSI Root Inclusion Request

s are raised in the next couple of days, then I will assume it’s OK to move forward with inclusion. You have my approval to move forward with this. Feel free to post a summary to bug 368970 and then ping me when you're done so I can add my formal approval. Frank -- Frank

Re: DCSSI Root Inclusion Request

ome resolution of some of the earlier issues left hanging. Frank -- Frank Hecker hec...@mozillafoundation.org -- 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)

previously-validated CSRs to the CA, and get back certificates in return.) In these cases the enterprises are essentially acting as RAs. Frank -- Frank Hecker hec...@mozillafoundation.org ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla

Re: MD5 broken, certs whose signatures use MD5 now vulnerable

o be taken), but I don't recall it being made explicit in the post. Frank -- Frank Hecker hec...@mozillafoundation.org ___ 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)

eir own internal systems (e.g., HR databases). Frank -- Frank Hecker hec...@mozillafoundation.org ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: PositiveSSL is not valid for browsers

practices and a corresponding (reasonably) common meaning on what EV meant. Frank -- Frank Hecker hec...@mozillafoundation.org ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: PositiveSSL is not valid for browsers

lem or this MD5 thing, where someone else might be able to do a MITM attack, capture our IMAP and SMTP passwords and access our mail accounts, capture our blog passwords and be able to post as us, etc. Frank -- Frank Hecker hec...@mozillafoundation.org _

Re: PositiveSSL is not valid for browsers

run afoul of the whole "qualified certificate" issue in the EU. (However in practice we don't accord qualified certificates any special treatment, so it may be a moot point.) Frank -- Frank Hecker hec...@mozillafoundation.org ___ de

Re: PositiveSSL is not valid for browsers

cause us significant liability in the event of a breach. We support DV certs in browsers for that market. Frank -- Frank Hecker hec...@mozillafoundation.org ___ 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)

up, but you shouldn't expect an immediate response if you post something or email me. I'm going to try to post a summary of where things are either tonight or tomorrow morning. -- Frank Hecker hec...@mozillafoundation.org ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Unbelievable!

turned out, people didn't want to do that for various reasons, but I myself am not wedded to the idea that the default root list should never be changed by downstream distributors. Frank -- Frank Hecker hec...@mozillafoundation.org ___ dev-tech-cryp

Re: Unbelievable!

t future Comodo WebTrust audits could and IMO should look at the question of how Comodo deals with resellers and affiliates, as part of the task of determining whether Comodo is operating in accordance with its CPS. Frank -- Frank Hecker hec...@mozillafoundation.org _

Re: Unbelievable!

Kyle Hamilton wrote: https://bugzilla.mozilla.org/show_bug.cgi?id=426575 UTN-UserFIRST-Hardware is enabled for EV per that bug. My apologies, you are right and my recollection was wrong. Frank -- Frank Hecker hec...@mozillafoundation.org ___ dev

Re: Unbelievable!

by a non-EV legacy root. (AFAIK this scenario was/is not unique to Comodo. I believe all the VeriSign EV CAs work this way as well: a newly added and EV-enabled EV root cross-signed by a non-EV legacy root.) Frank -- Frank Hecker hec...@mozillafoundatio

Re: Unbelievable!

Michael Ströder wrote: Frank Hecker wrote: From my point of view I'd wait on more information regarding items 2 and 3 above before making a recommendation. Could you please define a time-frame within Comodo MUST react? Comodo (in the person of Robin Alden) has already made a reply:

Re: Unbelievable!

Eddy Nigg wrote: My blog article and exposure has provoked somebody to come forward with additional evidences concerning the reseller activities of Comodo. In order to protect the innocent I decided to provide this information confidentially to Frank Hecker for now. Stay tuned. To expand on

Re: Unbelievable!

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

Re: Unbelievable!

ites is special-cased), but it could affect non-EV sites under other Comodo brands (I mean, other than the PositiveSSL brand) and it could also affect other CAs whose CA certs are cross-signed by the UTN-UserFirst-Hardware root. Frank -- Frank Hecker hec...@mozill

Re: Unbelievable!

r nature we can directly verify, and some we can't. For example, we can certainly verify how Certstar is operating currently (as Eddy and I did), and if certs get revoked we can verify that by downloading the CRLs that get issued. Frank -- Frank Hecker hec...@m

Re: dispute resolution procedures for Mozilla CA module

he ultimate legal authority resides in the board of the Mozilla Foundation (of which Mitchell and Brendan are members). For more background on this see http://www.mozilla.org/hacking/module-ownership http://blog.lizardwrangler.com/2008/05/30/governance-and-module-ownership/ Frank -- Frank

Re: Unbelievable!

actual security threat to users. Right now we have no real idea as to the extent of the problem (e.g., how many certs might have been issued without proper validation, how many of those were issued to malicious actors, etc.). Frank -- Frank Hecker hec

Re: Unbelievable!

e typical interval between security updates for Firefox and other Mozilla-based products. Frank -- Frank Hecker hec...@mozillafoundation.org ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Unbelievable!

Eddy Nigg wrote: For those interested, Frank opened a bug to investigate this incident: https://bugzilla.mozilla.org/show_bug.cgi?id=470897 Actually Nelson opened this bug. Frank -- Frank Hecker hec...@mozillafoundation.org ___ dev-tech-crypto

Re: Unbelievable!

arding items 2 and 3 above before making a recommendation. Frank -- Frank Hecker hec...@mozillafoundation.org ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Publishing CA information documents in PDF format

ight now. Why does everything have to have an explicit 'threat model' before cryptography can be applied? Well, it doesn't necessarily. My concern in this case had more to do with justifying any extra work that might be involved on our end in terms of getting the documents

Re: Publishing CA information documents in PDF format

#x27;m running a Mac with VMware Fusion I can check it out on a variety of platforms with different PDF readers. Frank -- Frank Hecker hec...@mozillafoundation.org ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: DSV/S-TRUST root inclusion request

bird, SeaMonkey, et.al. (And of course, just because email is a secondary use now doesn't mean it will always be so.) Frank -- Frank Hecker hec...@mozillafoundation.org ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.

Publishing CA information documents in PDF format

n't address protection of Bugzilla comments. Besides, any such attempt would likely be quickly detected when Kathleen or I upload documents ourselves. Frank -- Frank Hecker hec...@mozillafoundation.org ___ dev-tech-crypto mailing list dev-tech-

Re: DSV/S-TRUST root inclusion request

rting them to the start of the public discussion period and asking them to respond to this question. Frank -- Frank Hecker hec...@mozillafoundation.org ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinf

Re: DSV/S-TRUST root inclusion request

or the specific regulations, and get them translated. That's a good idea, I'll do that. I'd like to get a definitive answer on this question, since I know I've seen this practice with other CAs, including I think at least one not in Germany. Frank -- Frank

Re: DSV/S-TRUST root inclusion request

m glad that after a diet of Hungarian and Japanese we have something more to your taste :-) Frank -- Frank Hecker hec...@mozillafoundation.org ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto

DSV/S-TRUST root inclusion request

r preparing these! As we did with SECOM Trust, I'm planning to have a single one-week discussion period. After that week, if there are no outstanding issues relating to the request then I am going to go ahead and officially approve it. (Otherwise we'll postpone further discussion until

Re: SECOM Trust EV root inclusion request

l likely cause delays with their application. Frank -- Frank Hecker hec...@mozillafoundation.org ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: SECOM Trust EV root inclusion request

ndeed have these, but not all. Frank -- Frank Hecker hec...@mozillafoundation.org ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: SECOM Trust EV root inclusion request

ew request. The current request is to enable the new root for SSL use only. Note that I have in fact reviewed various sections of the CPS and CP, using Google Translate. I didn't see anything in them that was inconsistent with what I've written above. Frank -- Frank Hecker hec...@m

  1   2   3   4   5   >