Re: Problem reading certificate from hardware token
On 2009-07-03 04:33 PDT, Udo Puetz wrote: > What we've found out now is this: there is no CA certificate on the > token. And it seems that firefox needs the CA and the user certificate > from the same place: I don't believe it is true that Firefox requires both to be in the same token. > If I import a CA cert only into the authorities tab and plug in the token > I (naturally) have both, the CA and the user cert BUT in the details pane > there is still only the user cert there, it's NOT below the > corresponding CA cert. That's the problem. Agreed that the problem is that Firefox does not find the CA cert, but I think more investigation is needed. I highly doubt that the matter is purely one of where the cert is loaded (though it may seem that way). I have some ideas for more tests below. > That's why I reason that the CA and user cert have to come from the same > source, either the software storage or the token. But mixing the stores > doesn't seem possible. Except that I do that all the time. > My colleague is now trying to import the CA onto the token. As seen above > the p12 file includes both the CA cert and the user cert. Actually, I haven't seen evidence of that, although you did claim that when you imported the PKCS#12 file into the software token, that the missing CA cert was then found present. > But if one imports it with the safenet ikey token utility the CA cert > file seems to get lost. Seems to. I have a hunch that the CA certificate may have some issues that cause it to not be recognized as a CA cert. If you have a certificate that does not appear on its face to be a CA certificate, when you store it in Firefox's soft token, it can be marked with a flag that says "treat this like a CA cert, even if it's not a CA cert". This flag is known as the "Valid CA" flag. One possible explanation for what you're seeing is that that the CA cert is being marked with this flag when it is imported into the softoken from the PKCS#12 file, but is not being marked with that flag when it is imported into the hardware token. Consequently, it is not seen in the Authorities tab when it is in the token. It may be in one of the other tabs. > This seems now to be a problem with the token import utility. Do you > agree? Not necessarily, but perhaps. I can think of at least two explanations for the behavior you're seeing that do not imply that there is a problem with the token import utility. I can think of numerous tests that you could perform to better diagnose the problems, some of which use NSS utility programs that are not distributed with Firefox. Here are some tests you can try. 1a. Remove the token with the EE (SSL client authentication) cert. 1b. Import the PKCS#12 file into the software token again. 1c. Verify that this works (can client auth). 1d. Exit Firefox. Make sure that it's not running any more. 1e. Make a copy of cert8.db and key3.db in another folder. Let's call that folder "Pair1". 1f. Restart Firefox. 1g. Using Firefox's certificate manager, delete the EE certificate from "Your certificates" tab, but leave the CA certificate in place. 1e. Shut down and Restart Firefox, again. 1f. Insert the Token and authenticate to it (enter the token PIN). 1g. Now view the EE cert in the cert manager and see if Firefox finds the EE cert beneath the CA cert in the cert hierarchy pane. 1h. See if you can do client authentication there. Now, most of the rest of the diagnostics steps that occur to me involve using NSS command line tools that you probably don't have and with which you probably aren't familiar. So, rather than telling you how to get them, how to install them and how to use them, I'm going to suggest that you email me one file, namely the cert8.db file that you saved in "Pair1". I want only the cert8.db file, which contains only the public certificates, and not the key3.db file that contains your private keys, or any other DB files. I don't need any private keys to do this analysis I want to do. You can email it to the address from which this email comes. Regards, /Nelson -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Moving browser PKI forward (Re: Problem reading certificate from hardware token)
On 2009-07-03 05:29 PDT, Ian G wrote: > We desperately need some form of whitelisting in Firefox so that each site > always gets presented the same cert. If browsers can remember cookies > and username/passwords, then they can remember cert/domain combinations. This goes double for Thunderbird and mail servers, which are configured, not browsed. Bug 155089: Need a better way to associate a certificate to a mail account for authentication just had its 7th birthday. > As an aside, does anyone have any stats about how many people use these > non-Firefox security devices? I don't have numeric statistics. Users in certain countries, and users who are customers of certain banks, use them a lot. Banks in some countries give them away to customers. But elsewhere they're mostly used in "closed" corporate or governmental environments. (I guess banks and their customers are "closed" environments, too.) > It is somewhat clear that most end-users can't use these things, only > corporates can. So Mozilla priority for these things might be lacking. The average browser user doesn't even set/use a "master password". So, the site passwords that his browser remembers are stored "in the clear". The reason is not that the user doesn't know about master passwords. It's that users don't want to be bothered with a password request, EVER, not even once per browser process lifetime. These same users complain that Firefox has a dialog that will show them their saved web site passwords. They're (rightly) afraid that others will use this feature to steal their passwords when they're not looking. (Of course, they could also set their screen savers to require a password to unlock, but they don't do that, either.) When told that setting a master password will prevent Firefox's passwords from ever being shown without entering it immediately before the display, they balk at having to set a master password. They don't understand that, as long as the passwords are stored "in the clear", they're vulnerable, whether FF displays them in a dialog or not. My point is that I think the relevant questions are: - how many end users who *want* to use them can do so? and - What are the reasons they don't? I think we'll need something that is as widely accepted as a credit card before this takes off. But that by itself won't suffice. It will also require identity theft to get a LOT WORSE before the average consumer decides that having to lift a finger to protect himself isn't such a bad idea. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Moving browser PKI forward (Re: Problem reading certificate from hardware token)
On 2009-07-03 00:30 PDT, Martin Paljak wrote: > Some constructive suggestions; mostly for Firefox: > > 1. Use platform API-s where appropriate: cryptoapi (and basecsp via > this) on windows; cdsa/keychain on macosx. Regardless of who does it, this triples/quadruples the amount of work to be done and code to be supported. Google did that. I'm not opposed to it, if Mozilla wants to fund it. > FYI, to make sense to users of eID cards currently one has to embed > the word PIN into the token description as well, so that the prompt > that Firefox displays would make sense: "Please enter password for: > MARTIN PALJAK (PIN1)" GUI hints would be useful... Please elaborate. > 2. Fix Firefox/NSS - Firefox still thinks that you should be able to > authenticate to websites with certificates *without* TLS client > authentication extension. Add automatic certificate selection, and you > get trouble. Extended Key Usages do not ADD to a cert's capabilities. They take way from it. A cert with no EKU extension is valid for all EKUsages (with very few exceptions - only one comes to mind). But it's certainly true that if Firefox will take a cert with an EKU extension that does NOT include TLS client auth and use that for TLS client auth, that's a bug, pure and simple. File a bug on it if you have a working example. > 2a. I don't know if the defaults have changed lately, but allow the > end user to define the "friendly certs" option for PKCS#11 tokens, > which currently has no UI except the Javascript loading function which > got removed from UI land and moved to XPI land in FF 3.5. There are > tokens that require this feature, but some PKCS#11 providers like > OpenSC which support many different tokens have no easy way to work in > both ways. I agree that one way to fix this is to provide some UI by which the PKCS#11 module can be configured as friendly when it is added. but I think we can probably just figure it out with s simple run time test, and then ignore the configuration bit. That's a better solution, if we can make it work. Please file an RFE about this. > 3. For Firefox only: provide a useful JS interface to allow access to > keys which are not used for web authentication but present under "my > certificates" for real-life online signing procedures. Are you aware of crypto.signtext? (Please, No ranting!) If you are aware of it, please write specifics about what else you need that's not there. It produces a full CMS (PKCS#7) signature. Be aware that any proposed signature method that doesn't show the user what he's signing will probably not be allowed. So, a method to sign a bare hash, without knowing where it came from is a non-starter. A method to take data and hash it, and then sign that could be made to work, but that's what crypto.signtext does. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: client certificate JSS keystore
On 2009-07-03 10:52 PDT, Dmitriy Varnavskiy wrote: > I have run several tests of JSS on Linux - they all worked fine so seems > JSS is correctly installed. But when I am launching my app java for some > reason is not using certificates in firefox keystore. Thanks for being patient. Our JSS expert will be back from vacation next week. /Nelson -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: W3C Terminates XHTML2
On 2009-07-03 08:39 PDT, Anders Rundgren wrote: > This demonstrates that standardization is an option but an increasingly > difficult option as well in an ever faster-moving world: > http://www.w3.org/2009/06/xhtml-faq.html Does it? It appears to me that this is the standards body pruning the tree of html offshoots, recognizing a single standard for the "XML serialization of HTML". Now, I seem to recall that one of your complaints about the world of crypto is the lack of standardization of methods (e.g. scripting) for certain functions. I would think that you would see this effort to consolidate on a single standard to be aligned with your objectives. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: client certificate JSS keystore
I have run several tests of JSS on Linux - they all worked fine so seems JSS is correctly installed. But when I am launching my app java for some reason is not using certificates in firefox keystore. 2009/6/27 Dmitriy Varnavskiy > Fail means that window with prompt to select certificate appears. And list > of certificates in it is empty. > I believe that first request comes from java to jnlp file on server. I am > able to press cancel, closing appearing cert promts till application > loads(from cache actually, if not cached it fails to load), then comes first > request from application that results in 403 from server, cause certificate > is not present at request. I have found some info saying that binary > releases of JSS on mozilla ftp are not suitable for firefox use and I should > rebuild them manually with some other options(TARGET_OS=WIN95). Not sure is > it so or not - compiler fails with some errors on build. Maybe there are > binaries already builded this way available to download? > > 2009/6/26 Nelson B Bolyard > > On 2009-06-26 04:13 PDT, Dmitriy Varnavskiy wrote: >> > I am deploying javaws application that uses client certificate for >> > authentication. It is starting with jnlp ref from web page that also >> uses >> > client certificate. So, nedeed certificate presents in browser on client >> > machine. For application I first tried to import certificate through >> java >> > control panel. It generally worked ok, but asked user keystore >> > (trusted.clientcerts) password on every launch even if password was >> > initially set empty. Is there any way to eleminate this prompt? >> >> Someone here may be able to help you with that question, but it's not a >> JSS >> question. >> >> > I have not found it and started trying to get certificate from browser >> > keystore. Ok with IE. But as documented for Firefox JSS is nedeed. I >> > have downloaded last 2 versions of JSS binaries and jar from ftp and >> > tried to make it working with Firefox 3 and 2. All failed. >> >> Describe the failures. >> >> > I have tried to put jar in jre/lib/ext/, firefox/ firefox/jss, tried >> just >> > separate folder with specifying classpath env variable. I have tried to >> > put dll in /firefox, system32, and separate folder, copying dependencies >> > (nss etc.) with it and setting PATH. All failed. >> >> Again, describe the failures. When you say all your attempts failed, do >> you >> mean simply that none of the things you tried had any effect on the >> appearance of the prompt for a user keystore password? >> >> > Just after starting jnlp with javaws window "Select certificate to >> > auth." appears and its empty. [...] This time it just uses HTTPRequest >> > and no SSL related code. Even more - I believe first certificate request >> > comes not from my HTTPRequest, cause when it appears my app is not >> loaded >> > yet. I spent few weeks on this. Anything will be helpful. >> >> If your application is not yet loaded, and is only using http, not https, >> then clearly your application cannot be causing the prompt to select a >> client certificate. >> >> > Should I modify source of my app or jnlp for using JSS? >> >> Well, you have to do *something* to get javaws to use JSS. If may be a >> configuration change rather than an application change. I'm not sure. >> Our JSS expert is on vacation. Others here may be able to help you. >> >> -- >> >> 12345678901234567890123456789012345678901234567890123456789012345678901234567890 >> >> 0112233445566778 >> -- >> 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: W3C Terminates XHTML2
Ian G wrote: >> I'm sure that (for example) a signature scheme done by a handful of >> committed people >> as a Firefox extension would likely do much better than a W3C or OASIS WG >> could >> even dream of. >No doubt there whatsoever. The notion that W3C or any of the other >acronyms can do a signature scheme would have to face the tough test >unravelling the 2 decades of mistakes in electronic signing. No chance >whatsoever. That is exactly my thought. >The only way it can be done is a small dedicated team, but even that is >necessary not sufficient. That may be true but I see some steps here that could be needed and that may even include creating something BAD so that we can move forward and maybe come up with something that a majority think is GOOD. The German speaking countries will never accept anything of the kind I work with (simple, not trying to solve things that doesn't really have a solution), but they should be able to use an XML extension protocol scheme at least. Anders -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: W3C Terminates XHTML2
On 3/7/09 17:39, Anders Rundgren wrote: This demonstrates that standardization is an option but an increasingly difficult option as well in an ever faster-moving world: http://www.w3.org/2009/06/xhtml-faq.html I'm sure that (for example) a signature scheme done by a handful of committed people as a Firefox extension would likely do much better than a W3C or OASIS WG could even dream of. No doubt there whatsoever. The notion that W3C or any of the other acronyms can do a signature scheme would have to face the tough test unravelling the 2 decades of mistakes in electronic signing. No chance whatsoever. The only way it can be done is a small dedicated team, but even that is necessary not sufficient. iang -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
W3C Terminates XHTML2
This demonstrates that standardization is an option but an increasingly difficult option as well in an ever faster-moving world: http://www.w3.org/2009/06/xhtml-faq.html I'm sure that (for example) a signature scheme done by a handful of committed people as a Firefox extension would likely do much better than a W3C or OASIS WG could even dream of. Anders -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
CEN TS 15480 (Re: USB device profile for smart-card readers)
The URLs didn't work so I repost it and this time with a correct subject line... This is something I really hate: http://www.evs.ee/product/tabid/59/p-165216-cents-15480-22007.aspx Paying for *open* standards! Anyway, this scheme will get hard competition from a lot of places including the token vendors who certainly do not want to become replaceable like USB memory sticks. The IAS scheme also fails to address other important things like: - Questionable support for other providers. How many credentials don't we have these days? - Card readers are still not a standard facility - And of course; how does this relate to "iPhone" et al? Like this? http://na.blackberry.com/eng/ataglance/security/products/smartcardreader - Probably cannot be on-line provisioned in a credible way This is the reason (shameless plug) why I still believe that an Open Hardware project based on http://webpki.org/papers/keygen2/secure-key-store.pdf and http://www.atmel.com/dyn/products/tools_card.asp?tool_id=3879 in fact may turn out as a viable concept. It's not rocket science, it is just plain old-fashioned engineering :-) Anders Jean-Marc Desperrier wrote: Kyle Hamilton wrote: I'm not aware of any such profile. There is smart card profile > but I doubt it has much to do with PKCS #11, it is rather about > 7816. You're right, PKCS#11. http://www.usb.org/developers/docs/EH_MR_rev1.pdf But what is "7861"? He's refering to ISO7816, the set of smart card standards : http://www.cardwerk.com/smartcards/smartcard_standard_ISO7816.aspx But I didn't see even a reference to that in the document you refer, thought USB smart card reader seem to be quite properly standardized, so it certainly does exist. The trouble is that each smart card uses specific commands, which makes it impossible to go from ISO7816 to a universal pkcs#11 driver. In Europe, we see the start of going out of that through the European Citizen Card (ECC) standard "CEN TS 15480" and the IAS (Identification Authentication Signature) service based on it that enable this time to have a universal middleware, up to the pkcs#11 signature service layer. Unfortunately, very few cards comply to this standard. In case you are interested in some details about this IAS ECC thing, here's a few pointers : http://www.oberthurcs.com/press_page.aspx?id=211&otherid=112 http://www.gemalto.com/products/multiapp_id_ias_ecc -- 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: Moving browser PKI forward (Re: Problem reading certificate from hardware token)
On 3/7/09 09:30, Martin Paljak wrote: ... 2. Fix Firefox/NSS - Firefox still thinks that you should be able to authenticate to websites with certificates *without* TLS client authentication extension. Add automatic certificate selection, and you get trouble. Yes, this makes cert login as bad as other forms of login. We desperately need some form of whitelisting in Firefox so that each site always gets presented the same cert. If browsers can remember cookies and username/passwords, then they can remember cert/domain combinations. 2a. I don't know if the defaults have changed lately, but allow the end user to define the "friendly certs" option for PKCS#11 tokens, which currently has no UI except the Javascript loading function which got removed from UI land and moved to XPI land in FF 3.5. There are tokens that require this feature, but some PKCS#11 providers like OpenSC which support many different tokens have no easy way to work in both ways. As an aside, does anyone have any stats about how many people use these non-Firefox security devices? It is somewhat clear that most end-users can't use these things, only corporates can. So Mozilla priority for these things might be lacking. Whereas, end users can use browser-embedded certificates. 3. For Firefox only: provide a useful JS interface to allow access to keys which are not used for web authentication but present under "my certificates" for real-life online signing procedures. I know that here the vision of a polished solution differs between people but I also second Anders that there are many (tens?) custom built modules here in EU which re-implement at least the minimal part: signing a hash. Are these easy-to-deploy open source plugins of some form? GUI requirements (like displaying the title of a document, displaying a legal warning, displaying the whole document to be signed) could be worked upon in a common way once the basics are agreed upon to be useful. Right, digital signing would be a good application. But can't be done properly without the browsers accepting a common protocol. For now, I think the reason why there is so little interest for this field is that it is really hard to market such features. The reason why Apple has very low prirorities for smart card related fixes is that it is really hard for Steve to demo this on the big stage. Same goes with Firefox. And "those who really want it, can in theory achieve their goals with extras and extensions" works as well. Concur. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: USB device profile for smart-card readers
This is something I really hate: http://www.evs.ee/product/tabid/59/p-165216-cents-15480-22007.aspx Paying for *open* standards! Anyway, this scheme will get hard competition from a lot of places including the token vendors who certainly do not want to become replaceable like USB memory sticks. The IAS scheme also fails to address other important things like: - Questionable support for other providers. How many credentials don't we have these days? - Card readers are still not a standard facility - And of course; how does this relate to "iPhone" et al? Like this? http://na.blackberry.com/eng/ataglance/security/products/smartcardreader - Probably cannot be on-line provisioned in a credible way This is the reason (shameless plug) why I still believe that an Open Hardware project based on http://webpki.org/papers/keygen2/secure-key-store.pdf and http://www.atmel.com/dyn/products/tools_card.asp?tool_id=3879 in fact may turn out as a viable concept. It's not rocket science, it is just plain old-fashioned engineering :-) Anders Jean-Marc Desperrier wrote: Kyle Hamilton wrote: I'm not aware of any such profile. There is smart card profile > but I doubt it has much to do with PKCS #11, it is rather about > 7816. You're right, PKCS#11. http://www.usb.org/developers/docs/EH_MR_rev1.pdf But what is "7861"? He's refering to ISO7816, the set of smart card standards : http://www.cardwerk.com/smartcards/smartcard_standard_ISO7816.aspx But I didn't see even a reference to that in the document you refer, thought USB smart card reader seem to be quite properly standardized, so it certainly does exist. The trouble is that each smart card uses specific commands, which makes it impossible to go from ISO7816 to a universal pkcs#11 driver. In Europe, we see the start of going out of that through the European Citizen Card (ECC) standard "CEN TS 15480" and the IAS (Identification Authentication Signature) service based on it that enable this time to have a universal middleware, up to the pkcs#11 signature service layer. Unfortunately, very few cards comply to this standard. In case you are interested in some details about this IAS ECC thing, here's a few pointers : http://www.oberthurcs.com/press_page.aspx?id=211&otherid=112 http://www.gemalto.com/products/multiapp_id_ias_ecc -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Problem reading certificate from hardware token
On Jul 2, 7:28 pm, Nelson B Bolyard wrote: Hi all, I'll answer Mr. Bolyards questions briefly because I think we found the culprid. See at the bottom. > > I have a safenet iKey 1032 token where I imported the p12 certificate. > > In firefox (tried 2.0.x, 3.0.x and 3.5.x) I imported the safenet > > K1PK112.DLL PKCS#11 module. In the firefox cryptography module manager I > > now see the token and can (after entering the pin) see the certificate. > > So firefox _can_ read the certificate off of the token. > > While in this state, go into Firefox's certificate manager, and look through > the tabs to find the cert. Tell us in which tab(s) the cert > appears. In particular, does it appear in the "Your Certificates" tab? Yes it does. > Also, in that tab, note the value in the "Security Device" column in the > row for your certificate. There it lists the ikey device > Then, Select your certificate and click the "View" button. A Certificate > Viewer Dialog will appear. In that Dialog, select the "Details" tab. > In that tab are 3 boxes or "panes", the top one of which is labeled > "Certificate Hierarchy". That box will contain some number of lines. > Please copy the contents of that box (you may have to retype it by hand). > I will explain below what to do with this information. There is only one line, that of the user certificate. > > But when I go to the juniper firewall website I get the error message > > that the certificate can't be found. > > Where do you see this message? Is it in a Juniper log file? Or Firefox? > If it is a Juniper log file, can you tell from the message whether it is > saying: > a) That it received no certificate from the browser, or This. > b) That it cannot validate the certificate chain received, or > b) That it does not recognize the validated cert as being authorized? > > > When I (for testing) take out the token and import the p12 certificate > > directly into the firefox certificate store I can authenticate against > > the juniper firewall website with user and pass and the certificate. > > So the problem seems to be that in the cyrpto module manager firefox can > > read a certificate off of a token and can't read it off when queried by a > > website. > > While in this state, please repeat the steps I gave above, noting the tab of > the certificate manager in which your certificate appears, the security > device associated with your certificate, and the contents of the Certificate > Hierarchy pane in the Certificate Viewer. The difference to the above is that in the pane view it now shows the CA and below that the user certificate. > Then compare these two sets of results. I suspect they will differ. > It may be that, in one case the certificate appears in "Your Certificates" > tab, and in the other case, it does not appear in that tab, but appears > in some other tab. Or, it may be that in one case the Certificate Hierarchy > contains multiple lines (corresponding to multiple certificates) and in the > other case, it contains fewer lines (perhaps only one). > Or perhaps you will find both of these differences. Or perhaps neither. > [...] > 2) It may be that your certificate has a hierarchy with more than two > certificates in it, and all of those certificates are stored in Firefox's > software token when you import the PKCS#12 file there, but not all those > certificates are being stored on the token when you import the PKCS#12 file > there. In order to be able to successfully do client cert authentication, > Firefox needs access to the entire correct certificate hierarchy. It cannot > succeed if certs are missing from the hierarchy. If you find that > the two hierarchies seen in the steps above are different, that is the > likely cause. In that case, you really should try to import the missing > certs into the token. If you cannot do that, that is a bug in the token > or PKCS#11 module, however, there is a workaround. You can import the > missing CA certs into Firefox's software token instead. What we've found out now is this: there is no CA certificate on the token. And it seems that firefox needs the CA and the user certificate from the same place: Test: we unplug the token, clean up so that no user cert and CA cert is there. Import the p12 file. Then we have a CA cert in the authorities tab, a user cert in the "your certificates" tab with software store as device and in the details pane the CA with the user cert below it. Then the authentication works. If I clean up again (no user cert and CA cert there), plug in the token I only get the user cert, no CA cert. If I import a CA cert only into the authorities tab and plug in the token I (naturally) have both, the CA and the user cert BUT in the details pane there is still only the user cert there, it's NOT below the corresponding CA cert. That's the problem. That's why I reason that the CA and user cert have to come from the same source, either the software storage or the token. But mixing the st
Re: USB device profile for smart-card readers (was: Problem reading certificate from hardware token)
Kyle Hamilton wrote: I'm not aware of any such profile. There is smart card profile > but I doubt it has much to do with PKCS #11, it is rather about > 7816. You're right, PKCS#11. http://www.usb.org/developers/docs/EH_MR_rev1.pdf But what is "7861"? He's refering to ISO7816, the set of smart card standards : http://www.cardwerk.com/smartcards/smartcard_standard_ISO7816.aspx But I didn't see even a reference to that in the document you refer, thought USB smart card reader seem to be quite properly standardized, so it certainly does exist. The trouble is that each smart card uses specific commands, which makes it impossible to go from ISO7816 to a universal pkcs#11 driver. In Europe, we see the start of going out of that through the European Citizen Card (ECC) standard "CEN TS 15480" and the IAS (Identification Authentication Signature) service based on it that enable this time to have a universal middleware, up to the pkcs#11 signature service layer. Unfortunately, very few cards comply to this standard. In case you are interested in some details about this IAS ECC thing, here's a few pointers : http://www.oberthurcs.com/press_page.aspx?id=211&otherid=112 http://www.gemalto.com/products/multiapp_id_ias_ecc -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Moving browser PKI forward (Re: Problem reading certificate from hardware token)
On 3/7/09 07:15, Anders Rundgren wrote: Nelson B Bolyard wrote: but please don't take it out on us. Please refrain from further sniping in this mailing list and newsgroup. Constructive contributions are welcome. I'm sorry about that. Is there any other place where Mozilla people hang out where there is an interest in trying to understand why and what is happening on the PKI side for consumers? No, there is none as far as I know. Mozilla outsources the security architecture, partly because it subscribes to standards, partly because it is really interested in browsers and users rather than security and protocols, and partly because it (Netscape) tried it once in 1994, and got slapped down. As a historical legacy, Mozilla has chosen the 1980s design of PKI, and that's that. This isn't going to change any time soon. We, the industry, are locked in a deadly embrace on security. I admit to being fooled by this, and it took me years to figure out why people here didn't respond. Basically, Mozilla doesn't do security architecure. They just do security programming. They'll take whatever standard comes out of the standards groups, and implement them if and when they become necessary. Which means as an unfortunate side effect. When there is a bug in that architecture, Mozilla is powerless to fix it. Even if liable! It's not their fault, and there isn't much use in railing against it. (Mind you, it would help if Mozilla people also realised their position, and didn't encourage false expectations based on some sort of claim to security leadership.) iang -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Moving browser PKI forward (Re: Problem reading certificate from hardware token)
>Anders, I think you must take your ideas to a standards body Eddy, this is exactly what I believed/hoped/craved for. Unfortunately, the people who represent "stake holders" like EU governments and banks do participate in International foras like OASIS and IETF, nor fund such developments. It also seems that browser-standards are difficult to get anywhere with even if you are W3C. So for good or worse, I have come to the conclusion that Open Source and to some extent also Open Hardware (new tokens) is *my* way forward. I don't expect or need a Mozilla endorsement, but it would be awfully nice if we could get an XML protocol extension scheme running and then let Mr. Darwin figure who's extensions are the best! There are tons of stuff waiting for such a facility but instead of fixing it, everybody is trying their own scheme leading to miserable stability and very slow progress. NSAPI isn't really cutting it, because it is is for people doing web content. It would cost a week or two of Mozilla R&D but I am sure it would be worth it. I would do it myself but a Mozilla spokesman said that it would fail for every marginal revision and that put me down :-( Anders Eddy Nigg wrote: On 07/03/2009 08:15 AM, Anders Rundgren: I'm sorry about that. Is there any other place where Mozilla people hang out where there is an interest in trying to understand why and what is happening on the PKI side for consumers? Anders, I think you must take your ideas to a standards body - I think that's the only way to move it forward. I highly suspect that Mozilla will not adopt something which isn't more or less universally recognized, specially in this field. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Moving browser PKI forward (Re: Problem reading certificate from hardware token)
On 07/03/2009 08:15 AM, Anders Rundgren: I'm sorry about that. Is there any other place where Mozilla people hang out where there is an interest in trying to understand why and what is happening on the PKI side for consumers? Anders, I think you must take your ideas to a standards body - I think that's the only way to move it forward. I highly suspect that Mozilla will not adopt something which isn't more or less universally recognized, specially in this field. -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: start...@startcom.org Blog: https://blog.startcom.org -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Problem reading certificate from hardware token
Hello, my colleague has run off with the test token so I can only show you some screenshots I made for the german support of safenet. These show roughly what you requested. When my colleague returns I'll make new screenshots (in english if I manage somehow). Here are the shots: http://www.i-nex.de/uploads/certificate-view.JPG http://www.i-nex.de/uploads/cryto-module-firefox2.JPG http://www.i-nex.de/uploads/ff2-ikey-problem.JPG The last one is made with firefox 2, but like I said also FF3 and FF3.5 exhibit the same problem. We also looked with livehttp-headers what get's to and fro, maybe I can dig out a log or something there too. Thanks a lot, regards Udo Puetz P.s.: I normally use linux systems and OS X, but from what I saw till now I think ALL OSs suck when dealing with cryto tokens and such. And don't get me started on RSA SecurID tokens and vista...But let's please stick to the matter at hand. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Moving browser PKI forward (Re: Problem reading certificate from hardware token)
On 03.07.2009, at 8:15, Anders Rundgren wrote: According to most people who are into consumer PKI, Java applets is the best solution for cross-browser PKI. I think Java applets suck but indeed, that's really all we got. but please don't take it out on us. Please refrain from further sniping in this mailing list and newsgroup. Constructive contributions are welcome. Some constructive suggestions; mostly for Firefox: 1. Use platform API-s where appropriate: cryptoapi (and basecsp via this) on windows; cdsa/keychain on macosx. Yell at both companies at the same time to fix their API-s as well (pinpad support, multiple PIN support, GUI hints (PIN vs password) etc). IIRC http://mxr.mozilla.org/security/source/security/nss/lib/ckfw/capi/ was the thing that should enable this, it dates back to 2005, why this has not been polished and included with latest releases? Linux is the spaghetti mix where PKCS#11 indeed might be the best option, but once the big desktop players (KDE, GNOME) (re-)implement the relevant (bicycle/)API-s, there might be QCA (http://api.kde.org/kdesupport-api/kdesupport-apidocs/qca/html/ ) and something similar for GNOME as well. Should they be below NSS or above it in the software stack? Hard to say. FYI, to make sense to users of eID cards currently one has to embed the word PIN into the token description as well, so that the prompt that Firefox displays would make sense: "Please enter password for: MARTIN PALJAK (PIN1)" GUI hints would be useful... 2. Fix Firefox/NSS - Firefox still thinks that you should be able to authenticate to websites with certificates *without* TLS client authentication extension. Add automatic certificate selection, and you get trouble. 2a. I don't know if the defaults have changed lately, but allow the end user to define the "friendly certs" option for PKCS#11 tokens, which currently has no UI except the Javascript loading function which got removed from UI land and moved to XPI land in FF 3.5. There are tokens that require this feature, but some PKCS#11 providers like OpenSC which support many different tokens have no easy way to work in both ways. 3. For Firefox only: provide a useful JS interface to allow access to keys which are not used for web authentication but present under "my certificates" for real-life online signing procedures. I know that here the vision of a polished solution differs between people but I also second Anders that there are many (tens?) custom built modules here in EU which re-implement at least the minimal part: signing a hash. GUI requirements (like displaying the title of a document, displaying a legal warning, displaying the whole document to be signed) could be worked upon in a common way once the basics are agreed upon to be useful. For now, I think the reason why there is so little interest for this field is that it is really hard to market such features. The reason why Apple has very low prirorities for smart card related fixes is that it is really hard for Steve to demo this on the big stage. Same goes with Firefox. And "those who really want it, can in theory achieve their goals with extras and extensions" works as well. -- Martin Paljak http://martin.paljak.pri.ee +372.515.6495 -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
