UTF8 support in the Firefox certificate store?
Initially I posted this on another support forum, but was kindly requested to post here instead: I have created a X.509 v3 client certificate using OpenSSL. The CN and OU field contain UTF8 characters, in this case Thai characters for testing purposes. When I import this certificate into the Windows certificate store it shows all fields correctly, ie I can actually see the Thai characters I used. However when I import the certificate into Firefox (3.04) and view the certificate subject from Firefox (tools->options->advanced->view certificates->view->details) then the UTF8 characters are not shown correctly. Serverside the certificate subject is interpreted correctly for authentication purposes, when I use Firefox to go to a server to authenticate against. Does anybody know if there is a fix or perhaps an add-on for this, since it appears to be a lack of UTF8 support in the browser. For a screendump please refer to: http://www.vandersman.org/certstore.PNG Thanks. Kind regards, Michael ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: UTF8 support in the Firefox certificate store?
> > Attach a copy of the binary DER cert to the bug. Please put my email address > on the CC list for that bug. > > Are those fields encoded with UTF8String as they should be? Can you send a > URL pointing to the cert to this list? Thanks for the super quick response. I got the details on my company PC and will file the bug report and add the Cert as well as the other details coming Monday afternoon. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: UTF8 support in the Firefox certificate store?
Just uploaded the certificate in DER and PEM file format. It can be found here: www.boraxx.nl/Mozilla/Thai.der www.boraxx.nl/Mozilla/Thai.crt The required CA chain can be found here: www.boraxx.nl/Mozilla/ChainUCAcert.pem ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Reassessment of sub-ordinated CA certificates
Eddy Nigg (StartCom Ltd.) wrote: > Which raises at least with me the question, if this is indeed what was > envisioned when Mozilla decided to endorse EV as a better PKI model. Or > are people like Kyle perhaps rightfully thinking that he's being cheated > on by some CAs? I'm quoting a recent statement by Kyle: > > "The end result is that anyone who chooses to spend a hundred thousand > bucks or so on a single audit can then go around selling the benefit of > their inclusion in the trust list to the highest bidder without fear of > repercussion. Which is what they've been doing. And nobody has the balls > to stand up and say "user security is more important than user > convenience". (In addition, roots have been sold to other companies, > which have not passed continuing conformance audits.)" From project experience I can confirm that it's exactly like what Kyle suspects. I won't mention names but bringing your CA certs into MS IE and the Mozilla products is simply a cash cow. Nothing else. In the cases I know no audits were conducted on sub-CAs by the root CA people, not even simple reviews of the sub CA's CPS. Ciao, Michael. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Reassessment of sub-ordinated CA certificates
Eddy Nigg (StartCom Ltd.) wrote: > [EMAIL PROTECTED] wrote: >> 1. The Root is responsible for certs issued by a Sub-CA and are >> included in the Root's WebTrust audit. > > The issuing CA of a root certificate is *supposed* to be responsible for > its sub CAs naturally, however as a user of Mozilla software I want to > be *assured*, that this is indeed the case. There is no way to assure that even in the case of EV certs. IMO EV is just marketing, yet another cash cow with even higher prices per cert. > As a member of the Mozilla community I want to make sure, that this > is indeed the case, in order to protect the user and give the user > the confidence in the software he is using. No way. IMO you don't have a chance to detect violations of the policy even for the root CAs. > As a member and employee of a CA I want to make sure that all CAs > are competing on the same terms and don't devalue the efforts my > employer. In practice every employee of a CA is made to lower the bar by his management because others do it as well. Then EV was invented as a higher level of trust. I wonder why there was a need for this if the CAs already did a good job before? > Because when one CA misbehaves, all CAs are suffering as you can > understand from the quote above, and earning back the trust of the > relying party is almost impossible once it's lost. Well, the relying party is the weakest piece in this puzzle. PKI business suffers because the RPs don't care. >> The EV Guidelines also make this very explicit. > > I hope that the EV _audit_ guidelines and its auditors actually make > sure that this is the case. Good luck. >> Can you identify examples where this is not the case? > > My job is *not* to find such examples, but to impose the policies, rules > and requirements in order to guaranty as much as possible, that such an > example never will be identified. At least not here. Maybe you should rather think about how to clearly refuse giving guarantees and deny any warranties in your Mozilla policy. ;-} > The only responsible body where I can influence anything of the > mentioned above, is the Mozilla Foundation. Eddy, thanks for doing this work. Again: Good luck. Ciao, Michael. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
How can I sign something with a certificate from a untrusted issuer?
Hi guys, I am very insterested at NSS and try to use it now. I wrote some test code for signing file like cmd-p7sign.c, but I met a problem about signing something with a untrusted certificate. So I want to know whether we could do that or not? Another question is: How can I get the information about issuer of a certificate such as issuer's name, country, organization and so on. Any suggestions are appreciated. Thanks for your attention, Michael. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
SPNEGO and MDNS
HI! I hope I'm right here with a question regarding SPNEGO-based authentication and locating the Kerberos KDC via DNS. All the DNS zones and forwarding is correctly set up. If I configure the KDC in /etc/krb5.conf in section [realms] everything works fine. But I'd like to let the clients lookup the KDC in DNS SRV records. This works fine for the MIT utils like kinit etc. but not for Firefox and/or Seamonkey. Observing the networking traffic (with wireshark) I can see mDNS requests sent out to 224.0.0.251 by the Mozilla products. But I don't want to set up a mDNS responder just for that. Any clue how to let Mozilla locate the KDC via normal DNS SRV RRs? Ciao, Michael. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: SPNEGO and MDNS
Michael Ströder wrote: > > If I configure the KDC in /etc/krb5.conf in section [realms] everything > works fine. But I'd like to let the clients lookup the KDC in DNS SRV > records. This works fine for the MIT utils like kinit etc. but not for > Firefox and/or Seamonkey. > > Observing the networking traffic (with wireshark) I can see mDNS > requests sent out to 224.0.0.251 by the Mozilla products. But I don't > want to set up a mDNS responder just for that. > > Any clue how to let Mozilla locate the KDC via normal DNS SRV RRs? Well, I hit the new feature regarding top-level domains .local which I used for my local Unicast DNS test domains on my Linux system (see also http://avahi.org/wiki/AvahiAndUnicastDotLocal). Since I don't want to use MDNS, zeroconf or whatever at all 1. removing mdns4_minimal from /etc/nsswitch.conf and 2. adding "mdns off" to /etc/host.conf made it work like expected for me. Sorry for the noise... Ciao, Michael. ___ 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)
Eddy Nigg (StartCom Ltd.) wrote: > Paul, I think that the general idea (of Frank and others) is, to make a > requirement on new roots and act on the 1024 bit keys at some point in > the future. I also support the idea of throwing out 1024 bit keyed roots at a not so distant point in the future. I also hope that this will sort out some of the issues with root CA certs concerning so-called "cross-signing" and liberal use of sub CAs. > are issued from that root since we've successfully transitioned to the > newer 4096 bit root. FYI: A VPN product of a major vendor simply does not work with 4096 bit root. Ciao, Michael. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Modulus length (was Re: Draft CA information checklist)
Paul Hoffman wrote: > > Let's talk specifics. Greatly appreciated. > The Verisign "Class 3 Public Primary Certification > Authority", which is widely used to create popular SSL certs on the > Internet (see <https://www.amazon.com/>), has a 1024-bit RSA key and has > an expiration date of Aug 1 23:59:59 2028. Yes, that's a bit over 20 > years from now. > > Unless Mozilla says "we are going to yank that particular Verisign > certificate, and all the ones with similar key lengths, decades before > they expire", there is absolutely no reason for us to, 20 years in > advance, start requiring "new" CAs to use stronger keys. It is just not > justified. But probably new CAs have an even later expiration date. > If we want to ramp up the mandatory key sizes, we need to also > simultaneously promise to pull out all CAs that don't meet those sizes > at a reasonable time. Otherwise, we are just pretending to be helping. Yupp. > Proposal: > a) Starting January 1 2009, all new CA roots must be 2048 bit RSA or 256 > bit EC. > b) Starting January 1 2014, all CA roots must be 2048 bit RSA or 256 bit > EC. I'm fine with that. Maybe one could extend a) that 1024-bit keyed CA roots should not have an expiry date later than 2013-12-31. That would make the issue clear to CAs. > If we adopt such a proposal, but later start to waver on (b), we > immediately admit that (a) is silly from a security perspective. But it's not silly from a practical migration perspective. It does make sense for CAs. Ciao, Michael. ___ 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)
Paul Hoffman wrote: > I was arguing that people > who have weak locks on their doors should not bothering upgrading some > of the weak locks until they upgrade all of them. That's right strictly from the security perspective. But that requires that you have all locks under your control and you can freely choose to change them all at a time. Obviously that's not the case for the pre-installed root CA certs. Ciao, Michael. ___ 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)
Kyle Hamilton wrote: > I do know that some Cisco VPN equipment doesn't like 4096-bit root > keys. Yupp. > I don't know if it likes 2048-bit keys. It works with 2048-bit keys. Ciao, Michael. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Debian Weak Key Problem
Andrews, Rick wrote: >> That strikes me as a policy that one might describe as "attacker > friendly". >> I suggest: revoke first, contact later. >> >> When you revoke the certs, you're protecting your relying parties, and >> you can count on your relying parties to contact the subjects whose >> certs have been revoked. :) > > That's a good question, and I don't know the answer. I'll bring it up > with the business folks to decide what we should do. I fear that your business people will only look at the customers' (subscriber) side. But as a relying party I'd want that certs for weak keys are revoked in any case. Ciao, Michael. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Certs bearing simple host names and public IP addresses OK?
Nelson B Bolyard wrote: > > Likewise, if I go to https://home/ and get a "home" page for some > enterprise, what assurances have I really been offered? None, since your browser cannot check whether home is a fully-qualified domain name. > Does this bother any one else ? Yes. > Should Mozilla's policy speak to any of these issues? Yes. RFC 2818 (only INFORMATIONAL) references RFC 2459 concerning matching rules which was obsoleted by RFC 3280 which was recently obsoleted by RFC 5280. RFC 5280 references "Preferred name syntax" in RFC 1034. Glancing over these documents I found no provision that the dNSName in subjectAltName MUST specify a fully-qualified domain name. But maybe this issue should raised on the ietf-pkix mailing list. Ciao, Michael. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Certs bearing simple host names and public IP addresses OK?
Jean-Marc Desperrier wrote: > Michael Ströder wrote: >> [...] >> RFC 2818 (only INFORMATIONAL) references RFC 2459 concerning matching >> rules which was obsoleted by RFC 3280 which was recently obsoleted by >> RFC 5280. RFC 5280 references "Preferred name syntax" in RFC 1034. >> >> Glancing over these documents I found no provision that the dNSName in >> subjectAltName MUST specify a fully-qualified domain name. But maybe >> this issue should raised on the ietf-pkix mailing list. > > There's no reason to forbid at that level issuance of certificates that > are intended to be used only on an intranet. Well, if there are doubts whether https://de/ points to a A/CNAME record in the .de top-level domain or resolves to a local server (by DNS adding search suffix) and is therefore treated as equivalent to https://de.example.test/ then the TLS standard should say something about this. Also matching rules for dNSName are affected. > It should be more the policy of the CA that should either refuse to > issue such certificates, or require a written agreement that they are > intended only for intranet use. Nelson was asking for adding an additional provision to Mozilla's policy. Ciao, Michael. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Debian Weak Key Problem
Paul Hoffman wrote: > > However, given that a CA cannot know whether or not a domain has been > compromised, a CA that tries to save the customer by revoking the > possibly-compromised domain's keys is overstepping its responsibility. Whether the CA is overstepping its responsibility is subject of the CPS. > The public key is still associated with the domain; it might be > associated with Mallory as well, but that's unknown. A CA usually also makes provisions about the strength of keys. So if the keys do not comply to a required key strength anymore (which is IMHO not only made up by the key's bit-length) then the CA should revoke the accompanying cert. > They keys are not "broken", they are "trivial to break if an attacker > wants to". That's an important difference, and one that needs to be made > in any warning we give to a user. Yes. Ciao, Michael. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Certs bearing simple host names and public IP addresses OK?
Eddy Nigg (StartCom Ltd.) wrote: > For internal networks, internally assigned domain names should be used, > like NETWORK = intern.domain.com Thinking further about this whole stuff: I consider the hostname checking to be a very important validation of whether the browser really connects to a host to which the user really wanted to connect to. The user cannot distinguish whether the hostname in https://com is a fully-qualified domain name or not. If DNS resolving with automagic suffix search is conducted then some disambiguation has to be made. So I'd recommend either one of these two solutions: 1. If the user enters https://hostname (hostname without dots) then the DNS resolver should in case of SSL/TLS connects not apply any DNS suffix search list when resolving hostname. 2. If the user enters https://hostname (hostname without dots) and DNS suffix search is conducted the fully-qualified domain name used to connect to the host must be displayed to the user and must be verified to be in the cert. I'd prefer 1. For both solutions only fully-qualified domain names are needed in the certs. Ciao, Michael. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Certs bearing simple host names and public IP addresses OK?
Wan-Teh Chang wrote: > There is a bug on certs containing unqualified host names: > https://bugzilla.mozilla.org/show_bug.cgi?id=401317 I really wonder what makes a host name an "unqualified hostname"? No doubt that https://www/ looks like a valid example to us humans. But how about https://com/ (top-level domain)? As I noted in a previous posting technically you can't tell without actually trying to lookup a hostname in DNS (without search suffix automagic). Ciao, Michael. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Debian Weak Key Problem
Nelson B Bolyard wrote: > It may be reasonable for a CA to assume that the subscriber has taken due > care to generate a good key pair at the time that the certificate signing > request is received, but at such time as the CA has evidence that the key > is compromised (especially public evidence), then there can be no further > true assurances for the binding, and the CA is responsible to act, IMO. I strongly agree. Especially in this particular case. Ciao, Michael. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Debian Weak Key Problem
Nelson B Bolyard wrote: > Agreed, and part of the discussion here is: is it acceptable to Mozilla > to continue to "trust" certs from CAs who don't revoke timely in the > presence of evidence? I hope not. Such CAs provide only "security > theater", IMO. Yupp. > Actually, I think most of them already ARE more strident about this than > I am. There is already HUGE distrust of CAs among the Mozilla community, > especially developers. For a decade now there have been ongoing calls > for Mozilla to ship a browser with an empty trusted CA list. There are > STILL calls for removing Verisign certs from the trust list because of the > issuance of some bogus Microsoft certs some years ago. The number one > impediment to the acceptance of EV by the Mozilla community was that it > was initially promoted by the very CA they most despised. Nelson, thanks for these clear words. > CAs can use this as an opportunity to say "Users of PKI with our certs > don't need to carry around 3MB Key revocation lists. They don't need new > software. They just use the OCSP revocation that is already built in to FF3 > and IE7, and they're covered, because the CAs will do a competent job of > revocation for them." That's real value that any Debian user can see. Yes! To CA staff lurking here: Prove your trustability now to save your own business! Ciao, Michael. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Debian Weak Key Problem
Eddy Nigg (StartCom Ltd.) wrote: > I could produce millions of keys in my free time and post them to some > web site...I could tell you now that those are all compromised keys and > all CAs should now scan their subscribers keys against the ones I > posted. Should it find one, it should revoke it, right? Eddy, this is not comparable. We're talking about the likelihood of a key being in the range of what we now consider "weak Debian keys". Ciao, Michael. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Certs bearing simple host names and public IP addresses OK?
[EMAIL PROTECTED] wrote: > On Jun 9, 2:55 pm, Michael Ströder <[EMAIL PROTECTED]> wrote: >> I really wonder what makes a host name an "unqualified hostname"? > > One workable definition is a host name without a dot "." (ignoring any > trailing dots). This would exclude issuing certs for a top-level hostname. This could be a valid assumption though. >> No doubt that https://www/looks like a valid example to us humans. But >> how about https://com/(top-level domain)? > > It doesn't really matter what looks like a valid host name to humans. That's exactly what I meant. ;-) > What matters is the policy under which certificates are issued. If a > CA is willing to issue certs for "com" or "www" to anyone, then the > certificate does not guarantee who you're talking to. It depends: If the CA states that the hostname MUST be a fully-qualified domain name then even a hostname without a dot has a well-defined meaning without extra magic. >> As I noted in a previous >> posting technically you can't tell without actually trying to lookup a >> hostname in DNS (without search suffix automagic). > > It doesn't matter what DNS tells you. But it does matter what the browser asks for. > In this threat model, DNS is under the control of the attacker. Yes. > What matters is what the browser > can deduce from the CA's signature on the certificate. But the browser does the connect based on DNS resolving. Ciao, Michael. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Debian Weak Key Problem
Paul Hoffman wrote: >> The keys in question are not "possibly compromised". They are >> compromised. >> Period. > > Until we see any evidence of this in the real world, we disagree. Oh, come on. With ready-to-use tools to scan for these weak keys the evidence is there. >> A CA who informs it relying parties that it can no longer assure the >> binding >> that it once certified is fulfilling its responsibility, not exceeding >> it. > > a) Let's be careful with our assertions. The CA can still assure the > binding of the name to the public key; what they can't assure is the > unique control over the private key. Yes. But being in the CA *business* I would take this case to attest my trustability. > b) Does revoking a certificate inform a relying party of anything > significant? Yes. It makes a cert invalid. (I know that CRLs are not checked in practice very often.) > c) What responsibilities does a CA have to relying parties? I have never > signed a contract with any of them. Paul, that's really a very poor argument! Well, exactly this leads to the conclusion of PKI critics who pointed out that CAs are hiding behind their CPSs and do not feel responsible for anything. > To be frank, browser vendors have more responsibilities to relying > parties than CAs do. That's why the browser vendors carefully check > CPSs and enforce rules about them. This would mean kicking out all root CA certs of CA (chains) which do not act on this particular "Debian Weak Key Problem". ;-) >> The keys ARE compromised. A CA who refuses to timely revoke a cert >> with a >> known compromised key abrogates any public trust. > > "Any"? Do you really think that a typical Firefox user, even when this > is all explained to them, would be as strident as you are here? The typical Firefox user trusts the PKI. It delegates security checks to a trusted third party. The CA's *business* is to help this average user to use SSL-enabled Internet securely. Ciao, Michael. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: The time to stop considering 1024 bit as secure is now !
Paul Hoffman wrote: > Note, however, that > they seem to be about the only group who is publishing any results from > their efforts. That could either mean they are the only group working on > it, or that other groups working on it are not getting publishable results. Or 3. that other groups working on it do not want to publish their results... Ciao, Michael. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Debian Weak Key Problem
Eddy Nigg wrote: > Jean-Marc Desperrier: >> Eddy Nigg wrote: >>> [...] >>> StartCom has scanned and detected all vulnerable keys and informed the >>> affected subscribers. We'll revoke all compromised keys within a short >>> time. >> >> Can you tell how much it represented in percentage of the issued >> certificates ? > > Yes, I intended to do that later anyway, but I didn't had the final > information ready when I previously posted. I can't say for certain > right now how many *were* affected overall, because some subscribers > requested revocation beforehand and we didn't scanned expired or already > revoked keys, but out of all currently valid certificates 1.95 % > were/are affected by the Debian bug (Our initial estimates was about > 1.66 %). Thanks for this numbers. > Revocation requests are trickling in due to the messages we sent and I > hope that the larger part will have their certificates revoked and > re-created during the next few days. The remaining certificates will be > revoked forcefully within a short time. Thanks for your clear action. I'm pretty sure customers are also appreciating this. Ciao, Michael. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Importing exporting JKS key to NSS db
Yevgeniy Gubenko wrote: > > 1.export public key from Solaris to Windows in JKS format > > 2.import public key from Windows to Solaris into NSS database I would export as PKCS#12 format and import that to NSS cert DB. Ciao, Michael. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Live CRLs with Issuing Distribution Point extensions?
Nelson Bolyard wrote: > I'm working on some code to handle the "Issuing Distribution Point" > extension in CRLs. What happens if the CRL's URL is redirected to another URL? Ciao, Michael. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Live CRLs with Issuing Distribution Point extensions?
Nelson B Bolyard wrote: > Michael Ströder wrote, On 2008-06-28 02:03: >> What happens if the CRL's URL is redirected to another URL? > > I think you're asking what happens if the attempt to fetch a CRL itself > (say, via an http GET request) results in an http redirection response > from the server. Yes. Background: I have a customer who insist on maintaining the CRL within a CMS which redirects the URLs in certs and CRLs to other CMS-internal links. Well, this is bad but I gave up argueing. > Assuming that is the question, the answer depends on the capabilities of > the http engine supplied by the application for NSS to use for performing > those http requests. For Mozilla browsers, I believe the answer is that > the redirection will be followed. That is not deemed a security risk, Yes, it's not a security risk. I just asked whether the target can be reached. Ciao, Michael. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Live CRLs with Issuing Distribution Point extensions?
Kaspar Brand wrote: > From reading RFC 5280 section 4.2.1.13, however, it seems to me that > conformant implementations should rather not follow redirects: > >If the DistributionPointName contains a general name of type URI, the >following semantics MUST be assumed: the URI is a pointer to the >current CRL for the associated reasons and will be issued by the >associated cRLIssuer. When the HTTP or FTP URI scheme is used, the >URI MUST point to a single DER encoded CRL as specified in >[RFC2585]. HTTP server implementations accessed via the URI SHOULD >specify the media type application/pkix-crl in the content-type >header field of the response. Not that I'm endorsing setting cert/CRL download up with HTTP redirects but I cannot derive from the text snippet above that it's forbidden or explicitly not recommended. Also RFC 2585 (referenced in above text) does not say anything like this in section "3 HTTP Conventions". I'm rather scared of implementations not capable to follow HTTP redirects. Ciao, Michael. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: EV issues with redirects...
Kyle Hamilton wrote: > We have been unable to figure out any way to submit a site to the > phish filter (in firefox3), and given the recent hoohah about EV > certificates and their usage for validation I'm concerned that people > who have their navigation toolbars turned off aren't going to see the > problems until it's too late. Kyle, thanks for raising this issue. It shows that EV certs are only marketing buzz just for raising prices. > I'm told that there is no code in place for notification of leaving an > EV site for another site; I believe this is an oversight that should > be fixed Full ack! > (this is separate from the "SSL to non-SSL" config preference > which isn't enabled by default). Which is also sad anyway... :-( Ciao, Michael. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Cert MIME types (was: adding and removing certificate while FF3 is running?)
Nelson B Bolyard wrote: > I suggest you look at > http://developer.mozilla.org/en/docs/NSS_Certificate_Download_Specification > for ideas on importing certs. I wonder why Mozilla doesn't support application/pkix-cert and application/pkix-crl specified in http://www.rfc-editor.org/rfc/rfc2585.txt Ciao, Michael. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Comparison of OpenSSL and NSS
Wan-Teh Chang wrote: > On Thu, Jul 24, 2008 at 7:31 PM, Nelson B Bolyard <[EMAIL PROTECTED]> wrote: >> I've been told that GnuTLS's API only supports carrying non-binary >> text strings as application data, and doesn't facilitate the transmission >> of pure binary files (e.g. containing lots of zero bytes). I find that >> rather hard to believe, but it is cited as a reason that some developers >> choose NSS over GnuTLS. I'd appreciate any light that could be shed on that. > > I am not familiar with GnuTLS, but I don't believe GnuTLS could > have such a serious problem. http://trac.gnutls.org/cgi-bin/trac.cgi/ticket/18#comment:1 (Well, they even aren't keeping their issue tracker spam-free...) > I believe you're referring to Howard > Chu's posting "GnuTLS considered harmful" on openldap-devel: > http://www.mail-archive.com/[EMAIL PROTECTED]/msg02484.html Did you actually read this thread? Especially this posting: http://www.mail-archive.com/[EMAIL PROTECTED]/msg02510.html Ciao, Michael. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Cert MIME types
Nelson B Bolyard wrote: > Michael Ströder wrote, On 2008-07-25 06:13: >> Nelson B Bolyard wrote: >>> I suggest you look at >>> http://developer.mozilla.org/en/docs/NSS_Certificate_Download_Specification >>> for ideas on importing certs. >> I wonder why Mozilla doesn't support application/pkix-cert and >> application/pkix-crl specified in http://www.rfc-editor.org/rfc/rfc2585.txt > > It's a matter of PSM and UI design issues. > All issues with MIME content types are decided in the browser, not in NSS. Ok. But I'd really appreciate if all browsers would handle the same MIME types for certs. In web2ldap I have code which detects the browser and sends different MIME types. This might be feasible in web applications but it's not on simple web pages. > At cert download time, there are various decisions we might ask the user to > make, depending on the type of cert being downloaded. For example, when > downloading a CA cert, it is appropriate to ask the user to make trust > decisions about the cert. The user would be expected to make different > decisions or take different actions for > - his own personal user certs, vs > - certs for other servers or other email correspondents, vs > - CAs. Having implemented things like that in (outdated) http://pyca.de at the time of Netscape Comm. 4.x I know all these use-cases. > It's often not easy to tell which of those roles is appropriate for a cert > being downloaded. The MIME content type gives the browser a big clue about > which of those 3 categories encompass the downloaded cert. I agree that RFC 2585 is not ideal for that. But it's the only vendor-independent standard I know of. > Without those > clues, the UI would need to ask the user more questions, and these are the > types of questions that users are very likely to completely fail to > understand. I hate to say but Windows' certificate import wizard does a good job guessing what should be done (different types of key stores). One could leave out the use-case for installing a cert for an accompanying private key (a personal cert) because the whole enrollment process itself is highly browser-dependent. But for importing public-key certs the browser could guess what to do (e.g. by looking whether a cert is self-signed or checking basicConstraints extension). > The bottom line is: supporting a MIME content type that says nothing about > the way in which the cert will be used will require additional PSM UI work > and the browser's UI czars aren't motivated to do it. Hmm... Ciao, Michael. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Creating detached PKCS#7 signature with cmsutil
HI!
I'd like to generate and verify a detached signature (in a separate
file) with a key from my Seamonkey profile. Is this approach with
cmsutil ok (single command-line wrapped here)?
cmsutil -S -d ~/.mozilla/xxx/ -N "cert nickname" -G -H SHA1 -T -i
name.tar.gz -o name.tar.gz.p7m
From my understanding this accesses the cert/key DB only for reading.
Is it a problem if the Seamonkey is still running?
How about verifying it? I've tried this command which does not output
any verification result:
cmsutil -D -d ~/.mozilla/xxx/ -c name.tar.gz -i name.tar.gz.p7m -o test
I also tried signver but this hangs:
signver -V -v -d ~/.mozilla/xxx/ -i name.tar.gz -s name.tar.gz.p7m
strace output of hanging signver:
- snip -
open("name.tar.gz", O_RDONLY|O_LARGEFILE) = 5
open("name.tar.gz.p7m", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 6
read(0,
- snip -
This is all done with openSUSE 11.0 packages:
mozilla-nss-3.12.0-23.4
mozilla-nss-tools-3.12.0-23.4
Ciao, Michael.
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Creating detached PKCS#7 signature with cmsutil
Michael Ströder wrote: > > I'd like to generate and verify a detached signature (in a separate > file) with a key from my Seamonkey profile. Is this approach with > cmsutil ok (single command-line wrapped here)? > > cmsutil -S -d ~/.mozilla/xxx/ -N "cert nickname" -G -H SHA1 -T -i > name.tar.gz -o name.tar.gz.p7m > [..] > I also tried signver but this hangs: > > signver -V -v -d ~/.mozilla/xxx/ -i name.tar.gz -s name.tar.gz.p7m The following command works reading the detached signature from stdin: $ signver -V -v -d ~/.mozilla/xxx/ -i name.tar.gz < name.tar.gz.p7m signatureValid=yes But this differs from what signver -h says. Also on the web page http://www.mozilla.org/projects/security/pki/nss/tools/index.html#signver the old Sun docs on http://docs.sun.com/source/816-6153-10/signver.htm are referenced. For the examples given there command-line options are used which does not seem to work with recent signver anymore. Strange... Ciao, Michael. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Creating detached PKCS#7 signature with cmsutil
Michael Ströder wrote:
> I also tried signver but this hangs:
>
> signver -V -v -d ~/.mozilla/xxx/ -i name.tar.gz -s name.tar.gz.p7m
>
> strace output of hanging signver:
>
> - snip -
> open("name.tar.gz", O_RDONLY|O_LARGEFILE) = 5
> open("name.tar.gz.p7m", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 6
> read(0,
> - snip -
BTW: This even destroys the signature file since the signature file
seems to be opened for writing.
Ciao, Michael.
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Creating detached PKCS#7 signature with cmsutil
Nelson B Bolyard wrote:
> Michael Ströder wrote, On 2008-08-05 15:44:
>> Michael Ströder wrote:
>>> I also tried signver but this hangs:
>>>
>>> signver -V -v -d ~/.mozilla/xxx/ -i name.tar.gz -s name.tar.gz.p7m
>>>
>>> strace output of hanging signver:
>>>
>>> - snip -
>>> open("name.tar.gz", O_RDONLY|O_LARGEFILE) = 5
>>> open("name.tar.gz.p7m", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 6
>>> read(0,
>>> - snip -
>> BTW: This even destroys the signature file since the signature file
>> seems to be opened for writing.
>
> I looked quickly at the source code
> http://mxr.mozilla.org/security/source/security/nss/cmd/signver/signver.c#189
> and I don't see any code path that can do that.
> See especially line 209.
> This makes me wonder if perhaps you've got some other signver in your path.
Nope. It's always using /usr/bin/signver provided by package
mozilla-nss-tools-3.12.0-23.4 downloaded from here:
http://download.opensuse.org/repositories/mozilla/openSUSE_11.0/
I did not have signver in my $PATH before installing this package.
> FYI, Be aware that NSS contains two separate implementations of CMS.
> One implements the old original PKCS#7, and the other implements CMS 3.0.
> signver is a test program for the old PKCS7 library.
> cmsutil is a test program for the newer CMS 3.0 library.
Noted.
Strange enough this works as expected giving correct results:
signver -V -v -d ~/.mozilla/xxx/ -i name.tar.gz < name.tar.gz.p7m
Ciao, Michael.
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Creating detached PKCS#7 signature with cmsutil
Nelson B Bolyard wrote: >> cmsutil -D -d ~/.mozilla/xxx/ -c name.tar.gz -i name.tar.gz.p7m -o test > > I remember running into this long ago. As I recall, the pass/fail result > is very subtle. It may be nothing more than the program's result code. > > What did you get in the "test" file? It's the same file (here name.tar.gz) like given with -c. > Is the pass/fail indication there? Nope. The file given with -o seems to be the "decoded" file. If I invoke cmsutil with a wrong input file I get the following message: -- snip -- signer 0 status = DigestMismatch cmsutil: problem decoding: Signature verification failed: no signer found, too many signers found, or improper or corrupted data. ------ snip -- Ciao, Michael. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Creating detached PKCS#7 signature with cmsutil
Nelson B Bolyard wrote: > Michael Ströder wrote, On 2008-08-06 04:07: >> Nelson B Bolyard wrote: >>>> cmsutil -D -d ~/.mozilla/xxx/ -c name.tar.gz -i name.tar.gz.p7m -o test >>> I remember running into this long ago. As I recall, the pass/fail result >>> is very subtle. It may be nothing more than the program's result code. >>> >>> What did you get in the "test" file? >> It's the same file (here name.tar.gz) like given with -c. > > identical? same length and sum? Nothing extra on the beginning or end? Yes. >> If I invoke cmsutil with a wrong input file I get the following message: >> -- snip -- >> signer 0 status = DigestMismatch >> cmsutil: problem decoding: Signature verification failed: no signer >> found, too many signers found, or improper or corrupted data. >> -- snip -- > > OK, so the failure result is verbose and explicit, and the success result > is rather terse (:-). Yes. ;-) > Did the -v option improve that any? No. >> Strange enough this works as expected giving correct results: >> >> signver -V -v -d ~/.mozilla/xxx/ -i name.tar.gz < name.tar.gz.p7m > > It doesn't surprise me that that works. I am surprised that the other > command fails in the fashion you've documented. Looking at the NSS source > code I see no way for it to open the file named with the -s option for > output (writing), yet your strace results show that it did. This makes > me wonder if the program you have was built from official NSS sources, > or if someone has modified the sources from which the distribution you > used was built. :-( Here are the SRPMs: http://download.opensuse.org/repositories/mozilla/openSUSE_11.0/src/ The patches are therein. > The binaries for the NSS 3.11.4 release may be obtained from > ftp://ftp.mozilla.org/pub/security/nss/releases/NSS_3_11_4_RTM/ > If the -s option also behaves as you found with those binaries, I'd like > to know that. I will give it a try. Ciao, Michael. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Creating detached PKCS#7 signature with cmsutil
Michael Ströder wrote: > Nelson B Bolyard wrote: >> The binaries for the NSS 3.11.4 release may be obtained from >> ftp://ftp.mozilla.org/pub/security/nss/releases/NSS_3_11_4_RTM/ >> If the -s option also behaves as you found with those binaries, I'd like >> to know that. > > I will give it a try. To sum it up. It behaves in the same way (except a seg fault with signver). Ok, I've extracted ftp://ftp.mozilla.org/pub/security/nss/releases/NSS_3_11_4_RTM/Linux2.6_x86_glibc_PTH_DBG.OBJ/nss-3.11.4.tar.gz and set LD_LIBRARY_PATH to the extracted lib/ dir (see output of ldd below). Is signver statically linked? Note that locally installed RPM package mozilla-nspr-4.7.1-18.2 provides /usr/lib/libnspr4.so /usr/lib/libplc4.so /usr/lib/libplds4.so Is this compatible to the binary from the above URL? [EMAIL PROTECTED]:~/temp/nss-3.11.4> echo "test text" > test.txt [EMAIL PROTECTED]:~/temp/nss-3.11.4> bin/cmsutil -S -d /home/michael/.mozilla/michael/3fll5lwa.slt/ -N "Michael Stroeder's Thawte ID" -G -H SHA1 -T -i test.txt -o test.txt.p7m Enter Password or Pin for "NSS Certificate DB": This gives me a CMS (PKCS#7) file test.txt.p7m (also checked with openssl pkcs7). [EMAIL PROTECTED]:~/temp/nss-3.11.4> bin/cmsutil -D -v -d /home/michael/.mozilla/michael/3fll5lwa.slt/ -c test.txt -i test.txt.p7m -o test received commands NSS has been initialized. Got default certdb [EMAIL PROTECTED]:~/temp/nss-3.11.4> sha1sum test.txt test be85789dc7301b4060b3ffd7e16aa7b00cd4670f test.txt be85789dc7301b4060b3ffd7e16aa7b00cd4670f test But now something's going completely wrong (maybe because of a library incompability/mismatch?). [EMAIL PROTECTED]:~/temp/nss-3.11.4> bin/signver -V -v -d /home/michael/.mozilla/michael/3fll5lwa.slt/ -i test.txt < test.txt.p7m Segmentation fault Anyway the following command also deletes test.txt.p7m (before seg faulting): bin/signver -V -v -d /home/michael/.mozilla/michael/3fll5lwa.slt/ -i test.txt -s test.txt.p7m Ciao, Michael. ---- $ ldd bin/cmsutil linux-gate.so.1 => (0xe000) libssl3.so => /home/michael/temp/nss-3.11.4/bin/../lib/libssl3.so (0xb8029000) libsmime3.so => /home/michael/temp/nss-3.11.4/bin/../lib/libsmime3.so (0xb7ffc000) libnss3.so => /home/michael/temp/nss-3.11.4/bin/../lib/libnss3.so (0xb7f59000) libplc4.so => /usr/lib/libplc4.so (0xb7f4) libplds4.so => /usr/lib/libplds4.so (0xb7f3c000) libnspr4.so => /usr/lib/libnspr4.so (0xb7f05000) libpthread.so.0 => /lib/libpthread.so.0 (0xb7eed000) libdl.so.2 => /lib/libdl.so.2 (0xb7ee9000) libc.so.6 => /lib/libc.so.6 (0xb7da6000) libsoftokn3.so => /home/michael/temp/nss-3.11.4/bin/../lib/libsoftokn3.so (0xb7d41000) /lib/ld-linux.so.2 (0xb8065000) $ ldd bin/signver linux-gate.so.1 => (0xe000) libplc4.so => /usr/lib/libplc4.so (0xb7fe8000) libplds4.so => /usr/lib/libplds4.so (0xb7fe4000) libnspr4.so => /usr/lib/libnspr4.so (0xb7fae000) libpthread.so.0 => /lib/libpthread.so.0 (0xb7f96000) libdl.so.2 => /lib/libdl.so.2 (0xb7f92000) libc.so.6 => /lib/libc.so.6 (0xb7e4e000) /lib/ld-linux.so.2 (0xb8002000) ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Creating detached PKCS#7 signature with cmsutil
Wan-Teh Chang wrote: > Which Linux distribution is this? openSUSE Linux 11.0 Ciao, Michael. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Comparison of OpenSSL and NSS
Eddy Nigg wrote: > Well, consider that people are familiar with OpenSSL commands and new > users get quickly used to it. This "might" be what others are looking > for when checking out NSS and other libraries (and decide to forget > about it). Look into the other thread started by me "Creating detached PKCS#7 signature with cmsutil". The command-line tools does not behave like described. The referenced docs are outdated (still pointing to sun.com). I would not claim that OpenSSL docs for using it at the command-line are much better. But there are good 3rd-party docs around and people are familiar with it. Ciao, Michael. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Comparison of OpenSSL and NSS
Howard Chu wrote: > Nelson B Bolyard wrote: >> Howard Chu wrote, On 2008-08-10 03:30: >> When one considers all the important reasons to choose a crypto >> implementation, support for one file format which is not used in any >> standard protocols (e.g. TLS, SMIME) doesn't seem like a biggie. > > The issue isn't about a specific file format, it's about overall > usability. Ignoring the issue of hiding things in a fragile DB the > problem is that it's a one-shot monolithic configuration. Frankly dealing with "PEM" files is not optimal too regarding marking certs as trusted. The cert?.db files and certutil make it possible to clearly mark certs as trusted. That's especially useful when looking at the client side. Also AFAIK there's no software providing a certificate enrollment with client-side key generation which works with PEM files. I'd really appreciate if the OpenLDAP client libs could make use of client certs I have in my Mozilla profile. > It means that every user has a complete copy of all of the CA > certificates in each of their home directories, which makes certificate > management/revocation dicy at best. Well, the situation of stuffing everything in a directory/file with PEM-formatted certs is not better. And every software can have its own cert?.db. But the format of the cert?.db is indeed fragile since it's not clear which NSS version works with which DB version. I remember a serious problem with cert7.db used by a 3rd-party product and different media releases of NSS. Ciao, Michael. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Comparison of OpenSSL and NSS
Howard Chu wrote: > Likewise in the Mozilla Browser/nss_ldap situation, the credentials > needed for LDAP authentication will probably be quite different from the > credentials needed for web browsing or personal addressbook lookups. It > would be extremely bad if simply using Mozilla on a system with > nss_ldap/LDAP/MozNSS allowed arbitrary browser users to get privileged > secure connections to their authentication server just by adding a new > AddressBook definition. Isn't that a matter of server-side trust and authz? Also a client app would have to provide a UI for choosing which client cert to use. Maybe I didn't fully understand what you meant though. > I've now gotten OpenLDAP libldap running with the PSM/NSS instance > inside my Seamonkey browser, but it's only using the browser's > already-configured databases at the moment. Well, that would be something I'd like to use. ;-) Ciao, Michael. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: OpenLDAP and NSS
Howard Chu wrote: > Michael Ströder wrote: >> I'd really appreciate if the OpenLDAP client libs could make use of >> client certs I have in my Mozilla profile. > > Don't be so sure; it's not as good as it sounds... Without the new > shared DB support in NSS, this would very likely corrupt your certDBs in > short order. E.g., if you're running the browser (which opens its DBs > with Read/Write access) and then pop over to issue an ldapsearch from > the command line, you'll hose yourself. I'm quite aware of that problem (although it did not do any harm with my local installation up to now). But I appreciate that I can sign OpenOffice files just with the cert/key stored in my Mozilla profile. > At any rate, I've committed the preliminary code to CVS so you can > tinker with it if you want. It will take a lot more beating on before > it's actually usable. I've forwarded your message to Rich Megginson since he once expressed the wish to have NSS support in python-ldap. I'm not a C programmer. >>> It means that every user has a complete copy of all of the CA >>> certificates in each of their home directories, which makes certificate >>> management/revocation dicy at best. >> >> Well, the situation of stuffing everything in a directory/file with >> PEM-formatted certs is not better. And every software can have its own >> cert?.db. > > At least filesystems are known to safely support multiple concurrent > access... ;) That's an advantage of ASCII-armored files. But at the moment there is no way to attach meta data to the trusted CA certs. It's always a trust-for-all-purposes. Also the advantage of NSS is that you can add support for Smartcards through a well-defined API (PKCS#11) like e.g. the OpenSC people do. Engine support in OpenSSL is not so common up to now (and not so simple like dealing with PEM files anyway). > And PEM has been around since 1992 or so, without any real changes. > (Which isn't surprising since it's mostly dead...) AFAIK the ASCII-armored files being called in "PEM format" for OpenSSL aren't even PEM files. ;-) Ciao, Michael. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: OpenLDAP and NSS
Wan-Teh Chang wrote: > Most NSS-based server applications open the NSS databases in > read-only mode, so they can run with multiple processes safely. But > client applications such as Firefox and Thunderbird open the NSS > databases in read-write mode. According to what Nelson said, cmsutil also opens in read-write mode which would IMHO not be necessary. Ciao, Michael. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Comparison of OpenSSL and NSS
Nelson Bolyard wrote: > > When you trust a cert as a peer, you trust it for all the names that > appear in that cert, just as if it had been issued by a CA you trust. > If it has 50 subject alt names, or a wildcard name, you trust that cert > for all those names. > > It turned out that browser users never understood that. They always > assumed that when they chose to trust an unverifiable SSL server cert > as a peer, they were only trusting it for the one site (host name) > that they were attempting to visit when they encountered the unverifiable > cert. IIRC Firefox (and Seamonkey) never showed the 50 subject alt names when asking for the peer trust. If the UI wouldn't be so terse the user would have understood this. Regarding PKI/LDAP features there are still things lacking in recent Mozilla apps which worked pretty well in Netscape Comm. 4.5x. Ciao, Michael. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Unable to use signtool on Mac
I'm having a problem signing my Firefox extension on Mac OS X. The error I get is: signtool: function failed: An I/O error occurred during security authorization. I built NSS and NSPR myself using Darwin Ports sudo port install nspr (4.7_1) sudo port install nss (3.11.9_0) I have had no problem creating a database or importing my key. Any idea where to start to look? Thanks Mike Kaply ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Unable to use signtool on Mac
Wan-Teh Chang wrote:> > Please provide the signtool command line you used, and the > content of the relevant directories. > > "An I/O error occurred during security authorization" is > SEC_ERROR_IO. This error often has nothing to do > with I/O. SEC_ERROR_IO is reported when > libsoftokn3.dylib cannot be initailized. signtool command was: signtool -d ~ -k c1dfd405-9dc0-4b7c-8e98-7b2772a81922 -p "X" directory_name the content of my signing directory is: -rw--- 1 mkaply staff65536 Aug 27 10:22 cert8.db -rw--- 1 mkaply staff16384 Aug 27 10:22 key3.db -rw--- 1 mkaply staff16384 Aug 27 10:21 secmod.db Mike Kaply ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Unable to use signtool on Mac
For the record, everything works fine with an NSS 3.12 that I built on my machine. So I don't know if it is an NSS 3.11 problem (which might be the case since other people have reported it) or a problem with darwin ports (which I doubt) Mike Kaply ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Unable to use signtool on Mac
With NSS 3.12 it looks like this after import (and works) c1dfd405-9dc0-4b7c-8e98-7b2772a81922 u,u,u Thawte Code Signing CA - Thawte Consulting cc,, ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Unable to use signtool on Mac
Nelson B Bolyard wrote: > Michael Kaply wrote: >> Wan-Teh Chang wrote:> >>> Please provide the signtool command line you used, and the >>> content of the relevant directories. >>> >>> "An I/O error occurred during security authorization" is >>> SEC_ERROR_IO. This error often has nothing to do >>> with I/O. SEC_ERROR_IO is reported when >>> libsoftokn3.dylib cannot be initailized. >> signtool command was: >> >> signtool -d ~ -k c1dfd405-9dc0-4b7c-8e98-7b2772a81922 -p "X" >> directory_name >> >> the content of my signing directory is: >> >> -rw--- 1 mkaply staff65536 Aug 27 10:22 cert8.db >> -rw--- 1 mkaply staff16384 Aug 27 10:22 key3.db >> -rw--- 1 mkaply staff16384 Aug 27 10:21 secmod.db > > what does > certutil -d ~ -L > output? c1dfd405-9dc0-4b7c-8e98-7b2772a81922 u,u,u Thawte Code Signing CA - Thawte Consulting ccc,c,c thawte c,c,c ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Unable to use signtool on Mac
Nelson B Bolyard wrote:
> Michael Kaply wrote:
>> Nelson B Bolyard wrote:
>
>>> what does
>>> certutil -d ~ -L
>>> output?
>> c1dfd405-9dc0-4b7c-8e98-7b2772a81922 u,u,u
>> Thawte Code Signing CA - Thawte Consulting ccc,c,c
>> thawte c,c,c
>
>> With NSS 3.12 it looks like this after import (and works)
>>
>> c1dfd405-9dc0-4b7c-8e98-7b2772a81922 u,u,u
>> Thawte Code Signing CA - Thawte Consulting cc,,
>
> OK, there are some possible clues there, but I don't have enough info
> about those certs to be able to give a full diagnosis yet.
>
> Let me ask some questions and make some guesses that you can try.
>
> - I gather that you exported your code signing cert and its private key
> to a pfx file from Windows' cert store using Windows cert export wizard.
> That's because it has a UUID for a nickname. Windows gives every cert
> and key a UUID, and if you don't give your cert a "Friendly Name" before
> exporting it, Windows uses the UUID as the "Friendly Name" in the pfx
> file when it exports the cert and key. So, if you'd like a friendlier
> friendly name, go into windows cert manager and give that cert a
> Friendly name, then re-export it to a new pfx file, and then import it
> into a clean set of NSS DB files.
Yep, I did export from Windows and got that ugly name. I'll redo that.
> - Did those CA certs also get exported in the pfx file? Or did you
> import them some other way, such as through your browser or with
> certutil? Please tell us how you imported them.
I exported all the certs at once from IE and imported the one PFX file
after creating a brand new database.
> - Did you do the exact same set of steps with 3.11 as with 3.12,
> starting with a DB in the same starting state?
Yes. In both cases I did:
certutil -N -d ~
pk12util -i {filename}.pfx -d ~
> - Did you use the exact same pfx file in both cases? Or did you remake
> the pfx file each time?
Exact same PFX file.
> I'm guessing that you imported the CA certs from individual .cer files
> using the browser's cert manager, rather than from the pfx file. I guess
> that because their trust flags are c,c,c (which is almost never what you
> really want), and PSM has (or had, not sure if it still does) a habit of
> always setting those 'c' flags on CA certs when it imports them, if I
> recall correctly. But maybe that's a difference between 3.11 and 3.12.
>
> I also observe that your 3.11 DB has one more cert in it than the 3.12
> DB. I can think of several possible explanations for that, including:
> a) you only imported that cert for 3.11 and not for 3.12, or
> b) the cert that is seen in the 3.11 DB but not the 3.12 DB is present
> in nssckbi for 3.12 but not in nssckbi for 3.11.9.
Yeah, the cert situtation was weird. No idea why I got that "thawte" in
3.11 but not in 3.12. It was the same PFX file.
Incidentally, the instructions I followed for all this was here:
https://search.thawte.com/support/ssl-digital-certificates/index?page=content&id=SO2550
After step two is where I ended up with the PFX file.
>
> Now here's a guess about how to solve the problem. I'm guessing that
> the CA cert identified as "thawte" is actually a thawte root CA cert.
> I'm guessing that in 3.12, that cert is in nssckbi and is marked as
> trusted for object signing. In your 3.11 DB, you have that cert there
> marked as UNtrusted for code signing. Perhaps this is because that
> root cert is NOT present in 3.11.9. (I don't know if it is or not,
> because the nickname "thawte" doesn't tell me enough to identify
> which of thawte's many CA certs that is.) An easy test of this
> hypothesis is to mark that last thawte cert in your 3.11.9 DB with
> a different set of trust flags, showing that it IS trusted for issuing
> object signing certs, then try signing with signtool again.
> To change the trust flags on that "thawte" cert, use a command like this:
>certutil -d ~ -M -n "thawte" -t "c,c,C"
>
> Let us know if that does it.
Unfortunately the suggestion didn't work. DB now looks like
c1dfd405-9dc0-4b7c-8e98-7b2772a81922 u,u,u
Thawte Code Signing CA - Thawte Consulting ccc,c,c
thawte c,c,C
And I still get the I/O error.
Incidentally, someone else reported this problem
news://news.mozilla.org:119/[EMAIL PROTECTED]
Unfortunately they never got back with more info.
Mike
I'm putting the list of the PFX
Re: Unable to use signtool on Mac
For the record, I just checked my Windows machine (where all this works) It's NSS 3.11 The extra "thawte" is not in the database c1dfd405-9dc0-4b7c-8e98-7b2772a81922 u,u,u Thawte Code Signing CA - Thawte Consulting ccc,,c I used exactly the same PFX file to import into that database as I am on my Mac Mike ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Unable to use signtool on Mac
Julien R Pierre - Sun Microsystems wrote: > Mike, > > Michael Kaply wrote: >> For the record, everything works fine with an NSS 3.12 that I built on >> my machine. >> >> So I don't know if it is an NSS 3.11 problem (which might be the case >> since other people have reported it) or a problem with darwin ports >> (which I doubt) >> >> Mike Kaply > > There were several signtool bugs in NSS 3.12 . > > https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=signtool&classification=Components&product=NSS&target_milestone=3.12&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&resolution=FIXED&emailassigned_to1=1&emailtype1=exact&email1=&emailassigned_to2=1&emailreporter2=1&emailqa_contact2=1&emailtype2=exact&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0= > > > None of them look like the one you ran into. > > However, one very significant change was made to signtool in 3.12.1 : > https://bugzilla.mozilla.org/show_bug.cgi?id=438876 > > This change might explain some issues with initialization of NSS in > prior versions of signtool, but success in the current one. > > Were you using 3.12 or 3.12.1 ? I was using 3.12 which is the only 3.12 version available here ftp://ftp.mozilla.org/pub/mozilla.org/security/nss/releases/ ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Unable to use signtool on Mac
Nelson B Bolyard wrote: > Michael Kaply wrote: >> For the record, I just checked my Windows machine (where all this works) >> >> It's NSS 3.11 >> >> The extra "thawte" is not in the database >> >> c1dfd405-9dc0-4b7c-8e98-7b2772a81922 u,u,u >> Thawte Code Signing CA - Thawte Consulting ccc,,c > > I think you're reporting that you have 3 tests, two with 3.11.x and one > with 3.12.x. The 3.12.x and one of the 3.11.x tests have DBs without > the "thawte" cert, and one 3.11.x DB which has that cert doesn't work. > > Next idea, delete that cert. >certutil -d ~ -D -n "thawte" > Tried that, and that wasn't it either. Weird. Just for fun, I tried copying the DB files from my Windows machine onto my Mac, but I still get the signtool: function failed: An I/O error occurred during security authorization. Very strange. So at this point I think I'm just going to move to my custom built 3.12 and give up on 3.11 on Mac. The reason I liked the 3.11 is because the darwin ports made it an easy build install on Mac. Is there any information/documentation on how to properly install an NSPR/NSS build on Mac? Like where to put all the files after the build? Is there a make install? Mike ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Unable to use signtool on Mac
OK, so basically it's the darwin ports version of NSS 11.9 that is causing the problem. If I build it myself everything is great. What a waste of two hours yesterday. Anyone have a script that shows how NSS/NSPR should be installed on Mac? Mike ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: TLS-client-cert-auth in .SE
Anders Rundgren wrote: > Today I was in a meeting with Swedish bank-people. They > told me that they are planning exodus from TLS-client-cert-auth > because it (in their opinion) works really bad. Well, most times I don't count bank-people as IT security experts. > So what's the problem with TLS-client-cert-auth? Unfortunately the biggest problem is that it's not used very often. ;-) > it matches poorly with web sessions including logout Why should it match application sessions? Because the web application developers are too dumb to get the session handling right for themselves? Because the "logout" does not behave like they are used with passwords? > - the GUI look like c--p ??? > - it offers no branding capability Ah, well...frankly I'm very glad that no-one can place banner ads in this UI part. And I'd rather translate this to: It does not offer possibilities for spoofing attacks. ;-) > - it require PIN caching for smart cards If you configure your web server properly to do SSL session caching you don't need PIN caching. > - it is poorly implemented in many browsers with respect to path building Can you explain this? > - it offers very limited filtering capability What do you want to filter? At which point? The only caveat is that the authentication ends at the first SSL end-point. Most times this is a reverse proxy server, not the web application server itself. So the web application server has to fully trust the web frontend server. But behind this web frontend server you can do filtering of requests. Ciao, Michael. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: TLS-client-cert-auth in .SE
Jean-Marc Desperrier wrote: >> - it matches poorly with web sessions including logout >> - the GUI look like c--p >> - it offers no branding capability > > I think the problem is almost exactly the same as the one that has > caused form/cookie based authentication to replace "Basic Authentication". Not really. HTTP basic authc is security-wise worse than form-based authc with session handling because the user's credential goes over the wire in clear with each HTTP request and the browser caches it for the whole time it is running. Ciao, Michael. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: TLS-client-cert-auth in .SE
Michael Ströder wrote: > Anders Rundgren wrote: > > Today I was in a meeting with Swedish bank-people. They > > told me that they are planning exodus from TLS-client-cert-auth > > because it (in their opinion) works really bad. > > Well, most times I don't count bank-people as IT security experts. Precisely: This does not mean that I never met real IT security experts in a bank. Ciao, Michael. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: The branding stuff. Was: TLS-client-cert-auth in .SE
Anders Rundgren wrote: > It appears that the word "branding" in a PKI GUI sent > some bad vibes around but it is really about switching from > unintelligible textual data such as > > CN=John Smith, serialNumber=554544 > > to a card metaphor like you already use in the physical world; > not about annoying the user with Vista-like security pop-ups > that only security experts understand. Something along the > following lines http://informationcard.net is needed. > > Some people have "solved" this issue by making the PIN > dialog branded but that is usually done by assuming that > each card issuer has its own propriety driver. Sure the UI for choosing the client cert could be improved, e.g. just by displaying more informational attributes from the cert and the PKI properly filling this attributes. But I'm strictly against any service-specific branding in the GUI of a PKI client. It should always look the same no matter which service is accessed. Otherwise a user cannot learn how to do the right thing in general. And experience shows that designers do not have any technical understanding and will tend to overwhelm the user with dancing logos drawing the user's attention from the really important UI elements. I suspect that people asking for branding are also talking about sending something to the client which is then dynamically integrated into the UI (see the new hype AJAX). Given that even most banks do not get their simple web sites right to really prevent CSS attacks I'm strictly against such things. I'm scared that users are tricked. Period. Ciao, Michael. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Unable to use signtool on Mac
Kyle Hamilton wrote:
> http://www.darwinports.com/ -- the version they claim is 3.11.9.
>
They actually download, build and install the real thing, but they make
some changes.
Here are their makefile changes:
http://svn.macports.org/repository/macports/trunk/dports/net/nss/files/patch-Darwin.mk.diff
-DARWIN_SDK_CFLAGS = -isysroot $(MACOS_SDK_DIR)
+DARWIN_SDK_CFLAGS = -isysroot $(MACOS_SDK_DIR) -arch i386 -arch
-DARWIN_SDK_LDFLAGS = -Wl,-syslibroot,$(MACOS_SDK_DIR)
+DARWIN_SDK_LDFLAGS = -Wl,-syslibroot,$(MACOS_SDK_DIR)
-arch -DSO_LDOPTS = -dynamiclib -compatibility_version 1
-current_version 1 -install_name @executable_path/$(notdir $@)
-headerpad_max_install_names
+DSO_LDOPTS = -dynamiclib -compatibility_version 1 -current_version 1
-install_name @executable_path/$(notdir $@) -headerpad_max_install_names
-L@@PREFIX@@/lib
http://svn.macports.org/repository/macports/trunk/dports/net/nss/files/patch-config.mk.diff
-DSO_LDOPTS = -bundle
+DSO_LDOPTS = -bundle -L@@PREFIX@@/lib
http://svn.macports.org/repository/macports/trunk/dports/net/nss/files/patch-UNIX.mk.diff
- DEFINES+= -DDEBUG -UNDEBUG -DDEBUG_$(shell whoami)
+ DEFINES+= -DDEBUG -UNDEBUG -DDEBUG_$(shell whoami)
-I@@PREFIX@@/include/nspr/ -L@@PREFIX@@/lib
They actually build it like this:
build {system "cd ${worksrcdir} && make -C
mozilla/security/coreconf/nsinstall && make -C mozilla/security/dbm &&
make -C mozilla/security/nss"}
Mike
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Unable to use signtool on Mac
Wan-Teh Chang wrote: n/NSS_reference/Building_and_installing_NSS > > For Mac OS X, copy all the *.dylib and *.chk files from > mozilla/dist/Darwin...OBJ/lib to the installation directory. > Then copy the command-line tools you want from > mozilla/dist/Darwin...OBJ/bin to the installation directory. > Note that the *.dylib and the command-line tools should > be installed in the same directory on the Mac. Why is this the case? This is one thing the darwinports seem to have gotten right - libs go in /opt/local/lib and bin go in /opt/local/bin Why does my built NSS specify: @executable_path/libplc4.dylib Thanks Mike ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: The branding stuff. Was: TLS-client-cert-auth in .SE
Anders Rundgren wrote: > Michael Ströder wrote: >> Sure the UI for choosing the client cert could be improved, e.g. just by >> displaying more informational attributes from the cert and the PKI >> properly filling this attributes. > > Essentially you are saying that Information Cards is bad idea. I didn't say anything like this about Information Cards. > I believe that they rather form a virtual counterpart to physical > cards in a wallet. Frankly I don't know much about it. > In case you feel ready for yours truly's "PKI challenge", > you could try outlining how *you* would in an Internet- > scale deal with the problems mentioned in this document: > http://web.telia.com/~u18116613/A.R.AppliedPKI-Lesson-1.pdf > Naturally all these issues has been solved in a very nice fashion > but NOT by PKI people because they simply do not understand > IT, only cryptography. Frankly I don't know very much about the maths of cryptography. But I do understand a lot about making things work in the real world (including teaching users). And that's the reason why I'm staying out of making any general claims in this "Internet-scale" scope. But again the argument that the lack of branding options hinders SSL/TLS client authc to be used is really moot. And given how many web designers and marketing people render web sites/applications to be unusable/insecure for end-users I'm strictly against giving them any possibility to muck around with security-related UI parts in browsers (or other software). > Please don't take it personal, you could be an exception :-) Being in Usenet since '93 my protective clothing is pretty thick. ;-) Ciao, Michael. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: TLS-client-cert-auth in .SE
Anders Rundgren wrote: >>> it matches poorly with web sessions including logout > >> Why should it match application sessions? Because the web application >> developers are too dumb to get the session handling right for >> themselves? Because the "logout" does not behave like they are >> used with passwords? > > You essentially gave the answer yourself. In order to deploy > TLS-client-cert-auth you must hire very special people. Like with any other technology you'd like to deploy you have to know what you're doing. Everyone who is not able to even hire such people should stay out of that business. > That MSIE has a button "Clear SSL State" is a pretty good indication > that securing a static tunnel and browsing the web are two quite > distinct applications. Yes, they are distinct. But I'm not sure why MS introduced this button in IE. Do you know this? IMO it has nothing to do with web application's session handling. > That Mozilla apparently works completely different (?) is not an > argument for TLS-client-cert-auth, it is an argument *against* it. I don't understand. >>> - it is poorly implemented in many browsers with respect to path building > >> Can you explain this? > > At least in FF 2.x, a PIV user had to *install* the entire cert-path > in the browser trust store in order to authenticate since stuff like > AIA ca issuers isn't supported in spite of being mandated in PIV. > Hopefully this was fixed in FF 3.0 but of course this total misalignment > has given TLS-client-cert-auth a *well-deserved* bad reputation. I consider this to be a matter of appropriate client enrollment. I guess many CAs are doing it wrong. >>> - it offers very limited filtering capability > >> What do you want to filter? At which point? > > Well, I think that Nelson can testify that there has been a rather > long-lasting "bug" in FF regarding what certificate to show the > user in the TLS selection GUI based on [for example] key usage. > I don't consider this a bug in FF, but a deficiency in TLS- > client-cert-auth which didn't take this issue in consideration. > The "fat-app" alternatives usually offer much better selection > facilities like in: http://tinyurl.com/6ot2vz I fail to see how this could be improved by new shiny XML-based protocol but cannot be improved with the existing protocols (like TLS). Ciao, Michael. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Mac Signing issues - the weirdness continues
OK, so now I'm really confused. I've done some testing and I am getting predictable but very confusing results. I've figured out when the extra thawte cert shows up in my DB and screws things up. Note this is all with NSS 3.12 I built NSS 3.12 opt. Then I put the dylibs and the bin for certutil/signtool/pk12util into my /opt/local/bin directory. When I run certutil/pk12util, I get this result: Brand Thunderu,u,u Thawte Code Signing CA - Thawte Consulting cc,, thawte ,, If I then move all the dylibs for NSS/NSPR into the same directory where I am running certutil/pk12util, and create a new database and do the EXACT same steps, I get: Brand Thunderu,u,u Thawte Code Signing CA - Thawte Consulting cc,, NO thawte! If I then move the dylibds back to /opt/local/bin, I get the extra thawte I verified that if I rename the dylibs in /opt/local/bin, the tools don't load, so they are definitely using the versions in /opt/local/bin, not some other version on my system. So the problem seems to be (figure this one out) that when the NSS/NSPR libs are in /opt/local/bin, they are getting loaded/run incorrectly. I'm at a loss. Mike Kaply ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: TLS-client-cert-auth in .SE
Anders Rundgren wrote: > "Michael Ströder" <[EMAIL PROTECTED]> wrote > >> I fail to see how this could be improved by new shiny XML-based protocol >> but cannot be improved with the existing protocols (like TLS). > > Because the people that works with new shiny XML-based > security protocols are often more interested in interoperability and > user experience than the overly crypto-oriented people who created > schemes like S/MIME and TLS were: > http://lists.oasis-open.org/archives/tc-announce/200807/msg00010.html Personally I don't think so. > This is probably due to the fact that these efforts are not based on what > the US government needs but what the Internet community needs. I fail to see who exactly "the Internet community" is. Maybe that's the reason I don't understand the problem. Ciao, Michael. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Mac Signing issues - the weirdness continues
Some more test info. I put everything (dylibs, executables) into usr/local/bin certutil works pk12util works (although I get the extra thawte that we talked about earlier) signtool fails with: signtool: function failed: Failure to load dynamic library. Unknown error: -2804 if I move all the dylibs into the same directory where I'm running signtool, signtools works, even with the extra thawte cert. Something is SERIOUSLY screwed up here. Mike ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Inclusion of the "KeyGen" tag in HTML5
Eddy Nigg wrote: > The keygen tag is used widely and Mozilla supports smart cards with the > associated PIN excellent. I agree. And I'd prefer it over the scripted approach of MS IE. Some issues could be solved by adding attributes for further parameters. Ciao, Michael. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: FireFox v3.0.1 of Windows uses SSLv2 Record Layer even when SSLv2 is disabled
Suresh Kumar J wrote: > > You are correct that Apache Tomcat web-server(v6.0.13) choked with the > full set of cipher suites implemented in the Windows FF3.0.1. When I > disable the following cipher suites via the "about:config" option, the > web communication started working and the server didn't complain anything. > security.ssl3.dhe_dss_camellia_128_sha > security.ssl3.dhe_dss_camellia_256_sha > security.ssl3.dhe_rsa_camellia_128_sha > security.ssl3.dhe_rsa_camellia_256_sha > security.ssl3.rsa_camellia_128_sha > security.ssl3.rsa_camellia_256_sha Are the Tomcat developers aware of this issue? Ciao, Michael. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
freedesktop.org secret storage project
Hi, (Someone directed me here after posting to dev-apps-firefox - I hope this is the right list) I'm the maintainer of the KDE Wallet system and I'm currently in process of starting a freedesktop.org specification for storage for secret information like passwords or certificates. Other people involved in this project are the gnome keyring developer and developers of other free browsers. What got this project started were various user requests for having one central password storage/ management facility on their desktop. The system's general architecture will be quite similar to what kwallet/keyring offer nowadays, with a symmetrically encrypted storage and a client/server architecture. There hasn't been anything ironed out yet and I'd like to invite developers of the various mozilla projects to join and voice their opinion about what they'd want such a system to be to make use of it as well. Currently the project creation request resides in the freedesktop.org bugtracker: http://bugs.freedesktop.org/show_bug.cgi?id=16581 Please CC me on replies as I'm currently not subscribed to this list. Regards, Michael ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: How-to guide for email encryption
Anders Rundgren wrote: IM[NS]HO, S/MIME encryption using PKI is one of the biggest security farces ever. I don't see why. Regarding the guide, I believe that e-mail encryption would be fairly common if it had been (generally) based on using a shared secret, because passwords are easier to use than PKI (for encryption NB). This is nonsense. Passing a shared secret to somebody else would be impractical. The biggest obstacle preventing people to use S/MIME (or even PGP) is that they don't have to. They are not forced by security policies, business contracts etc. to encrypt their e-mail. So they simply avoid additional work. This cannot be solved technically. Ciao, Michael. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: How-to guide for email encryption
Anders Rundgren wrote: Of course S/MIME encryption works for PKI experts. It can also work for normal users. The problem is that both ends of the communication channel have to be willing to do the preparation work needed. But how do I send an encrypted message to the IRS? (S/MIME have been largely funded by the US government). "Michael Ströder" <[EMAIL PROTECTED]> wrote: The biggest obstacle preventing people to use S/MIME (or even PGP) is that they don't have to. They are not forced by security policies, business contracts etc. to encrypt their e-mail. So they simply avoid additional work. This cannot be solved technically. If people would have to use it technical solutions which are more usable could be easily provided (like public PKC repositories). Ciao, Michael. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: How-to guide for email encryption
Julien R Pierre - Sun Microsystems wrote: My insurance company chose to deploy webmail with an HTTPS interface with a shared-secret login (password) for secure messages between patient and doctors. As a result, I cannot (easily) archive the messages I receive and send locally. I have to login to a web site every time to look at them. And that web site sets the archiving policy. Especially the lack of control over the archiving policy can really bite you. However, it's obvious that the system they deployed is much simpler to use than S/MIME. Still, my dietitian finds it too complicated, and can only be contacted through regular insecure email to this day. And that's exactly the point: Your dietitian don't have to use encrypted e-mail. If it would be a MUST (by law or similar regulations) he would. That's a non-technical issue and cannot be solved by yet another technical approach which looks more "easy" to some people. Ciao, Michael. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: How-to guide for email encryption
Julien R Pierre - Sun Microsystems wrote: Michael, Michael Ströder wrote: Anders Rundgren wrote: IM[NS]HO, S/MIME encryption using PKI is one of the biggest security farces ever. I don't see why. Regarding the guide, I believe that e-mail encryption would be fairly common if it had been (generally) based on using a shared secret, because passwords are easier to use than PKI (for encryption NB). This is nonsense. Passing a shared secret to somebody else would be impractical. I agree with you if you are talking about sharing that secret instantly with any other random person line. Yes, that's what I meant. However, sharing secrets is done routinely with a limited number of entities in a variety of ways, eg. you go to your bank to set your ATM card pin, or (gasp) over the phone. My insurance company sends a temporary password through postal (smail) mail the first time you sign up for email access. I think you can also sign up in person at the hospital. Yes, it's also often done during cert enrollment. Ciao, Michael. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: How-to guide for email encryption
Paul Kinzelman wrote: Wow, I guess I really opened a can of worms. Interesting discussion, but like somebody said, it's really off the original topic I posted. You should have a look at the ietf-pkix mailing list archive to a get a feeling about more cans of worms. ;-) I'm just glad to contribute something to others that are trying to wack themselves a way through the jungle of getting secure email off the ground. And that's much appreciated! Ciao, Michael. ___ 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)
Eddy Nigg wrote: The Wisekey case could be where we might draw the line. Provided that - there is a *good compelling reason* for using sub-ordinate certificates in first place, limited to the domains under the control of the owner (via name-constraints) and with reasonable controls in place (like annual site visits, proper CA key generation, distribution and storage); I wonder how you want to limit the domains via name constraint extension in current business practice. I have a customer who has ~2 registered domains. They bought another big company with ~3 registered domains. They usually register all variants of product names under all top-level domains so the number is growing quite fast. For each domain there MAY be SSL certs issued by an own sub CA. In this environment the naming constraints are just defined by contract with the root CA owner not by cert extension. Ciao, Michael. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Web signing?
Anders Rundgren wrote: I also understand your worries regarding what to sign and I would be very dishonest if I said I have "solved" it. In fact, my design doesn't even address this issue (!) except that if of course builds on the assumption that at least the "viewer" works as expected. But it's the main issue! If you don't address this it's simply worth nothing. And you're bashing S/MIME use. Ah well... You may be interested (still awake?) knowing that payment operations in brick-and-mortar shops is ultimately the most important application for the suggested scheme. Since this list doesn't really work with payments, I won't bore you to death with how this is supposed to work, but it does! Real-world example: A company has many point-of-sale systems placed at external partner companies. Guess what? They have legal fights going on about real money. The question debated is whether the POS software itself worked correctly. Digital signatures wouldn't help in this situation since the partner would simply claim that what was displayed on screen was different from what was signed by the software. (They have a lab where each and every version of the software is installed for testing by assessors.) Also when signing a contract by hand I usually get a physical copy of it which I can archive. That's not the case when doing web-signing. That's another important flaw of that scheme. Ciao, Michael. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Web signing?
Nelson Bolyard wrote: Eddy Nigg wrote: On 11/19/2008 05:52 PM, Anders Rundgren: In the meantime, wouldn't it be of some value if Mozilla tried to satisfy a PKI- related activity that in number of users, already is much bigger than S/MIME, i.e. the concept of "Web Signing"? What is this supposed to be? Perhaps I missed it? I think this is a reference to the action historically called "form signing" (or more accurately "form post signing") in Mozilla. It's a way to sign the data being sent in to a web server with the user's private key, as the data is being sent. [..] There are some fundamental issues with this stuff, such as, how does the user know what he's being asked to sign? How does he know that he's not being asked to sign a document conveying the deeds for all his real property to the web site owner? In some countries where digital signatures have the full force of law, just like a real signature, this could be a serious issue. Yupp. Glad you already wrote what I wanted to say. When thinking it to the end it even gets more messy than the S/MIME stuff. Especially since web designers and marketeers come into the way when talking about the user interface. I'm personally wary of efforts that push to make it possible for users to make such legally effective signatures without solving the problems of how to protect the user. The German signature law and the accompanying directive tried to protect the user by specifying minimal requirements for the signature process and components used. I guess that's what Anders calls "(German nfluences...) monstrosity" in his other posting. Ciao, Michael. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Web signing?
Ian G wrote: Nelson Bolyard wrote: Eddy Nigg wrote: On 11/19/2008 05:52 PM, Anders Rundgren: In the meantime, wouldn't it be of some value if Mozilla tried to satisfy a PKI- related activity that in number of users, already is much bigger than S/MIME, i.e. the concept of "Web Signing"? What is this supposed to be? Perhaps I missed it? I think this is a reference to the action historically called "form signing" (or more accurately "form post signing") in Mozilla. It's a way to sign the data being sent in to a web server with the user's private key, as the data is being sent. Mozilla implements this with a javascript extension known as "crypto.signtext". I think IE implements it with an ocx (an Active-X module). Um. So these tools organise a signature from a client cert over the text in the form text box, and then post the signature up to the server? Yes, more or less. There are several approaches in proprietary products. With Netscape's form signing the web application had to generate simple HTML from the form content which was displayed in a separate popup-window. I vaguely remember that the HTML displayer was restricted to avoid white on white or similar faking. The simple HTML blob was then signed (PKCS#7). There doesn't seem to be any standard for a way make this work that is common to all browsers. NSS provides the necessary crypto code. This requires a client-certificate HTTPS connection to the webserver to make it happen? No. This is a business problem not a tech problem. Exactly! Ciao, Michael. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Web signing?
Ian G wrote: This requires a client-certificate HTTPS connection to the webserver to make it happen? No, this can happen over an insecure http connection. The connection between the browser and server has nothing to do with the crypto.signtext() function. Typically, you would probably want to run it over an https connection, but the point is there is no relationship between the signing of the text and the transport over the network. There is also no relationship between the CA used to trust the server connection, and the CA used to trust the user's signature. Wow, that is nice. So the java script is running the crypto access completely separately from the HTTPS stuff? Yes. OK, then, how does the browser manage the signed text? It just sends the PKCS#7 blob along with the form. The server-side application has to validate the signature and parse the input data from the simple HTML which was signed. Store it somewhere? Verify it somehow? Nope. Ciao, Michael. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Creating a Global User-level CA/Trust Infrastructure for SecureMessaging
Anders Rundgren wrote: I want each organization/domain entity that can afford an SSL certificate to become a virtual CA and run their own secure messaging center. Based on the SSL certificate they can use whatever issuance policies they feel comfortable with as long as they keep inside of their "PKI sandbox" which is (by the not yet defined application), constrained regarding subject naming-schemes. This is BTW, how I believe secure e-mail should have been from the beginning; secured at the domain-level. Anders, that's not the real problem with S/MIME or PGP. Encrypting/signing is simply not a business requirement. One of my customers has a special CA for issuing S/MIME certs to its own internal end users. The end users are always surprised how easy they can get a S/MIME cert within a minute. But the external partners are not obliged to encrypt e-mail and they are not willing to do the necessary work on their side. I already tried this 10 years ago with a PKI which would have issued certs to external partners. They were not willing to do their part even if made fairly simple. => Encrypting/signing must be made a business requirement in contracts. That's the whole point. And there's no technical solution for it. Ciao, Michael. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Creating a Global User-level CA/Trust Infrastructure forSecureMessaging
Anders Rundgren wrote: I think we are looking for different things. I'm looking for a system that offers authenticated and confidential messaging which would among things include mobile phone voice messaging. But it's the very same problem. If such system would require users to trust certificates and stuff, it will fail. Off course you can use untrusted keys but then you have the MITM issue (as others already mentioned). Our current only alternative is the trusted provider concept. I'm interested in making the trusted provider something else than Vodafone; which could be your employer or Google, and for the really paranoid a server you run yourself. As I wrote even if you have your domain-wide PKI the other end has to also do the homework. If there's no real business requirement to do so they will not. Ciao, Michael. - Original Message - From: "Michael Ströder" <[EMAIL PROTECTED]> Newsgroups: mozilla.dev.tech.crypto To: Sent: Tuesday, November 25, 2008 21:52 Subject: Re: Creating a Global User-level CA/Trust Infrastructure forSecureMessaging Anders Rundgren wrote: I want each organization/domain entity that can afford an SSL certificate to become a virtual CA and run their own secure messaging center. Based on the SSL certificate they can use whatever issuance policies they feel comfortable with as long as they keep inside of their "PKI sandbox" which is (by the not yet defined application), constrained regarding subject naming-schemes. This is BTW, how I believe secure e-mail should have been from the beginning; secured at the domain-level. Anders, that's not the real problem with S/MIME or PGP. Encrypting/signing is simply not a business requirement. One of my customers has a special CA for issuing S/MIME certs to its own internal end users. The end users are always surprised how easy they can get a S/MIME cert within a minute. But the external partners are not obliged to encrypt e-mail and they are not willing to do the necessary work on their side. I already tried this 10 years ago with a PKI which would have issued certs to external partners. They were not willing to do their part even if made fairly simple. => Encrypting/signing must be made a business requirement in contracts. That's the whole point. And there's no technical solution for it. Ciao, Michael. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Creating a Global User-level CA/Trust Infrastructure forSecureMessaging
Ian G wrote: PGP and Skype both offer authenticated + confidential messages, without the "certificate" side of things. They do it conceptually by tightly binding the keys to the user, and having each user authenticate their handles directly to each other. Well, there has to be a persistent secret in the game - likely the user's password which is being used as shared secret. Kerberos works that way. The caveat is that it needs network on-line access to a central infrastructure. X.509 PKI does not require this. Ciao, Michael. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Creating a Global User-level CA/Trust Infrastructure for SecureMessaging
Ian G wrote: Michael Ströder wrote: Anders, that's not the real problem with S/MIME or PGP. Encrypting/signing is simply not a business requirement. ... => Encrypting/signing must be made a business requirement in contracts. That's the whole point. And there's no technical solution for it. That's as close to a perfect dilemma as I've come across! Yupp. It's not a business requirement, so we must make it a business requirement ... What then creates the upstream requirement? If it doesn't come from business, where does it come from? You have to teach people to make these requirements part of the company's security policy which in turn has to be made integral part of business contracts with external partners. Technicians cannot solve this by inventing yet another technology. But it seems that some security people are very busy with PKI bashing and convincing others that a new technology will solve all the non-technical problems. That will obviously fail miserably. Ciao, Michael. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Creating a Global User-level CA/Trust Infrastructure for SecureMessaging
Anders Rundgren wrote: Ian G wrote: => Encrypting/signing must be made a business requirement in contracts. That's the whole point. And there's no technical solution for it. That's as close to a perfect dilemma as I've come across! It's not a business requirement, so we must make it a business requirement ... Another alternative is to Anders, still you fail to see the real problems since you propose technical solutions for non-technical issues. But let's see: 1. abandon non-scalable trust infrastructures such as the one required by S/MIME Why "non-scalable"? Can you be more verbose? 2. abandon schmes that use explicit encryption keys like S/MIME Are you aware of the requirements for separate encryption keys? Some companies have the legal requirements for key escrow in litigation cases. That's the main reason why encryption and signature keys are separated. 3. introduce secure mobile secure key-storage Ah, yeah. Did you ever think of a growing key history and such? 4. put the latter in cell phones Even cell phones can break. And I don't consider them to be trustworthy key stores 1. with all the control the cell phone provider has over them, 2. all the gadgets installed with security issues, 3. with the limited data storage size on today's SIM cards. And the main point: You fail to explain how trust is to be established. Ciao, Michael. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Creating a Global User-level CA/Trust Infrastructure for SecureMessaging
Ian G wrote: Michael Ströder wrote: Ian G wrote: Michael Ströder wrote: Anders, that's not the real problem with S/MIME or PGP. Encrypting/signing is simply not a business requirement. ... => Encrypting/signing must be made a business requirement in contracts. That's the whole point. And there's no technical solution for it. That's as close to a perfect dilemma as I've come across! Yupp. It's not a business requirement, so we must make it a business requirement ... What then creates the upstream requirement? If it doesn't come from business, where does it come from? You have to teach people to make these requirements part of the company's security policy which in turn has to be made integral part of business contracts with external partners. You can't put something in a company's security policy unless it is a business requirement first. Reality is much more complex. Sometimes requirements are in a security policy but not in business contracts. And sometimes the management asks for e-mail encryption but does not enforce the use of an existing e-mail encryption infrastructure afterwards. Or sometimes the technical infrastructure turns out to be pretty buggy and everybody avoids using it. Fortunately these interop problems are almost solved today. (Unless we endorse the absolutist view of security, in which, we have to fix security holes because we know how to ... rather than whether they cost money for the business. But that's a firing offense ;) Well, it's all about risks and how people weigh them. Some security people know a little more about some risks and technical counter measures and try to propose them. But it's hard to reach everybody in the business especially in big companies. And it's hard to convince people to spend time/budget to mitigate the risks. Ciao, Michael. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Creating a Global User-level CA/Trust Infrastructure forSecureMessaging
Anders Rundgren wrote: It seems that you don't believe much in technical solutions as enablers. In fact I do. But still there are non-technical issues to be solved for which no technical solution exist. And I think that steadily inventing new standards is not a solution for establishing a technology (here cryptography in general). Let me take a practical example. In the EU most on-line banks use two-factor authentication. The majority of these use OTP (One Time Password) solutions that definitely not are without cost as well as susceptible to phishing. In addition OTP is not terribly convenient for users but that is (of course) something the banks care a little bit less about. So why don't they use PKI instead? There are several reasons for that. One was that if you want to use smartcards as key store for better security you have to install software and hardware on the user's system. Most times the smartcard "middleware" was quite buggy, sometimes it was simply unmaintained crap. Also the card software was not available for all the client systems out there (not everybody uses Windows). That's why e.g. HBCI never hit the mass market. Currently it gets a little bit better with some crypto tokens. But crypto tokens are not suitable for S/MIME encryption keys because of the growing key history needed. So one has to distinguish PKI-enabled applications. Some people say it is because PKI is difficult and introduces legal and liability hurdles. IMNSHO this is total BS since a bank-local PKI isn't designed to work outside of the bank's domain. I agree here. PKI in such a setup is just another kind of password. Hmm, here I disagree since a password, even when used like in Kerberos, leaves the user's system (directly or as shared secret) whereas a private key used for signing something during authentication never leaves the key store of the client's system. So what is then real problem? 1. The European Smart Card industry who do not want to become suppliers of commodities. ??? Each time I talked to smartcard vendors they were keen on selling their stuff. The more the better. 2. Governments who believe that ID-cards and eID are natural combos in spite of the fact that USB and USB memory sticks are everywhere, while the traditional smart card interface is not. 3. Governments claiming that the use-case for physical IDs and eIDs are essentially the same 4. Governments that do not understand that their eID concept does not address more than a tiny fraction of their citizens' needs for authentication on the Internet 5. Governments investing in stuff like CEN 15480 and ISO/IEC 24727 Do you think banks care for governments at all? They don't! I saw some banking PKI fail since they believed: We're big enough and we invent our own stuff which rules out everything else. They mainly suffered from internal politics and the DOT.COM blurb. 6. Governments pushing bizarre Bridge CA concepts BTW: The Bridge CA in Germany was not invented by the government. IIRC the founders were a bank and a big telco company. PKI for consumers will become bigger than OTP when PKI is housed in mobile phones although initially OTP will be used in mobile phones rather than by special-purpose devices. I doubt that. To achieve that we need a whole bunch of enablement technologies. Most of the PKIX enrollment stuff will be obsolete in 5-10 years from now I'd never trust a system where the mobile phone vendor initializes a key to avoid an enrollment process. If you really plan to establish such a system be assured that I will fight against this. The problems with mobile phone security issues are exaggerated and are also in no way cast in concrete. On which planet are you living? If the requirement is "perfect" security, There's no 100% security. We all know that. But e.g. given the Bluetooth attacks I'm concerned of drive-by copying of private keys. And given the strange customizing of mobile phones by the telco companies my trust is even lower. > we have to accept that nothing will happen. Frankly I prefer having to deal with OTP when doing online banking over using my handy with some obscure key container initialized by a vendor on it. Google's Android as well as Symbian 9.3 are not comparable to Windows which indeed has a broken security model. But many security reviewers know a lot about Windows (and Linux and Mac OS X) in comparison to public knowledge about Android. So you can't tell at this time. I don't expect a reply on this because it will anyway take some five years or so to figure out if the above is correct or not. Well, mabye the problem is that I'm not as visionary as you are. ;-) Ciao, Michael. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Creating a Global User-level CA/Trust Infrastructure for SecureMessaging
Just to clarify: I also see a lot of practical problems to be solved when encrypting/signing e-mails. And I supported real end-users doing so. But these are not caused by S/MIME (or PGP) standards itself. Ian G wrote: * it has no open + effective key distribution mechanism. (I exclude the LDAP stuff as that is generally for internal / corporates, and is not a general solution for the users.) Just exchanging signed S/MIME e-mails is quite easy for most users. The case that e-mail receivers are completely unknown is fairly seldom. This is a non-issue. E.g., after changing laptops recently, I still cannot s/mime to half my counterparties because I don't have their certs. This happens regularly with everyone I know... ??? I've changed my notebook harddisk quite often. I never lost my Seamonkey cert DB containing the key history of the last 10 years since it's part of the Mozilla profile which I have backups of. When people in companies get new PCs there's backup concept to migrate their old data. If not the user has more problems than just the e-mail certs of others. If you create a new profile in your MUA then you have to import the certs therein. But does that happen very often? This is a non-issue. * it needs a few tweaks in UI to align it with the safe usage models, so, for example the "signing" icon has to go because it cannot be used for signing, because signing is needed for key distribution. It also cannot be used for signing unless reference is made to the conditions of signing, and no UI vendor has ever wanted to give time&space to a CPS. Maybe it's me but frankly I don't understand what you say here. Especially I don't see the need for a "UI vendor" to define a CPS (if Certificate Practice Statement is meant here). No doubt the UI could be better in some S/MIME-enabled MUAs. > C.f., that recent thread with Nelson, where he reads everything before > signing. The thread about form signing? There was a basic question whether it's feasible at all and I commented on that. * it needs a click-to-launch method of key-creation, sort of like that which Anders was demoing with Firefox. Or preferably, it should be launched by default. "There is only one mode, and it is secure." But that will likely clash with the next point. Are you talking about the PGP model of peer trust? (Each end-user defining individual trust for each participant's public key). * the security architecture is referred to some IETF committee. This means it is incapable of modifying its security model to deal with evolving threats. Anything with its security leadership split across too many components eventually falls into stasis. I don't understand this. 2. abandon schmes that use explicit encryption keys like S/MIME Are you aware of the requirements for separate encryption keys? Some companies have the legal requirements for key escrow in litigation cases. That's the main reason why encryption and signature keys are separated. What happens when we add complexity to an already broken system? I fail to see why it's broken. So I can't answer. And I fail to see why the other schemes proposed are less broken. IMHO the opposite is true. 3. introduce secure mobile secure key-storage Ah, yeah. Did you ever think of a growing key history and such? Is that the counterparty certs, which would then also disappear every time someone changed cellphone? Yeah, I agree. It needs a better key distro mechanism, like the key servers of OpenPGP. No, I meant the archived private keys for accessing old encrypted e-mails. 4. put the latter in cell phones Even cell phones can break. And I don't consider them to be trustworthy key stores 1. with all the control the cell phone provider has over them, 2. all the gadgets installed with security issues, 3. with the limited data storage size on today's SIM cards. Sounds about as robust as any Internet software on any modern PC that bombs out once a year or so :) Yes, there are risks with software on a PC. But on a PC I have a fairly good chance to keep more control on what I'm using. The mobile phones tend to be customized. Configuration options are very sparse. There is no reasonable update mechanism keeping me informed about security updates. (It was a major PITA to update the buggy firmware on my Sony Ericsson mobile phone. The update software needed a flash player to be installed to display some fancy graphics. Uumpf!) And the main point: You fail to explain how trust is to be established. Well, there is the old trick I described: do a DH key exchange and then use the voice to authenticate the checksum over the results. Yupp. But that's kind of an enrollment process which is what Anders would like to avoid. (Mind you, let's not get too
Re: Creating a Global User-level CA/Trust InfrastructureforSecureMessaging
Anders Rundgren wrote: >> So what is then real problem? >> 1. The European Smart Card industry who do not want to become suppliers >> of commodities. >??? >Each time I talked to smartcard vendors they were keen on selling their >stuff. The more the better. You mean there is a standard blank smartcard that you can buy from multiple vendors that works right-out-of-the-box in most computer systems? Using what kind of standard personalization software? Different vendors have different smartcards but you can use them from different applications through PKCS#11 and CAPI/CSP. The software quality differs. You claimed that banks do not use PKI with smartcards for authc because there's nothing available. I don't think so. The banks do not want to get involved with supporting software/hardware installed at the user's PC. You should look at the HBCI history. >> To achieve that we need a whole bunch of enablement technologies. >> Most of the PKIX enrollment stuff will be obsolete in 5-10 years from >> now >I'd never trust a system where the mobile phone vendor initializes a key >to avoid an enrollment process. If you really plan to establish such a >system be assured that I will fight against this. The idea is rather than the phone vendor provides an Open Key Container which is initialized by a certified device key which is used for key attestations: And how is the device key certified to establish trust? http://tinyurl.com/6rg7ap <http://tinyurl.com/6rg7ap> Pretty vague. This all does not solve the basic problem which is: People are too lazy to use this technology to mitigate risks if they are not forced to use it (by law or security policy). Ciao, Michael. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Creating a Global User-level CA/Trust Infrastructure forSecureMessaging
Anders Rundgren wrote: Michael Ströder wrote: Ian G wrote: * it has no open + effective key distribution mechanism. (I exclude the LDAP stuff as that is generally for internal / corporates, and is not a general solution for the users.) Just exchanging signed S/MIME e-mails is quite easy for most users. The case that e-mail receivers are completely unknown is fairly seldom. This is a non-issue. The e-mail receivers are seldom unknown but their CAs are. Using Windows Mail most PKIX signed messages give me a black screen telling there is something wrong with this message, while messages asking me to download EXE files pass without warnings. When I'm in a project working for a company which has a S/MIME CA importing the CA cert into my S/MIME-enabled MUA is a no-brainer. What's the issue? I establish trust for a certain purpose: Exchanging secured e-mail with a certain company so nobody can read the documents *they* want to keep confidential. I'm happy to do that once for a CA cert instead of having to initiate a secure key exchange with every employee of the company. The sad thing is: The users, in this case my project colleagues, sometimes do not know how to use the existing S/MIME infrastructure although they enrolled during a user registration process and they already have everything on their desktop. Although I'm not involved personally with the S/MIME infrastructure my attitude is to teach the people how to use it. And they feel better when using it because they know there's a need for e-mail protection. But they were simply not teached. That's a non-technical problem. And any other signature/encryption/whatever standard will suffer from this. E.g., after changing laptops recently, I still cannot s/mime to half my counterparties because I don't have their certs. This happens regularly with everyone I know... ??? I've changed my notebook harddisk quite often. I never lost my Seamonkey cert DB containing the key history of the last 10 years since it's part of the Mozilla profile which I have backups of. Each time you want to use another computer. Oh, come on! How often do you *really* do this? And how do you move around the rest of your workspace? There are many more things to consider when you want real roaming than just your keys and PKCs of others. Why do you think I claim that mobile crypto is a prerequisite? Either your mobile also runs the apps or you have to integrate your mobile with the PC on which the whatever-you-call-your-standard-enabled app runs. The latter is the same problem space like using smartcards/readers or USB tokens as key store. For hackers, yes. For corporations with IT-support, yes. For consumers OTOH it is a showstopper. BTW: Consumers don't switch PCs so often. My friends and relatives who get a new PC also try to backup and restore their MUA profile data (or somebody helps them to do it). * it needs a few tweaks in UI to align it with the safe usage models, so, for example the "signing" icon has to go because it cannot be used for signing, because signing is needed for key distribution. It also cannot be used for signing unless reference is made to the conditions of signing, and no UI vendor has ever wanted to give time&space to a CPS. Maybe it's me but frankly I don't understand what you say here. Especially I don't see the need for a "UI vendor" to define a CPS (if Certificate Practice Statement is meant here). I believe Ian is referring to the problem which made me starting this thread... That is, the need for end-users to become trust managers. Everybody is a trust manager. All day everybody is making trust decisions. But there's no ultimate trust. Ciao, Michael. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Creating a Global User-level CA/Trust Infrastructure forSecureMessaging
Ian G wrote: Michael Ströder wrote: Anders Rundgren wrote: Michael Ströder wrote: > I can offer a counterpoint: a recent well-thought-out project to do something similar started out with S/MIME, and concluded that S/MIME should be optional because it is brittle, The phrase "because it is brittle" does not give any particular reason. So it's impossible to answer in a meaningful way. and all email should go through corporate servers, and TLS should be used for the protection. And how did you ensure that *all* of the relevant communication partner had StartTLS enabled at their MUAs, all MUAs were corporate servers (especially the receiving MX) and how was CA trust handled? Pretty similar problems... (In this case, every user was either an experienced security and tech person, or an extremely experienced security and tech person.) Well, strange... The unexperienced users I've teached to use the existing S/MIME infrastructure were capable of doing so. The sad thing is: The users, in this case my project colleagues, sometimes do not know how to use the existing S/MIME infrastructure although they enrolled during a user registration process and they already have everything on their desktop. Although I'm not involved personally with the S/MIME infrastructure my attitude is to teach the people how to use it. And they feel better when using it because they know there's a need for e-mail protection. But they were simply not teached. That's a non-technical problem. IMO, the root cause is not training. The root cause is that protecting e-mails is not enforced/endorsed within companies even if they have a working infrastructure. The lack of training is the consequence of this. Nor legal. Yes, not a legal issue. The root cause is that the S/MIME security model is inefficient; it doesn't deliver benefits in accordance with the costs imposed. I disagree (see above). Funnily enough, users are very savvy. I agree (see above ;-). They can spot a worthless system much more easily than engineers. What they can't do is explain why it is worthless; they simply bypass it. This is why smart product is always developed in association with lots of user feedback, and paper designs generally don't succeed. As I wrote the users themselves felt better after protecting e-mails with encryption. They are savvy. They know that it's bad not to encrypt e-mails. In another project my task was to explicitly support external partners of a company with a S/MIME infrastructure to get S/MIME-enabled. A normal user from within that company had triggered this support request. I tried to contact the admins of several external partners to help them but they just ignored it. => the lack of security requirements in the contracts were the root cause for failure. This has to be enhanced. In this sense, Mozilla is on the right track with trying to put in place a user security model that doesn't require user intervention. (E.g., the UI hides the CA, from the "all CAs are equal" assumption.) However, this only works if the result is efficient. As Kyle comments, it isn't, for S/MIME, and the result is that the model experiences low usage rates. In any case the sender *and* the receiver has to enabled for e-mail protection => the very same problems will arise. And any other signature/encryption/whatever standard will suffer from this. If by "standard" you mean "security model," that's simply not true. Yes, IMO the security model is part of a standard (cryptographic protocol). Skype delivers the goods and takes only a few minutes of training. I don't trust Skype! AFAIK the protocol and security model was never publicly reviewed. And it only works with access to a central infrastructure. I'd never accept such a thing. Correct me if I'm wrong, but I don't think any standards approach ever came up with a security model that works for users. A pretty broad statement... E.g., after changing laptops recently, I still cannot s/mime to half my counterparties because I don't have their certs. This happens regularly with everyone I know... ??? I've changed my notebook harddisk quite often. I never lost my Seamonkey cert DB containing the key history of the last 10 years since it's part of the Mozilla profile which I have backups of. It is a curious thing: I have been using Tbird for many years, and each time I've never managed to transport more than a portion of the stuff across. I just spent some time looking and couldn't find the magic command, so I always wonder... I know there is a thing called profiles, but where does one import & export them? By simply copying files? That's how I'm doing it. Each time you want to use another computer. Oh, come on! How often do you *really* do this? And how do
Re: Creating a Global User-level CA/Trust Infrastructure forSecureMessaging
Kyle Hamilton wrote: First off: User training is arguably more technical than computer infrastructure. You can't simply say "they were simply not teached [sic]" and "that's a non-technical problem", Let me rephrase: The decision whether users are teached is a business decision since budget has to be spent for that. This is a non-technical decision and the lack of training even though the technical infrastructure already exists is therefore a non-technical problem which cannot be solved by yet another technical infrastructure. perhaps more important: WHY to perform a series of complex tasks. Yes, a very valid question. (Why should someone change the oil in their car? Because it helps the car's engine last longer. Good example. Why should someone go through the additional mess and morass of using S/MIME? To let themselves in for more user-interface headache and annoyance?) My point was the users themselves already were aware of the problems with unencrypted e-mail. They felt better encrypting their e-mails because they want to avoid harm to their company which pays their loan. What X.509 needs to be viewed as is not "a means of identification". It needs to be viewed as "a means of authentication which uses the same identity policy as the issuing realm" -- in other words, it's a means of agreeing which set of rules is being used to identify each person. I agree here. As I wrote in another posting. There's no ultimate trust. And IMO in most deployments the people are quite aware of this. Everybody is a trust manager. All day everybody is making trust decisions. But there's no ultimate trust. No user can make a trust decision without evaluation of the circumstances. Without info, it is called gambling. They are indeed good at evaluation, given the limited resources that they can apply at any time. However, as S/MIME does not provide any "circumstances" that suggest a reliable framework for agreements, it should drop the suggestion entirely. (Users as a mass have already rejected S/MIME as a signing framework, so this is more about protecting those users who might otherwise be mistaken or might otherwise be sold a product by their IT supplier.) Sure there's ultimate trust. I disagree. You are making trust decision only in a certain context. To avoid getting too philosophical a PKI-related example: You would trust your employer to issue certs for encrypting corporate business-related e-mails and even accept that the private keys are subject of key recovery/escrow within the company's context. You would probably not want to use these keys for personal communication exchanging intimate details of your private life. The problem is that there are as many points of ultimate trust as there are people. I'd argue that there even are many points of trust per person. ;-) But the trust model is not the main obstacle. Ciao, Michael. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Creating a Global User-level CA/Trust Infrastructure forSecureMessaging
Ian G wrote: Michael Ströder wrote: The root cause is that protecting e-mails is not enforced/endorsed within companies even if they have a working infrastructure. The lack of training is the consequence of this. OK, so would you agree that this is not very useful for the non-company people, like yours and my mum? If so, if we agree on that, we might also say "well, companies can look after themselves;" and/or "Mozilla has no offering suitable for secure email for ordinary users." Let me check that. I'll try to teach my friends to use S/MIME and see what happens. I don't know about you, but I'm here at Mozilla to get a solution to everyone. I appreciate that. Companies come second in my book, because they can pay. Probably, this is just a personal fetish of mine, and I don't mind being told that Mozilla doesn't agree. But currently, its mission seems to suggest that *all users* and especially non-corporate users are the ones that Mozilla targets. Agreed in the focus of Mozilla project. Right, but that doesn't change the underlying economic model: the use of S/MIME does not sustain itself. You need to put in fines or penalties or additional costs in order to make it work. Without that, it is not "economic". However, you always have to pay those fines/costs/penalties ... and these need to be balanced against the benefit of S/MIME. So even with the fees/rules/contracts, S/MIME is not economic until you have shown the benefit. This is a classical failing of the security world. Having established the absolute need for "secure X" we then run around and organise the business such that there are incentives to ensure "secure X". However, there is no particular analysis that it was worth the cost, because it is assumed to be "worth any cost". Well, I'd argue that the classic failing of the economic world is that it always wants to have a proof for monetary fines/costs/penalties of a risk. But there are other fines/costs/penalties too, especially for the non-corporate users. Additionally even when having a strictly economic view the real costs are never calculated exactly since the real world is too complex to come to a precise result. Security models are individual to businesses and individuals. They derive from threat to the persons, which again are peculiar to businesses and individuals. WYTM? Without walking that path, we are simply "protecting what we can" rather than "protecting the business." Yes, like in various other parts of our life. I know there is a thing called profiles, but where does one import & export them? By simply copying files? That's how I'm doing it. Right, this is out of scope for users. (And, sure, I have enough unix experience to figure it out too, but, these days I treat such a thing as a bug.) Then this would be a room for improvement of Mozilla products. Consider that most systems use password and username. This is *the standard* albeit defacto. To move this to a "personal key store on the net" scenario, we encrypt the private key with the password. Indeed, we encrypt the entire account store with the password. This way, we can log in from whereever and get access to the whole lot. The client downloads the encrypted store, decrypts it with the password, then extracts the private key. I know at least one commercial implementation of that roaming scheme with which I worked in a customer project. Hey presto, an application that is better than today's standard. As usual there are pros and cons. I'd consider this to be applicable for the corporate user, not our moms. And if you plan to implement such a thing for Mozilla be prepared to work around some patents. And most of my friends (non IT people) don't use webmail. They use MUAs on their PCs with POP3/SMTP. It is odd! There are two big groups here, with no real favourites. The market isn't giving us any clear signals. Yes, I vaguely remember having read some survey results (hope that's the right word) that European (especially German users) prefer having a MUA on their own PC. In contrary U.S. users preferring webmail. Maybe it's me but frankly I don't understand what you say here. Especially I don't see the need for a "UI vendor" to define a CPS (if Certificate Practice Statement is meant here). Not quite, what I mean here is that somehow, the user has to figure out what is happening. Yes. The PKI view is that this is done by referring to the CPS. No. How so? How do you define any use of certs without referring to the CPS or equivalent set of documents? You have to distinguish that the user is informed once what to do with a certain cert. Yes, that involves the CPS of the CA. Recall Nelson's view that he does not sign anything wit
Re: Creating a Global User-level CA/Trust Infrastructure forSecureMessaging
Ian G wrote: (Client side certs are a lot more ready for mass-deployment than S/MIME ones, but still have their foibles. One thing I discovered was that if you have multiple certs, the KCM is not so well developed in Firefox. It works if set to "choose-by-self," in which case we don't know which cert is in use. Or, if set to "ask-me", it asks me practically every click which to choose, and sometimes twice or thrice per click. If I had more time I'd chase the bugzilla.) I think these issues are mainly caused by misconfigured servers. Ciao, Michael. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Creating a Global User-level CA/Trust Infrastructure forSecureMessaging
Eddy Nigg wrote: On 12/04/2008 01:04 PM, Graham Leggett: httpd v2.3.0-alpha is to be tagged soon, which means SNI will start being available in a release very soon, and SNI will start getting some attention from end users. Just to reiterate, that the missing SNI support has been a pain for a huge number of web site operators needing to buy additional IP addresses for every secured web site. StartCom Linux released yesterday a patched version of Apache with SNI support (on the AS-5.0.2 release) and immediately available. It;'s hard to believe that such an important feature has been missing for so long for no apparent reason. The Apache project team is pretty unresponsive. I've filed an issue for what I consider a bug in mod_ssl together with a patch to fix NID/OID of attribute 'uid' in subject names: https://issues.apache.org/bugzilla/show_bug.cgi?id=45107 Status is still NEW...and will probably forever. Ciao, Michael. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Mozilla CA Certificate Policy - Useful?
Eddy Nigg wrote: On 12/05/2008 08:58 AM, Ian G: > When I lose a key, all the old encrypted email is no longer readable ... which presumably happens when revocation happens as well. For your protection, yes. ??? If the private key is no longer available, yes, encrypted data technically cannot be decrypted anymore. If the public-key certificate was revoked but the accompanying private key is still available you should be able to decrypt archived S/MIME messages just like when the public-key certificate expired. But a sender MUST not use your public-key certificate anymore for generating a new encrypted S/MIME message to you and you MUST NOT use it for generating a new digital signature anymore. Just like when the public-key certificate expired. If NSS is doing it differently I'd consider this a bug. I'd appreciate if NSS developers could shed some light on this. If in doubt this should be clarified (e.g. on ietf-smime mailing list). Ciao, Michael. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Mozilla CA Certificate Policy - Useful?
Ian G wrote: Michael Ströder wrote: Eddy Nigg wrote: On 12/05/2008 08:58 AM, Ian G: > When I lose a key, all the old encrypted email is no longer readable ... which presumably happens when revocation happens as well. For your protection, yes. ??? If the private key is no longer available, yes, encrypted data technically cannot be decrypted anymore. Note the decision here to store the email in private-key encrypted form, instead of (for example) cleartext or re-encrypting it with the master password. I think it's the right behaviour to store it with the key used to decrypt the message. Note that this key is not necessarily in the key3.db. It could be on a smartcard for which key recovery is enabled in the CA backend. Also note that you might have also lost your master password. There are also S/MIME-enabled MUAs which have another local storage policy. AFAIK the S/MIME standard does not mandate any policy for local storage of encrypted e-mail. This raises a lot of questions; why this implicit choice makes sense to a user, for example, and what happens when a key is lost: will the user ever return to using crypto ever again? If your MUA stores encrypted e-mail as is (like I prefer) you have to preserve the key history. That's not news and one can deal with it easily as discussed in my other postings. I concur that a profile backup/restore facility would be admirable for Mozilla products. I then started thinking about revocation, as the official way to "lose" the key, You don't loose your private key if the accompanying public-key cert was revoked and AFAIK it's not forbidden by any standard to use it to decrypt archived data. Only the validity status of the public-key cert is changed. Ciao, Michael. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Mozilla CA Certificate Policy - Useful?
Anders Rundgren wrote: Ian G wrote: Michael Ströder wrote: If the private key is no longer available, yes, encrypted data technically cannot be decrypted anymore. Note the decision here to store the email in private-key encrypted form, instead of (for example) cleartext or re-encrypting it with the master password. Yes, this is one of the weird things with S/MIME. You really wanted to encrypt the message during *transport* but as a "bonus" got it encrypted for *storage* as well. Personally I also prefer the MUA to do the latter. As practice showed I can keep my key history since 10 years now without any hassle (in my Linux home directory). There are S/MIME-enabled MUAs which implement local storage differently though. That's what I mean with "fundamentally broken architecture". Sorry, but this whole S/MIME bashing discussion leads me to think that the main "fundamentally broken" thing regarding S/MIME is the lack of practice of some of its critics. Ciao, Michael. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Creating a Global User-level CA/Trust Infrastructure for SecureMessaging
Anders Rundgren wrote:
That there should be as you claim mainly a "UI problem" is an opinion
that has some support in the literature ("Jonny can't encrypt"),
but I feel that it is much deeper than that; security should probably
as in the case of Skype be transparent, not needing any UI at all.
I start Skype and that's about it.
In the absence of further technical details about Skype I believe it's
probably symmetric encryption based on shared secrets derived from user
passwords similar to Kerberos. The main disadvantage and difference to
S/MIME with X.509-PKI is that you need online network access to a
central infrastructure to make use of it. That's ok for a phone
application or instant messenger but not necessarily for e-mail. (I
already pointed this out but you ignored it.)
Ciao, Michael.
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
