Audit requirements for government CAs

language in a future policy revision? I'll give my own thoughts about this in a subsequent message, but I'll pause here to let others comment. Frank -- Frank Hecker [EMAIL PROTECTED] ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org

Re: KISA root CA certificate inclusion request

in a separate message). The audit requirements on commercial CAs (item 7, General Requirements) don't apply to government CAs. Frank -- Frank Hecker [EMAIL PROTECTED] ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https

Re: KISA root CA certificate inclusion request

for that subordinate (and just that subordinate) and can mark it as untrusted. 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

happened. This is better responded to elsewhere as well. It's part of a more general discussion about the respective emphasis we should put on prevention of potential problems vs. detection of and response to actual problems. Frank -- Frank Hecker [EMAIL PROTECTED

Re: KISA root CA certificate inclusion request

to regulatory constraints imposed by the government (including regulations mandating verification requirements, etc.) and are subject to oversight by KISA, including audits. Frank -- Frank Hecker [EMAIL PROTECTED] ___ dev-tech-crypto mailing list dev

Re: What we want [was: Audit requirements for government CAs]

everything else in the world of Mozilla security and the world of CAs. If we're going to change the policy, I don't want to have us change the policy simply to address theoretical concerns and proposed threat scenarios of uncertain importance, and ignore any associated trade-offs. Frank -- Frank

Re: Audit requirements for government CAs

then that (if at all). I'm still not clear on your exact objections to the Microsoft policy, or what you would consider a better one. Frank -- Frank Hecker [EMAIL PROTECTED] ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https

Re: Audit requirements for government CAs

don't think we have any general way to restrict government CAs or other country-specific CAs to issuing certs under their particular national TLDs; we'd need to have additional code in NSS or PSM to enforce custom restrictions. (Or just not include the roots at all.) Frank -- Frank Hecker [EMAIL

Re: What we want [was: Audit requirements for government CAs]

practices were still within boundaries outlined in our policy (which does allow issuance of DV certs). So I don't really see a security issue here in terms of how this would affect typical users. Frank -- Frank Hecker [EMAIL PROTECTED] ___ dev-tech-crypto

Re: What we want [was: Audit requirements for government CAs]

transactions (financial or otherwise) should migrate to EV certs. This certainly should include major sites like Bank of America, E*Trade, etc., Amazon, etc., as well as any ecommerce site for which the annual EV cert fee is a small fraction of overall operating expenses. Frank -- Frank Hecker

Re: Audit requirements for government CAs

Gervase Markham wrote: Frank Hecker wrote: It's a reasonable proposal, and we did look into doing this. Unfortunately there are .com domains and perhaps other non-.kr domains with certs issued by CAs in the KISA-rooted hierarchy. This is not unique to KISA and Korea either AFAIK. I

Re: What we want [was: Audit requirements for government CAs]

Eddy Nigg (StartCom Ltd.) wrote: Frank Hecker: (As a side note, based on my experience with and reading about industry dynamics, I think that advances in PKI-related technologies are much more likely to occur in new protocols and new products than in mainstream cases like browsing SSL web

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

Frank Hecker wrote: Comodo has applied to (among other things) add a new EV root CA certificate for the COMODO Certification Authority to the Mozilla root store, as documented in the following bug: https://bugzilla.mozilla.org/show_bug.cgi?id=401587 snip I have evaluated this request

Re: Comodo request for EV-enabling 3 existing roots

guidelines, and so left it out of my considerations. 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: Network Solutions EV root inclusion request

for the SSL trust bit.) Frank -- Frank Hecker [EMAIL PROTECTED] ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto

DigiNotar EV root inclusion request

of DigiNotar's validation procedures, and we can verify technical correctness of the actual EV certificates ourselves. Frank P.S. to Nelson: I've changed the status whiteboard in the bug and checked in a change to the pending list (not yet on the site) to mark DigiNotar as 'pending'. -- Frank

Re: DigiNotar EV root inclusion request

report, one argument is that (assuming identity validation is effective) any vulnerability is restricted to cases where people share the same name (e.g., someone else named Frank Hecker and I both apply for a cert). It might also be useful to have input from some people in the Netherlands who

Re: DigiNotar EV root inclusion request

for an existing user base itself has security implications.) That's another reason why I'd like more input from people more familiar with how the certs are used in practice. Frank -- Frank Hecker [EMAIL PROTECTED] ___ dev-tech-crypto mailing list dev

Re: DigiNotar EV root inclusion request

need further investigation. 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: Governing EV

Eddy Nigg (StartCom Ltd.) wrote: Frank Hecker: I agree with your general point, namely that we should start doing better tracking of audit dates, particularly for EV audits. However I don't know at this point what would be appropriate in terms of setting timeframes for when an audit would

Re: EV email usage

extension with values SSL Client Certificate and SSL Server Certificate.) 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: EV email usage

Frank Hecker wrote: Appendix C of the EV guidelines contains requirements relating to EV certificate extensions. My apologies, that reference should be to Appendix B of the EV guidelines. Frank -- Frank Hecker [EMAIL PROTECTED] ___ dev-tech-crypto

Re: EV email usage

by the CA. This is a consequence of the EV guidelines' requirement in Appendix B that EV certificate fields and extensions not specified in the EV guidelines must be set in accordance with RFC 3280. Frank -- Frank Hecker [EMAIL PROTECTED] ___ dev-tech-crypto

Re: DigiNotar EV root inclusion request

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

Re: Entrust CA, Staat der Netherlanden CA, Proposal

new projects like CA management tools. Frank -- Frank Hecker ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Entrust CA, Staat der Netherlanden CA, Proposal

Eddy Nigg (StartCom Ltd.) wrote: Frank Hecker: snip Eddy, I think it would be unwise (to put it mildly) to make a major change like disabling Entrust's email trust bit in a rush. We have no idea at this point what the impact of a change like that would be. And in any case the change

Re: Entrust CA, Staat der Netherlanden CA, Proposal

questions they must answer within a certain time-frame. If the answer is not satisfying turn off the e-mail trust flag after this time-frame. I think I may have mentioned this already, but I'm already in contact with Entrust on these issues. Frank -- Frank Hecker [EMAIL PROTECTED

Looking for help in processing CA inclusion requests

hours per week or month you'd want to work. 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 Vulnerability

for inclusion at this point. Maybe I'm naive, but I can't imagine any commercial CAs are using OpenSSL for CA functions -- but in any case we can certainly ask CAs about this. Could you please file a bug on this against mozilla.org / CA certificates and assign it to me? Frank -- Frank Hecker [EMAIL

Re: Certificate Vulnerability

version of the commercial Red Hat Certificate System. -- Frank Hecker [EMAIL PROTECTED] ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Looking for help in processing CA inclusion requests

Frank Hecker wrote: I'm therefore looking for people who are willing and able to help specifically with the information-gathering phase of processing CA requests. Note that I found someone to help with this. Kathleen Wilson will be assisting with information gathering on CA-related bugs

Re: Including FNMT cert in Firefox 3 (Spanish government)

a version of Firefox including that CA's root is released. 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: Including FNMT cert in Firefox 3 (Spanish government)

-level government CAs over requests for local/regional government CAs, whether in the same country or a different one. Frank -- Frank Hecker [EMAIL PROTECTED] ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org

Re: Deutsche Telekom Root CA 2 inclusion into Firefox 3

certificates, since EV support is a major new feature in Firefox 3. However your request is relatively early in the queue, so once we get through the EV requests we should look at your request soon thereafter. Frank -- Frank Hecker [EMAIL PROTECTED] ___ dev

Re: Including FNMT cert in Firefox 3 (Spanish government)

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

CA pending and included lists updated

. 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: Modulus length (was Re: Draft CA information checklist)

after a certain date), I think that's a good idea. As for the ECC question: 256 bits is equivalent to 128 bits of symmetric strength, as in AES-128. Thanks! Frank -- Frank Hecker [EMAIL PROTECTED] ___ dev-tech-crypto mailing list dev-tech-crypto

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

Paul Hoffman wrote: At 11:02 AM -0400 5/30/08, Frank Hecker wrote: I'd be glad to soften the language about cause for concern, but I still want to flag 1024-bit roots as worthy of a further explanation. (E.g., is this a root created some time ago that is only now being proposed for inclusion

Entrust EV request

checked in Entrust-related updates for these list just a few minutes ago, so it may take an hour or two for them to show up on the site. Frank -- Frank Hecker [EMAIL PROTECTED] ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https

Re: Entrust EV request

. So in that sense, yes, the governing CPS for the hierarchy is the EV CPS. 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: Entrust EV request

. In my opinion the level of verification for IV/OV certs, as practiced in the CA industry and required by our policy, corresponds to a commercially reasonable efforts standard. If we want to apply a best efforts standard then IMO that's what EV is for. Frank -- Frank Hecker [EMAIL PROTECTED

Re: Entrust EV request

Frank Hecker wrote: I've been looking at a request from Entrust (bug 416544) to (among other things) have its new Entrust Root Certification Authority root enabled for EV. This is a new Entrust root that was approved for inclusion last year by Gerv (bug 382352) and subsequently added to NSS

Re: Problematic Practices

flag, as being worthy of further investigation. Frank -- Frank Hecker [EMAIL PROTECTED] ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto

Entrust EV request, second round

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

Re: Update on DigiNotar and Entrust

it. However the problem is that even if Entrust were to revoke DigiNotar's intermediate CA certificate that would not help resolve the problem, for the reason I mentioned earlier (Firefox/Thunderbird et.al. don't do revocation checks for CA certs). Frank -- Frank Hecker [EMAIL PROTECTED

Re: Update on DigiNotar and Entrust

, provided that there are people who can do the work. 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: make sure upgraded users get new cert8.db

the trademarks. Maybe Frank Hecker will say more about that. Strictly speaking the Mozilla Foundation doesn't evaluate and approve potential uses of the Firefox trademarks (word mark and logo); that's done by the Mozilla Corporation. Send an email to [EMAIL PROTECTED] and explain your request

Re: Entrust EV request, second round

Frank Hecker wrote: We've completed the first round of public comment on the request from Entrust to have its new Entrust Root Certification Authority root enabled for EV. Based on the results of the first comment period and other available information, I'm inclined to approve this request

Re: Entrust EV request, second round

Frank Hecker wrote: The second comment period is now over, with no further comments received. Based on my evaluation and the comments received thus far, I am officially approving this specific request to enable the Entrust Root Certification Authority for EV use, and will now proceed

Re: questionable CA practices: CA's generating users' private keys

non-standard was going on.) Frank -- Frank Hecker [EMAIL PROTECTED] ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto

GlobalSign requests (replacement root, EV)

. Note that I think this is the first request for which we're using the new information checklist at http://wiki.mozilla.org/CA:Information_checklist Thanks go to Kathleen for all her work in collecting the information! -- Frank Hecker [EMAIL PROTECTED

Re: Firefox 3 connection now results in ssl_error_bad_cert_domain

, and you use SubjAltName, you should put all three names in the extension, as opposed to (e.g.) putting CN=a.example.com and then just b.example.com and c.example.com in SubjAltName. Frank -- Frank Hecker [EMAIL PROTECTED] ___ dev-tech-crypto mailing

Re: GlobalSign requests (replacement root, EV)

straightforward also IMO. 3. General review of the roots, since this never happened previously. IIRC the only thing out of the ordinary here was GlobalSign having some subordinate CAs operated by third parties. I can comment more on that as we get into the discussion. Frank -- Frank Hecker [EMAIL

Re: GlobalSign requests (replacement root, EV)

Frank Hecker wrote: GlobalSign has submitted requests to include a replacement root certificate for an already-included root certificate (same public key, new expiry date) and to enable it and a second GlobalSign root for EV: https://bugzilla.mozilla.org/show_bug.cgi?id=406794 https

Re: The TLS Report

Eddy Nigg (StartCom Ltd.) wrote: Eddy Nigg (StartCom Ltd.): Frank Hecker: I tried out my own site on it, and got a C. LOL, I got a A 80 :-) Actually it doesn't honor SAN DNS extension...but it's a cute utility. Reached a A 82 as well, just need to use the CN value of the certificate

Re: The TLS Report

. It forced me to specify www.hecker.org as the CN and hecker.org as a SAN, when I would have preferred it the other way around, since hecker.org is now the canonical site name. Frank -- Frank Hecker [EMAIL PROTECTED] ___ dev-tech-crypto mailing list dev

Re: GlobalSign requests (replacement root, EV)

account control using the typical mechanisms used by other CAs, and they will revise future versions of the CPS to state this more clearly. I too think they could have made this more clear up front, but I don't see a real issue here. Ditto re domain ownership. Frank -- Frank Hecker [EMAIL

Re: Decline in firefox usage due to lacking CA certificates

consultation, and we follow a similar process of community discussion when considering CAs. We do have more people now working on CA-related tasks (unlike previously when I was the only person, and could do it only part-time). However the process will never be quick IMO. Frank -- Frank Hecker

Deutsche Telekom/T-Systems CA request

issue email certificates and verify email account control per the relevant CPSs/CPs. This first public comment period will be for one week, and then I'll make a preliminary determination regarding this request. Frank -- Frank Hecker [EMAIL PROTECTED

Re: Decline in firefox usage due to lacking CA certificates

if we can move them forward. 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: EV SSL cert user experience

of this scenario already, and as far as I know they work fine. 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: Decline in firefox usage due to lacking CA certificates

or phone or whatever) to remind me that their requests need attention. Please feel free to do that if ever you should need to. -- Frank Hecker [EMAIL PROTECTED] ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org

Wells Fargo CA inclusion/EV request

regarding 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: Comodo ECC CA inclusion/EV request

/COMODOECCCertificationAuthority.crt Are those sufficient input to do validation against, or do we need further information? Frank -- Frank Hecker [EMAIL PROTECTED] ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org

Re: Public comment periods

complicated. If you or anyone else feel that we need more time to discuss a particular request, just tell me and I will extend the public discussion period for that request as needed. Frank -- Frank Hecker [EMAIL PROTECTED] ___ dev-tech-crypto mailing list dev

Re: Public comment periods

period is essentially the signal that the request is at a state where further public review is called for. (Of course you or anyone else could have been doing review prior to that, based on the information in the bug.) Frank -- Frank Hecker [EMAIL PROTECTED

Re: Comodo ECC CA inclusion/EV request

know if this is accurate, or needs further revision. 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 ECC CA inclusion/EV request

Paul Hoffman wrote: At 9:27 AM -0400 7/18/08, Frank Hecker wrote: Paul Hoffman wrote: Has anyone validated the ECC paramters they used? Not that I'm aware. I think that's unfortunate. It is easy for all of us to test the parameters for RSA certs, but few of us have software for testing

Re: Public comment periods

and reverse it. In the old system people didn't have a formal opportunity to register objections until after I'd already made a decision. In the new system I want to get the bulk of the objections raised up front, before I make any decision at all. Frank -- Frank Hecker [EMAIL PROTECTED

Re: GlobalSign requests (replacement root, EV)

Frank Hecker wrote: Eddy Nigg wrote: snip Not sure what GlobalSign deems as a secure manner to provide PKCS12 files (including private keys) mentioned in 1.9.6.9 of their CPS. I'll ask about this issue. My apologies, I forgot to post what I found out. Briefly, GlobalSign is not currently

Re: GlobalSign requests (replacement root, EV)

On Jul 11, 8:21 pm, Frank Hecker [EMAIL PROTECTED] wrote: Frank Hecker wrote: GlobalSignhas submitted requests to include a replacement root certificate for an already-included root certificate (same public key, new expiry date) and to enable it and a secondGlobalSignroot for EV: https

Re: Deutsche Telekom/T-Systems CA request

statement about the practices of these subordinate 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

Re: Wells Fargo CA inclusion/EV request

EV certs, and then by the time we were able to consider their requests in some cases they were still covered by the readiness audit and in other cases had advanced to a regular audit. Frank -- Frank Hecker [EMAIL PROTECTED] ___ dev-tech-crypto

Re: Comparison of OpenSSL and NSS

licensees (including Mozilla) are concerned. 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 CA inclusion/EV request

until they have been in operation for a minimum of two months. The pre-issuance readiness audit was put in place to bootstrap the process. Bruce, thanks much for the info. This confirms what I thought. Frank -- Frank Hecker [EMAIL PROTECTED] ___ dev

Re: Wells Fargo CA inclusion/EV request

Frank Hecker wrote: I am now opening the first public discussion period for a request from Wells Fargo to add the WellsSecure Public Root Certificate Authority root certificate to Mozilla and enable it for EV use. This is bug 428390, and Kathleen has produced an information document

Re: Comodo ECC CA inclusion/EV request

Frank Hecker wrote: I am now opening the first public discussion period for a request from Comodo to add the Comodo ECC Certification Authority root certificate to Mozilla and enable it for EV use. This is bug 421946, and Kathleen has produced an information document attached to the bug

Re: Comodo ECC CA inclusion/EV request

determination was that the practices of issuing wildcard DV certs and long-lived DV certs, though potentially problematic, were not in my opinion sufficient to justify denying the request. That's my position in this case as well. Frank -- Frank Hecker [EMAIL PROTECTED

Re: Comodo ECC CA inclusion/EV request

stated that Comodo will expand the use of this root at some point. 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 ECC CA inclusion/EV request

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: Comodo ECC CA inclusion/EV request

Frank Hecker wrote: Frank Hecker wrote: I am now opening the first public discussion period for a request from Comodo to add the Comodo ECC Certification Authority root certificate to Mozilla and enable it for EV use. This is bug 421946, and Kathleen has produced an information document

Re: Comodo ECC CA inclusion/EV request

Frank Hecker wrote: Robin Alden wrote: snip Frank, would you consider these practices of issuing certificates to hostnames* and also of issuing to non-internet routable IP addresses as being something to add to your problematic practices list? Yes, I'll do that. Done: https

Re: Comodo ECC CA inclusion/EV request

Eddy Nigg wrote: Frank Hecker: Yes, I'll do that. (Incidentally, I'm now calling it the potentially problematic practices list, because there's a lack of consensus on the extent to which some of these practices are problems in general.) Frank, where is the lack of consensus exactly? IIRC

Re: Documenting default trusted CAs

have a single web page providing a list of all the pre-loaded root CA certs in readable form. For now the certdata.txt file is the only complete and authoritative source. Frank -- Frank Hecker [EMAIL PROTECTED] ___ dev-tech-crypto mailing list dev-tech

Re: Working on Perl bindings for NSS

see no problem with just including such code in the NSS release. 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: questions on root creation

number. I think the existing term IV (identity validation or identity validated) covers this. Frank -- Frank Hecker [EMAIL PROTECTED] ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto

Setting a schedule for CA evaluations

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

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

/CA:Recommendations_for_Roots to provide some technical background for anyone interested. -- Frank Hecker [EMAIL PROTECTED] ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto

Microtec CA inclusion request

a preliminary determination regarding this request. Frank [1] Fun fact: Within Hungary names are normally given in Eastern order (i.e., like China or Japan) with surname first. In this case I've transposed to Western order (I think). -- Frank Hecker [EMAIL PROTECTED

Re: Microsec CA inclusion request

Frank Hecker wrote: I am now opening the first public discussion period for a request from Microtec Ltd to add the Microsec e-Szigno Root CA root certificate to D'oh! It's Microsec, *not* Microtec. I got it right everywhere except for the subject line and the first sentence. Sigh... Frank

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

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

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

certificate of EV certificates and makes sense also here. Thanks. If you have time please feel free to edit the wiki page and add a note on this near the bottom (where subordinate are discussed). Frank -- Frank Hecker [EMAIL PROTECTED] ___ dev-tech-crypto

Re: Microtec CA inclusion request

Eddy Nigg wrote: On 10/03/2008 12:43 AM, Frank Hecker: * This CA is based in Hungary. Though it provides a lot of information in English (including a helpful CA hierarchy diagram) unfortunately all of its CPS documents are currently available in Hungarian only. Frank, I think we should buy

Re: Setting a schedule for CA evaluations

to close out phase 1 of public comment on Microsec. I'm going to make some comments on Microsec, and then push the whole schedule back a few days to account for my delays. My apologies... Frank -- Frank Hecker [EMAIL PROTECTED] ___ dev-tech-crypto

Re: Microtec CA inclusion request

Frank Hecker wrote: In accordance with the schedule at https://wiki.mozilla.org/CA:Schedule I am now opening the first public discussion period for a request from Microtec Ltd to add the Microsec e-Szigno Root CA root certificate to Mozilla. This is bug 370505, and Kathleen has produced

Re: revocation of roots

such a CRL would note revocation of the root certificate, and from that point forward would refuse to recognize as valid any certificates chaining up to the root, any subsequent CRLs signed by the root, and so on. Or am I missing something? Frank -- Frank Hecker [EMAIL PROTECTED

Re: Microtec CA inclusion request

Nelson Bolyard wrote: Frank Hecker wrote: * OCSP. My understanding is that the Microsec practice of having a separate root for OCSP is very problematic, particularly given the inclusion of AIA extensions with OCSP URLs in end entity certificates. As I understand it, Microsec is removing AIA

Re: revocation of roots

to be used again. 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

-tamp-00.txt is the main document of interest? At first glance this looks interesting, though I haven't yet read it in detail. Frank -- Frank Hecker [EMAIL PROTECTED] ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https

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

<    1   2   3   4   >