Re: cert extension: authority key identifier (AKI)

that 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 Hecker hec

Re: Basic ECC in NSS 3.12.4 with NSPR 4.8

(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

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

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: 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

. 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 mailing list dev-tech-crypto

Re: Extrace Mozilla trusted certs into PEM files?

/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

for the 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: 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

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

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.org/listinfo/dev-tech

Re: Firefox 3.5

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: Pending roots and EV enablements

this, 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 mailing list dev-tech

Re: Pending roots and EV enablements

-- 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: Fwd: Has any public CA ever had their certificate revoked?

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...@mozillafoundation.org

Re: Microsec Root Inclusion Request Round 2

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 https

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

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...@mozillafoundation.org -- dev

Re: ComSign Root Inclusion Request

, but there is no 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: Hongkong Post Root Inclusion Request

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 -- Frank Hecker hec

Re: Hongkong Post Root Inclusion Request

/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

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

for the partitioned 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: 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

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: 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's OK

Re: Hongkong Post Root Inclusion Request

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-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo

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

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.org/listinfo/dev

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

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

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

that? (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.org https

Re: Hongkong Post Root Inclusion Request

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-tech-crypto mailing list dev-tech-crypto

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

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 https

Re: Certigna Root Inclusion Request

-- 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?

-- 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?

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: 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: Certigna Root Inclusion Request

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 mailing list dev-tech-crypto@lists.mozilla.org

Re: Quorum requirements for approval of CAs?

. -- 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: 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: Certigna Root Inclusion Request

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: Policy: revoke on private key exposure

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@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: DCSSI Root Inclusion Request

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

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 Hecker hec

Re: DSV/S-TRUST root inclusion request

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.org https://lists.mozilla.org

Re: SECOM Trust EV root inclusion request

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: Policy: revoke on private key exposure

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: Full Disclosure!

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

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.org -- dev-tech

Re: Policy: revoke on private key exposure

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: Policy: revoke on private key exposure

, 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

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...@mozillafoundation.org -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https

Re: DCSSI Root Inclusion Request

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)

-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.org https

Re: PositiveSSL is not valid for browsers

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: PositiveSSL is not valid for browsers

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 ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https

Re: PositiveSSL is not valid for browsers

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 ___ dev-tech

Re: PositiveSSL is not valid for browsers

-- 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)

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: CAs and external entities (resellers, outsourcing)

this week visiting family. I plan to continue working on this issue and responding to messages in this newsgroup, 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

Re: Unbelievable!

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 ___ dev-tech-crypto

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: http

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...@mozillafoundation.org

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

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!

-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...@mozillafoundation.org

Re: Unbelievable!

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

that might be involved on our end in terms of getting the documents signed; I was also concerned that signng might mess up reading the documents on non-Adobe software (a concern that turned out to be misplaced). Frank -- Frank Hecker hec...@mozillafoundation.org

Publishing CA information documents in PDF format

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-crypto@lists.mozilla.org https

Re: DSV/S-TRUST root inclusion request

, 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.mozilla.org/listinfo

Re: Publishing CA information documents in PDF format

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: SECOM Trust EV root inclusion request

. 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

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 the issues are resolved.) Frank -- Frank

Re: DSV/S-TRUST root inclusion request

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

Re: DSV/S-TRUST root inclusion request

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 Hecker hec...@mozillafoundation.org

Re: SECOM Trust EV root inclusion request

to'.) Good point. I can speak for the Mozilla Foundation on this, so CAs should indeed consider my previous comments as The Mozilla Foundation encourages them... Frank -- Frank Hecker hec...@mozillafoundation.org ___ dev-tech-crypto mailing list dev

Re: SECOM Trust EV root inclusion request

Frank Hecker wrote: I am currently working with SECOM Trust to determine the status of the reports for Security Communication EV RootCA1, which is the new EV root that SECOM Trust is requesting to be included (per bug 394419). I will post more information as I have it. OK, I now have more

Re: SECOM Trust EV root inclusion request

Frank Hecker wrote: However since we received the reports from SECOM Trust and not from PWC Aarata, we do need to verify that they are indeed genuine reports, just as we have done for other WebTrust reports that were published on the WebTrust.org site. I meant to write, just as we have done

Re: SECOM Trust EV root inclusion request

Frank Hecker wrote: As it turns out, the latest WebTrust report for SECOM Trust (for 2008) is actually available from the WebTrust site [1]: http://cert.webtrust.org/SealFile?seal=816file=pdf My mistake. This report is for SECOM Trust.net Root1 CA (ValiCert Class 1 Policy Validation CA

Re: SECOM Trust EV root inclusion request

; they thought they had sent us something, but we apparently didn't get it. Kathleen is going to try to straighten it out. Frank -- Frank Hecker [EMAIL PROTECTED] ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https

Re: SECOM Trust EV root inclusion request

Frank Hecker wrote: There was apparently some sort of mix-up between the SECOM Trust folks and Kathleen and me regarding getting the latest audit report; they thought they had sent us something, but we apparently didn't get it. Kathleen is going to try to straighten it out. As it turns out

Re: Creating a Global User-level CA/Trust Infrastructure for Secure Messaging

Nelson B Bolyard wrote: What does https cannot be easily shared across one IP numbers mean? I presume Ian is referring to the case of multiple virtual hosts sharing a single IP address (due to lack of SNI support in deployed versions of Apache). Frank -- Frank Hecker [EMAIL PROTECTED

SECOM Trust EV root inclusion request

going 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 -- Frank Hecker [EMAIL PROTECTED] ___ dev-tech-crypto mailing list dev-tech

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

, particularly outside the context of S/MIME proper. (For example, have some interesting web service that uses client certs for authentication.) Frank -- Frank Hecker [EMAIL PROTECTED] ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https

Re: Mozilla CA Certificate Policy - Useful?

don't want to see errors occur when connecting to SSL-enabled web sites. 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 inclusion request (re-start public discussion)

my understanding. However I've already commented on my views regarding name constraints. 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 inclusion request (re-start public discussion)

Frank Hecker wrote: Per the CA schedule, the next CA on the list for public comment is WISeKey, which has applied to add its (one) root CA certificate to the Mozilla root store, as documented in the following bug: https://bugzilla.mozilla.org/show_bug.cgi?id=371362 and in the pending

Re: WISeKey root inclusion request (re-start public discussion)

Frank Hecker wrote: Frank Hecker wrote: Per the CA schedule, the next CA on the list for public comment is WISeKey, which has applied to add its (one) root CA certificate to the Mozilla root store, as documented in the following bug: https://bugzilla.mozilla.org/show_bug.cgi?id=371362

Re: Creating a Global User-level CA/Trust Infrastructure for Secure Messaging

. 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 inclusion request (re-start public discussion)

. (And I should add that if there problems in NSS that need additional work to fix them, the Mozilla Foundation does have the ability to fund such work.) Frank -- Frank Hecker [EMAIL PROTECTED] ___ dev-tech-crypto mailing list dev-tech-crypto

Re: subroots (was WISeKey)

over these duties sometime in 2009.) However I think these sorts of discussions are useful, as they will provide good context if/when we actually get down to drafting a formal CA agreement. Frank -- Frank Hecker [EMAIL PROTECTED] ___ dev-tech-crypto

Re: subroots (was WISeKey)

to review CAs not up for inclusion. As I said, our time is finite. 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: subroots (was WISeKey)

to the intent of the policy to provide some base-level assurance relative to using certificates. Frank -- Frank Hecker [EMAIL PROTECTED] ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto

WISeKey root inclusion request (re-start public discussion)

meets the general intent of our policy. Frank -- Frank Hecker [EMAIL PROTECTED] ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto

Draft how to apply guide for CAs

to apply guide for CAs. We now have a draft of that guide available at https://wiki.mozilla.org/CA:How_to_apply Please feel free to comment on it, or even to edit it yourself if you'd like. Frank -- Frank Hecker [EMAIL PROTECTED] ___ dev-tech

Re: Dealing with third-party subordinates of T-Systems and others

to affect typical users.) 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: revocation of roots

. Anyone interested in the general issue of how the Mozilla project responds to vulnerabilities can consult the Mozilla security announcements database: http://www.mozilla.org/security/announce/ combined with the associated Bugzilla reports (linked to from the announcements). -- Frank Hecker

  1   2   3   4   >