Re: Fwd: Time to dump NSS
On 2014-10-24 00:25, Daniel Veditz wrote: Forwarding to dev-tech-crypto where this is more on-topic. Dan, This is not really a cryptographic problem, it rather an platform architecture and strategy issue. This single-page presentation shows another part of the puzzle which clearly is outside of NSS: http://webpki.org/papers/key-access.pdf Regards, Anders Rundgren -Dan Veditz -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Fwd: Time to dump NSS
On 2014-10-24 07:11, Daniel Veditz wrote: Your subject, time to dump NSS, intimately affects NSS developers who will have to worry about replacing all the things NSS does for us before they can even start to think about the additional concepts. I fully understand that. If you're proposing a mechanism that can live on the side without actually dumping NSS then I suppose we can discuss it elsewhere, According to Paul T Mozilla have such discussions but they are not public (HW-vendors like to plot in secrecy) so it is not obvious how to go forward. I would consider a task-force. The idea is creating a new secure core based on a TEE like Apple and Google have. The new core would indeed have to support legacy APIs like NSS. but if it involves cryptography (how could it not?) then the tech.crypto group is the one the people who know about cryptography participate in. It would be a combination of crypto and OS architecture, perhaps like: http://webpki.org/papers/SKS-KeyGen2_FullStack.pdf There are several (sometimes competing) efforts within the W3 and IETF to create standards around concepts like key management. We're unlikely to implement a solution that doesn't get buy-in from other browser and server makers in that kind of forum. So far nobody has done anything even close to what I'm proposing. Well, Apple may have but they didn't take it to standardization yet. I believe that's very wise, complex stuff must mature in the real world first. I don't think an SDO can take on a project of this kind. SDOs only deal with partial solutions which is why we during the 20 years with credit-card payments on the web haven't moved one inch forward to make them Secure AND Convenient. Anyway, you wouldn't necessarily have to start from zero in case Mozilla feels that the groundwork me and my colleges have done could be useful. Regards, Anders Rundgren -Dan Veditz -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
The TPM is dead, long live the TEE!
Somewhat unfortunate for Microsoft and Intel who have bet the house on TPMs (Trusted Platform Modules), all their competitors in the mobile space including Google and Apple, have rather settled on embedded TEE (Trusted Execution Environment) schemes enabling systems like this: http://www.nasdaq.com/article/samsung-mobilesecurity-platform-to-be-part-of-next-android-20140625-00937 iOS: http://images.apple.com/iphone/business/docs/iOS_Security_Feb14.pdf How come the competition didn't buy into the TPM? TPMs are based on a one-size-fits-all security API philosophy. Since Intel relies on external vendors supplying TPM-components this (IMHO fairly unwieldy) API must also be standardized which makes the process updating TPMs extremely slow and costly. TEEs OTOH can be fitted at any time with application-specific security APIs which both can be standardized or entirely proprietary. In fact, even third-parties can crate new security APIs using GlobalPlatform's TEE! How about security? Since there is (generally) very little consensus on these matters, I should probably not dive too deep into this :-) Anders -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
EC support / PK11_ImportDERPrivateKeyInfoAndReturnKey
I'm trying to implement SKS/KeyGen2 in Firefox. This scheme is heavily based on EC keys. According to this file https://chromium.googlesource.com/chromium/chromium/+/master/crypto/ec_private_key_nss.cc PK11_ImportDERPrivateKeyInfoAndReturnKey doesn't support EC keys. This was reported 2006. Is there any usable workaround? My knowledge of NSS and P11 is quite limited Can you do a raw ECDH operation (return Z only) in NSS as supplied in Firefox? Anders -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Removal of generateCRMFRequest
On 2013-10-10 01:36, Nathan Kinder wrote: On 09/28/2013 12:17 PM, Brian Smith wrote: On Sat, Sep 28, 2013 at 7:52 AM, Sean Leonard dev+mozi...@seantek.com wrote: On 9/27/2013 5:51 PM, Robert Relyea wrote: I don't have a problem with going for an industry standard way of doing all of these things, but it's certainly pretty presumptuous to remove these features without supplying the industry standard replacements and time for them to filter through the internet. bob Why isn't keygen good enough? There is no support for key archival with keygen, which is supported by generateCRMFRequest. We heavily rely on generateCRMFRequest in Dogtag Certificate System (and Red Hat Certificate System), and key archival is one of the features that we use. I'm all for a standardized replacement, but it seems wrong to rip out something that has been a nice functional feature that people have come to rely on for many years before a replacement is available. Since keygen and generateCRMFRequest are 18 respective 12 years old this seems to be a rather reasonable request. I.e. we can not expect a suitable replacement until 2020 or so. Anders Thanks, -NGK Cheers, Brian -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Removal of generateCRMFRequest
On 2013-10-10 01:36, Nathan Kinder wrote: On 09/28/2013 12:17 PM, Brian Smith wrote: On Sat, Sep 28, 2013 at 7:52 AM, Sean Leonard dev+mozi...@seantek.com wrote: On 9/27/2013 5:51 PM, Robert Relyea wrote: I don't have a problem with going for an industry standard way of doing all of these things, but it's certainly pretty presumptuous to remove these features without supplying the industry standard replacements and time for them to filter through the internet. bob Why isn't keygen good enough? There is no support for key archival with keygen, which is supported by generateCRMFRequest. We heavily rely on generateCRMFRequest in Dogtag Certificate System (and Red Hat Certificate System), and key archival is one of the features that we use. I'm all for a standardized replacement, but it seems wrong to rip out something that has been a nice functional feature that people have come to rely on for many years before a replacement is available. Since keygen and generateCRMFRequest are 18 respective 12 years old this seems to be a rather reasonable request. I.e. we can probably not expect a suitable replacement until 2020 or so. Anders Thanks, -NGK Cheers, Brian -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: nickname for imported PKCS 12 from Firefox is called 'Imported Certificate'
snip Although currently Firefox doesn't display nickname to users in PSM, but in the near future, FirefoxOS (B2G) will need to display this (nickname) to the user, FirefoxOS needs a completely renovated PKI client in order to be competitive and useful. Issuer-defined Icons for credential GUIs is one of the many small things that are needed. The bigger issue is replacing the 19 year old keygen hack because keygen never worked for anybody but a handful of PKI geeks. Anders -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Should we create a Web API for importing PKCS 12
On 2013-05-15 11:35, Yoshi Huang wrote: Hi, Currently on Firefox OS (B2G), there's no Web API could install PKCS 12. The use cases could be Wifi, VPN,... etc. Some examples can be found on Android, see [1] Although I have found WebCrypto in the wiki and bugzilla, but it seems it didn't support pkcs12, right? Also I found that NSS would use XUL to show some UI (i.e. password) But XUL is definitely not a good opinion on Firefox OS. Firefox OS needs a completely revamped PKI-client, the existing PKI-client doesn't support BYOD, consumer-PKI or payments. The enrollment solution (keygen) is relic from 1995. Anders So my question is should we create some Web API for managine those certificates/pkcs12 .. etc ? or something like expose nsIX509CertDB.idl to the web? Thanks [1]: http://support.google.com/android/bin/answer.py?hl=enanswer=1649774 -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Removal of generateCRMFRequest
On 2013-04-08 14:52, helpcrypto helpcrypto wr ote: More generally, I would like to remove all the Mozilla-proprietary methods and properties from window.crypto; i.e. all the ones athttps://developer.mozilla.org/en-US/docs/JavaScript_crypto. Some of them are actually pretty problematic. Are there any worth keeping? signText() is used heavily by us. It would be a pity to miss it... . While awaiting to http://www.w3.org/TR/WebCryptoAPI/ Java applets for client signning, signText and keygen are needed. This seems to be out of scope: http://lists.w3.org/Archives/Public/public-webcrypto/2013Apr/0072.html Also things like Handling smart card events or Loading PKCS #11 modules is being use by many. So, you _CANT_ remove https://developer.mozilla.org/en-US/docs/JavaScript_crypto If you want/need more detailed discussions, dont hesitate to ask me. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Removal of generateCRMFRequest
On 2013-04-08 15:21, helpcrypto helpcrypto wrote: On Mon, Apr 8, 2013 at 12:10 PM, Anders Rundgren anders.rundg...@telia.com wrote: This seems to be out of scope: http://lists.w3.org/Archives/Public/public-webcrypto/2013Apr/0072.html Hi Anders. As it scopes signning: http://www.w3.org/TR/WebCryptoAPI/#Crypto-method-sign, I suppose you mean smartcards are out of scope. Until theres another alternative (dont you have one? :P), keygen and smartcard handling could/should remain the same. As you know, and as we have talked several times, we need something new/better, but until then, we need to continue supporting this. Maybe W3C Crypto Group should consider changing their scope to adopt/propose a new standard for all this? I think there is too much prestige and IPR associated for this to be realistic. Hordes of patent trolls are just waiting for suing the asses off Google and Microsoft. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Removal of generateCRMFRequest
On 2013-04-01 23:46, Brian Smith wrote: See https://bugzilla.mozilla.org/show_bug.cgi?id=524664 (bug 524664) and See https://developer.mozilla.org/en-US/docs/JavaScript_crypto/generateCRMFRequest My understanding is that keygen is supposed to replace window.crypto.generateCRMFRequest. I have no idea how common window.crypto.generateCRMFRequest is. Is it obsolete? The entire certificate system (including soft token storage) is obsolete. All big consumer-PKIs are deploying their own counterparts since ages ago. Now with mobile devices with embedded security hardware like in most high-end Android phones, there's a ocean-wide gap between the browser and platform. Should it be removed? Does anybody have a link to a site that is using it for its intended purpose? You cannot remove until there is an established replacement that matches the legitimate requirements people have on on-line certificate enrollment. Anders If it is obsolete, I would like to remove it ASAP. More generally, I would like to remove all the Mozilla-proprietary methods and properties from window.crypto; i.e. all the ones athttps://developer.mozilla.org/en-US/docs/JavaScript_crypto. Some of them are actually pretty problematic. Are there any worth keeping? Thanks, Brian -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Web Crypto API(s) and what Mozilla wants / needs
On 2013-02-21 09:22, helpcrypto helpcrypto wrote: So, to sum up: Will it be possible, using Web-Crypto API, to sign using a Pkcs#11 key/cert? What about MSCAPI key/cert? No. Will it be possible, using Web-Crypto API, to sign in batch-mode? Since your requirement was associated with giving a PIN once and PINs are not a part of the WebCrypto API the question doesn't really apply. Anders Thanks for answers! -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Web Crypto API(s) and what Mozilla wants / needs
On 2013-02-21 12:28, helpcrypto helpcrypto wrote: BTW, what is this? http://html5.creation.net/webcrypto-api/ These are the s.c. Korean Use-cases which have largely been ignored by the Web Crypto WG. Anders -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Batch Signatures. Was: Web Crypto API(s) and what Mozilla wants / needs
Will it be possible, using Web-Crypto API, to sign in batch-mode? Like this, I presume: http://www.secrypt.de/en/products/digiseal-office-pro I believe Germany is about the only country using such schemes. IMO it is based on an altogether weird interpretation and use of the EU signature directive which forces German companies to sign e-invoices as individuals, rather than by a server-hosted company stamp. This makes the use of batch signatures a necessity for electricity and telecom bills since these are issued in huge volumes. Needless to say Germany is way behind the rest of the world in secure e-invoicing. Anders -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Batch Signatures. Was: Web Crypto API(s) and what Mozilla wants / needs
On 2013-02-21 18:39, helpcrypto helpcrypto wrote: When we have to generate signed copies for a lot of documents (eg: student course certificates), we use our applet the following way: - step 1: authenticate and retrieve certificate to use - setp 2 (n times): sign using selected certificate Of course, there are risks of signing undesired documents, but thats another story. Obviously, our smartcard doesnt have the CKF_ALWAYS_AUTHENTICATE PKCS#11 flag. We do this A LOT, and this will be great (if possible) through javascript. Did I say I dont like using Java applets? In my opinion this is a perfect application for server-based signatures. What's needed is an authorization signature where a responsible person attests that he/she have verified the correctness of the input data that I guess is presented in web format. The attestation would be stored in the information system together with the student information. The student certificates would presumable be distributed in PDF format with the educational institution's signature. The attestation is only of interest for internal processes since the signing individual most likely is unknown by outsiders. There are also huge problems using employee certificates outside of the employer border while a legal entity (organization) certificate actually can be issued by TTPs. Anyway, the Web Crypto API doesn't address traditional signature applications. At least, I cannot see that based on the current draft. Anders On Thu, Feb 21, 2013 at 4:51 PM, Anders Rundgren anders.rundg...@telia.com wrote: Will it be possible, using Web-Crypto API, to sign in batch-mode? Like this, I presume: http://www.secrypt.de/en/products/digiseal-office-pro I believe Germany is about the only country using such schemes. IMO it is based on an altogether weird interpretation and use of the EU signature directive which forces German companies to sign e-invoices as individuals, rather than by a server-hosted company stamp. This makes the use of batch signatures a necessity for electricity and telecom bills since these are issued in huge volumes. Needless to say Germany is way behind the rest of the world in secure e-invoicing. Anders -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Web Crypto API(s) and what Mozilla wants / needs
On 2013-02-15 09:46, helpcrypto helpcrypto wrote: snip IMHO, once we have a pkcs#11 interface to handle any smartcard, even installed cert using NSS softoken, and maybe a wrapper to mscapi...the only thing left is to use those certs stored somewhere with your javascript API. The problem with this approach is that you expose keys to arbitrary javascript code which is rather different to for example TLS-client-certificate authentication which only exposes a high-level mechanism as well as a [reasonably] secure credential filtering scheme and user GUI. I.e. we need something similar to your current signed java applets in order to enable web-based javacript access to keys in NSS et al. I have proposed using the model used in Google Wallet which is signed code with a twist: It is not the platform (or you) that trusts the code, it is the security resource. Traditional signed code is IMO rather lame since anybody can buy a valid code-sign certificate. I.e. a code signature from someone you never heard about is doesn't add much to the table. Anders -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Web Crypto API(s) and what Mozilla wants / needs
On 2013-02-15 11:32, helpcrypto helpcrypto wrote: The problem with this approach is that you expose keys to arbitrary javascript code which is rather different to for example TLS-client-certificate authentication which only exposes a high-level mechanism as well as a [reasonably] secure credential filtering scheme and user GUI. clear as water. Shouldnt we be able to expose key handles rather than keys? Yes, that's was the intention. ie: javascript invoke getKeyFromPKCS11(modulename) and #1 is returned, but can be used. How do you envision that this access should be controlled? Here imagine that you have dozens of keys, not just a single key in a smart card. A difference to keys compared to for example your location (which is exclusively your resource) is that keys in most cases are given to users by external providers. The providers do not want their keys to be misused, particularly not by users who accidentally made the wrong trust assertion. A scheme that doesn't take this in account IMO has little chance of getting market acceptance. In my professional life I deal with PKIs for EAC (Extended Access Control) which is used in e-passports for selective access to biometric information. Using EAC it is the *passport* that grants access based on credentials provided by the inspection systems so what I'm proposing is by no means a novelty; it just haven't reached the web. Yet. Anders Traditional signed code is IMO rather lame since anybody can buy a valid code-sign certificate. I.e. a code signature from someone you never heard about is doesn't add much to the table. Agree -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Web Crypto API(s) and what Mozilla wants / needs
On 2013-02-15 06:38, Martin Paljak wrote: Hello, On Thu, Feb 14, 2013 at 5:48 PM, David Dahl dd...@mozilla.com wrote: I do understand the frustration you must feel in trying to get browsers to work closely with your national ID/Cert system. There are many such systems, and trying to create an API that works with your specific requirements, hardware and regulations is very difficult. The WG notes this by placing such efforts in the WG's secondary features. This is a shame, but it is also a bit of realism as getting caught up in multiple varying national schemes may have stunted progress on a more generic API, which I feel is a first priority. Given that I'm a citizen of a country that has a national ID system and I've also had to/tried to make browsers (including Firefox) work closely with it, I'd like to ask this controversial question: Maybe creating a PKCS#11 for javascript will not fix anything, except create a new fantastic attack vector and source for mitm/timing attacks? Maybe analyzing the higher level implementations would actually reveal requirements (legal and operational), when catered for would actually benefit a fair amount of users? Given that usecases of a citizen don't differ that much from average corporate users, the work would most probably be useful to two important groups: corporate users and average home users. Hi Martin, As far as I can tell, the current Web Crypto API doesn't address national eID-cards at all. IMO, the most workable (security + privacy + usability) solution for such support requires dropping arcane stuff like PKCS #11 and NSS and turning to more current security-architectures, like the one powering the Google Wallet, where the security-resource itself declares which applications are allowed to access it. By doing that you don't get separate tracks for apps and the web and you will also be able to provision and manage security-resources through unified mechanisms. This obviously requires signed application-code and that the crypto API runs as a part of the OS or in a specific TEE (Trusted Execution Environment). Anders The fact that in browser world only Firefox depends on PKCS#11 and thus lags behind in features and interoperability on platforms where more useful and serious API-s are present is a sign that *maybe* PKCS#11 really is just a low level plumbing API for scenarios where plumbing matters (maybe HSMs, but deficiencies and proprietary solutions are not su uncommon there as well). In fact, I think that the most ambiguous standards/specifications I've worked with are PKCS#11 (where most interesting things are left out of the scope) and ISO7816 and friends, where most is optional and choices to choose from are plenty. Users choose a working tap over interoperable plumbing elements. Maybe trying to design a tap instead of plumbing joints would be a better idea. I think that plumbers would also like it. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Alternative pinning scheme. Re: Proposing: Interactive Domain Verification Approval
On 2012-12-31 16:18, Kai Engert wrote:
I propose to more actively involve users into the process of accepting
certificates for domains.
If we get away from garbage like keygen, PKI-based authentication
becomes a natural feature for mobile devices. This in itself render
the mentioned attacks much less useful. If you to that add an optional
X.509 extension holding a trust list, the client won't even allow you
to login to the fake site.
Anders
I envision a UI where users are required to approve once, whether the
combination of a CA and a domain is acceptable to the user.
The following UI would be shown whenever a user starts a connection to a
secure site, and the site uses a CA that has not yet been approved for
the respective domain (or if the uses a fresh computer or a fresh
browser profile).
The following UI would only be shown, if the certificate can otherwise
be correctly chained up to a trusted CA - the scenario that we currently
allow to proceed automatically.
Inline comments regarding the UI are wrapped using .
==[begin UI]==
You are trying to open a secure connection to a remote site:
www.my-bank.xy
A connection can be secure, if the remote site can proof to be the
legitimate owner of the site.
The remote site claims to be:
Organization = My Bank
Name = www.my-bank.xy
Locality = My City, Counry = XY
[view complete site certificate]
The site presented a certificate from this Certificate Authority (CA):
Organization = A trustworthy CA
Organizational Unit = Class n Certification Authority
Country = XY
[view complete CA certificate]
for domain validation certs
The CA claims to have verified that an owner of the domain is operating
the remote site.
for extended validation certs
The CA claims to have verified the identity of the operator of the
remote site, based on business registration documents, to be the
registered owner of the site.
Do you trust the Certificate Authority to have correctly verified the
remote site, and that the verification is sufficient for your security
needs?
user must make a choice, or the connection won't proceed
( ) yes, for all sites in top level domain “.xy”
( ) yes, for all sites in domain “my-bank.xy”
( ) yes, for all sites in domain “www.my-bank.xy”
(*) no, don't connect
[ remember choice and continue ]
the system will remember the selected association of {CA, domain}
future, different combinations of {CA, domain} will require anther
confirmation
==[end of UI]==
Crossposted to dev-security.
Please follow-up to dev-tech-crypto@lists.mozilla.org
Thanks and Regards,
Kai
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
Secure credit-card payments? Re: Proposing: Interactive Domain Verification Approval
On 2012-12-31 16:26, Kai Engert wrote:
I propose to more actively involve users into the process of accepting
certificates for domains.
Although the recent CA failures cast a shadow over the web they have AFAIK
not led to any major losses for anybody.
The credit-card system OTOH is a major source of losses and hassles.
IMO the only parties that can fix it are the browser vendors.
In the EU and Asia hundreds of millions of EMV-cards are in circulation
but since there is no useful system on the Internet these cards are
still equipped with mag-strip and CCV passwords printed in clear on the back
of the cards which makes them subject to attacks in spite of the chip.
What's Mozilla's take on this?
Anders
I envision a UI where users are required to approve once, whether the
combination of a CA and a domain is acceptable to the user.
The following UI would be shown whenever a user starts a connection to a
secure site, and the site uses a CA that has not yet been approved for
the respective domain (or if the uses a fresh computer or a fresh
browser profile).
The following UI would only be shown, if the certificate can otherwise
be correctly chained up to a trusted CA - the scenario that we currently
allow to proceed automatically.
Inline comments regarding the UI are wrapped using .
==[begin UI]==
You are trying to open a secure connection to a remote site:
www.my-bank.xy
A connection can be secure, if the remote site can proof to be the
legitimate owner of the site.
The remote site claims to be:
Organization = My Bank
Name = www.my-bank.xy
Locality = My City, Counry = XY
[view complete site certificate]
The site presented a certificate from this Certificate Authority (CA):
Organization = A trustworthy CA
Organizational Unit = Class n Certification Authority
Country = XY
[view complete CA certificate]
for domain validation certs
The CA claims to have verified that an owner of the domain is operating
the remote site.
for extended validation certs
The CA claims to have verified the identity of the operator of the
remote site, based on business registration documents, to be the
registered owner of the site.
Do you trust the Certificate Authority to have correctly verified the
remote site, and that the verification is sufficient for your security
needs?
user must make a choice, or the connection won't proceed
( ) yes, for all sites in top level domain “.xy”
( ) yes, for all sites in domain “my-bank.xy”
( ) yes, for all sites in domain “www.my-bank.xy”
(*) no, don't connect
[ remember choice and continue ]
the system will remember the selected association of {CA, domain}
future, different combinations of {CA, domain} will require anther
confirmation
==[end of UI]==
Crossposted to dev-security.
Please follow-up to dev-tech-crypto@lists.mozilla.org
Thanks and Regards,
Kai
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
2013: keygen R.I.P.
During the Netscape heydays keygen was probably pretty OK. However, that was a long time ago. In fact, keygen only meets a single of the dozen+ imaginable features outlined here: http://webpki.org/papers/PKI/certenroll-features.pdf For the PC platform which seems to resist all modernization efforts in this space (probably due to the Wintel hegemony plus the inability of the smart card community creating anything Internetish), there's little point in upgrading stuff; this request is dedicated to the always connected, mobile devices which primarily rely on embedded platform capabilities. Although swapping keygen for something else has indeed been proposed. IMO, that wouldn't help much because the underpinnings like NSS is also in need of renovation. The somewhat bigger question is thus whether NSS should be upgraded or of it (as I propose) should be complemented with *another* API for provisioning. The primary reason why I think the latter is a better idea is that credential provisioning security-wise should operate one level down in the stack compared to credential usage. Proof: The Google Wallet doesn't utilize on NSS/keygen-like technology for provisioning, it rather builds on (according to unverified sources...) GlobalPlatform's SCPnn. Anders -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: PSM module ownership, switching my focus to NSS
On 2012-12-13 17:10, Kai Engert wrote: Brendan Eich suggested posting to this list, too (already posted yesterday to Mozilla's dev-planning list). Hello Mozilla, I'd like to announce a change. PSM is the name of Mozilla's glue code for PKI related [1] security features, such as certificate management, web based certificate enrollment, tracking the security state of web pages (padlock/EV), application preferences for certificate validation, SSL error reporting, handling of certificate exceptions, user interface for SSL client authentication, etc. After having contributed to this module for over 11 years, it's time for me to step down from the PSM module ownership role. The new module owner of PSM will be Brian Smith. I've switched my main focus to the NSS security libraries [2], and to PKI features across Linux applications in general. So will Linux eventually get a crypto system that runs as a protected/OS-level process like Android's KeyChain or is this functionality supposed to be supplied through GKR? PSM operates on top of NSS, thereby I'll continue to indirectly contribute to Mozilla's projects. I'd like to thank the people who have contributed to the PSM module over time, and I'd like to thank my employer Red Hat, Inc., which has allowed me to make PSM a priority during the previous 7 years and continues to support my work on NSS. Regards Kai [1] http://en.wikipedia.org/wiki/Public_key_infrastructure [2] https://developer.mozilla.org/en-US/docs/NSS -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: PSM module ownership, switching my focus to NSS
Hi Julien, What is Oracle's interest in NSS? IMO, NSS and JDK are behind the rest of the crypto world due to the lack of integration with the target OS. It is possible that this is a no-issue for server-companies like RedHat but for Mozilla OS it spells disaster. That is, cryptographic keys should be access-controlled by the OS regardless if the key resides in a file or in a machine. With OS-level access-control you can eventually add an application-discriminator as well. I believe the latter is more or less a prerequisite for supporting a GlobalPlatform-like SE: http://code.google.com/p/seek-for-android/wiki/AccessControlIntroduction I believe this is featured in the Google Wallet. Trusted GUIs for PIN-codes is also a part of such a plot. Can trusted GUI's be spoofed? Yes, but with a properly designed platform it doesn't really matter because the crypto module won't care about PINs supplied through other means if that is the policy set on the key. This obviously requires that the crypto stuff runs in a trusted process rather than in a user context. Anders On 2012-12-14 03:35, Julien Pierre wrote: Hi Kai, Good to see you stick around in the Mozilla crypto world . Are there big projects coming up in NSS land ? Or did somebody leave the project ? Thanks, Julien On 12/13/2012 08:10, Kai Engert wrote: Brendan Eich suggested posting to this list, too (already posted yesterday to Mozilla's dev-planning list). Hello Mozilla, I'd like to announce a change. PSM is the name of Mozilla's glue code for PKI related [1] security features, such as certificate management, web based certificate enrollment, tracking the security state of web pages (padlock/EV), application preferences for certificate validation, SSL error reporting, handling of certificate exceptions, user interface for SSL client authentication, etc. After having contributed to this module for over 11 years, it's time for me to step down from the PSM module ownership role. The new module owner of PSM will be Brian Smith. I've switched my main focus to the NSS security libraries [2], and to PKI features across Linux applications in general. PSM operates on top of NSS, thereby I'll continue to indirectly contribute to Mozilla's projects. I'd like to thank the people who have contributed to the PSM module over time, and I'd like to thank my employer Red Hat, Inc., which has allowed me to make PSM a priority during the previous 7 years and continues to support my work on NSS. Regards Kai [1] http://en.wikipedia.org/wiki/Public_key_infrastructure [2] https://developer.mozilla.org/en-US/docs/NSS -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
NSS in Firefox OS
I've heard about the Firefox OS but haven't been able to find much information about the internals, at least not the crypto-part. Anyway, I guess that Firefox OS uses NSS? Is it still is based on the idea that key access is done in the application context rather than through a service? Anders -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
W3C takes on Web+SecurityElements
http://www.w3.org/2012/09/sysapps-wg-charter http://www.linkedin.com/redirect?url=http%3A%2F%2Fwww%2Ew3%2Eorg%2F2012%2F09%2Fsysapps-wg-charterurlhash=Tqzg_t=tracking_disc Since the smart card industry have never managed making their stuff web compatible before, I assume they will fail this time as well. Anders -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: JSS library and parsing CMS
Kid Alchemy,
This is the wrong list for BouncyCastle questions!
-Anders
Anyway, here is an extract from code that I use (I'm not an expert of CMS):
import org.bouncycastle.cms.CMSException;
import org.bouncycastle.cms.CMSProcessableByteArray;
import org.bouncycastle.cms.CMSSignedData;
import org.bouncycastle.cms.SignerInformation;
public class VerifyProxy
{
public byte[] getAndVerifySignedData (byte[] signedData,
ListX509Certificate caCerts) throws SignatureException, CMSException,
IOException, GeneralSecurityException
{
CMSSignedData csd = new CMSSignedData(signedData);
CertStore certs = csd.getCertificatesAndCRLs(Collection, BC);
SignerInformation signer = (SignerInformation)
csd.getSignerInfos().getSigners().iterator().next();
Collection? extends Certificate certCollection =
certs.getCertificates(signer.getSID());
X509Certificate cert = (X509Certificate)
certCollection.iterator().next();
if (!signer.verify(cert.getPublicKey(), BC)) {
throw new SignatureException (Signature Error);
}
for (X509Certificate caCert : caCerts) {
if (cert.getIssuerX500Principal().getName
().equals(caCert.getSubjectX500Principal().getName ())) {
cert.verify(caCert.getPublicKey());
CMSProcessableByteArray cpb = (CMSProcessableByteArray)
csd.getSignedContent();
byte[] signedContent = (byte[]) cpb.getContent();
return signedContent;
}
}
throw new SignatureException (No CA key matching: +
cert.getIssuerX500Principal().getName());
}
2012-09-14 15:51, KidAlchemy wrote:
On Friday, August 17, 2012 5:44:40 AM UTC-4, Anders Rundgren wrote:
On 2012-08-15 21:35, KidAlchemy wrote:
On Thursday, August 9, 2012 10:26:12 AM UTC-4, KidAlchemy wrote:
I want to use the JSS library just to parse the CMS package into the
specific structures that are provided by JSS. I can get the signedData,
then I call signedData.getContentInfo(), which gives me the
encapsulatedContentInfo populated structure and this works fine.
The problem: The encapsulatedContentInfo now contains a
id-ct-KP-encryptedKeyPkg. How do I proceed with my parsing from here? The
encapsulatedContentInfo.getContent() returns an OCTET_STRING but I dont
know what to do with it from here.
Can you provide some code examples in Java for me?
Anyone have a clue?
Yes, DO NOT use JSS if you want to consume (parser) cryptographic messages.
JSS is essentially unsupported. BouncyCastle has the stuff you are looking
for.
Can you answer this...why cant I find an example that starts from the
beginning, meaning reading in a whole CMS package and use JSS and bouncy
castle to parse it?
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Update on Intel's Identity Protection Technology
On 2012-08-22 00:38, Julien Pierre wrote: Julien, On 8/21/2012 00:45, Anders Rundgren wrote: On 2012-08-21 05:42, Julien Pierre wrote: Anders, On 8/14/2012 20:40, Anders Rundgren wrote: http://communities.intel.com/community/vproexpert/blog/2012/05/18/intel-ipt-with-embedded-pki-and-protected-transaction-display Apparently your next PC already has it. Some PCs based on Intel chips may have it. A few of us out there do not use Intel chips. I guess Intel is still testing the waters which I think is a good alternative to politically, commercially and technically awkward standardization efforts that seem to take forever and in the end often are circumvented by other developments in the market. Been there, done that :-) True enough. But I still can't get very enthusiastic about this. We live in a world with so many different devices, not just PCs. These mobile devices do not run Intel chips either. You are right. If there had been a standard things would have been easier but there's none and therefore I'm happy at least that a major vendor does an effort to move something that has been in in deadlock forever. It is rather a replacement for passwords. Embedded credentials is the thing that will at last/finally make client-side PKI a main-stream authentication solution. That's fine if you only plan on ever logging in from the one device that has the credentials embedded. It seems a bit restrictive. Unless you always have that device with you. In which case it's probably a smartphone, not a PC. The only solution I can think of is that each of the devices is fitted with the embedded credentials needed for using them. In fact, you can use device (or card) as secure bootstrap for a credential clone to another device using a *self-service process*. This principle has already been used by many millions of Swedish citizens to enroll soft certificates (embedded) on their PCs. Currently they are using proprietary software since the US SW giants never managed creating a useful enrollment system, not to mention a standard. Anders Julien -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: JSS library and parsing CMS
On 2012-08-15 21:35, KidAlchemy wrote: On Thursday, August 9, 2012 10:26:12 AM UTC-4, KidAlchemy wrote: I want to use the JSS library just to parse the CMS package into the specific structures that are provided by JSS. I can get the signedData, then I call signedData.getContentInfo(), which gives me the encapsulatedContentInfo populated structure and this works fine. The problem: The encapsulatedContentInfo now contains a id-ct-KP-encryptedKeyPkg. How do I proceed with my parsing from here? The encapsulatedContentInfo.getContent() returns an OCTET_STRING but I dont know what to do with it from here. Can you provide some code examples in Java for me? Anyone have a clue? Yes, DO NOT use JSS if you want to consume (parser) cryptographic messages. JSS is essentially unsupported. BouncyCastle has the stuff you are looking for. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Update on Intel's Identity Protection Technology
On 2012-08-15 18:53, Price, Bill wrote: Although the details are sketchy, it appears that the scheme can be used with other OS's and PKIs. Intel appears to have provided hooks. There's apparently an MS CAPI visible provider for the hardware/firmware module. Any plans to provide an NSS/PKCS 11 interface for Linux, MAC, Windows operating systems? A private message from an Intel employee indicates that not even under Windows you cannot use any CA without arrangements with Intel. Using NSS/PKCS #11 seems even more distant since its inferior browser companion, keygen doesn't support PIN-codes, client-key agility, issuer conformation, etc. Anders -Original Message- From: dev-tech-crypto-bounces+wprice=mitre@lists.mozilla.org [mailto:dev-tech-crypto-bounces+wprice=mitre@lists.mozilla.org] On Behalf Of Anders Rundgren Sent: Tuesday, August 14, 2012 11:41 PM To: mozilla's crypto code discussion list Subject: Update on Intel's Identity Protection Technology http://communities.intel.com/community/vproexpert/blog/2012/05/18/intel-ipt-with-embedded-pki-and-protected-transaction-display Apparently your next PC already has it. What's missing is a provisioning facility for unleashing the power of this scheme so that it isn't limited to one OS, one CA (?), and Enterprises. Anders -- 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
Update on Intel's Identity Protection Technology
http://communities.intel.com/community/vproexpert/blog/2012/05/18/intel-ipt-with-embedded-pki-and-protected-transaction-display Apparently your next PC already has it. What's missing is a provisioning facility for unleashing the power of this scheme so that it isn't limited to one OS, one CA (?), and Enterprises. Anders -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Intel Identity Protection Technology with PKI
http://www.intel.com/content/www/us/en/architecture-and-technology/identity-protection/public-key-infrastructure.html Like most HW-security solutions this appears to be more or less secret... Anders -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: VISA drops the password and replaces it with - NOTHING
On 2012-08-02 22:16, David Woodhouse wrote: On Wed, 2012-08-01 at 11:58 +0200, Anders Rundgren wrote: http://www.finextra.com/news/announcement.aspx?pressreleaseid=45624 Current platforms are useless for banking so what else could they do? The big problem with the VbV insanity wasn't the current platforms. It was largely the user experience — a frame in the browser, where they can't *tell* that it's actually from a trusted site; it appears in a page that's on the untrusted merchant site. Into which you're expected to type parts of your password. Any sane person refused to use it anyway, surely? True, but a fundamental problem still remains in the platform. If you use PKI instead of a password a fraudster doesn't get anything he/she can use to emulate the card-holder. However, consumer-PKI using the Mozilla platform is simply put unusable. When platform vendors get interested in a solution great things can happen: http://googlecommerce.blogspot.co.uk/2012/08/use-any-credit-or-debit-card-with.html That nothing of this kind happens in Mozilla PKI is because there is no business, not because they have bad or lazy engineers. I also think that the lack of hardware security limits the scope of the platform considerably. Intel has a role to play but I guess the bean counters say no :-( Anyway, the action isn't really here, it is there: http://googlecommerce.blogspot.co.uk/2012/08/use-any-credit-or-debit-card-with.html Google becomes a bank and you have your cards in their cloud! Lots of very useful security stuff as well. Anders VbV was just another case of banks actively *training* their customers to succumb to fraud. Just like when they send non-S/MIME-signed email. I'm pleased to see it being phased out, at least in its current form. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: VISA drops the password and replaces it with - NOTHING
On 2012-08-02 13:22, Jean-Marc Desperrier wrote: Anders Rundgren a écrit : http://www.finextra.com/news/announcement.aspx?pressreleaseid=45624 Current platforms are useless for banking so what else could they do? What role does the password serve here, except forcing me to create an unrequired account by every merchant I decide to use ? 3D Secure/VbV is a kind of federation system where a payment request is routed to your bank/issuer which vouches for that you are an authentic card-holder. Here VISA dropped the password requirement and thus in fact the whole routing/vouching scheme. I.e. the global VISA standard for Internet payments is using a user id (Card number) plus password (CCV) distributed in clear on plastic cards. Going back to the platform, keygen simply doesn't cut it, never did. In Asia and Scandinavia the banks therefore deploy their own PKI clients. Anders -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
VISA drops the password and replaces it with - NOTHING
http://www.finextra.com/news/announcement.aspx?pressreleaseid=45624 Current platforms are useless for banking so what else could they do? Anders -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Shared system database
I think you need to take a step back and consider which
market and user-base you are targeting. Linux on the
desktop? Why bother with that? Linux servers? Well,
*that* could be interesting. Unfortunately it doesn't
help much since most servers run JBoss etc so it is
actually more a JDK problem. Although JBoss can use
NSS I bet essentially nobody use it.
Regarding per-application storage of private keys, Android
solved that by creating a specific user for each app.
Anders
On 2012-07-27 10:03, David Woodhouse wrote:
On Thu, 2012-07-26 at 14:13 -0700, Robert Relyea wrote:
Error verifying signature
parse error
--ms050908010406000106010405
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
(Want to investigate that off-list, or is it expected mailman breakage?
My own S/MIME signed posts seem to have survived unscathed, but the
actual signature part was missing from yours.)
So what I actually want is
- To fix the API to the NSS system database so it isn't insane.
Do you have any suggestions on how the API would be changes. One thing=20
I'm always fighting is providing an API for apps without breaking=20
existing apps.
Well, *not* having to grub around for 'library=libnsssysinit.so'
in /etc/pki/nssdb/pkcs11.txt in order to decide whether to open
sql:/etc/pki/nssdb or sql:$HOME/.pki/nssdb would be my main request.
One idea might be to just for the use of NSS system DB under the covers. =
We can control this from some sort of outside control (like an=20
environment variable). There is an issue about what the default should=20
be (on or off). Since NSS can open more than one database, we can open=20
the database the user requested as well. This would also mean apps will=20
start using the NSS system DB without requiring applications to change.
That sounds ideal to me. In the general case, if a system database has
been set up in /etc/pki/nssdb by the {sysadmin,distribution}, it should
be used. If not, it shouldn't. The default behaviour, if it's *there*,
should be to use it. With an environment variable to override that.
You may be thinking in a different direction, I would be interested in=20
hearing your ideas.
I'd also pondered allowing a NULL argument as the dbpath to NSS_Init(),
to indicate that the default database should be opened.
- To fix Firefox, Thunderbird and the NSS samples to use it correctly=
=2E
Legacy is what has been holding FF and TB back. It would be relatively=20
easy to get FF or TB to use the sqlite database. It's been a real bear=20
trying to get anyone to work on doing database migration.
Well, if we allow the old database to be used as a third slot, perhaps
we don't *need* to migrate. For per-application private keys, we're
going to need a private database in addition to the system-wide and
user-wide ones anyway, right?
So how about automatically opening not only /etc/pki/nssdb as a separate
slot if that directory has a database in it, but *also* ~/.pki/nssdb. So
firefox et all would just continue to open their legacy database, but
automatically pull in the trusted CAs and any private keys which are
installed in the other databases.
- To go on a bombing run across all other NSS-using applications to
fix those too (I've done Evolution already, but it'll need fixing
once the API is made saner and it doesn't need to go grubbing aroun=
d
in /etc/pki/nssdb/pkcs11.txt to work out what DB path to open.
- To make the 'combined' system and user trust databases (two slots
in the same token)
I'm not sure about your terminology here. Slots are locations for tokens =
to be plugged into (mapping to the PKCS #11 slots, which usually refer=20
to physical readers). Do you mean 2 slots in the same module?
Sorry, yes. I mean 2 slots in the same module. I've managed to access
*one* or the other of ~/.pki/nssdb and /etc/pki/nssdb by loading the
softokn module via p11-kit, but not both.
If we go for the automatically open the extra slot option that you
suggested, I think this problem just solves itself.
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Shared system database
Unifying trust and even more private key storage has reasonable solutions in other operating systems. These solutions make sense for app-developers to use. I don't think that a quick fix can compensate for the more over-arching issue which really is a lack of product management. Fixing JDK would be great but it won't happen because there is nothing to connect to in the *NIX world. This forced Google inventing a new key-store scheme (and lots of other non-JDK stuff as well), which caused a major split in the Java world. It is possible that playing with lib*.so or sqllite can make a difference but personally I think it just a waste of cycles. That Apple trow out Tokend is an example of that there's something is really wrong here. Apple IMO did the right thing, smart cards simply doesn't work for normal users. Anders On 2012-07-27 11:03, David Woodhouse wrote: On Fri, 2012-07-27 at 10:53 +0200, Anders Rundgren wrote: I think you need to take a step back and consider which market and user-base you are targeting. No, I believe that's been clear from the beginning. Apologies if I didn't make it explicit enough. Linux on the desktop? Why bother with that? Linux distributions in general. I'll treat the second cited question as a rhetorical one. Linux servers? Well, *that* could be interesting. Unfortunately it doesn't help much since most servers run JBoss etc so it is actually more a JDK problem. I did explicitly mention that the intention is to achieve consistency of the trust database across SSL implementations (including OpenSSL, GnuTLS, etc.). Yes, I suppose Java should be included in that, although I may leave that as an exercise for someone else. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Intel Identity Protection. Was: Shared system database
I won't bother you more on this topic but I honestly do not think that there will be any progress worth mentioning (particularly on the fragmented OSS side) until Intel comes out with a open version of: http://ipt.intel.com I hope to make it easier for Intel by doing things in the opposite way, establishing a SW implementation that is designed for HW execution. Anders -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Shared system database
I think the lack of progress [*] here has a lot to do with the fact that there's really nothing to gather around. Making security solutions for security-conscious people is probably quite fun but since this only addresses a tiny fraction of the market the urge for consolidation seems pretty limited. The Gold Standard for Internet-payments is still after more than 15 years with on-line banking using Card Numbers and CCVs printed in clear on plastic cards. IMO, the only way to change this would be to introduce secure key-store primitives in the CPU; then there would finally be something to focus on! The only fly in the soup is that there's no paying customer out there which is one reason why this market has been largely ignored. Personally I don't see the problem; the money is in the services. 0.05 mm2 of silicon real estate is probably all that it takes. Smart cards is for the 1% market. br ar *] For the *NIX community it might be reassuring to know that not even the latest Android- and iOS-releases support deployment of two-factor authentication tokens. Nobody (AFAIK at least) use the built-in enrollment solutions for mobile banking On 2012-07-24 16:23, David Woodhouse wrote: On Tue, 2012-07-24 at 16:12 +0200, Anders Rundgren wrote: IMO, this is not an NSS issue, it is rather a *NIX issue. All other operating systems (that I'm aware of NB...) including *NIX-derivates like Android, already have a system-wide cryptographic architecture. Yes. It's an issue I'm actively trying to solve. NSS seems to have made some *attempt* at solving it... which has some issues, and which doesn't even seem to have been picked up by Mozilla's own products. I'm trying to work out whether I should attempt to fix what NSS has and build on top of it, or whether it should just be discounted as a bad idea and I should do something completely different. I'd *prefer* to get something based on the NSS sysdb to work, and make it work in GnuTLS/OpenSSL/etc via PKCS#11. But that's just my initial prejudice. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Shared system database
IMO, this is not an NSS issue, it is rather a *NIX issue. All other operating systems (that I'm aware of NB...) including *NIX-derivates like Android, already have a system-wide cryptographic architecture. Most (if not all) of these builds on services rather than libraries. Anders On 2012-07-24 15:07, David Woodhouse wrote: Is the NSS shared system database actually going to be used for real? I note Firefox *still* isn't using it, four years after bug 449498 was opened. If even Mozilla products aren't using NSS properly, do we really expect anyone *else* to? And what does properly mean, anyway? As far as I can tell, the only way an application can *tell* whether the shared database is set up on the system is to open /etc/pki/nssdb/pkcs11.txt and search for 'library=libnsssysinit.so' in it. Based on the result of that search, the application then opens sql:/etc/pki/nssdb or sql:$HOME/.pki/nssdb. Which is just evil. It seems that the shared system database isn't really complete, and isn't particularly well-thought-out. Is there scope for changing it? For example, is there a reason that things weren't done the other way round? Why couldn't the softokn module just automatically load the contents of /etc/pki/nssdb as an extra read-only slot, regardless of which directory the application gave as its primary store? Surely that would have been easier? I've also been looking at how to consolidate the trust database with other SSL libraries, such as OpenSSL and GnuTLS. GnuTLS can load the NSS softokn as a PKCS#11 module, and access *one* database, although there's a bit of work to be done on understanding the trust assertions. But I can't see how to get the softokn module loaded from p11-kit with *both* slots available. Is that possible? Again, if we switch things around so that you just load sql:/$HOME/.pki/nssdb and the additional slot is automatically loaded from /etc/pki/nssdb *if* a database exists there, this may all just work... is that something we can consider? -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Building and running NSS for Android.
Ian, Pardon me if I was a bit terse in my response. What I meant was simple that Operating Systems manage critical resources but only occasionally keys. That is, access to persistent keys should only be done through OS calls like it has been the case for files since at least 40 years back. However, keys have other properties than files but that still don't make the concept bad; just different. Example: A key may be owned by a user but it might still not be granted access by all the user's applications because the key is (in most cases) provided by another party. NSS and JDK seems to be severely lagging in this respect. I don't think porting NSS to Android necessarily is a prerequisite for porting Firefox to Android. IMO, it is rather a disadvantage with multiple keystores and systems. Anders On 2012-07-06 12:54, Anders Rundgren wrote: On 2012-07-06 10:29, ianG wrote: On 6/07/12 16:14 PM, Anders Rundgren wrote: On 2012-07-06 01:51, Robert Relyea wrote: I've gotten NSS to build and mostly run the tests for Android. Cool! There are still a number of tests failing, so the work isn't all done, but it was a good point to snapshot what I had. How does this compare/interact with Android's built-in key-store? I'm personally unconvinced that security subsystems running in the application's/user's own security context represent the future since they don't facilitate application-based access control unless each application does its own enrollment. The way I see this is that security subsystems running in the app/user's own security context is sub optimal for development cost purposes. And, ??? running in the platform's security context is sub optimal for security motives. I'm not sure I understand the rationale here. Where the sweet spot is tends to vary and isn't really a universally answerable question. Anders iang -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Building and running NSS for Android.
On 2012-07-06 01:51, Robert Relyea wrote: I've gotten NSS to build and mostly run the tests for Android. There are still a number of tests failing, so the work isn't all done, but it was a good point to snapshot what I had. How does this compare/interact with Android's built-in key-store? I'm personally unconvinced that security subsystems running in the application's/user's own security context represent the future since they don't facilitate application-based access control unless each application does its own enrollment. Anders I've stuck some very rough instructions on https://wiki.mozilla.org/NSS:Android . I'm move them to https://developer.mozilla.org/en/NSS after the upgrade to Kuma wiki, probably next week. *The Cross Build* It's not surprising that I was able to get NSS to build for Android since two other teams are already building NSS for Android in their own environment. What was surprising was I needed to make a few changes: one to dbm (use of errno) and one to freebl/ran_unix.c (use of sysinfo). I was wondering how the other teams were working around the problems I ran into. Besides those 2 problems, I also had to deal with shlibsign in cmd. I simply changed the makefile to try to use a system installed shlibsign if you were cross compiling (works on fedora and RHEL, where I know we include shlibsign with our packages, I don't know about other versions of Linux. It certainly wouldn't be happy in a windows host). The magic to get all this to work was judicious use of make environment variables. I've added new targets in the Makefile in mozilla/security/nss which knows how to build Android cross. I believe you only need the Android NDK to build NSS and NSPR. I haven't tested without having the SDK installed, but I didn't tell any software how to get to the SDK, so I'm pretty sure it wasn't used. *Running the Tests* I've included several make targets to install the built binaries onto the Android device and run them. The targets do not use adb, mostly since I don't have my little cable for my Android Table here at work. Instead I installed SSHDroid and used sftp and ssh to install and run the tests. It should be possible to make adb versions of the same commands, but I'm pretty sure you'll then need to install Busybox to get everything to run (Busybox comes with SSHDroid already, and I know I make use of several of the Busybox commands in the build). Since I'm using ssh/sftp, the Android device doesn't need to be physically hooked to the Linux host, only connected to a network that the Linux host could address. Anyway feel free to try out the instructions, and update things that aren't quite right. Surprisingly, the fast majority of the tests seem to run, though I'm still getting quite a few failures. bob -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Building and running NSS for Android.
On 2012-07-06 10:29, ianG wrote: On 6/07/12 16:14 PM, Anders Rundgren wrote: On 2012-07-06 01:51, Robert Relyea wrote: I've gotten NSS to build and mostly run the tests for Android. Cool! There are still a number of tests failing, so the work isn't all done, but it was a good point to snapshot what I had. How does this compare/interact with Android's built-in key-store? I'm personally unconvinced that security subsystems running in the application's/user's own security context represent the future since they don't facilitate application-based access control unless each application does its own enrollment. The way I see this is that security subsystems running in the app/user's own security context is sub optimal for development cost purposes. And, ??? running in the platform's security context is sub optimal for security motives. I'm not sure I understand the rationale here. Where the sweet spot is tends to vary and isn't really a universally answerable question. Anders iang -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: To NSS-Java or not to NSS-Java, thats the question.
On 2012-04-20 10:34, helpcrypto helpcrypto wrote: After reading your three mails, i have only one thing to say: Clear as water. Thank a lot for your patience and effort on explaining this for short-minded like me. Thanks a lot, REALLY, for your long, detailed and clear answer. Of course, thanks a lot to Anders (which also suffered me) and others, for the patience you are showing. Thanx!!! Now, a few comments to some of yours and some questions at the end. Here, you mean the keygen operation? I think it has to be the Software Security Device. aka, the soft-token ? When an smartcard is present, and a request to generate a keypair is made, Mozilla shows a dialog to select the cryptographic device where the keys are going to be. If im developing a page to request a certificate on the smartcard, i (as a developer) CANT control if the user selects the card or softokn. Helpcrypto, a possible *long-term* solution to this is that the requester indicates such preferences. So if the requester says external card (for example) the dialog would not need the user to select. If there is no card present, it would ask the user to insert a suitable card. This is at least how KeyGen2 works. So, if the user doesnt read the BIG warning that i show (you must select the CARD!!!), and never does, the keys are generated on softokn and that ends in many problems. Starting with the user thinking the cert is on the smartcard, where is not. Our users know what the card is. Some UI tests have shown 99% of those warnings to be ignored. Some optimistic tests have shown only 60% are ignored... Some active teaching experiences have shown they can get it down to 30% with training, but the test repeated after 3 months shows return to bad habits :) dont tell me. you must select the CARD!!! Is your application so valueless that you can cope with that? When using smart card systems, you'll notice there are no warnings... because the smart card designers at least know that if they rely on warnings, it's game-over. This proves you havent used spanish DNIe. Designers decide that, as a warning can be ignored, make sure user dont ignore the warnings. So DNIe show 2384729847239874923794 warnings, and i ignore them all. Mind you, we don't know how valuable or valueless your application is. Perhaps you could tell us what the key pair or signature is used for? company users need to sign documents (xml/pdf...) or mail we use FNMT (some guy could be killed for that) certs we have an smartcard where we put the cert in. we want users to be able to sign data (webforms or documents) using web [Actually using Java] we want users to be able to request certs 'directly' on smartcard (from a website) Do you need more details? I understand this is a trusted site is FAR AWAY from this is a trusted site that can read my hard drive/execute commands. Signed applets, at the other hand, have full access, and can access to the smartcard. If there are no better options at the moment, shouldnt we (mozilla/firefox) suport them properly? This is of course not of my business but I personally do not see JSS neither as the solution for now or the future. I think these guys have do a huge work with signature Applets: http://www.openoces.org Anders -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Feedback on DOMCryptInternalAPI
On 2012-04-19 17:09, David Dahl wrote: Hello All: [I have cross posted this message to dev-platform and dev-tech-crypto, perhaps we should discuss this on dev-platform as it has a larger subscriber base?]. I am just putting together a draft feature page for an internal API needed by the eventual DOM bindings for DOMCrypt (see: https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Latest and http://www.w3.org/2012/webcrypto/ ). I would like for this API to not only support the eventual Web Crypto API, but also to allow extension developers to have a useful, high-level API to work with. This seems to be quite in demand based on the number of companies and developers who have contacted me about hacking on my fork of WeaveCrypto ( in the DOMCrypt Extension https://addons.mozilla.org/en-US/firefox/addon/domcrypt/ .) Mozilla developers will also be able to take advantage of this internal API to more easily create browser features and/or extensions in the security and privacy space. I would also like to produce a Jetpack wrapper. The existing spec for DOMCrypt will no doubt change very soon as the Web Crypto Working Group is ramping up and based on discussions with bent and khuey, we need to move to an event-driven interface. The Internal API described on this feature page: https://wiki.mozilla.org/DOMCryptInternalAPI should be able to handle that, however, some wider discussion and feedback will really be appreciated, especially with all of the changes in line for our DOM bindings. The initial work for this internal API is in bug 649154. Regards, David I have already provided feedback on this in a W3C list, so this a condensed version of on the Mozilla list. As I understand it, this scheme is about public keys bound to a domain which is a bit like cookies on steroids. This shouldn't introduce any new or difficult security concerns. Regarding real-world use-cases, I'm slightly less convinced. In particular encryption has proved to be hard to exploit but OTOH there are [still] folks out there who claim S/MIME is the flagship of PKI so I guess somebody knows what they are asking for However, the WG has also taken on Signing High-value Transactions. I find this use-case poorly researched. There have been no references to existing web signature systems although such have existed since late 90'ties. I suggested early on dropping this topic, as it with a high probability will jeopardize both the time schedule as well as uptake by other browser vendors. In addition, it is claimed from time to time that a future version of DOMCrypt will also support X.509 certificates. If I had developed a car, I would be rather hesitant saying that the next iteration will fly without having a pretty good idea of how. I'm personally continuing on the path created by Netscape eons of time ago, where cryptographic operations in browsers are performed in self-contained applications like HTTPS URL innovation, keygen, and signText() because they have proven to work, while (for example) Microsoft's CertEnroll has been a complete failure due to the issues created by exposing APIs to untrusted web-pages. Somewhat surprising the WG excluded smart cards in spite that built-in security hardware will be a standard feature in every high-end mobile device by the time this WG has finished! IMHO, smart cards in browsers is actually quite easy; you just bypass the vendors and define a card/container for the web :-) If you ever had looked into the OpenSC mailing list it is pretty obvious that supporting conventional cards is impossible, at least for enrollment. Anders -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: To NSS-Java or not to NSS-Java, thats the question.
On 2012-04-19 09:21, helpcrypto helpcrypto wrote: (to me, that question makes no sense. users can't talk to smart cards. Only smart card readers and programs can. So what smart card reader and what program is doing this? A dumb smart card reader and a browser, following Javascript instructions from a website? That'd be game over...) Why a website cant use javascript to communicate with the card? A number of banks came up with the wonderful idea adding a citizen ID application to their already shipping EMV (payment) card. What this meant was that any merchant could read your citizen ID certificate (=national ID) without your knowledge. Naturally this scheme was endorsed by the government and their consultants. I'm by *no means* a privacy advocate but this is way below what I consider a useful solution. My criticism of this idea made me quite unpopular but it seems that they actually never put it in production :-| Anyway, this was another way of expressing a core problem with direct access. I do not think that clever GUIs can do much here either. Then there are security-related stuff such as PIN spoofing and associated credential misuse that I makes me pretty uncomfortable with the whole idea. My solution to this is to treat all PKI-using applications as complete applications running in trusted code. W3C tries to do something different, we'll see how that pans out... Anders -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: To NSS-Java or not to NSS-Java, thats the question.
On 2012-04-19 16:41, helpcrypto helpcrypto wrote: My solution to this is to treat all PKI-using applications as complete applications running in trusted code. W3C tries to do something different, we'll see how that pans out... Ok Anders, but you are -again- talking much about your protocol, Dear HelpCrypto, I'm not pushing my protocol. I just don't think that web-pages should be able to directly address *any* device but the screen. If you take PKCS #11 it has a lot of methods and I haven't a clue how to warn/alert the user when a method is called in a way that makes sense. Since you typically need a bunch of calls in order to do something pkcs11-ish you would annoy the user with tons of warning dialogs. If Mozilla thinks this is viable solution I think it is (about) time to speak up! BTW, I don't think your English is that bad :-) I'm no pro either :-) Anders not answering my question (or at least, i didnt get it as clear as water). I think, this must be a communication problem between my spanish and yours swedish (?). I really sorry for that. Im talking about something much more simpler: Detect a card insertion and be sure the card is doing the operation i requested. For example: Within a browser, i click on dear card, please, RSA sign this data button. IIUC, you say that should not be done or that is not good for ~ reasons. And that is want to know. Why, if i request a certificate using a webpage (=generate keypair), i cant control if the operation is performed within the card (not in softokn)? (Using latest build, i can do that operation, but i cant control where is done...) Actually, if i access an untrusted SSL site, i see a warning you are about to enter on an untrested site... Why i could not see this page wants to use the smartcard... warning? Maybe, this discussion should be on private to avoid spamming dev-tech-crypto list...? -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: To NSS-Java or not to NSS-Java, thats the question.
Dear helpcrypto, now it became a little bit messy because I'm talking about principles while you are talking about specific interfaces like NSS, and PKCS #11. During enrollment, i need to know card is present and the keypair is generated inside. how can i achieve this without a pkcs#11 interface? None of the popular cryptographic APIs support container attestations. None of the PKIX enrollment protocols support container attestations. Container attestations must be performed at the APDU-level since E2ES cannot be abstracted. Redhat supports container attestations (aka Secure Messaging) in their DogTag card management product. This part does not rely on PKCS #11. Microsoft's CertEnroll solution exposes quite a bunch of sensitive APIs. This creates an awful lot of security and privacy-related dialogs which no normal user can possibly understand. I call it Epic Fail :-) CISC vs. RISC. I think PKCS#11 its not so awful and will not be an epic fail. Are we actually talking about the same thing here? I'm talking about exposing cryptographic APIs to code running in an arbitrary web page. This is what CertEnroll does and that is an *extremely* bad idea. Compare this with HTTPS which can be invoked from any page without exposure of a single cryptographic method. That's a good system. I still don't understand the Spanish use-case and particularly not why you need card-level Secure Messaging for signing data. I guess it is also about the server authenticating to the card? Anders On 2012-04-18 09:16, helpcrypto helpcrypto wrote: Although E2ES (End-to-End-Security with respect to the *container*) is actually my line of work (http://webpki.org/papers/keygen2/sks-api-arch.pdf), I don't understand why you would use it during signing or authentication. Yes, TLS-client-cert-authentication is also E2ES but it works one level up. So, simplified: authentication is done using certificates, no matter if on smartcard or softokn. Isnt it? During enrollment you may want to verify that the device you are talking to is genuine or not. During enrollment, i need to know card is present and the keypair is generated inside. how can i achieve this without a pkcs#11 interface? After enrollment you do not need to repeat this because the policy expressed though the enrolled certificate should implicitly or explicitly provide this information to the relying party. So, our policy says: certs are always generated inside the smartcard, isnt it?. Thats not our case. We use an official(sorry for that) FNMT (sorry again) certs that is imported to the card. Anyhow, how can we control the card without a pkcs#11 interface? There may surely be something in the Spanish scheme which I don't know about, but I suspect that whatever it may be, it is probably a bit unusual :-) Feel free enlighten me! Nothing unusual, AFAIK. Spanish DNIe is just a securte crypto card where keypairs are not extractable/writable, generated inside and where communications are done using a secure channel. The card has a component certificate to show its a real DNIe. More info: Microsoft's CertEnroll solution exposes quite a bunch of sensitive APIs. This creates an awful lot of security and privacy-related dialogs which no normal user can possibly understand. I call it Epic Fail :-) CISC vs. RISC. I think PKCS#11 its not so awful and will not be an epic fail. Exposing NSS, PKCS #11 or PC/SC to downloaded browser code suffers from the same issues. I agree PC/SC is too low to be ok. Softokn and other PKCS#11 crypto devices can be controlled by PKCS#11 api, and this is IMVHO the correct option to control devices. (having a well-sized/defined API). Must be a translation issue + my lack of english skills, but i dont feel you answered my previous and current question: how can i work with a smartcard without a pkcs#11 interface? -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: To NSS-Java or not to NSS-Java, thats the question.
On 2012-04-18 11:04, helpcrypto helpcrypto wrote: On Wed, Apr 18, 2012 at 10:03 AM, Anders Rundgren anders.rundg...@telia.com wrote: Dear helpcrypto, now it became a little bit messy because I'm talking about principles while you are talking about specific interfaces like NSS, and PKCS #11. Ok. Rather than discussing technical or theorical point of views, i think we could start focusing on what the user need and how can we do it possible(design/implementation). During enrollment, i need to know card is present and the keypair is generated inside. how can i achieve this without a pkcs#11 interface? None of the popular cryptographic APIs support container attestations. None of the PKIX enrollment protocols support container attestations. Using CryptoAPI you can select which CSP to work with, and a CSP can point to a specific smartcard. If the keys are generated inside the card i dont need a PKIX enrollment protocol that support anything special, cause im sure the keys are generated on the right place. My scenario is a billion+ community who haven't a clue what a CSP is and never will. They may not even know what a certificate is! A CSP-solution doesn't give the issuer any information about where and how a key was generated. The same goes for NSS, JCE, and PKCS #11. Container attestations must be performed at the APDU-level since E2ES cannot be abstracted. I dont understand that. See section 9.5 of: http://forja.cenatic.es/docman/view.php/160/684/cwa14890-01-2004-Mar.pdf I have taken another path than ISO/CEN but both concepts stem from the same root: http://openkeystore.googlecode.com/svn/trunk/resources/docs/Efficient-Provisioning-of-Complex-Structures-Over-Unsecured-Channels.pdf As can be seen from the documents, Secure Messaging isn't something you could bring up on a typical cocktail party :-) :-) Again: lets try (both) to leave the theorical/technical, and think in what the user needs. Are we actually talking about the same thing here? I'm talking about exposing cryptographic APIs to code running in an arbitrary web page. This is what CertEnroll does and that is an *extremely* bad idea. Consider: I want a user to be able to request a certificate on our company smartcard. Is that an *extremely* bad idea? If it works like CertEnroll or SConnect it is indeed an extremely bad idea because it exposes the card to accesses by untrusted parties. If you think is not, lets focus on the problem itself: how to request a certificate within a smartcard If you think is it...could you tell me why? Compare this with HTTPS which can be invoked from any page without exposure of a single cryptographic method. That's a good system. I really this understand this. You think a protocol is the solution? Almost. I started years ago with a protocol and later realized that secure messaging must be a part of that. However, given the weirdness of smart cards, I found that you would also need a carefully matching container in order to ever get it supported inside a standard browser. I still don't understand the Spanish use-case and particularly not why you need card-level Secure Messaging for signing data. I guess it is also about the server authenticating to the card? Seems the DNIe doesnt help to clear the problems im having. Forget the example and try to focus on the detect anc work with the smartcard issue. Regards, Anders -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: To NSS-Java or not to NSS-Java, thats the question.
On 2012-04-18 13:06, ianG wrote: (lo-pri interest only requests) Short return then :-) On 18/04/12 20:00 PM, Anders Rundgren wrote: On 2012-04-18 11:04, helpcrypto helpcrypto wrote: Container attestations must be performed at the APDU-level since E2ES cannot be abstracted. I dont understand that. See section 9.5 of: http://forja.cenatic.es/docman/view.php/160/684/cwa14890-01-2004-Mar.pdf I have taken another path than ISO/CEN but both concepts stem from the same root: http://openkeystore.googlecode.com/svn/trunk/resources/docs/Efficient-Provisioning-of-Complex-Structures-Over-Unsecured-Channels.pdf As can be seen from the documents, Secure Messaging isn't something you could bring up on a typical cocktail party :-) :-) Hmm... I haven't read your cocktail books above, but do you have a minimalist recipe? What's a Secure Message? In explanatory terms. In the SC-world it is a secure channel between something and the card. ... Are we actually talking about the same thing here? I'm talking about exposing cryptographic APIs to code running in an arbitrary web page. This is what CertEnroll does and that is an *extremely* bad idea. Consider: I want a user to be able to request a certificate on our company smartcard. Is that an *extremely* bad idea? (to me, that question makes no sense. users can't talk to smart cards. Only smart card readers and programs can. So what smart card reader and what program is doing this? A dumb smart card reader and a browser, following Javascript instructions from a website? That'd be game over...) Exactly my point. Microsoft's solution to this is annoying the user with dialogs like this site wants enumerate your keystore, do you accept? ... Compare this with HTTPS which can be invoked from any page without exposure of a single cryptographic method. That's a good system. I really this understand this. You think a protocol is the solution? Almost. I started years ago with a protocol and later realized that secure messaging must be a part of that. curious ... (smart card) money products also work this way. That is, at its base layer, peers talk with secure messaging. Once you've got that layered in as the core design, the rest is easy (handwave handwave)... they problem is that most designs don't get that right, and struggle. Although, maybe I'm reading more into secure message than is meant. However, given the weirdness of smart cards, I found that you would also need a carefully matching container in order to ever get it supported inside a standard browser. Well, using my view of a secure message, the conceptual browser can't be a peer. So all it can do is do packet routing. That's exactly what it does in the document above. But, real-world browsers don't do that, they pretend to be the only peer, and that's where the trouble starts. iang Anders -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: To NSS-Java or not to NSS-Java, thats the question.
On 2012-04-17 09:06, helpcrypto helpcrypto wrote: I would not build a scheme based on NSS because NSS is not a prerequisite unless you force people to use Firefox. We arent forcing. We already support Microsoft, OSX and Google browsers, and (trying) Firefox too. Hooking Mozilla/NSS into native APIs like CryptoAPI is a much more important task. IIUC...will someday Mozilla hook NSS with System (Windows or OSX)? Mozilla is also actively trying to establish Firefox in mobile devices. In such devices you do not really have any choice but accepting the platforms native key store scheme. Anything else would be foolish. Anders Quoting bsmedberg (https://bugzilla.mozilla.org/show_bug.cgi?id=654939#c19): No, writing enterprise apps which poke into the Firefox certificate store is not a desired use-case Is that the official Mozilla position? I'll ask another way: Is there any argument against compiling NSS with @loader_path instead of current @executable_path? (https://bugzilla.mozilla.org/show_bug.cgi?id=578751) Will patches be accepted (if correct), or some people want @executable_path, rather than @loader_path ? -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: To NSS-Java or not to NSS-Java, thats the question.
On 2012-04-17 11:14, helpcrypto helpcrypto wrote: So, do you (we) ALL agree NSS should be modified to hook with system keystores like Windows or OSX? (Linux has no default system keystore, so there will be no changes by now) Maybe wtc has something to say against this... Are mozilla (we) going to see (wait) whats is said on: http://www.w3.org/2011/11/webcryptography-charter.html ? I participated both in a workshop in Mountain View as well as in some of the early discussions in a mailing-list. I got the impression that the proposers do not completely understand the difference between exposing APIs to untrusted browser-code versus APIs that are only available to built-in or explicitly installed plugin code. It was for example suggested that PKCS #11 should be exposed as a JavaScript object. I think that is downright ridiculous idea, almost as bad as: http://www.sconnect.com/FAQ/index.html Making Firefox compliant with Windows and OSX keystores is IMO an entirely different task. Anders -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: To NSS-Java or not to NSS-Java, thats the question.
On 2012-04-17 14:14, helpcrypto helpcrypto wrote: It was for example suggested that PKCS #11 should be exposed as a JavaScript object. I think that is downright ridiculous idea, almost as bad as: http://www.sconnect.com/FAQ/index.html Let me expose two user-cases where i think that will be helpfull (and maybe the only option). -Web page that allows company users to request a certificate WITHIN company smartcard: User inserts smartcard, click request, connection to pkcs#11 is made, if card present, all the operation can be done. Otherwise (current), request is done somewhere. If a card is present, a dialog (where the user can mistake and select the bad crypto device) is shown, otherwise is requested on softokn. We dont have any control if certificate is on card or softoken :( -I want to establish a secure conversation between my server and an smartcard like european ids, knowing im talking with a valid secure device (like Spanish DNIe secure channel) Although E2ES (End-to-End-Security with respect to the *container*) is actually my line of work (http://webpki.org/papers/keygen2/sks-api-arch.pdf), I don't understand why you would use it during signing or authentication. Yes, TLS-client-cert-authentication is also E2ES but it works one level up. During enrollment you may want to verify that the device you are talking to is genuine or not. After enrollment you do not need to repeat this because the policy expressed though the enrolled certificate should implicitly or explicitly provide this information to the relying party. There may surely be something in the Spanish scheme which I don't know about, but I suspect that whatever it may be, it is probably a bit unusual :-) Feel free enlighten me! Making Firefox compliant with Windows and OSX keystores is IMO an entirely different task. Indeed it is. Good. So, IMHO there are 2 milestones: -Make NSS work with CryptoAPI/Keychain / Linux? -Export a PKCS#11/15 javascript API to communicate with any cryptographic device. (This+OpenSC=everything working everywhere!) Anders, I'll like to hear why you consider that (PKCS#11) a downright ridiculous idea. Microsoft's CertEnroll solution exposes quite a bunch of sensitive APIs. This creates an awful lot of security and privacy-related dialogs which no normal user can possibly understand. I call it Epic Fail :-) Exposing NSS, PKCS #11 or PC/SC to downloaded browser code suffers from the same issues. Anders -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: To NSS-Java or not to NSS-Java, thats the question.
On 2012-04-16 09:47, helpcrypto helpcrypto wrote: If you'd like to help make Firefox better for enterprises, we'd be delighted to have you submit patches instead of questioning our commitment to our users. I'll ask another way: Is there any argument against compiling NSS with @loader_path instead of current @executable_path? (https://bugzilla.mozilla.org/show_bug.cgi?id=578751) I would not build a scheme based on NSS because NSS is not a prerequisite unless you force people to use Firefox. Even if JSS works, it simply cannot be high-priority task for Mozilla keeping this in shape. Hooking Mozilla/NSS into native APIs like CryptoAPI is a much more important task. I don't really see the link between XadES-XL and key-stores. The Windows key-store is probably more secure than NSS since the former is running at OS-level. Anders Using Java with NSS is something I don't believe is a good idea for applets. Why is not a good idea? Do you know a better way of doing a XAdES-XL? Anyway, if JSS is for java local apps, rather than Applets, that should appear on JSS documentation. IMO it is Oracle's call creating useful key-store mechanisms for the different platforms. So far they have only done that for Windows. Java can work with PKCS#12, PKCS#11, SunMSCAPI, OSX Keychain and NSS (with a few bugs, as you can see). The question here is: Can Oracle invoke NSS? Quoting bsmedberg (https://bugzilla.mozilla.org/show_bug.cgi?id=654939#c19): No, writing enterprise apps which poke into the Firefox certificate store is not a desired use-case Is that the official position? -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: To NSS-Java or not to NSS-Java, thats the question.
On 2012-04-11 07:42, Gen Kanai wrote: On 4/9/12 6:05 PM, helpcrypto helpcrypto wrote: The question can be changed to: -Do mozilla want companies and bussiness to use Firefox? (rather than chrome) -Do mozilla think themes and make up are more important to bussines than this kind of features? If you are familiar with the Mozilla project and the history of Firefox, Mozilla has always been focused on the end user. We know that many enterprises do deploy Firefox but our product decisions are clearly not based on the needs of enterprise IT managers. It's not that we don't care about the enterprise market. We do. We recently worked to develop an extended support version of Firefox for that segment when it was clear that the rapid-release model was impossible for enterprises. However, we are a small non-profit and we need to set priorities and focus our resources. We can't do everything. If you'd like to help make Firefox better for enterprises, we'd be delighted to have you submit patches instead of questioning our commitment to our users. Using Java with NSS is something I don't believe is a good idea for applets. IMO it is Oracle's call creating useful key-store mechanisms for the different platforms. So far they have only done that for Windows. Mozilla+Redhat OTOH, ought to rework the *NIX keystore so that it one day actually matches what Windows have had since 95 or 98. Static libraries do not represent the future; Google use services in Android 4 and this is where the rest of the industry is going as well. Anders -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: cert8.db rewrite reasons and exceptions?
On 2012-04-09 10:27, helpcrypto helpcrypto wrote: So, IIUC, both of you consider using system/os/platform keystore (directly [or hooked]) the best option? IMHO it depends quite a bit on what your target audience is. If you (for example) are working with server-applications you are likely to either use .NET or Java. For .NET the Windows keystore is by far the easiest to use. For Java the situation is a little bit less clear but most people probably use the Java system unless they use HSMs which typically are supported by PKCS #11 which can be used from java but unfortunately not on Windows 64-bit. For client-based solutions, I definitely think that the native platform keystore should be used if possible. For 1-2% using Desktop *NIX the options are plentiful which for some people is considered an advantage but I consider difficult. Anders -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: cert8.db rewrite reasons and exceptions?
On 2012-04-09 11:21, helpcrypto helpcrypto wrote: IMHO it depends quite a bit on what your target audience is. Document signing on a web browser, its *always* done using a java applets. Tax payment, traffic bills, more taxes...in hour case, official documents signed by the ministry autorized people. That's interesting! You might want to look into this: http://www.w3.org/2011/11/webcryptography-charter.html The ability to select credentials and sign statements can be necessary to perform high-value transactions such as those involved in finance, corporate security, and identity-related claims about personal data I'm rather skeptical about this group's ability creating a standard for web signatures. FWIW, I have since *very* long time back toyed with a web standards proposal http://webpki.org/papers/wasp/wasp-tutorial.pdf which I may turn into real when/if I succeed with the enrollment/keystore standard that I [nowadays...] consider having *much* higher priority than signatures: http://webpki.org/papers/keygen2/sks-keygen2-exec-level-presentation.pdf Anders -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: cert8.db rewrite reasons and exceptions?
On 2012-04-09 12:13, helpcrypto helpcrypto wrote: http://www.w3.org/2011/11/webcryptography-charter.html BSmith ans RRelyea directed me there also. All fishes go to sea... ;) The really big fishes (Google, Apple, and Microsoft) haven't said a word (in public) about their interest in this. I think they have reasons to wait for Mozilla to release their signature solution... http://webpki.org/papers/wasp/wasp-tutorial.pdf http://webpki.org/papers/keygen2/sks-keygen2-exec-level-presentation.pdf I think i already read both documents some time ago. Isn't the inferiority of the soft token implementations a problem? In Sweden, banks rejected these since PIN-code protection isn't controllable. They opted for PKCS #12 containers protected by 12-character passphrases. Pretty inconvenient but what else could they possible do? Related: The IETF has recently started the development of yet another PKI enrollment scheme that doesn't support PIN-code provisioning! Anders -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: cert8.db rewrite reasons and exceptions?
On 2012-04-02 21:07, Robert Relyea wrote: On 03/27/2012 01:00 AM, helpcrypto helpcrypto wrote: Cough, cough...exit(CKR_OK) != return CKR_OK...cough, cough Now cert8 is modified always (with or without our module). Anyway, can someone tell me why cert8 is rewrited on each run/close? Because that's how the old berkeley DB works. It's weirdness like this that caused us to implement the new sql-lite db. It just hasn't been integrated into mozilla yet. I think that NSS is in need of a major upgrade: http://nelenkov.blogspot.se/2011/11/ics-credential-storage-implementation.html PC-based *NIX will soon be the only system lacking a *unified* keystore scheme based on a system service. Anders bob On Tue, Mar 27, 2012 at 9:18 AM, helpcrypto helpcrypto helpcry...@gmail.com wrote: Hi all. Due some problems using Thunderbird ESR, we have found the following, and would like to ask the experts... We have noticed Thunderbird 10.3 (probably older versions too) rewrites cert8.db each time it closes. The file its the same, but the modified date has changed. - Is this normal? - There is a technical/security reason? More test have shown cert8.db is not modified/rewrited after adding our PKCS#11 module in secmod.db. (!) Our PKCS#11 is working OK for a long time without any problems, but there must be something wrong in here to prevent the default behaviour, right? Why is this happening? Going to test on a debug environment to get some traces. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: cert8.db rewrite reasons and exceptions?
On 2012-04-04 13:04, helpcrypto helpcrypto wrote: IIRC, NSS doesnt have an official mantainer on Mozilla bugs, isnt it? If this happens, its probably the source of many problems here. I have filed a few bugs and most of then arent even checked. To be fair honest, im also guilty of that, but i dont feel confident enough to edit Mozilla source. Could any expert make a workshop and teach us(me) how to ? I thinks this could be a quite simple start:https://bugzilla.mozilla.org/show_bug.cgi?id=670895 Having this unified keystore, has ever been discussed between mozilla and unix people? What did they decide? I think this remains something that only vendors like Microsoft, Google and Apple can do; the general *NIX lot is too divided to settle on such a thing. Mozilla should IMO rather hook into the other vendors cryptographic solution, possibly at the expense of NSS. According to a college of mine Chrome even use the platform's SSL implementation! Well, not in *NIX since there is no such thing... In JDK/JRE Oracle (previously SUN) have native support for CAPI which is unclean but is what Windows(-only) developers would prefer. Then you get away from spicing your server-apps with a gazillion static password configs that fill absolutely no security purpose! Anders -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Mozilla Team-about the upcoming branding changes at Symantec/VeriSign, and working to implement them in Mozilla/Firefox
It is hard to see that GUI changes would have any function except for the very few who understand the difference between roots and sub-CAs. It is similar to the EV green bar. It doesn't make any difference for normal people. The recent screw-ups didn't invalidate the system; it rather made the certificates vendors a bit more concerned about their operations which is good. Screw-ups is the road to improvements :-) -anders -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Running NSS as a Service
After looking into several similar solutions including Gnome Keyring I wonder if it is not time for NSS transcending into a service rather than a library running in application context. Anyway, it seems pretty difficult adding a trusted GUI or application ACL support to NSS without a major redesign. Thoughts? Anders -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Developing pkcs11 module for Firefox
On 2012-01-05 02:45, Robert Relyea wrote: I am curious as to how smartcard management is supposed to work for Linux. It seems to me that it would be ideal for Firefox to support the shared DB on Linux. Are there OS-level tools for managing the shared DB. For example, is there an OS-level UI for adding/removing PKCS#11 modules in Fedora/RHEL that would make Firefox's UI for this redundant? System level PKCS #11 modules (installed by the administrater) are stored in /etc/pki/nssdb, user level pkcs #11 modules (installed by the user) are stored in ~/.pki/nssdb . User level application load both the system modules and the user modules. Now this works under the covers is described here: https://wiki.mozilla.org/NSS_Shared_DB_And_LINUX Doesn't Gnome Keyring essentially shoot for the same target? -- Anders -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Developing pkcs11 module for Firefox
On 2012-01-03 23:44, Robert Relyea wrote: On 12/30/2011 06:53 AM, Anders Rundgren wrote: On 2011-12-29 23:08, Brian Smith wrote: Matej Kurpel wrote: On 22. 12. 2011 10:36, Imen Ibn Hotab wrote: I`m developing pkcs#11 module for Firefox. I was developing a PKCS#11 module as well. Just out of curiosity, what do your PKCS#11 modules do? Would it make things easier for either of you if Firefox and Thunderbird supported CAPI CSPs in addition or instead of pkcs#11 modules for client certificates on Windows? Yes! I think Firefox would gain by in addition to PKCS #11, also support the native OS crypto system (if there is one). Cheers, Anders There is a capi module in the NSS source tree, but it purposefully does not surface removable CAPI modules under the assumption that such devices already have PKCS #11 modules. I'm not sure what you mean with removable CAPI modules but the assumption that PKCS #11 is standard on Windows is not entirely correct since PIV cards (for example) can be as is in W7 and forward without any middleware installation. Other cards may need an install via Windows Update but this (AFAIK) does usually not include PKCS #11. Chrome uses CAPI by default. OTOH, the situation is the same for Java. The Oracle JRE contains built-in support for CAPI not needing any setup or configuration. Well, there is support for PKCS #11 but it requires much more work to be used. BTW, integration of crypto seems to have taken a giant leap forward: http://channel9.msdn.com/Events/BUILD/BUILD2011/HW-462T http://www.google.com/wallet I think this step was inevitable; supporting third-party drivers and custom enrollment schemes have simply proved to be too hard if you are targeting consumers. That the inside of the schemes above currently are kept under wraps is an indication of that this field is slowly but surely heating up :-) If the unverified rumor that Google's Wallet is based on GP (GlobalPlatform) actually is true, it looks like E2ES (end-to- end-secured) provisioning will be the next big thing in crypto middleware. It will be quite interesting to see how this is going to be dealt with by Mozilla as well as by the *NIX community. My take on this (as you have heard about a gazillion times before), is defining a unified E2ES-enabled crypto container (SKS) so that you in the majority of cases would never have to bother about middleware in a contemporary platform. SKS differs from GP in many respects, most notably in the trust model where GP assumes that the container trusts the issuer which mainly is a smart card business model issue rather than a security requirement. In SKS it is the user who grants an issuer the right creating a key based on the existing (semi-functional) Internet trust model. Since a fake key doesn't open any genuine doors, this should work just fine. Anders bob Cheers, Brian -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Developing pkcs11 module for Firefox
On 2011-12-29 23:08, Brian Smith wrote: Matej Kurpel wrote: On 22. 12. 2011 10:36, Imen Ibn Hotab wrote: I`m developing pkcs#11 module for Firefox. I was developing a PKCS#11 module as well. Just out of curiosity, what do your PKCS#11 modules do? Would it make things easier for either of you if Firefox and Thunderbird supported CAPI CSPs in addition or instead of pkcs#11 modules for client certificates on Windows? Yes! I think Firefox would gain by in addition to PKCS #11, also support the native OS crypto system (if there is one). Cheers, Anders Cheers, Brian -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Fwd: gnome-keyring Question about ACL per storage item
Naturally a system like described below must support an*/issuer-defined/* ACLs on enrolled keys... /a Original Message Subject:gnome-keyring Question about ACL per storage item Date: Thu, 20 Oct 2011 10:17:00 +0300 From: Elena Reshetova elena.reshet...@gmail.com To: gnome-keyring-l...@gnome.org Hi, I have been studying different solutions available in Linux for securely storing certificates, keys and other credentials and one of the solutions I am going through is Gnome Keyring. I saw that it used to have ACL per item in the storage, where one can specify basic read/write/delete rules and identify application (or applications?) that is allowed to use the item. However, this functionality is now marked deprecated and I could not find explanations for such decision. The use case I am interested in is very simple. I am as a user would like to be able to control what of my secrets are accessible to which applications on the system. Because I may have very different applications installed on my system and not trust each of them in the same way. For example, I may have two different key pairs for signing my emails, one for corporate emails and one for personal. Similarly I may be forced to use two different mail clients: for private emails my favourite open-source mail client (that my company doesn't feel that it is trusted enough) and company approved mail client for company emails. And of course I would like to specify that these two email clients should be able to access only a private key from corresponding key pair for signing. I can think of quite many use cases like that. Are there any plans/desires to have such functionality supported in Gnome Keyring? It isn't listed in architecture goals and plans and that's why I am interested to ask. Best Regards, Elena. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Token Provisioning in Firefox
Recently there has been some discussions in the IETF PKIX list regarding future enrollment systems including those in browsers. I remain confident that it is infeasible extending such a scheme to include smart cards since Certificate Enrollment and Token Provisioning are very different, even if the latter would only be about PKI. You don't have to go very far to verify this claim: Just setting a PIN-code usually requires administrator permission to the token and that is contra to what banks and similar providers would be interested in. AFAICT, a scalable approach should be based on that the issuer establishes a secure session with the token in which it can enforce its own policy _/without elevating user or middleware privileges/_. I have (FWIW), completely dropped the idea of creating a new browser Certificate Enrollment protocol since it wouldn't solve any problem. Well, minor adjustments of keygen could be useful (such as making the key strength buttons optional), but that has nothing to do with Token Provisioning. http://www.ietf.org/mail-archive/web/pkix/current/msg29682.html Anders -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
HTTPS client-certificate-authentication in browsers
Today's harvest :-)
HTTPS client-certificate-authentication in browsers
===
I don't believe that TLS CCA (Client Certificate Authentication) in the
form of HTTPS as implemented in current browsers has much of a future.
In fact, quite a bunch of the entities in the EU working with consumer PKI
have replaced HTTPS CCA with an application level scheme{1].
That the TLS CCA protocol doesn't even support Logout haven't made
it a logical choice for web developers either. Well, there are some
workarounds but they are by no means straightforward, supported
out-of-the-box by server authentication schemes, and are (of course)
entirely undocumented.
The button Clear SSL state in MSIE is an indication how horribly bad it
can go when security experts design systems for people.
There's no way you can hide the fact that TLS CCA is only truly useful
securing tunnels between boxes.
Anders
[1] which wasn't such a big deal since they anyway were forced writing
a browser PKI client more or less from scratch since the ones shipped
with browsers doesn't support PKI as defined by banks and government
(like mandatory PIN codes also for on-line enrolled keys).
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: DOMCrypt API developments
On 2011-06-21 11:18, Konstantin Andreev wrote: [combining two cites to save space] On 21.06.11 00:48, Anders Rundgren wrote: We have both come to the conclusion that Firefox et al sucks since just about all serious users need to deploy plugins in order to use their PKIs. On 18.06.11 19:59, Anders Rundgren wrote: [Subject: Update: Browser Crypto Protocol Invocation] Some three years ago I published a proposal [...] I have revised it to be fully format-neutral. http://webpki.org/papers/web/XMLBrowserExtensionScheme.pdf Anders, as far as I understand, the two cites above are related. They sure are! Is there anywhere an informal, brief intro into the subject you are talking about? I'd like to get some awareness of. Hi Konstantin, There is a lot of information on different levels. Way back I started with digital signature support: http://webpki.org/papers/wasp/wasp-tutorial.pdf The last 4 years I have focused on on-line provisioning of credentials since it is working fairly badly [*] in Firefox which has created a virtual *industry* supplying proprietary plugins for this purpose. The page below contains the usual high-level marketing BS but the links in it point to quite detailed information on how the proposed scheme is designed: http://webpki.org/auth-token-4-the-cloud.html The idea is creating a complete technical solution for issuing, managing and using credentials (PKI, OTP, Information Card, U-Prove etc) over the internet using a [future] standard browser. It may be hubris but so far I haven't found any showstopping technical issues at least. Only browser integration and market acceptance remains :-) :-) Regards, Anders *] - No PIN provisioning - Unknown smart card support - No credential management support - No support for anything but PKI -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: DOMCrypt API developments
On 2011-06-20 09:29, Jean-Marc Desperrier wrote: Anders Rundgren wrote: The webcrypto-api proposal is oriented around certificate/X509/smartcard PKI, I end up with the feeling the two proposal lives in different realms. http://html5.creation.net/webcrypto-api Thanx J-M, I wasn't aware of this one. H**y c**p! Somebody is actually doing something! That proposal says it's using some of your ideas, so I didn't expect you didn't know about it. We have both come to the conclusion that Firefox et al sucks since just about all serious users need to deploy plugins in order to use their PKIs. Last I communicated with Channy it sounded like he planned to do something on the HTML level. Regarding technical solutions and proposals you now have three quite different takes on how to extend browsers. The gazillion messages on the OpenSC list indicates that token initialization is the #1 trouble. That's why I defined the whole stack from crypto HW to XML which is how Apple gets their stuff to work so great. Having one team create a protocol, another writing a browser, a third writing middleware and then add the different cards you will never get system that can be manag by an average user. Anders -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Update: Browser Crypto Protocol Invocation
Some three years ago I published a proposal on how browsers could be extended with potentially more powerful, XML-centric variants of keygen, signText(), CertEnroll, etc,. Given the recent work on JSON-based security-protocols in the IETF, as well as some old-timers clinging on to ASN.1, I have revised it to be fully format-neutral. http://webpki.org/papers/web/XMLBrowserExtensionScheme.pdf Feel free dissing :-) Yes, the name still says XML but I just kept the old URL... --Anders -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: DOMCrypt API developments
On 2011-06-17 15:31, Jean-Marc Desperrier wrote: David Dahl wrote: I find this API effort very interesting, however I'm left with the feeling you wish to leave out the use of PKI elements. A really neutral API would work both with and without PKI. Public Key crypto is actually the main use case of this API. I meant more certificate/X509 based PKI, and I've reached the conclusion that's very certainly *not* the main use case of this API. The webcrypto-api proposal is oriented around certificate/X509/smartcard PKI, I end up with the feeling the two proposal lives in different realms. http://html5.creation.net/webcrypto-api Thanx J-M, I wasn't aware of this one. H**y c**p! Somebody is actually doing something! -- Anders -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: DOMCrypt API developments
On 2011-06-14 16:48, Jean-Marc Desperrier wrote: David Dahl wrote: From: L. David Barondba...@dbaron.org On Monday 2011-06-13 15:31 -0700, David Dahl wrote: In trying to get the word out about a browser crypto API I am championing (see: https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Latest ), I wanted to post here for feedback and criticism. Hmm, I may as well respond here, though I'm a little concerned about how many places the feedback on this is going. I am trying to communicate this to as many interested parties as possible. I also don't want to force anyone to join another list to offer feedback. I am not planning to post this to any further mailing lists. However you did not post this to the obvious choice of mozilla.dev.tech.crypto. I find this API effort very interesting, however I'm left with the feeling you wish to leave out the use of PKI elements. A really neutral API would work both with and without PKI. Given the open discussions on key generation / smart card interface requirements on this list in the past, it is probably better to just get something out of the door and see where that leads you. Anyway, a problem with this particular draft is that there are (IMO) too few described use-cases. Client-based encryption of credit card numbers which has been mentioned as a valid DOMCrypt use-case sounds like a cool idea at the 1m level. When you look closer you will find that it severely disrupts existing business processes. There *may* be other more easily accessible use-cases but the experiences we have to date with *message encryption* (in contrast to transport encryption), are less than satisfying. Sure, security *is* important but not at the expense of convenience! Skype, HTTPS, SSH, and IPSEC already perform encryption for the masses without the users ever needing to know what encryption is. Unfortunately there is another fundamental issue as well... Microsoft's CertEnroll demonstrates the drawbacks of performing multi-step cryptographic operations from untrusted browser code into the trusted platform. You typically end-up with a bunch of hard-to-set security/privacy parameters or confuse users with questions they don't understand. This is the sole reason why KeyGen2 runs as an *trusted application* where everything from message order and content to access to critical resources and GUI is handled analogous to how HTTPS is implemented in browsers. Although the interest from the browser-community so far has been zero, I intend making the invocation/extension mechanism of KeyGen2 available for anybody to use. A handful of trusted crypto applications may indeed prove to be more useful than a universal (but de-facto quite crippled) crypto API. -- Anders -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: keygen CRMF on Firefox for mobile
On 2011-05-12 19:52, Honza Bambas wrote: On 5/9/2011 10:52 PM, Michael Helm wrote: This flavor of firefox 4 Useragent string: Mozilla/5.0 (Android; Linux armv7l; rv:2.1.1) Gecko/ Firefox/4.0.2pre Fennec/4.0.1 (which can be installed on Android phones tablets) seems to lack a functioning keygen magic tag, or the crypto object. The browser doesn't seem to react well at all even to a test for crypto. Any insight into this appreciated. The crypto object has been disabled on the mobile version of Firefox (= Fennec). That has been done in bug 561244. Bug 582297 is about to renew this functionality. I have no information on when/whether it will be delivered, but the priority (AFAICT) is not high. Adding keygen would be pointless unless integrated with the rest of the Android platform so that apps could use keys as well. Due to the closed development process it seems that this is more or less unachievable as well. Open Source comes in many flavors :-| Anders -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
PKIX enrollment activities
Dear NSSers, It seems that enrollment of credentials has finally gotten the attention it deserves: http://www.ietf.org/mail-archive/web/pkix/current/msg29024.html Anders -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Google's Chrome. Was: Root certificate authorities
On 2011-03-13 16:36, Honza Bambas wrote: On 3/5/2011 9:22 PM, Nelson B Bolyard wrote: There's an unfinished set of code in Mozilla's CVS repository that implements a PKCS#11 module on top of MS CAPI, enabling access to certs and keys in Windows' cert and key stores. Read about it in http://mxr.mozilla.org/security/source/security/nss/lib/ckfw/capi/ Nelson, are there any movements to finish this ones? I could potentially work on it as I'm mainly a Windows developer. -hb- Is your intention to get the best of two worlds with respect to Root CAs? I wouldn't recommend that. Google's Chrome hooks into Windows and does not add anything AFAICT. That is really what most Windows users prefer. Anders -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Why porting NSS to Android won't work
Well, of course it works. But it won't provide much value. Why? Because Android's security model (which I like) allows you installing Apps that may do potentially bad things without corrupting the OS. One such bad thing is (for example) using keys of other Apps to do background transactions. The only way to thwart that without completely revising the security model is to tag keys in such a way that only apps specified by the issuer will be allowed using a specific key. This is only possible if you integrate the key handling in the OS itself. It also requires a way to describe and issue tagged keys. Other features needed are trusted path PIN input which is about a key attribute telling that that a key can only be unlocked by a PIN going through a trusted path of the OS. That is, even if you steal a PIN through a spoofed GUI, you wouldn't be able to use it except through physical access to the device. Pardon for being a PITA but mobile phones should IMO not inherit all the legacy c**p we have in desktop systems. Anders Rundgren -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: TLS-SRP (was Re: J-PAKE in NSS)
On 2011-03-10 09:32, Daniel Stenberg wrote: On Wed, 9 Mar 2011, Anders Rundgren wrote: It is too late introducing TLS-SRP, the market will not use it. Uh? There's not just one single market that will or won't use a particular protocol feature. There are plenty of different areas where TLS is used and some of them will use TLS-SRP, and some even already are. TLS-SRP doesn't do anything that certificates do not do better. If SRP had been available in the browser it could have been important. But it failed, hard. Anders -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: TLS-SRP (was Re: J-PAKE in NSS)
It is too late introducing TLS-SRP, the market will not use it. Why not make NSS more useful for certificates instead? Anders On 2011-03-09 09:45, Jean-Marc Desperrier wrote: Brian Smith wrote: An augmented PAKE user authentication protocol might be very useful for some things, but TLS-SRP seems very troublesome. IIRC, there are at least four deal-breaking problems with TLS-SRP as a substitute for PKI: I don't see it as a substitute for PKI, only as a substitute for user/password. And my point from start was not really that NSS must implement an EKE protocol, but that if there was one then it should be SRP rather than JPAKE. BTW about the patent situation, I did my research, the conclusion is that they are various patents about everything EKE, but SRP has the advantage above most others protocols, including JPAKE, that Stanford owns a patent on it (the license is free for any usage) whose claims are apparently not shared with other existing patents, so if someone wants to claim rights on it, they'd first have to show Stanford shouldn't have received this patent. Not that this never happens (cf Microsoft/Lucent/Fraunhofer), but it's still much less likely than to just to hope nobody will ever claim rights on the format you're using. 1. The user's username is sent in the clear. The user's username should be protected. You mean for privacy reasons, not as a way to limit brute force attacks ? Although I don't see SRP as a replacement for PKI, I'm tempted to say that the equivalent of the username in PKI is the certificate, and that the certificate is not protected at all. In a SSL session with client authentification, the client certificate is sent in the clear (except in the case of IIS, that open a non-authenticated SSL session and renegotiates it at the time it needs user authentication). 2. The strength of the authentication of the website to the user is a function of the strength of that user's password; that is, a user with a weak password will have a very weak assurance of the server's identity. (I don't remember if this is exactly correct, but I think so.) That seems correct to me, and that's really an important point to take into account for the security of SRP based solution, thanks. 3. The user cannot verify the identity of the server until after the password has been entered. However, we've trained users to enter their passwords only after verifying the server's identity. The rule doesn't change so much : you still need to enter your password inside a secure element, ie if we teach user it's OK to enter their SRP password in a non secure GUI because it won't be sent to the server we loose. 4. You cannot identify the server until after you've created a username/password on that server. But, account creation usually requires giving the server personally identifying information that should be protected by encryption and only sent after the server has been authenticated. Using the TLS_SRP_SHA_RSA_* cipher suites avoids problems #2 and #3 and using a non-SRP ciphersuite for account signup solves #4. But, that requires using PKI and #1 is still a big problem. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Personal crypto device (or smart card) success stories?
Aug 30, 2007 (!!!) Nelson Bolyard wrote: /NSS, the crypto software used in mozilla browsers and email clients, was one of the first adopters of PKCS#11, the interface standard for crypto devices like smart cards and USB crypto fobs. Network client products that use NSS have been able to work with a large variety of crypto devices from various vendors for a decade now. But for much of that time, it was not economical for individual users to get their own crypto devices. In quantities of 10,000, the prices were reasonable, but if you only wanted to buy one or two, the prices were well over USD $100 each, for a long time. As an NSS developer, I was frustrated that crypto devices were economical for my employer, but not for me personally. I had the use of a crypto device provided by my employer, but the keys in it were the property of my employer, and they could legally take them whenever they wanted. I wanted a device of my own, that I owned, and that on-one had the right to use, except me. But it just wasn't economical. Now that seems to have changed. Good USB crypto devices can be had for less than USD $50, and really good ones for well below $100. Today, I'm using an Aladdin eToken Pro USB device with enough memory to store all the certs and private keys I'll need for a few years to come. It works very well with Mozilla, FireFox, Thunderbird, SeaMonkey, etc. I'm using it with Aladdin's software on Windows, but Linux drivers are also available through OpenSC. I bought mine from startcom.org. I'm very pleased with it. It's mine, all mine! :-) So, I'm wondering. Are others on this list also using their own personal smart cards or crypto devices (not their employers, but theirs personally)? Are they working well for you with mozilla products? With other products? Would you recommend the product you use to others? What did it cost you? On what platforms is is supported? Obviously, I don't want to turn this into a big advertising opportunity, but I figure if people are telling their own personal success stories about products they personally bought (like I did), we shouldn't go too far off into advertising land./ The somewhat bigger question is why we should care about smart cards when you effectively must have some kind of CMS (Card Management System) to make on-line credential distribution useful also for people without a PhD in cryptography. Firefox has AFAIK not improved on this point since 199X. Since PKCS #11 as been attested [1] by Bob Relyea doesn't actually address the enabling part at all, there's obviously quite a few holes in the NSS vision. It is in this context worth mentioning that Microsoft recently put their quite interesting CardSpace client on the backburner [2] since they never managed to make work with smart cards (which comes as no surprise since this part essentially is stuck in a form tailored for Windows 98). If we are really serious about competing with passwords it must be exactly as easy for the end-user getting a certificate as it is defining/getting a password. It's that simple. Or hard if you prefer that :--) Anders [1] http://groups.google.com/group/mozilla.dev.tech.crypto/msg/20810995b57e6808 [2] http://blogs.msdn.com/b/card/archive/2011/02/15/beyond-windows-cardspace.aspx -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Two-factor auth for Bugzilla
aerow...@gmail.com wrote: On Tue, Feb 1, 2011 at 1:19 PM, Marsh Ray ma...@extendedsubset.com wrote: On 02/01/2011 02:41 PM, Anders Rundgren wrote: What about the client cert in a smart card? That's old and standard and supported by Mozilla. I don't know what kind of prices you'd have to pay for small quantities though. $119 if you go with ACOS5, gives you 10 cards, a usb token, and two readers (one fullsize and one SIM factor). It also includes the developer documentation and tools, and of course the PKCS11 module. Since I was CC:ed I would just like to point out that this offering and and a ubiquitous web-token have fairly little in common. Web-tokens will emerge on iPhones because Apple knows how to make high-tech usable for consumers. That Apple also has a master plan including becoming a PayPal competitor of course helps a bit :-) Web-tokens are provisioned on-line using end-to-end-secured methods which excludes Mozilla as well as NSS. Anders R -Kyle H -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: NSS SoftToken Capabilities
Robert Relyea wrote: snip Token provisioning is outside the PKCS #11 module. It uses global platform secure channels to communicate to the card. The APDU's are specific for the cards applet. Yes, and this is why Firefox and other browsers are slightly incompatible with the web from a client-side PKI perspective since none of the above is likely to ever be supported from a browser down to crypto middleware and token. Therefore I maintain that a high(er)-level E2ES provisioning scheme like SKS will eventually make PKI a better password, not only for security reasons but also from a usability perspective. SKS does not build on Global Platform because GP is tied to a business model which IMHO makes GP less suited for an Internet populated by a gazillion of users and providers. You should be able to buy an Internet token at Wal-Mart that can be used as is without awkward driver installation. Such functionality might one day even be a part of NSS since SKS is designed to be a companion API to PKCS #11 :-) Anders http://webpki.org/auth-token-4-the-cloud.html -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: NSS SoftToken Capabilities
Matej Kurpel wrote: On 4. 1. 2011 22:23, Robert Relyea wrote: On 01/03/2011 01:04 PM, Anders Rundgren wrote: Hi, I'm in the starting phase upgrading Firefox so that it can provision credentials in a way that that banks and governments require which among many things include E2ES (End-to-End Security) and issuer- specified PIN-codes (or just policies for user-defined dittos). The plan is mainly focusing on (enhanced) HW-tokens which NSS due to its PKCS #11 heritage doesn't support with any of the above. However, for soft tokens where all is running in user-space, the distinction between middleware and the container is mostly academic so it could be an idea supporting the NSS softtoken. Unfortunately, I know rather little about NSS so I wonder if the idea is feasible or not. Q1: Is is correct that you can only have a single PIN for all soft tokens? You have a single pin per 'slot'. Any PKCS #11 module can implement multiple slots. You can even cause the NSS softoken to have multiple slots. I also think that there is a definition on how to do key specific pins in the later versions of PKCS #11. I think it involves using a special user type, with the key operation already selected in the current session. I'd have to go back and look, it might also just be I'm remembering the AUTHENTICATE_ALWAYS semantic. Yes, it's CKA_ALWAYS_AUTHENTICATE attribute set to TRUE for a private key and, unfortunately, NSS currently does not support this. I don't know exactly how to interpret this... Does the softoken support PINs or not? How do you set it from Firefox? OTOH, it would be strange if it did since none of the upstream components like keygen has any support for PIN provisioning. Most serious users of soft token PKI due that distributes their own provisioning and keystore SW and that won't change because I say it should. It probably takes Apple or Google to get the priorities straight ;-) anders Q2: Is it possible to add arbitrary data attributes to a key? I need such in order to support credential logotypes and information cards. If these general token types, I suggest getting them added to the PKCS #11 working group. PKCS #11 also allows vendor defined attributes and objects. We use these to supply NSS specific operations and objects, that aren't generally interesting to the PKCS #11 group as a whole. If the ideas are generally usable by a myriad of tokens, then trying to get them defined in the working group is best. CKA_VENDOR_SPECIFIC (0x800) and above. For example, NSS uses some vendor-specific attributes such as the value of CKO_NETSCAPE_CRL for CKA_CLASS attribute. You can implement such vendor-specific attribute as well. There is also an already define generic 'data' object. If these objects aren't really attached to the key , then it's own object type would make more sense. bob thanx, Anders M. Kurpel -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
NSS SoftToken Capabilities
Hi, I'm in the starting phase upgrading Firefox so that it can provision credentials in a way that that banks and governments require which among many things include E2ES (End-to-End Security) and issuer- specified PIN-codes (or just policies for user-defined dittos). The plan is mainly focusing on (enhanced) HW-tokens which NSS due to its PKCS #11 heritage doesn't support with any of the above. However, for soft tokens where all is running in user-space, the distinction between middleware and the container is mostly academic so it could be an idea supporting the NSS softtoken. Unfortunately, I know rather little about NSS so I wonder if the idea is feasible or not. Q1: Is is correct that you can only have a single PIN for all soft tokens? Q2: Is it possible to add arbitrary data attributes to a key? I need such in order to support credential logotypes and information cards. thanx, Anders -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
On-line provisioning of keys in NSS
http://www.gsmworld.com/newsroom/press-releases/2010/5726.htm As I said a million times before, on-line provisioning of HW tokens is the future. My take on this subject is (still...) defining a standard container based on Open Hardware because E2ES (End to End Security) cannot be abstracted (due to MACs); it is concrete by nature. That you as a side-effect gets a unified driver as well may turn out as the most significant thing in the end. Who (in their right mind...) *likes* smart card middleware? Due to the E2ES requirements, relics like CertEnroll, keygen, and generateCRMFRequest() will hardly be around five years from now but there will be a veritable war regarding their replacements. Regarding NSS (which I have no deeper knowledge of), I wouldn't be surprised if most of the contenders will come to the same conclusion as I have which is that Using keys and Provisioning keys are quite distinct, and therefore do not particularly gain by being cast in a single API like PKCS #11, at least not if on-line E2ES is to be honored. PKCS #11 is probably OK as is, while on-line provisioning is more like starting at square one :-) thanx, Anders -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: EC point compression
David Stutzman wrote: I'm assuming not based on my experience, but does NSS support point compression on EC keys? Dave Isn't that a thing that Certicom have patented? -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: [seek-for-android] Re: Port Mozilla NSS/JSS to smart phone platform
May I comment a bit on this? msm Li wrote: Currently, the smartphone platform is lack of unified software/hardware security module. For example, iPhone stores certificates in the Keychain, BlackBerry stores certificates in BlackBerry device key store, Android has no such secure storage. True. This project is intended to provide a unified interface/framework/middleware to access/manage secure elements for storing certificates and private key and making various PKI operations, such as signing and encryption. That's good. The secure applications can be built on top of the framework, for example, Mobile Wallet applications, such as credit card app, debit card app, identity card app(SSN app in US), driver license app, medical card app, even use your phone to vote in election, ... Absolutely! These applications can transparently make various PKI operations regardless of underlying hardware components, a file system, a SIM card, a NFC chip, a secure µSD card, ... Here I be to disagree. The industry has worked for ages to abstract PKI interfaces so that they could use any underlaying crypto module. Has it worked out well? No, it has worked incredibly bad making us entirely dependent on third-party drivers. Take a peek in the list: http://www.opensc-project.org/pipermail/opensc-devel and you will find plenty of evidence that you are looking for problems that haven't been properly solved in the PC world and has an even less chance of getting ironed out on mobile phones since there is no easy way upgrading/installing 3rd party drivers, not to mention keeping them in shape for the ever-changing mobile OSes. You should also be aware of the fact that secure provisioning requires communication on the APDU level which is entirely at odds with NSS, JCE, PKCS #11, MS-CAPI etc. Due to this I think you should consider dropping NSS and start over with something like described here: http://www.ietf.org/mail-archive/web/keyprov/current/msg00999.html Mozilla's keygen is an example of a scheme that was OK 15 years ago but it has little relevance today except for marginal deployments used by trained people. I think that you need to look on the whole ekosystem in order to create something useful. If somebody are interested we could have a skype conference about how we could solve something non of the platform vendors have succeeded with! Regards Anders The FireFox is the most widely ported application, it runs on Windows, Mac, Linux, Unix, ... Most importantly, people uses it to do online-banking, online-shopping in daily life. The NSS/JSS, one component of FireFox, supports cross-platform development of security-enabled applications. It supports PKCS #5, PKCS #7, PKCS #11, PKCS #12, S/MIME, TLS, SSL v2 and v3, X.509 v3 certificates, and other security standards. Furthermore, NSS itself is comply with FIPS 140-2, it is crucial cretia to meet requirements of governments and financial institutions. The proven tracking records of NSS/JSS have made it a perfect choice for managing security on smartphone platforms. The popular smartphone platforms are listed as follows : Platform Develop Language Android phone/tablet Java/C iPhone/iPad/iPod C Symbian/Maemo/MeeGo C BlackberryJava Windows Mobile C Palm Pre/webOS C Currently, the targeted plaforms of porting NSS/JSS are Android and iPhone. It is understood that not every platform vendor provides suitable development kit to build NSS/JSS. It is desirable to have platform vender support. Other related open-source projects are listed as follows for reference: 1) Android™ Keystore V2 http://android-keystore-v2.webpki.org/ http://webpki.org/auth-token-4-the-cloud.html 2) Secure Element Evaluation Kit for the Android platform http://code.google.com/p/seek-for-android/ 3) CoolKey http://directory.fedoraproject.org/wiki/CoolKey 4) OpenSC http://www.opensc-project.org/opensc 5) PCSC-Lite http://pcsclite.alioth.debian.org/ 6) MUSCLE http://www.linuxnet.com/info.html On Wed, Aug 25, 2010 at 5:11 PM, Wan-Teh Chang w...@google.com wrote: On Wed, Aug 25, 2010 at 1:39 PM, msm Li mlim...@gmail.com wrote: First thing first, does Mozilla have such plan to port NSS/JSS to smart phone platform ? Mozilla doesn't use JSS, so Mozilla is unlikely to work on porting JSS to new platforms. Mozilla is porting NSS to Android. I have not seen any NSS patches for iPhone, so I don't know if Mozilla is porting NSS to iPhone. I am interested in the project you proposed. Why do you want to port JSS? Wan-Teh -- 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: Port Mozilla NSS/JSS to smart phone platform
I have one question: Why would you want NSS in Android? The reason I wonder is because apps in Android are mainly written in (sort-of) java and both bouncycastle and openssl are already on-board. If you really want to make a change that would be adding a useful way to get keys on mobile devices because that part sux beyond belief. Well, actually the regular Firefox (and MSIE) is pure crap in *this* respect. Related: http://android-keystore-v2.webpki.org http://webpki.org/auth-token-4-the-cloud.html Anders msm Li wrote: Hi, all, I am writing this to you to propose a new and separate project to port Mozilla NSS/JSS to smart phone platform, currently target at Andorid and iPhone. The new means that I am not aware of such project exists. The separate means that it's separated from the fennec project which is to port FireFox web browser to smart phone platform. First thing first, does Mozilla have such plan to port NSS/JSS to smart phone platform ? The goal here is that take the source code archive, like nss-3.12.6-with-nspr-4.8.4.tar.gz and jss-4.3.1.tar.bz2, type make android or make iphone, you can build libraries for android or iphone. Secondly, has anyone outside of Mozilla already started such project ? Third, please voice your opinions regarding this matter. I've intentionally attach other related email discussions below to give more background. Thanks and regards. mli On Wed, Aug 25, 2010 at 1:09 PM, Aaron Lippold lipp...@gmail.com mailto:lipp...@gmail.com wrote: Hi All, Been crashing on a few things but hope to get to this as soon as I can. I am very very interested in keeping this going. The other part of this that we will have to work is getting the certificate manager and access to the right certificate stores without having to have a root;'d device. I the the certificate manger is a strait java script app so we may just have to rebuild it. The folks at the Seek Project: http://code.google.com/p/seek-for-android/ Have an app for managing the certs on hard tokens so perhaps they would be interested in expanding that or integrating with the Mozilla cert manager. Either way, it is a group with similar interests. Has anyone looked the bluetooth stack with all this? i.e. securing the DUN using the certs that are in the Mozilla store etc. Thanks, A On Tue, Aug 24, 2010 at 10:05 PM, msm Li mlim...@gmail.com mailto:mlim...@gmail.com wrote: Hi, Scott, Last week, I managed to build nss/jss at android, but when I ran it at android emulator, I got ReferenceTable overflow (max=512), then I sent an email, subject ReferenceTable overflow (max=512), to 4 groups: android-ndk, android-porting, dev-tech-crypto@lists.mozilla.org mailto:dev-tech-crypto@lists.mozilla.org and fennec-android-pre-al...@googlegroups.com mailto:fennec-android-pre-al...@googlegroups.com(this groip). I wish that someone can point me a direction how to solve the problem. I wish I am not the first one encountered this problem or I did something wrong. Aaron Lippold lipp...@gmail.com mailto:lipp...@gmail.com has replied to this group and asked Can you attach your build process and packages. I decided to post my building steps to this group, so other people can reproduce the problem or find where I did wrong. So far I have not received any response of solving the problem. I am not an expert of NSS/JSS, I wish that experts of NSS/JSS in this group or other group can help me to solve this problem. By the way, my VM ubuntu 10.04 file got corrupted, I can not start my building box. I've created another VM ubuntu 10.04, I followed the building steps, I still got the same error ReferenceTable overflow (max=512). Hopefully I answered your question. Best regards. mli On Tue, Aug 24, 2010 at 4:56 PM, Scott Steinhart shim0...@gmail.com mailto:shim0...@gmail.com wrote: If you dony mind me asking, to whom is this message directed? On Aug 24, 2010 4:51 PM, msm Li mlim...@gmail.com mailto:mlim...@gmail.com wrote: Building Steps of NSS/JSS at Android Platform Table of Contents : A. Download development tools B. Set up building environment C. Download nss/jss source code D. Apply patches E. Build nss F. Build jss G. Misc -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Locking down authentication keys
The following is mainly directed to people working with mobile devices although the issue of course also applies to PCs. Recently I had an interesting conversation with a security technologist of a major payment provider who had seen links to my SKS/KeyGen2 stuff [0]. He was quite concerned about how I intend to cope with Key Misuse. One solution is of course to lock-down the entire OS so that all applications actually have been verified as trust-worthy [1]. Being a free spirit I find such measures too restrictive and having a hampering effect on the market. It also greatly reduces the ability to run in-house applications that simply wont be sent for verification by a trusted third party. However, the mentioned requirement is highly legitimate since an authentication key is a door opener that should only be used by the actual key-holder. Therefore I'm plotting with the idea that keys could (during provisioning) be marked in such a way that a (trustworthy) OS could control that only granted applications are allowed to use a key. My question (but probably not the answer...) is really quite simple: Is there any universal way to identify applications that has a chance of working over the fairly wide range of operating systems that we have today? It is true that this fairly rudimentary scheme does not address traffic *inside* of an authenticated VPN tunnel but that is by design because it is a very complex topic and is already addressed by other efforts like TNC (Trusted Network Connect), while there is hardly any work going on on the *consumer* side. The latter is sort of understandable since there is no paying customer to be found anywhere :-( OTOH, it is a truly virgin territory with close to zero competition as well :-) Thanx, Anders [0] http://webpki.org/auth-token-4-the-cloud.html [1] http://www.zdnet.co.uk/news/security-threats/2010/08/11/android-handsets-hit-by-first-sms-trojan-app-40089792/ -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Fwd: Hi, I have three questions about embed bank CA cert in Firefox
On 2010-07-21 16:26, Amax Guan wrote: Thank you very much, it's very helpful. I put most of the replies inline. On Wed, Jul 21, 2010 at 8:30 AM, Gervase Markham g...@mozilla.org mailto:g...@mozilla.org wrote: On 20/07/10 04:23, Amax Guan wrote: I've got a problem help China Construction Bank(CCB for short) support Firefox. CCB has its own CA root, used to issue certificate to his users, and they issued some server cert using this cert. Do you know why they cannot buy a cert from a trusted CA, like every other business (including most banks)? I think basically it's because they have too much Cert to issue (One for each user), it cost too much money, and they do not want anyone else to know how many users they have, and their names, including the CA. Absolutely. It would be extremely inconvenient also- Kai mentioned that it's OK to use a untrusted CA signed user certificate in Firefox to sign, But they are not only using this cert in signing, they also use the cert for two-way SSL, and they periodically renew the cert. But if you generate a user Certificate that's issued by a untrusted CA, there will be an alert popup. If that's really true I would call it a bug. I guess it is renewal that really is the problem? keygen doesn't support renewals. Few if any end-user banks certificates have their root in browsers. The server cert I don't know why, but I guess maybe it's because they already have this CA system, they just want to save some money and time? I mean not every cert on their website is signed by themselves, they have verisign certificates on most of their webpages, but on some specific server, they use cert issued by their own CA. The server using their own CA is in the certificate generation process, I wonder is it related to two-way SSL or something? And btw, every bank in China has its own CA System, to generate user certificate. Yes, and that is how it should be, SSL certificates is another (hopefully unrelated) topic. Anyway, Chinese banks will some day get a solution in Firefox that actually addresses consumers (rather than cryptographers), but it will take some time to get it out of the door: http://webpki.org/auth-token-4-the-cloud.html Since US banks and Government Agencies do not use certificates for consumers and citizens this is primarily a European/Asian issue and we cannot expect to get any support from Mozilla except maybe a Good luck or so :-) Regards Anders Rundgren And they want to put their CA Root certificate into Firefox, so that there will be no alert popup in the certificate generate process and no security alert when users access their website. And here comes the questions Can you be more specific about the errors that people who bank with CCB encounter in the certificate generate process? They use keygen tag to generate the user certificate (They need to renew the certificate periodically), and the form is submitted to a cert page with contentType=x509/certificate or something like that. Firefox will automatically save the certificate to where it's corresponding key is, and after that popup an alert saying the cert is download successfully. AND THEN, if the CA of the cert is untrusted, Firefox will pop up another alert talking about Cannot import the certificate, the issuer of the cert is unknown, the cert is invalid or 1. Right now, we are trying to use certutil.exe in their USB-Key driver installer to do that. However, one of my colleague seems to have some problem build the certutil.exe in visual studio 2005. And sometimes, it fails to run on some machine. I tried to find a stable version of that tool through google, but I failed. Is there any stable version of certutil I can download, that will work on most version of windows? Or why is it so hard to build, is there some way to make it better? I don't know the answer to this particular question. Unlucky for me:( Because according to several emails I made yesterday, this way seems to be the most doable and effective way. 2. Since the certutil.exe solution did not went very well, we think maybe we could embed their CA cert in our Firefox China Edition. According to my knowledge, at least half of the population in China are CCB bank users, and cannot access online bank is our major problem in China, so we think this make sense. We can make an addon to do that, but it occurred to us that an addon is so open, that anyone that knows where it is can change the cert, or do something else dangerous. So, is there a better way to put the cert in? Maybe through a binary XPCOM is better? The Mozilla project does not issue copies of Firefox that trust new
Re: Fwd: Hi, I have three questions about embed bank CA cert in Firefox
On 2010-07-21 17:57, Amax Guan wrote: Hi Anders Thanks for your information. Do you know where I can download a windows binary of certutil.exe? Hi Amax, Try this SDK which is supposed to contain certutil.exe as well: http://www.microsoft.com/downloads/details.aspx?FamilyID=860ee43a-a843-462f-abb5-ff88ea5896f6displaylang=en But I can't imagine end-users dealing with such a horrible tool. This is for *cryptopgraphers* only. Making a Chinese Firefox distribution should be a more workable solution. Anders On Wed, Jul 21, 2010 at 11:32 PM, Anders Rundgren anders.rundg...@telia.com mailto:anders.rundg...@telia.com wrote: On 2010-07-21 16:26, Amax Guan wrote: Thank you very much, it's very helpful. I put most of the replies inline. On Wed, Jul 21, 2010 at 8:30 AM, Gervase Markham g...@mozilla.org mailto:g...@mozilla.org mailto:g...@mozilla.org mailto:g...@mozilla.org wrote: On 20/07/10 04:23, Amax Guan wrote: I've got a problem help China Construction Bank(CCB for short) support Firefox. CCB has its own CA root, used to issue certificate to his users, and they issued some server cert using this cert. Do you know why they cannot buy a cert from a trusted CA, like every other business (including most banks)? I think basically it's because they have too much Cert to issue (One for each user), it cost too much money, and they do not want anyone else to know how many users they have, and their names, including the CA. Absolutely. It would be extremely inconvenient also- Kai mentioned that it's OK to use a untrusted CA signed user certificate in Firefox to sign, But they are not only using this cert in signing, they also use the cert for two-way SSL, and they periodically renew the cert. But if you generate a user Certificate that's issued by a untrusted CA, there will be an alert popup. If that's really true I would call it a bug. I guess it is renewal that really is the problem? keygen doesn't support renewals. Few if any end-user banks certificates have their root in browsers. The server cert I don't know why, but I guess maybe it's because they already have this CA system, they just want to save some money and time? I mean not every cert on their website is signed by themselves, they have verisign certificates on most of their webpages, but on some specific server, they use cert issued by their own CA. The server using their own CA is in the certificate generation process, I wonder is it related to two-way SSL or something? And btw, every bank in China has its own CA System, to generate user certificate. Yes, and that is how it should be, SSL certificates is another (hopefully unrelated) topic. Anyway, Chinese banks will some day get a solution in Firefox that actually addresses consumers (rather than cryptographers), but it will take some time to get it out of the door: http://webpki.org/auth-token-4-the-cloud.html Since US banks and Government Agencies do not use certificates for consumers and citizens this is primarily a European/Asian issue and we cannot expect to get any support from Mozilla except maybe a Good luck or so :-) Regards Anders Rundgren And they want to put their CA Root certificate into Firefox, so that there will be no alert popup in the certificate generate process and no security alert when users access their website. And here comes the questions Can you be more specific about the errors that people who bank with CCB encounter in the certificate generate process? They use keygen tag to generate the user certificate (They need to renew the certificate periodically), and the form is submitted to a cert page with contentType=x509/certificate or something like that. Firefox will automatically save the certificate to where it's corresponding key is, and after that popup an alert saying the cert is download successfully. AND THEN, if the CA of the cert is untrusted, Firefox will pop up another alert talking about Cannot import the certificate, the issuer of the cert is unknown, the cert is invalid or 1. Right now, we are trying to use certutil.exe in their USB-Key driver installer to do that. However, one of my colleague seems to have some problem build the certutil.exe in visual studio 2005. And sometimes, it fails to run on some machine. I tried to find a stable version of that tool through google, but I failed. Is there any stable version of certutil I can download, that will work on most version
Re: During the Certificate issue process, is there anyway to select a token for user automatically?
Amax Guan wrote: Hi, I'm working on a Certificate renew process for a bank in china. The bank stored the certificate in a USB key, and when the user needs to renew the certificate, the bank will trigger the cert issue process to do that, using keygen. But when the issue begins, because the USB key, which is a token, is connected to the computer, that will cause the Firefox detect at least 2 tokens, and a dialog will popup and tell the user to select a token. But, if the user select the software token embedded in Firefox, which is the default choice, then the cert issue process will be in vain, although it may succeed. Is there anyway to automatically select a token for the user, So that the token choose dialog does not appear? Thank you very much in advance:) Hi Amax, keygen wasn't designed for usage by consumers (and particularly not for hard tokens); it was designed by Netscape some 15 years ago to enable client-certificate provisioning for people who actually know both what a token is and a certificate is. There is no easy fix to the specific issue you are pointing to and it has not been recognized by the HTML5 WG as an issue either although it as you say is a rather delicate problem. In a so far only emulator-ware keygen replacement proposal of mine, the above situation is handled by indicating token type (soft, embedded, external, any) which in most (but not all) cases eliminate token container selection dialogs. Since banks in the US are ten years behind EU and Asia when it comes to PKI for consumers, I guess we cannot expect Mozilla to do anything about keygen :-( Anders -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: During the Certificate issue process, is there anyway to select a token for user automatically?
Amax Guan wrote: Hi Anders, Thank you very much for your reply, and I like your suggestion, I think the token parameter will handle most cases. However, it seems it's not gonna happen fast enough for my case. So, is there a alternative way other than keygen that can be used to solve this problem? I checked the generateCRMFRequset way, but it seems it cannot specifies the token either. Besides, I have not found a good way to handle the CRMF/CMMF from the server side yet, I heard JSS can do the trick, but changing the whole server architecture for this seems not a very promising solution for the bank, but that's another story. Back to the topic, I read from another email that the website JS when given the authority to use XPCOM, can be used to detect whether a hardware token is connected to the machine, and which token that is. Is there a way to maybe specify the token used to generate the certificate request, and generate the request using JS? Hi Amax, This is unfortunately outside of my knowledge but my gut feeling is that this is not feasible without the user installing something in Firefox since API access from untrusted browser code (=leaving the sandbox) is a feature browser vendors try to limit as much as possible. I guess it won't make you happy but the most common solution to this is completely avoiding using the browser's client-PKI implementation and rather use a Java applet because this also works in MSIE which is a browser most banks need to support as well. Microsoft's keygen is more powerful but they have no good solution for hardware tokens either unless you can control every tiny bit in the installation. A free example that you could use is here: http://www.openoces.org/index.html Regards Anders On Sun, Apr 11, 2010 at 4:18 PM, Anders Rundgren anders.rundg...@telia.com wrote: Amax Guan wrote: Hi, I'm working on a Certificate renew process for a bank in china. The bank stored the certificate in a USB key, and when the user needs to renew the certificate, the bank will trigger the cert issue process to do that, using keygen. But when the issue begins, because the USB key, which is a token, is connected to the computer, that will cause the Firefox detect at least 2 tokens, and a dialog will popup and tell the user to select a token. But, if the user select the software token embedded in Firefox, which is the default choice, then the cert issue process will be in vain, although it may succeed. Is there anyway to automatically select a token for the user, So that the token choose dialog does not appear? Thank you very much in advance:) Hi Amax, keygen wasn't designed for usage by consumers (and particularly not for hard tokens); it was designed by Netscape some 15 years ago to enable client-certificate provisioning for people who actually know both what a token is and a certificate is. There is no easy fix to the specific issue you are pointing to and it has not been recognized by the HTML5 WG as an issue either although it as you say is a rather delicate problem. In a so far only emulator-ware keygen replacement proposal of mine, the above situation is handled by indicating token type (soft, embedded, external, any) which in most (but not all) cases eliminate token container selection dialogs. Since banks in the US are ten years behind EU and Asia when it comes to PKI for consumers, I guess we cannot expect Mozilla to do anything about keygen :-( Anders -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Fixing it Re: import key pairs but un-exportable private key
Nelson B Bolyard wrote: snip keygen since a CA has no options for key protection during issuance using Firefox which it has using MSIE. Yes, I quite agree with you on this point, Anders. The problem is that the CA cannot express to Firefox that it wants Firefox to require that the generated key be unextractable. Exactly. It might be of interest knowing that hardly any bank in the EU (many use soft certificates) have bothered with MSIE or Firefox keystores at all, since banks require PIN-codes which is a feature they are accustomed with. Due to this they have their own client software for both auth and keygen. Yes, you've told us that frequently. Have you now written an add-on for Firefox and an .ocx or BHO for MSIE that implements the same new cert enrollment html or JavaScript feature in those two browsers? If so, please provide a URL for the web site describing them. Then we'll see if there's any follow-up interest here. I think this is why not even mighty Microsoft have been able to come up with something useful: You need an *inter-disciplinary* solution that is architected. Xenroll is just an ugly hack to bypass the awkward internal architecturing process. BTW, regarding technical solutions, I have in an earlier posting (keygen NG) described what *I* consider the right approach. So far I have been unable to get any feedback on that which I guess either must depend on a bad description or as I suspect, limited interest in fixing on-line provisioning since the demand almost 100% comes from non-paying entities like governments and banks in foreign places. I have of course not given up this by no means but I'm looking for funding because it is a $500K+ project even when running as Open Source. Anders -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: import key pairs but un-exportable private key
Hi Mountie, A service provider cannot specify *anything* regarding key protection using Firefox. Anders Mountie Lee wrote: Thanks Eddy. in IE the service provider can choose the private key can be exportable or not. the manual configuration is not so attractive for service provider. is it possible to enable FIPS mode by providing checkbox or some other ways by server? On Thu, Apr 8, 2010 at 7:49 PM, Eddy Nigg eddy_n...@startcom.org mailto:eddy_n...@startcom.org wrote: On 04/08/2010 01:41 PM, Mountie Lee: Hi. I'm Mountie. Hi Mountie... in Firefox is it possible to make private key in keystore as un-exportable that the key was imported from outside. Did you try to activate FIPS mode? See Preferences - Advanced - Security Devices - Enable FIPS. -- Regards Signer: Eddy Nigg, StartCom Ltd. XMPP:start...@startcom.org mailto:start...@startcom.org Blog:http://blog.startcom.org/ Twitter: http://twitter.com/eddy_nigg -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org mailto:dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto -- Mountie Lee Tel : +82 2 2140 2700 E-Mail : moun...@paygate.net mailto:moun...@paygate.net Twitter : mountielee === PayGate Inc. * WEB STANDARD PAYMENT * PCI DSS v1.2 COMPLIANT * www.paygate.net * payg...@paygate.net -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: import key pairs but un-exportable private key
Nelson B Bolyard wrote: snip Hi Mountie, A service provider cannot specify *anything* regarding key protection using Firefox. Anders, I think Mountie was referring to Crypto Service Provider (CSP), which is Microsoft's name for software modules that follow Microsoft's alternative that is approximately equivalent to the PKCS#11 standard. snip I thought the following line of Mountie the manual configuration is not so attractive for service provider referred to Firefox's inferior key generation concept. Although MSIE absolutely also is crap, it does indeed allow a service provider (CA) to set quite a bunch of parameters during key generation. Sorry guys, but keygen will haunt you until it is finally replaced with something that addresses post-1995 requirements :-) Anders -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: import key pairs but un-exportable private key
- Original Message - From: Nelson B Bolyard nel...@bolyard.me snip I think he's referring to the fact that the PKCS#11 module must be manually configured to be in FIPS mode or not in FIPS mode. I'm not aware of any automatic protection settings for manual key import in Windows, unless you can do it with some PKCS #12 magic. OTOH when you do manual key import you have what it takes to steal the key without any programming so Mountie's concerns seems a bit unjustified since importing keys this way is for experts only. Mountie, please tell us what you meant. Thanks. Agreed :-) Anders -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: import key pairs but un-exportable private key
Mountie Lee wrote: I mean CKA_EXTRACTABLE. as a Sub-CA, when they issue client certificate, they want to make sure the private key will be exported outside of browser keystore. the only one exception is when the private key is in hardware token, it can be moved to other browser. I didn't get that one. Why do they want keys to be exportable? I thought it was the opposite. this is one of main reasons that many banks are not allow firefox. I have business account in Japanese banks. the bank authenticate client with certificate and private key. they keep strong policy that do not allow private key being exportable. Although the Mozilla people may express things differently, the source of the problem is not in PKCS #11 (it has everything that is needed), but in keygen since a CA has no options for key protection during issuance using Firefox which it has using MSIE. It might be of interest knowing that hardly any bank in the EU (many use soft certificates) have bothered with MSIE or Firefox keystores at all, since banks require PIN-codes which is a feature they are accustomed with. Due to this they have their own client software for both auth and keygen. Anders -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Signing using JS in Safari
Hi Sunny, I haven't heard about Message Pro. Here is an open source (free) applet plugin: http://www.openoces.org/index.html It is used in Denmark and maybe somewhere else as well. In Sweden the government has spent some $30M over the years on: http://nexussafe.com/en/Products/Nexus-Personal IMO, both solutions are inferior but since they are actually used it doesn't really matter :-) It interesting to note that many signature plugins come with an authentication plugin which unifies the PKI GUI which using TLS is quite terrible. Some crypto people think that replacing TLS-client-cert-auth with an application-level authentication mechanism is a bad thing but there are tons with drawbacks using TLS-client-cert-auth and there is no hope for improvements and the alternatives are already in place. Even USPTO have selected an Java applet for PKI login... Anders Sunny wrote: Hi Anders, Thanks for your mail. Is there any proprietary solution that's named Message Pro or so?? On Apr 6, 5:26 pm, Anders Rundgren anders.rundg...@telia.com wrote: Hi, Since there are no standards in this space most banks and e-governments use proprietary (but cross-browser) Java plugins. In the EU there are at least 10 different national schemes. Chrome and Safari presumably do not support any pre-configured solution since no such solution has gotten any traction worth mentioning. There is a lot of stuff you can buy though... Anders Sunny wrote: Hi, I'm not able to find any literature on the topic of Signing data using Digital Certificates with JS in Safari browser. like, in Firefox, we have window.crypto.signtext() method that you can call from Java script to select a certificate and sign the data using the certificate. For IE, we have a CAPICOM plug-in to do that. Do we have anything in chrome/safari that will help signing using Digital Certificates in java script? Please let me know. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Signing using JS in Safari
Hi, Since there are no standards in this space most banks and e-governments use proprietary (but cross-browser) Java plugins. In the EU there are at least 10 different national schemes. Chrome and Safari presumably do not support any pre-configured solution since no such solution has gotten any traction worth mentioning. There is a lot of stuff you can buy though... Anders Sunny wrote: Hi, I'm not able to find any literature on the topic of Signing data using Digital Certificates with JS in Safari browser. like, in Firefox, we have window.crypto.signtext() method that you can call from Java script to select a certificate and sign the data using the certificate. For IE, we have a CAPICOM plug-in to do that. Do we have anything in chrome/safari that will help signing using Digital Certificates in java script? Please let me know. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Using of HTML keygen element
Wan-Teh Chang wrote: Does anyone know why HTML5 specifies keygen must use the md5WithRSAEncryption signature algorithm? Was the use of MD5 discussed when keygen was standardized in HTML5? Eddy, does your CA accept a SignedPublicKeyAndChallenge (SPKAC) structure signed using sha1WithRSAEncryption? Wan-Teh I don't think that the hash function over the request that - is used once - is impossible to link to a particular container - is always used over HTTPS actually represents a problem since a (correctly written) CA ignores all but the public key when it issues the certificate. PKCS #10, SPAC, CRMF were not designed for browser provisioning since you in a browser scenario have a session making it fairly redundant sending stuff back and forth that you (the CA) already know. As a challenge the additional stuff is fine though.. BTW, keygen was never standardized[*], because that would have sinked the entire work since an average crypto standard takes years to complete. KEYPROV is now wrapping up after almost 4 years of work. Anders *] Nobody even cared to put together any requirements... -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
