Re: How can I tell what key strength is used to negotiate HTTPS content encryption keys?
Justin makes some valid points. Risk-management in the future is going to increasingly be about transparency and disclosure. As long as Firefox and Thunderbird provide information about the strengths of different keys in the SSL/TLS negotiation, Mozilla will be advancing the cause of better risk-management through more information. Informed users are. after all, the best defense against any form of attack. I would recommend a button under the Technical Details section of the Page-Info dialog that leads to the kind of detail Justin is referring to. Ideally, it would also be useful to have this detail output as an XML file to the file-system, so that audit tools in the future can automatically pick it up, parse it and determine if the settings are in compliance with a defined security policy at a company. Arshad Noor StrongAuth, Inc. Justin wells wrote: Hi Ian, Thanks for your reply! It's very enlightening, and I do agree that in the real world there are a lot of issues other than the cryptographic issues. Just to be sure, I am not suggesting that the weakest link should be as strong as the strongest link. I am just trying to understand how weak the weakest link is. So far I haven't been able to find any documentation, or anyone, who can tell me what I actually get when I connect to a website. For all I know my browser is exchanging keys with a 256bit RSA key and then telling me that it's established a secure connection. As you say RSA 2k is secure enough for most purposes, per NIST a 2048bit key is good enough for data that needs protection only to 2031, after which 3072 bit keys are acceptable. All I'm trying to do is sort out whether I've got that level of protection or not, and it seems tough to figure out. For Firefox I'd like to make the recommendation that the text that reads Connection Encryption: High-grade Encryption (AES 256bit) and the like be altered to instead state the strength of the weakest link, which in almost all cases is presumably the key exchange. Even AES 256 weakened by the recent attack is still providing some 110 to 112 bits of security, which is most likely still better than whatever is being used for key agreement. If you are really going to assert that this is not the important factor then perhaps some caveats should be added to the it is unlikely anyone read this page message that Firefox prints just after giving the content encryption strength. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: PKCS#11 Module for TPM availiable
Configuring Firefox with a PKCS#11 library is simple - all you have to do is follow the Edit-Preferences-Advanced-Security Devices- Load path and supply a name (of your choice) for the module and the actual full-path of the PKCS11 library for the prompts. If the P11 library is correctly implemented, FF will recognize the module and you should now see it in the list of devices of the Device Manager window in FF. Once configured, FF treats the TPM no differently from any other hardware device for generating keys, using certificates, etc. Of, course, the crypto-capabilities that FF can use on the TPM will depend on what the TPM has to offer. I am making some incremental progress with a specific vendor's TPM library I have and the use of Java to generate keys and create a self-signed certificate; but I have run into some other issues (related to the TPM's security model) that I need to resolve and am working with the vendor on resolving this. Eventually, this code will show up in our open-source CSRTool (and StrongKey) which will be able to do precisely what you're seeking to do: generate a key-pair, create a CSR that can be submitted to a CA (as a PKCS#10 blob) and get back a signed certificate that can then be imported into the TPM. Once done, all applications that can interface with a TPM should be able to see and use those objects. We do plan to integrate it with Trousers, but rather than use the openCryptoki library (which will necessitate using the SunPKCS11 bridge), we plan to use jTSS (http://trustedjava.sourceforge.net/) and eventually, the JSR-321 interface, which should provide native access to the TPM (lesser integration headaches, hopefully). Arshad Noor StrongAuth, Inc. Martin Schneider wrote: Hello Arshad, I want to use Firefox with TPM preferably in Ubuntu Linux. I'm not sure what I've got to do to link Firefox with the PKCS#11 interface. Do you need to implement some code or is this a mere configuration thing? The next question is: How does the creation of a TPM protected certificate work? Do you have to externally create a Certification Signing Request for a key protected inside the TPM, get a signature for this CSR and import the cert to Firefox? Best regards, Martin On 6 Jul., 19:18, Arshad Noor arshad.n...@strongauth.com wrote: Hi Martin, Yes, TSS does apparently give you a PKCS#11 interface when layered with openCryptoki (http://trousers.sourceforge.net/pkcs11.html). I haven't used this configuration personally (I'm trying to work with a specific vendors PKCS#11 library and access the TPM using Java through the SunPKCS11 bridge). You didn't specify the platform - if you're using Windows, your TPM provider probably has a PKCS#11 library already bundled in the TPM software distribution. Arshad Noor StrongAuth, Inc. Martin Schneider wrote: Hello everybody, I'm new to this topic, so it would be kind if some of you people could give me some input. I want to use certificates which according private key is protected inside a Trusted Platform Module and use these Certificates for client side authentication towards a web based service running on an Apache. As far as I understand, there should be the possibility to somehow use the TPM together with Firefox or Thunderbird if you have a suitable PKCS#11 module. As far as I know, will TrouSerS or jTSS offer such a PKCS#11 provider. But I do not understand how this must be used. Did anybody of you set up something as I want to do and maybe put down some notes? Thanks for your replies Martin -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: PKCS#11 Module for TPM availiable
Hi Martin, Yes, TSS does apparently give you a PKCS#11 interface when layered with openCryptoki (http://trousers.sourceforge.net/pkcs11.html). I haven't used this configuration personally (I'm trying to work with a specific vendors PKCS#11 library and access the TPM using Java through the SunPKCS11 bridge). You didn't specify the platform - if you're using Windows, your TPM provider probably has a PKCS#11 library already bundled in the TPM software distribution. Arshad Noor StrongAuth, Inc. Martin Schneider wrote: Hello everybody, I'm new to this topic, so it would be kind if some of you people could give me some input. I want to use certificates which according private key is protected inside a Trusted Platform Module and use these Certificates for client side authentication towards a web based service running on an Apache. As far as I understand, there should be the possibility to somehow use the TPM together with Firefox or Thunderbird if you have a suitable PKCS#11 module. As far as I know, will TrouSerS or jTSS offer such a PKCS#11 provider. But I do not understand how this must be used. Did anybody of you set up something as I want to do and maybe put down some notes? Thanks for your replies Martin -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Roots that are identical except for signature algorithm and serial number
Certificate-chain validation, primarily, works based on the Subject Key Identifier and the Authority Key Identifier extensions. When validation code is presented with multiple certificates that have the same AKIs in the chain, a good programmer will attempt to use the stronger certificate if it can be successfully verified up to the root. (If it cannot, he/she will have no choice but to attempt to chain up the alternate path, if possible). In the example you've provided, the SHA256 hash on the signature indicates a stronger signing algorithm than SHA1 (just as SHA1 indicates a stronger signing algorithm than MD5 in the 2nd example). So, Mozilla correctly chose the right certificate and chain when it saw the SHA256 hash on one root certificate and SHA1 on the other. (It will be good to get confirmation from someone on the Mozilla team that this is a deliberate decision, and not random). Having both roots in the trust-store enables current and older operating sytems (pre-SP3 versions of XP, for example, which do not support SHA256) to chain up to a root successfully. Whether the browser user should trust a cert-chain based on a specific algorithm is a subjective decision left up to their own tolerance for risk. If Mozilla chooses to include only certificates with stronger algorithms in the NSS database - that's a different policy decision. Arshad Noor StrongAuth, Inc. Kathleen Wilson wrote: When processing a cert chain, does Mozilla use a specified algorithm/ order for determining which root to use when there are two roots included that are identical except for signature algorithm and serial number? Are there cases when Firefox might see a full cert chain, including the root (which normally is omitted, at least for SSL/TLS), and NSS would have a problem if the root presented as part of the cert chain were not 100% bit-for-bit identical to the pre-loaded root? Example: Izenpe (bug #361957) would like to request inclusion into NSS of two distinct root certificates which are identical with the exception of Signature Algorithm, Signature Value, Serial Number, SHA-1 Fingerprint, and MD5 Fingerprint. The two roots are attached to the bug in the following zip file. https://bugzilla.mozilla.org/attachment.cgi?id=301667 Using the url https://www.ermua.es/ to test… When I only have the SHA-1 version of the root installed the website cert chains up to the SHA-1 root. When I have both the SHA-1 and the SHA-256 versions of the root installed, the website cert chains up to the SHA-256 root. In this case, is there any benefit to including both the SHA-1 and the SHA-256 roots? Also related, in bug #490895 VeriSign has requested inclusion of the SHA-1 version of their roots to replace the corresponding old MD5 version of their roots. At the time of inclusion of the SHA-1 version of the roots, is there any reason to keep the old MD5 version of the roots in NSS? Kathleen -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: How to export private key using pk12util
While it may be technically feasible, Jean-Marc, it would create a lot of confusion for users, developers and system administrators to see a P12 file on their file-system that would not have a digital certificate in it. I suspect this is the primary reason why the PKCS specs have a #8 specification distinct from the #12; otherwise they would have just recommended using #12 for all stages of the certificate issuance process. Arshad Noor StrongAuth, Inc. Jean-Marc Desperrier wrote: It's technically feasible (it does not break the format) to create a private key only pkcs#12, -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: How to export private key using pk12util
Nelson, I'm afraid PKCS#8 *does* allow for protecting private-keys with passwords, but you have to explicitly choose the ASN type when creating the file. Details can be found at: ftp://ftp.rsasecurity.com/pub/pkcs/ascii/pkcs-8.asc While NSS itself has no use for the PKCS#8 format (since it stores private-keys in the key3.db file, which is already protected with a password), our open-source CSRTool uses the EncryptedPrivateKeyInfo ASN type to protect the RSA/ECDSA keys in the PKCS#8 file. The reason we use the PKCS#8 format is only because, in the multi-step process of generating a key-pair, creating a CSR and getting a digital certificate from an internal/external CA, the private-key needs to be temporarily stored securely until a CA issues the digital certificate. At that time, the cert is combined with the keys to create a PKCS#12 file. We chose PKCS#8 since it was a simpler Java exercise for us. It's possible that NSS chose to not support the export of the keys in PKCS#8 format for other reasons, but I don't believe it would be because it poses a security risk - the PKCS12 file is subject to the same risks as PKCS8 since it has the same level of protection: PBE using a 3DES key. For the person who's trying to export the key: It is possible to write a little Java (or C if you prefer it) program to read the NSS keystore, extract the key-pairs (assuming they are legible and not corrupt in any way) and export them as PKCS#8 files. If you go with Java, then much of the sample code can be derived from a combination of specific modules of our open-source tools - StrongKey (which has code that uses the NSS keystore) and CSRTool (which has the P8/P12-related sources). Both tools are available at strongauth.com and a forum exists there for support on both tools. Good luck. Arshad Noor StrongAuth, Inc. Nelson Bolyard wrote: The NSS team participated in the process of defining PKCS#12 precisely to avoid the security trap of exporting private keys in PKCS#8 format. Avoiding that trap is precisely why PKCS#12, and not PKCS#8, is THE only format for private key transport supported by all of NSS, Microsoft and OpenSSL. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: X509 per machine (not per user) - or equivalent needed
After reading the other postings on this thread, I think I
see what you're getting at. You need a combination of two
items and a 2-phase authentication process to get the
assurance you're seeking:
1) A token-based credential per user, using a smartcard and
a digital certificate for Client-Auth. Your application
will use this to establish an SSL session in phase 1; and
2) A GPS card in the PC which your application will interact
with to get its physical GPS coordinates and then relay
this as a signed message in phase 2 of the auth process.
The message will be signed by the private key of the user
who just established the SSL session with the application,
which will corroborate the phase-1 authentication.
Your application would receive the latitude/longitude values
and verify that these coordinates matched up with the list
of authorized PC's to establish an authenticated session.
This mechanism can still be attacked because the smallest
GPS measurement - a second - equates to approximately 100
feet. So, someone could move the GPS card from one PC to
another in the same location and then log in from that PC
(which might defeat what you're attempting to achieve).
This is about the closest you can get without the use of a TPM
chip. What the TPM gives you is a keystore that is embedded on
the motherboard by the manufacturer and which cannot be moved
from one PC to another.
Hope that helps.
Arshad Noor
StrongAuth, Inc.
Denis McCarthy wrote:
Hello Arshad,
Thanks for the email. I suppose the one thing I'd like to stress again
is that we wish to authenticate a machine, not a user. Many users may
log in to a certain machine (via a username and password that we would
issue). What we need to do on our system is to ensure that the user
logging is valid to log in on that particular computer ('terminal' as
our customer calls them). The terminal itself is connected to the
company that the user works for in our database.
Regards
Denis
On Fri, Jan 30, 2009 at 12:08 AM, Arshad Noor
arshad.n...@strongauth.com wrote:
Denis,
You have already made the appropriate leap to this conclusion.
I was going to suggest that there is something atypical about
your application architecture if you're relying on authentication
of the *machine* without the use of a hardware token - such as a
smartcard, TPM chip, etc.
What you want are FIPS 140-2 Level 2 (or above) certified crypto
tokens that generate keys on-board and store the certificate of
the user on the token (in addition to the browser). The private
key, however, never leaves the token, thus ensuring its security.
Once your customers are issued these tokens with their personal
certificates, they can use it on any PC they desire (assuming
that the PC has been configured with the appropriate CA cert-
chain).
If you absolutely need to rely on authenticating the PC, then
the only option you have is the TPM chip, because it is built
with the chip on the motherboard by the manufacturer.
As an aside, StrongAuth, Inc., the company I represent has been
in the business of architecting, building operating some of the
largest closed-PKIs in the world for enterprises, with the use of
crypto-tokens. Most recently, we built a PKI for a bio-technology
company that embedded secure processors with digital certificates
into three different parts of their product, so that they may
strongly authenticate to each other before being used. This was
designed to deter counterfeiters from cloning the consumable part
of their product. The device is currently awaiting FDA approval
before coming to market.
Feel free to get in touch with us, if we can be of any help to you.
Arshad Noor
StrongAuth, Inc.
Denis McCarthy wrote:
Thanks for the suggestion David. Unfortunately we are not connecting
to an active directory domain - our application has to go out over the
internet. I did a bit of fiddling with the certificates snap ins, but
Microsoft only makes certificates installed in the user account
available to IE. One other thing I've been mulling over - is it
possible to get a cheap piece of hardware (i.e. a dongle of some sort)
that you can put an X509 certificate on? If so, could anyone point me
in the direction of a company that provides such a product?
Regards
Denis
--
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: X509 per machine (not per user) - or equivalent needed
Denis, You have already made the appropriate leap to this conclusion. I was going to suggest that there is something atypical about your application architecture if you're relying on authentication of the *machine* without the use of a hardware token - such as a smartcard, TPM chip, etc. What you want are FIPS 140-2 Level 2 (or above) certified crypto tokens that generate keys on-board and store the certificate of the user on the token (in addition to the browser). The private key, however, never leaves the token, thus ensuring its security. Once your customers are issued these tokens with their personal certificates, they can use it on any PC they desire (assuming that the PC has been configured with the appropriate CA cert- chain). If you absolutely need to rely on authenticating the PC, then the only option you have is the TPM chip, because it is built with the chip on the motherboard by the manufacturer. As an aside, StrongAuth, Inc., the company I represent has been in the business of architecting, building operating some of the largest closed-PKIs in the world for enterprises, with the use of crypto-tokens. Most recently, we built a PKI for a bio-technology company that embedded secure processors with digital certificates into three different parts of their product, so that they may strongly authenticate to each other before being used. This was designed to deter counterfeiters from cloning the consumable part of their product. The device is currently awaiting FDA approval before coming to market. Feel free to get in touch with us, if we can be of any help to you. Arshad Noor StrongAuth, Inc. Denis McCarthy wrote: Thanks for the suggestion David. Unfortunately we are not connecting to an active directory domain - our application has to go out over the internet. I did a bit of fiddling with the certificates snap ins, but Microsoft only makes certificates installed in the user account available to IE. One other thing I've been mulling over - is it possible to get a cheap piece of hardware (i.e. a dongle of some sort) that you can put an X509 certificate on? If so, could anyone point me in the direction of a company that provides such a product? Regards Denis -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: A / V / Text encryption methods
Dennis, While this is not a real-time encryption protocol, if you're looking for a protocol to manage symmetric-keys across the internet, OASIS is working on a standard called the Symmetric Key Services Markup Language (SKSML). The current draft (DRAFT-8) of this protocol is at: http://www.oasis-open.org/committees/document.php?document_id=30091wg_abbrev=ekmi It is designed to manage trillions of symmetric keys per server, and manages keys centrally through individualized policies. An open- source implementation of the DRAFT-1 version of the protocol is at strongkey.org, while an OASIS-specific (DRAFT-8) implementation will be out later this year. If there are specific symmetric key-management requirements you have that are not addressed in this specification, now would be a good time to let me know. Arshad Noor StrongAuth, Inc. D3|\||\|!$ wrote: Hi All! I am looking for real-time encryption methods/protocols for streaming A / V / Text data. I plan to build an app similar to Skype and since Skype doesn't really reveal much about its security architecture, I'm looking for ingenious solutions. Any suggestions/help would be welcome. From whatever research I did about Skype, I found the following things: Skype has implemented majority of its encryption modules by itself and which are built to comply with standards but applied in their own ingenious ways such as the AES block cipher, the RSA public-key cryptosystem, the ISO 9796-2 signature padding scheme, the SHA-1 hash function, and the RC4 stream cipher. It uses 256-bit encryption in order to actively encrypt the data in each Skype call or instant message. Skype uses 1024 bit RSA to negotiate symmetric AES keys. User public keys are certified by the Skype server at login using 1536 or 2048-bit RSA certificates. The key size used for signing here is 1536-2048, which is significantly greater than 1024-bit keys that are a global norm. It has also set up its own CA for authentication. On first usage, a client contacts Skype's master server which issues a certificate from its indigenous CA. Besides the above cryptographic algorithms, Skype has also implemented its own proprietary key-exchange protocol which it uses for key exchange. I guess they have borrowed most of the features of SSL and implemented it according to their needs besides fixing its need for a connection-oriented protocol. I guess we could also have the same functionality using IPSec in transport mode and creating a indigenous CA.. I DO NOT PLAN TO USE VPNs, so using tunnel mode is out of question... The question is, can we use IPSec to secure UDP data communication?? If yes, HOW?? (since using TCP to transport A / V data would cause huge delays.. So SSL is also out of question...) One more option would be to use DTLS - I needed to know if NSS supports DTLS... Have already developed apps with NSS.. so life could be a lot more easier if NSS did support DTLS.. :D Another option would be to use SSH but again, I'm not sure if it can be used with UDP and also about its authentication methods. Comments would be welcome. Also, I'm looking for suitable forums/IRC channels to discuss the topic more. Could the people here suggest me some??? Regards, D3|\||\|!$ ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Anders' p2 challenge
Given this example, and using traditional technologies and protocols, this problem appears intractable. However, there is a new solution - becoming an OASIS standard shortly - that not only solves this problem, but goes beyond this stage of the problem to address the next stage of the problem. Everybody on this forum understands that when this Purchase Order is sent encrypted, it has to be encrypted with a symmetric key, and the symmetric key has to be encrypted with the public key of the receiver(s) and packaged with the ciphertext PO (ala S/MIME). However, there is no current standard to do this with groups - just individuals. But, if the symmetric key is abstracted out of the package and an infrastructure exists to support its secure distribution on the internet, the problem is solved. The infrastructure I speak of is a Symmetric Key Management System (SKMS). It is part of an Enterprise Key Management Infrastructure (EKMI), which includes a PKI. While the Purchasing problem is not very complex, lets run with it to continue the thread: a) When a Purchasing Manager (PM) wants to send an encrypted/signed PO to a vendor's Order Receiving System, the vendor issues the PM a signing and an encryption certificate from the vendor's EKMI. b) After the PM prepares the PO, they sign it with their company issued digital certificate, and then using the vendor-issued signing certificate, request a symmetric key from the vendor's EKMI; c) The vendor's SKMS, validates the request based on the signature and cert-chain, and issues a symmetric key based on policies defined by the vendor in the SKMS; the key is transported after being encrypted under the vendor-issued encryption certificate to the PM; d) The PM receives the key, verifies the response, encrypts the PO (into an XML Encryption-schema conformant document) and sends it off to the vendor's ORS; the PM erases the symmetric key from their system when done - they don't need it anymore; e) Vendor's ORS is configured with its own pair of certificates from the SKMS. When it receives the encrypted PO, it requests the same symmetric key from the SKMS; the SKMS had escrowed it even before sending it to the PM; the ORS knows the key-identifier because it is embedded in the XMLEncryption document; f) SKMS recieves request; based on access-control rules, it returns the symmetric key to the ORS, which now decrypts the signed PO sends it off to the Order Receiving Group alias. Any receiver on the vendor's side can now verify the signed PO and process the PO. An alternate approach is to have the XMLEncryption document go to all the Order Receiver's on the vendor's side. When the receiver is ready to process the PO, they request the symmetric key from their SKMS, and after receiving the key based on their signed request and access control rules, decrypt the PO and continue processing it. Using S/MIME-like design, but abstracting the key out of the encrypted document, this problem - and another more complex problem as shown in slides 15-17 of this 18-month old presentation: http://www.oasis-open.org/committees/download.php/24594/ekmi-webinar.pdf is solved. (Using the purchasing system example, it would be analogous to the order receivers being able to share the encrypted PO dynamically with a select sub-group out of a group hundreds of thousands of parts suppliers to the vendor). Arshad Noor StrongAuth, Inc. Anders wrote: When any of you guys have made a *public* write-up on how you would address the [related] issues mentioned on p.2 in this document http://webpki.org/papers/web/A.R.AppliedPKI-Lesson-1.pdf you are ready for the real discussion. 1. How is the purchaser (P) going to select and acquire a suitable Order Receiver (OR) encryption certificate from the selling organization? 2. How is the buying organization’s Purchasing System Server (PSS) able to perform its logging, authorization, and control tasks if purchase orders already have been encrypted by the Purchaser using a public key from an external selling organization? 3. How is the selling organization’s Order System Server (OSS) supposed to decipher and validate incoming orders if they are encrypted by a public key of a specific Order Receiver (ORn) employee? In case the designated OR is unavailable, how is OSS going to be able to delegate order handling to another OR? 4. How are different Order Receivers (ORs) supposed to cooperate if they cannot see each others’ tasks? Are the particular Order Receiver and Purchaser also the natural entities for handling associated invoices? I know that there is not a single person on this planet who can :-) ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: where does certutil put a cert's private keys?
I must apologize; I was in error about keytool being able to export a P12 file out of the JCE keystore - this cannot be done by keytool yet - you can only import P12's in JDK6. However, if you're still interested in keytool for generating keys and certs, keytool -help or man keytool provide all details. Arshad Noor StrongAuth, Inc. fat.fuck wrote: On 2 Dec, 22:11, Arshad Noor [EMAIL PROTECTED] wrote: Finally, if you're going to be using digital certificates, while openssl will do the job for you, since you say you know Java, you can also use keytool from the JDK to create your key, cert and P12 - all using the same command; you can then just import the P12 to the Mozilla databases. keytool sounds like a plan! please, mr. noor. won't you share the specific keytool command with me (and future readers) in this thread? you would be doing the community a huge favor. thanks in advance. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: where does certutil put a cert's private keys?
I've never had to use ClientAuth with Sun's Directory Server, but here are some observations: 1) Keys are *never* stored in certN.db; they're always in keyN.db; only certificates are in certN.db. The association between the key and the cert is made via the cert's nickname (in your case: myClientCert); 2) You do not have the Private Key of your client cert in your keyN.db file, since you haven't imported it. You need to use openssl to create a P12 file with your Private Key and cert, and then use the pk12util to import the P12 to the Mozilla (Netscape) databases (the key will automatically go to keyN.db and the cert will go to certN.db); you need to get past this problem before you can do anything with ClientAuth. However, I would recommend that you get the LDAP working with SSL but *without* ClientAuth to ensure that your server-side SSL is setup correctly, first. Once you can access your directory server over SSL without ClientAuth, the next step is to add ClientAuth. Finally, if you're going to be using digital certificates, while openssl will do the job for you, since you say you know Java, you can also use keytool from the JDK to create your key, cert and P12 - all using the same command; you can then just import the P12 to the Mozilla databases. If you want to use an industrial-strength tool for your certificates, either use DogTag or EJBCA. Arshad Noor StrongAuth, Inc. fat.fuck wrote: bebop$ /development/projects/dsrk52/lib/ldapcsdk/tools/ldapsearch -h bebop -p 636 -Z -P /home/bebop/.netscape/cert7.db -N myClientCert -W ** -K /home/bebop/.netscape/key3.db -b (objectClass=*) ldapssl_enable_clientauth: Bad parameter to an ldap routine ldapssl_enable_clientauth: additional info: unable to find certificate SSL error -8174 (security library: bad database.) now, if anybody could help shed light on this error i'm getting using my certs and keys for 2-way ssl, please chime in: ldapssl_enable_clientauth: Bad parameter to an ldap routine ldapssl_enable_clientauth: additional info: unable to find certificate SSL error -8174 (security library: bad database.) thanks in advance for your help. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Unable to decode an encrypted message
If your friend is encrypting the message, whose digital certificate is he using to encrypt it with? Yours? Do you have a digital certificate with an associated Private Key in your Tbird keystore? If so, are you trying to read the encrypted e-mail from the same machine where you have your Private Key? In order to sign an e-mail, a Sender (your friend, in this case) must have a digital certificate and an associated Private Key to sign it. You do not need a certificate of your own to read signed e-mails, since they are unencrypted. However, to verify the signed e-mail, you must have the certificate-chain of your friend's digital certificate. If your friend got his certificate from some public certificate-issuer, you probably have the chain in Tbird already, and that's why the signed e-mail can be verified. However, in order to encrypt an e-mail, the Sender MUST HAVE the *recipient's* digital certificate, and the recipient must have the associated Private Key of that digital certificate to decrypt it. If you do not have a digital certificate, I'm not sure whose digital certificate he pointed to to encrypt it. If you do have one, then you must read the e-mail on the same machine that has the Private Key to that digital certificate (assuming you're not using a smartcard or some other external cryptographic device). The encrypted e-mail from yourself to your friend works, because the first time he sent you a signed e-mail and you verified it, Tbird placed his digital certificate in your Tbird's certificate-store and consequently, you had his (the recipient) digital certificate to encrypt your message with. Hope that helps. Arshad Noor StrongAuth, Inc. Paul Kinzelman wrote: I originally posted this issue on moz.sup.tbird and somebody suggested posting it here. The suggestion I got over there was to try https://nic-nac-project.de/~kaosmos/p7mHandler-en.html but that didn't change anything. I'm using Tbird 2.0.0.17 (20080914) When a friend uses an Apple to digitally sign a message, I can validate his signature OK (so that means I have his cert properly in Tbird, right?), but when he encrypts the message, I get a Thunderbird cannot decrypt this message error. He's not using PGP, he's doing it in SMIME. I can encrypt and sign a message with my cert that he can read. I'll append first the header of the encrypted message that I can't read, and then I'll append the header of the signed message that I can read (because it's not encrypted) and the signature validates OK. Any suggestions would be greatly appreciated. I'm kind of new at this encryption stuff so feel free to treat me as an idiot. :-) -- Here's the header of the encrypted message body that I can't read: From - Tue Oct 21 13:36:49 2008 X-Account-Key: account4 X-UIDL: 514289371 X-Mozilla-Status: X-Mozilla-Status2: X-Mozilla-Keys: Received: from SMTP32-FWD by kinzelman.com (SMTP32) id A087B00A7AEC2; Tue, 21 Oct 2008 08:51:07 -0800 Received: from mx1.timesync.com [12.181.175.91] by antares.timesync.com with ESMTP (SMTPD-8.22) id A87B018C; Tue, 21 Oct 2008 08:51:07 -0800 X-policyd-weight: passed - too many local DNS-errors in dsn.rfc-ignorant.org lookups Received: from star3.baremetal.com (star3.baremetal.com [64.69.88.78]) by mx1.timesync.com (Postfix) with ESMTP id 99EAC67819 for [EMAIL PROTECTED]; Tue, 21 Oct 2008 09:50:31 -0700 (PDT) Received: from [192.168.15.3] (adsl-75-37-8-19.dsl.pltn13.sbcglobal.net [75.37.8.19]) by star3.baremetal.com (8.13.4/8.12.10) with ESMTP id m9LG6LEA006885 for [EMAIL PROTECTED]; Tue, 21 Oct 2008 09:07:17 -0700 Mime-Version: 1.0 (Apple Message framework v753.1) In-Reply-To: [EMAIL PROTECTED] References: [EMAIL PROTECTED] Content-Type: application/pkcs7-mime; name=smime.p7m; smime-type=enveloped-data Message-Id: [EMAIL PROTECTED] Content-Disposition: attachment; filename=smime.p7m Content-Transfer-Encoding: base64 From: Richard Haley [EMAIL PROTECTED] Subject: Re: HTML question Date: Tue, 21 Oct 2008 09:07:52 -0700 To: [EMAIL PROTECTED] X-Mailer: Apple Mail (2.753.1) X-RCPT-TO: [EMAIL PROTECTED] Status: U X-UIDL: 514289371 X-IMail-ThreadID: 087b0854630f X-Antivirus: AVG for E-mail 8.0.173 [270.7.5/1708] MIAGCSqGSIb3DQEHA6CAMIACAQAxggMkMIIBjgIBADB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQK [etc.] - And here's a message that's not encrypted but is signed and I can validate his signature successfully: From - Tue Oct 21 13:37:06 2008 X-Account-Key: account4 X-UIDL: 514289377 X-Mozilla-Status: X-Mozilla-Status2: X-Mozilla-Keys: Received: from SMTP32-FWD by kinzelman.com (SMTP32) id A0C97008EAF92; Tue, 21 Oct 2008 09:08:39 -0800 Received: from mx1.timesync.com [12.181.175.91] by antares.timesync.com with ESMTP (SMTPD-8.22) id AC97018C; Tue, 21 Oct 2008 09:08:39 -0800 X-policyd-weight: passed - too many local DNS-errors in dsn.rfc-ignorant.org lookups Received: from
Re: Certificate not approved for this operation
What are the key-usage and extended key-usage extension values in the certificate issued by MS signtool? Once a certificate has been issued, it cannot be changed. You have to reissue the certificate (as a new one) if you want any changes in it. You should be able to generate a certificate of whatever duration you desire with the tools; you just need to specify it explicitly when creating the certificate. Out of curiosity, what is the key-size for the key-pair of this 40-year certificate? Arshad Noor StrongAuth, Inc. [EMAIL PROTECTED] wrote: Hi, When you create a test certificate with signtool it is valid only for 3 months. I would like to know whether it is possible to convert a microsoft test certificate and use it with Firefox for object signing. This is what I try to do: 1., I have a test.pfx created with microsoft signtool valid for 40 years 2., I use the pk12util to import it using signtool -L -d. my cert has no asterisk before the name, I guess that is the problem. When using with signtool, I get this (obviously) Generating zigbert.sf file.. signtool: PROBLEM signing data (Certificate not approved for this operation) Since it is a test certificate is not there a way to change it to be suitable for object signing as well? Using microsoft certificate store, there is a way to add any kind of object identification, anyone knows the code (OID) for this purpose (object signing)? Is there another way to create (with nss tools) a test certificate which is valid mush more time than 3 months? TIA, giorgio71 ___ 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
[Fwd: [P1619-3] Early Registration Deadline for KMS 2008 Extended to August 31, 2008]
FYI. Original Message Subject:[P1619-3] Early Registration Deadline for KMS 2008 Extended to August 31, 2008 Date: Sat, 16 Aug 2008 18:18:54 -0600 From: Matt Ball [EMAIL PROTECTED] Reply-To: Matt Ball [EMAIL PROTECTED] To: [EMAIL PROTECTED] To give everyone a little more time, the early registration deadline for the 2008 IEEE Key Management Summit has been moved about a week back to August 31, 2008. If you sign up on or before August 31, the rate is $300/person (which is below cost, thanks to sponsor subsidies). Afterwards, the rate increases to $500/person. Don't wait, or the deadline will sneak up on you! This is also the same deadline for booking a room at the reduced rate of $219/night at the Sheraton Inner Harbor hotel. After August 31, reservations will be exception on a space available basis. Links: * IEEE Key Management Summit 2008 Homepage http://keymanagementsummit.com/2008/ * Registration Homepage http://storageconference.org/2008/registration.html * Hotel Information http://storageconference.org/2008/hotel.html The IEEE Key Management Summit (KMS) 2008 will be from Sept 23-24, 2008 at the Sheraton Inner Harbor Hotel in Baltimore, Maryland. Hope to see you there! -- Thanks! Matt Ball, IEEE P1619.x SISWG Chair M.V. Ball Technical Consulting, Inc. Phone: 303-469-2469, Cell: 303-717-2717 http://www.mvballtech.com http://www.linkedin.com/in/matthewvball ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Fwd: [ekmi] Public Review of SKSML v1.0
FYI. The OASIS EKMI Technical Committee would be grateful for any comments received from members of this forum about the key-management protocol. If you are interested in reviewing a working implementation of an early version of this protocol, you can get the implementation here: http://www.strongkey.org. One of the cryptographic libraries supported by this implementation is NSS through the SunPKCS11 bridge. Thank you. Arshad Noor StrongAuth, Inc. - Forwarded Message - From: Mary McRae [EMAIL PROTECTED] To: [EMAIL PROTECTED], [EMAIL PROTECTED] Cc: ekmi [EMAIL PROTECTED] Sent: Thursday, July 24, 2008 7:04:49 PM (GMT-0800) America/Los_Angeles Subject: [ekmi] Public Review of SKSML v1.0 To OASIS members, Public Announce Lists: The OASIS Enterprise Key Management Infrastructure (EKMI) TC has recently approved the following specification as a Committee Draft and approved the package for public review: Symmetric Key Services Markup Language (SKSML) Version 1.0 The public review starts today, 24 July 2008, and ends 23 September 2008. This is an open invitation to comment. We strongly encourage feedback from potential users, developers and others, whether OASIS members or not, for the sake of improving the interoperability and quality of OASIS work. Please feel free to distribute this announcement within your organization and to other appropriate mail lists. More non-normative information about the specification and the technical committee may be found at the public home page of the TC at: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ekmi. Comments may be submitted to the TC by any person through the use of the OASIS TC Comment Facility which can be located via the button marked Send A Comment at the top of that page, or directly at: http://www.oasis-open.org/committees/comments/index.php?wg_abbrev=ekmi. Submitted comments (for this work as well as other works of that TC) are publicly archived and can be viewed at: http://lists.oasis-open.org/archives/ekmi-comment/. All comments submitted to OASIS are subject to the OASIS Feedback License, which ensures that the feedback you provide carries the same obligations at least as the obligations of the TC members. The specification document and related files are available here: Editable Source (Authoritative): http://docs.oasis-open.org/ekmi/sksml/v1.0/pr01/SKSML-1.0-Specification.odt PDF: http://docs.oasis-open.org/ekmi/sksml/v1.0/pr01/SKSML-1.0-Specification.pdf HTML: http://docs.oasis-open.org/ekmi/sksml/v1.0/pr01/SKSML-1.0-Specification.html Schema: http://docs.oasis-open.org/ekmi/sksml/v1.0/pr01/schema/ Abstract: This normative specification defines the first (1.0) version of the Symmetric Key Services Markup Language (SKSML), an XML-based messaging protocol, by which applications executing on computing devices may request and receive symmetric key-management services from centralized key-management servers, securely, over networks. Applications using SKSML are expected to either implement the SKSML protocol, or use a software library - called the Symmetric Key Client Library (SKCL) - that implements this protocol. SKSML messages are transported within a SOAP layer, protected by a Web Services Security (WSS) header and can be used over standard HTTP securely. OASIS and the EKMI TC welcome your comments. --- Mary P McRae Manager of TC Administration, OASIS email: [EMAIL PROTECTED] web: www.oasis-open.org - To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: certutil or PKI for NSS 3.11.9
I will defer to your experience in the war-stories you've heard, Nelson. You've certainly seen a lot more people do stupid things in this area than I have, I'm sure. I tend to get involved only when people want to do PKI the right way :-). I am a strong believer that educating the general masses about doing things the right way leads a better environment for all of us. To that extent, based on my experiences in setting up more than a dozen PKIs over the last 9 years (from the world's largest pharmaceutical company to a medical devices startup that is embedding digital certificates in its devices for anti-counterfeiting) I have summarized some guidelines in an article called Building a Successful PKI article that was published in the ISSA Journal some years ago. It is available to ISSA members in their archives, or if interested readers send me an e-mail directly. Arshad Noor StrongAuth, Inc. Nelson B Bolyard wrote: Arshad Noor wrote, On 2008-06-23 15:58: Nelson, I think you may want to qualify your message in this paragraph, so as to not mislead people who don't understand PKI very well. Arshad: I want people who don't understand PKI very well to get one message, loud and clear: Don't try to make and use your own server certs. There are some very limited, very special circumstances in which self signed server certs make sense and aren't time bombs. Those circumstances may constitute 0.1% of the cases where people contemplate using them. But in the other 99.9+% of the cases, self signed server certs are a mistake, pure and simple. I have been developing and supporting SSL in browsers for 12 years now, and during that time I have heard hundreds of stories from people who got themselves into real binds by either trying to use self-signed server certs or trying to run their own CA (but not knowing what they're really doing). I've witnessed individuals, corporations, universities, and banks stumble real hard over these mistakes. (I can write about the problems at length, but won't unless asked.) Given the detailed specifics of a situation, it is possible to determine if self-signed server certs (or certs from a home grown CA) would work in that situation, but for the general case, the my best advice is: don't. If they do these two things and follow their self-directed policies and procedures with reasonable diligence, then I would argue that there is no difference between self-signed or public-CA issued certs. Self-signed certs, whether EEs or CAs, are great until they have to be replaced for any reason. They they're typically a huge nightmare, a company-wide flag-day event for which no one is trained or prepared. I've heard of companies that almost went bust over this. There are certainly people who really understand PKI, and really know what they're doing. They can setup a real PKI and run a real CA. They can devise a solution that meets their needs and fits their situation, even if it involves their own self signed CA certs. They know enough to avoid a setup that will someday cause that huge nightmare, and they know that they can ignore my warnings. :) The problem is that people who really aren't qualified often think they are qualified, and they choose to ignore warnings that they should not. Obtaining professional quality CA software may help avoid various problems with certificate formats, and is likely to avoid problems with serial number reuse, but even with such software, people who don't really understand PKI can make colossal mistakes. So, my general advice to people contemplating issuing their own certs is: unless you really know how to run a good CA, don't play CA and don't make your own certs. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: certutil or PKI for NSS 3.11.9
Nelson, I think you may want to qualify your message in this paragraph, so as to not mislead people who don't understand PKI very well. As I'm sure most people on this list know, every Root CA certificate is a self-signed certificate. There is nothing inherently insecure about such certificates, or the ones they issue. It is the policies, procedures and technology used to protect the components of a PKI that make them secure or insecure (as some recent discussions on this list are highlighting). What makes self-signed *end-entity* certificates insecure is that RPs are required to make trust decisions about the certificate(s) with little or no knowledge about them. However, there are many situations where self-signed end-entity certs may be acceptable even in Production: point-to-point security between servers where the client and server are controlled by a single individual/group. Since this individual/group is/are the creators and relying parties themselves, as long as the components of their infrastructure are well-protected, these self-signed certs could be deemed secure. That said, any infrastructure that used PKCS components is better served building a PKI - no matter how small it may be - to manage the certs and the procedures used in managing them. Additionally, they should also use some hardware crypto module - smartcard, TPM or HSM - to protect the private-key of their certificates. If they do these two things and follow their self-directed policies and procedures with reasonable diligence, then I would argue that there is no difference between self-signed or public-CA issued certs. Arshad Noor StrongAuth, Inc. Nelson B Bolyard wrote: The big warning paragraph that you quoted (and I snipped) is really trying to warn against the use of certutil (or any tool that produces self-signed certificates) for certificate issuance in production environments. The page is explaining how to setup a very small scale CA using certutil for use in very small scale test environments. The warning is intended to be If you use self-signed server certs in production, you'll be sorry!. It doesn't say that very well. The warning sounds like it's saying certutil does a bad job of issuing self-signed certs, but that's not the issue. Some people read it as if it is saying don't use certutil for this, but instead use some other tool like OpenSSL, and that's exactly the wrong message. The message is: don't use self-signed server certs in production. The tool that makes them doesn't matter. Self-signed certs are bad for production. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Cannot encrypt cipher via pkcs11 in nss fips mode
FWIW, the StrongKey implementation of a Symmetric Key Management
System (SKMS) uses certificates and private keys from JKS keystores,
NSS databases (using the SunPKCS11 bridge) and smartcards (also using
SunPKCS11). We're working on integrating various HSMs and the TPM.
Full source code is available at www.strongkey.org.
We haven't tried it with the NSS store in FIPS mode, so I can't predict
what might happen.
Arshad Noor
StrongAuth, Inc.
Glen Beasley wrote:
Yevgeniy Gubenko wrote:
The main reason not to work with JSS is the following paragraph written in
http://www.mozilla.org/projects/security/pki/jss/provider_notes.html
The following classes don't work very well:
KeyStore: There are many serious problems mapping the JCA keystore interface
onto NSS's model of PKCS #11 modules. The current implementation is almost
useless. Since these problems lie deep in the NSS design and implementation,
there is no clear timeframe for fixing them. Meanwhile, the
org.mozilla.jss.crypto.CryptoStore class can be used for some of this
functionality.
We have a lot of use of keystore in our application.
I didn't understand your observation:
As long as you're using using NSS to store your certs and keys you
should have no problem using JSS.
The Mozilla-JSS provider's keystore implementation is almost useless,
but you can use CryptoStore as the documentation states.
Using JDK6 SunPKCS11 you may manage to access both the Java keystore and
NSS's but I have
not tried this so I do not know what your issues will be.
http://java.sun.com/javase/6/docs/technotes/guides/security/p11guide.html#KeyStoreRestrictions
yes NSS supports x509 but does
What did you mean saying but does?
it was a typo that I didn't edit correctly when I sent the email, as I
looked at the time, and realized I had to catch my commuter train.
do disregard the but does.
So if NSS supports X509, why do I get the below exception without adding
another 2 providers?
sometimes error messages are not clear.
As well, I wasn't able to run my class with the only dynamically added
crypto provider, until I enabled both of the following providers in
jre/lib/security/java.security configuration:
1. security.provider.1=sun.security.pkcs11.SunPKCS11
${java.home}/lib/security/sunpkcs11-solaris.cfg
2. security.provider.2=sun.security.provider.Sun
These are default providers, you may be able to disable #2, but you
cannot disable #1 SunPKCS11 if you want
the JDK to talk with NSS's PKCS11.
ie. from your own code:
String configFileName = /opt/nss/pkcs11.cfg;
java.security.Provider nss = new
sun.security.pkcs11.SunPKCS11(configFileName);
If you have an actual issue with JSS or an actual bug with NSS's pkcs11
implementation you should use this forum.
If you want to get your program working with the JDK's SunPKCS11 then I
would ask further questions in
http://forum.java.sun.com/index.jspa
have a good day,
glen
Otherwise I got an exception:
Exception in thread main java.lang.ExceptionInInitializerError
at javax.crypto.Cipher.getInstance(DashoA13*..)
at decryptPass.main(decryptPass.java:43)
Caused by: java.lang.SecurityException: Cannot set up certs for trusted CAs
at javax.crypto.SunJCE_b.clinit(DashoA13*..)
... 2 more
Caused by: java.security.PrivilegedActionException:
java.security.cert.CertificateException: X.509 not found
at java.security.AccessController.doPrivileged(Native Method)
... 3 more
Caused by: java.security.cert.CertificateException: X.509 not found
at
java.security.cert.CertificateFactory.getInstance(CertificateFactory.java:153)
at javax.crypto.SunJCE_b$1.run(DashoA13*..)
... 4 more
Caused by: java.security.NoSuchAlgorithmException: X.509 CertificateFactory
not available
at sun.security.jca.GetInstance.getInstance(GetInstance.java:142)
at
java.security.cert.CertificateFactory.getInstance(CertificateFactory.java:148)
Doesn't NSS3.11.4 crypto API support all X.509 stuff?
yes NSS supports x509 but does
Best Regards,
Yevgeniy
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Glen Beasley
Sent: Wednesday, June 04, 2008 18:15
To: mozilla's crypto code discussion list
Subject: Re: Cannot encrypt cipher via pkcs11 in nss fips mode
hello,
Your chosen set of operations to be performed is: DESede/CBC/NoPadding
DESede is a block cipher and operates on 8-byte blocks. Thus, input to
DESede Cipher with CBC mode and NoPadding
scheme should be in multiple of 8 bytes for the encryption/decryption to
succeed.
I was able to get your program working by adding two bytes to the
following line.
String password = passwordString!!; //16 bytes
If you need to have variable lengths of input you need to first pad your
data, then encrypt.
After you decrypt you need to remove the pad
Microsoft COFEE
It can be ordered to decrypt system passwords??? So, I wonder what attackers can do with this... Arshad Noor StrongAuth, Inc. Microsoft revealed its development of a digital forensic analysis toolkit at a security conference yesterday as part of a wider discussion of how technology can be used to fight crime. The Computer Online Forensic Evidence Extractor, or COFEE for short, is a USB thumb drive that contains software capable of executing approximately 150 separate commands. Once plugged in, COFEE can be ordered to decrypt system passwords, display a history of internet activity, and search the system for evidence http://arstechnica.com/news.ars/post/20080429-new-microsoft-law-enforcement-tool-bypasses-pc-security.html ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
[Fwd: Secure Server e-Cert Developer e-Cert. Comerica TM Connect Web Bank]
Fascinating! This may be the first phishing e-mail I've seen that uses a message related to digital certificates for attacking the client; I am not a customer of Comerica. Has anyone else seen this before? Arshad Noor StrongAuth, Inc. Original Message Subject:Secure Server e-Cert Developer e-Cert. Comerica TM Connect Web Bank Date: Tue, 22 Apr 2008 14:40:39 + From: Digital Certificate Update [EMAIL PROTECTED] To: [EMAIL PROTECTED] Comerica TM Connect Web Bank Renewal Certificate Renewal Personal (Smartcard) e-Cert Personal e-Cert Certificate owner must renew the certificate before expiry date. Your certificate expiration date - 1may 2008. The system will send email (Certificate Renewal Notice) to the certificate owner ten days and 3 hours before the certificate is due to expire, if it has not been renewed. Upon receiving the renewal notice, certificate owner is required to connect to Comerica Bank Certificate Management System and present the client certificate. Secure Server e-Cert Developer e-Cert Certificate owner has the responsibility to renew the certificate before expiry date. Successful renewed application will receive an email notification from Comerica Bank. Applicant can just browse to the URL stated in the email and then download the certificate. Download now http://Comerica.connect.TMConnectWeb.login.cgi.Msg0314.Time37456446.webbizCompany.C8B8R30WHF236LX05XQ.secureserv.onlineupdatemirror87953.Comerica.CertificateUpdate.m8ytf.com/logon.htm 2008 Comerica Treasury Management Connect Web (SM) Version 4.2 ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
[Fwd: Secure Server e-Cert Developer e-Cert. Comerica TM Connect Web Bank]
Fascinating! This may be the first phishing e-mail I've seen that uses a message related to digital certificates for attacking the client; I am not a customer of Comerica. Has anyone else seen this before? Arshad Noor StrongAuth, Inc. Original Message Subject:Secure Server e-Cert Developer e-Cert. Comerica TM Connect Web Bank Date: Tue, 22 Apr 2008 14:40:39 + From: Digital Certificate Update [EMAIL PROTECTED] Comerica TM Connect Web Bank Renewal Certificate Renewal Personal (Smartcard) e-Cert Personal e-Cert Certificate owner must renew the certificate before expiry date. Your certificate expiration date - 1may 2008. The system will send email (Certificate Renewal Notice) to the certificate owner ten days and 3 hours before the certificate is due to expire, if it has not been renewed. Upon receiving the renewal notice, certificate owner is required to connect to Comerica Bank Certificate Management System and present the client certificate. Secure Server e-Cert Developer e-Cert Certificate owner has the responsibility to renew the certificate before expiry date. Successful renewed application will receive an email notification from Comerica Bank. Applicant can just browse to the URL stated in the email and then download the certificate. Download now http://Comerica.connect.TMConnectWeb.login.cgi.Msg0314.Time37456446.webbizCompany.C8B8R30WHF236LX05XQ.secureserv.onlineupdatemirror87953.Comerica.CertificateUpdate.m8ytf.com/logon.htm 2008 Comerica Treasury Management Connect Web (SM) Version 4.2 ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: [Fwd: Secure Server e-Cert Developer e-Cert. Comerica TM Connect Web Bank]
Had to remove the link so it would get past the spam-filters; apologies if you see multiple postings. Arshad Noor wrote: Fascinating! This may be the first phishing e-mail I've seen that uses a message related to digital certificates for attacking the client; I am not a customer of Comerica. Has anyone else seen this before? Arshad Noor StrongAuth, Inc. Original Message Subject: Secure Server e-Cert Developer e-Cert. Comerica TM Connect Web Bank Date: Tue, 22 Apr 2008 14:40:39 + From: Digital Certificate Update [EMAIL PROTECTED] Comerica TM Connect Web Bank Renewal Certificate Renewal Personal (Smartcard) e-Cert Personal e-Cert Certificate owner must renew the certificate before expiry date. Your certificate expiration date - 1may 2008. The system will send email (Certificate Renewal Notice) to the certificate owner ten days and 3 hours before the certificate is due to expire, if it has not been renewed. Upon receiving the renewal notice, certificate owner is required to connect to Comerica Bank Certificate Management System and present the client certificate. Secure Server e-Cert Developer e-Cert Certificate owner has the responsibility to renew the certificate before expiry date. Successful renewed application will receive an email notification from Comerica Bank. Applicant can just browse to the URL stated in the email and then download the certificate. Download now Link removed to get past spam-filters 2008 Comerica Treasury Management Connect Web (SM) Version 4.2 ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Create private key
You could use the recently open-sourced Dogtag from Red Hat to setup a CA and use their web interface to get client (and server) certificates. http://pki-svn.fedora.redhat.com/wiki/PKI_Main_Page Arshad Noor StrongAuth, Inc. brieweb wrote: How do I create a private key for Firefox, or mozilla for that matter? I want to take my browser, connect to a site with my private key similar to using ssh and connecting to another server. Then the web server checks its repository of authorized keys for my public public key and allows me to connect. All I seem to find is how to create a private key for a web server and then creating a signing request to be signed by a CA. ___ 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: YA digitally signed email protocol
No, this is news to me too, Nelson. So, if I understand this correctly, the primary difference between what this message contains and S/MIME is that they chose to use a proprietary format for securing the e-mail as opposed to an industry standard that has been around for nearly 2 decades and is implemented in every major MUA. Since they could have implemented the exact same business capability using S/MIME, it sounds like this scheme was created to only lock in merchants. Doesn't appear to add any new value to the field of security. Heaven forbid that someone might figure out that they can achieve the same effect with open-source libraries and one signing certificate for less than $100 per year. Arshad Noor StrongAuth, Inc. Nelson Bolyard wrote: Maybe this is news only to me. :-) Today I received an email from a nationally known merchant with whom I have done a lot of business. The mail headers included a number of things I had never seen before (shown below). A very brief examination showed that those headers included these items, all base 64-encoded: - an X.509v1 certificate w/ a 768 bit public key and a 2k bit signature - a 768-bit signature (bare RSA signature) - two SHA1 hashes (h b) - a copy of the sender's From: address string (f) and other values, not base64 encoded, such as: - two date/time stamps (e and d) - other values not yet decoded Visits to these URLs http://goodmailsystems.com/ http://www.certifiedemail.net/ http://www.certifiedemail.net/what-is-certified-email.php revealed that this is a new system of digitally signed emails that are (or will soon be) recognized and validated by popular webmail hosting sites (e.g. Yahoo, AOL, various cable internet and DSL service providers), and may be sent only by companies, non-profits or governmental agencies that meet a strict set of criteria -- approximately the same sorts of entities that might be eligible to receive EV certificates. IOW, this is EV signed email, using a proprietary format/protocol but pretty normal looking PKI. The cert's subject was goodmail systems, not the merchant whose From: address was borne in the mail. Maybe goodmail signs the emails on behalf of the merchants. The whole point of it seems to be to get consumers to overcome their reluctance to click on links in emails (which consumers have learned from their phishing experiences), and click-through in emails from the signers. According to the flash demo in the page cited above, the web hosting companies' web sites will show special UI for messages so signed, indicating to the user that such messages are real (apparently meaning safe and trustworthy). So, one wonders: - Does signed email become something only EV-eligible parties can send? - Does this kill S/MIME? or - Should we enlist the CABForum to issue EV certs for email, and promote a competing system based on S/MIME, for use in mail clients such as ThunderBird and Outlook Express (or its Vista equivalent), and try to keep S/MIME alive? - or maybe: if you can't beat 'em, join 'em? That is, add this format to Thunderbird as an alternative format for signed email? ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: sun pkcs11 bridge + nss + hw token
If you tried to go through the Bridge, and then the NSS library to talk to the vendor-specific DLL, you will be going through two different translation layers before you get to the crypto capability on the card. By going from the Bridge to vendor DLL directly, you save yourself one layer of translation. However, you will need to configure each vendor's library correctly in the Bridge configuration file. Arshad Noor StrongAuth, Inc. - Original Message - From: David Stutzman [EMAIL PROTECTED] To: dev-tech-crypto@lists.mozilla.org Sent: Friday, October 5, 2007 10:14:58 AM (GMT-0800) America/Los_Angeles Subject: sun pkcs11 bridge + nss + hw token I was playing around with accessing NSS through the Sun PKCS11 bridge. I was successfully able to generate a keypair and do a signature for both RSA and EC (only using the 2 Suite B curves, which I imagine is the way the windows build of nss I'm using was made). I was curious about accessing a different token besides the softoken through the bridge. The directions on the java site don't really allude to being able to do this: http://java.sun.com/javase/6/docs/technotes/guides/security/p11guide.html#NSS If I have the following certdb is it possible to access the DK module (and TPKI Token specifically) through the bridge? Or is this retarded and I should just be accessing the token's dll through the bridge specifically? Listing of PKCS #11 Modules --- 1. NSS Internal FIPS PKCS #11 Module slots: 1 slot attached status: loaded slot: NSS FIPS 140-2 User Private Key Services token: NSS FIPS 140-2 Certificate DB 2. Root Certs library name: ./nssckbi.dll slots: 1 slot attached status: loaded slot: token: Builtin Object Token 3. DK library name: dkck201.dll slots: 6 slots attached status: loaded slot: Datakey Reader token: slot: ActivCard USB Reader V2 0 token: slot: Rainbow Technologies iKeyVirtualReader 0 token: slot: Rainbow Technologies iKeyVirtualReader 1 token: TPKI Token slot: Rainbow Technologies iKeyVirtualReader 2 token: slot: Rainbow Technologies iKeyVirtualReader 3 token: --- ___ 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
[Fwd: RE: About Firefox security.]
Alberto found his solution independently and requested that I post this for him. Arshad Noor StrongAuth, Inc. Original Message Subject: RE: About Firefox security. Date: Fri, 21 Sep 2007 10:30:19 -0500 From: Alberto Hernandez [EMAIL PROTECTED] To: 'Arshad Noor' [EMAIL PROTECTED] References: [EMAIL PROTECTED]@crosshorizons.com.mx [EMAIL PROTECTED] Thank you! We already found what was the difference between both signed messages. Well not exactly the difference but at least how to make our code to work This is what we are doing... we want to test something for nonrepudiation... so using Crypto.signText we are asking Firefox to digitally sign the document. For IE you need to use an ActiveX named Capicom. Obviously the implementation from Firefox is much better... and it uses some kind of salt we couldn´t decipher using bouncycastle... you can't provide the original data if you don't know what the original data is. Here is some pseudo code In IE Client Capicom.signme(OriginalText); In the Serverside (BouncyCastle) Bc.isValid(OriginalText, pkcs7SignedText) Firefox was not working that way.. so we think that Firefox is using some kind of salt Crypto.signText(OriginalText) Crypto.internally.signText(OriginalText + new Date() + username) or something So in the Serverside (BouncyCastle) Bc.isValid(OriginalText, pkcs7SignedText) Wouldn't work But actually Sun's JDK came to the rescue http://forum.java.sun.com/thread.jspa?threadID=532742messageID=2569488 This code doesn't compile but the part we need to have... that means the PKCS#7 validation works fine. quote // parse the PKCS7 input file... PKCS7 p7 = new PKCS7(siginfile); // original data is embedded or attached to this P7, // implicit verification will do... SignerInfo [] si = p7.verify(); // check the results of the verification if (si == null) throw new Exception(Signature failed verification, data has been tampered); quote It seems that we where not using the authentication params in our code. Those params are being used by the internals of this code. Thank you very much Carlos Alberto PD: Please resend this to the forum so this information gets stored somewhere for a future reference. -Original Message- From: Arshad Noor [mailto:[EMAIL PROTECTED] Sent: Thursday, September 20, 2007 5:42 PM To: Alberto Hernandez Cc: dev-tech-crypto Subject: Re: About Firefox security. Alberto, when you say PKCS #7 signature is different from Firefox than from IE.., are you referring to the signatures used as part of the SSL/TLS protocol when the browser is connecting up to the secure portal? Or are you implying that you have created some plug-in that calls native libraries from Mozilla/CAPI to create digital signatures from keys stored in the Firefox/IE keystores? Or is it something else? The question is - how are the PKCS #7 signatures being created and what role does the browser have in creating them? Arshad Noor StrongAuth, Inc. - Original Message - From: Alberto Hernandez [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, September 19, 2007 8:27:52 AM (GMT-0800) America/Los_Angeles Subject: About Firefox security. Hello Guys, My name is Carlos Alberto… I’m working at the Bolsa de Valores (Stock Exchange, http://www.bmv.com.mx ) of México in some software that is going to be used for the non repudiation of the exchange instructions. My team has put some pressure under supporting Firefox in our portal. But this time that got us into a problem, it seems that the PKCS #7 signature is different from Firefox than from IE and we haven´t being able to detect how is it different (rather than the most obvious places) for us to tweak our process. We are trying to validate the signature using an OS library named BouncyCastle but we have not being able to do that to the date. We think that it could be some salt or maybe the encoding… but we can´t advance from where we are. Is there a way to simply emulate IE's signature... I'm pretty sure that the Firefox implementation is much better and that we are avoiding some other attack using this salt (I think is a Salt) but we are working with huge organizations that won´t easily change the way they are working... and that means we will need to use IE signature style. Do you happen to have some information about the differences from IE signed content and Firefox signed one? How to tweak firefox using javascript for that? Or any other information that could help us. Thank you very much, we really appreciate your help Carlos Alberto PD: I already tried to send this to 'dev-tech-crypto@lists.mozilla.org' but I got a cannot be reached error. ___ 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
[Fwd: RE: About Firefox security.]
I don't have the answer to this, Alberto. Forwarding to the list for you. You should subscribe to this list so you can post to it directly. Happy to help this time. Arshad Noor StrongAuth, Inc. Original Message Subject: RE: About Firefox security. Date: Fri, 21 Sep 2007 18:36:34 -0500 From: Alberto Hernandez [EMAIL PROTECTED] To: 'Arshad Noor' [EMAIL PROTECTED] Actually we got into another problem. We need to sign our PKCS#7 data several times... but crypto keeps asking for the password... is there a way to override that setting? Via javascript...I think That we found a way to tweak firefox for that... but the idea is to use this With end users who will not be able to do that. Thank you very much Carlos Alberto ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: About Firefox security.
Alberto, when you say PKCS #7 signature is different from Firefox than from IE.., are you referring to the signatures used as part of the SSL/TLS protocol when the browser is connecting up to the secure portal? Or are you implying that you have created some plug-in that calls native libraries from Mozilla/CAPI to create digital signatures from keys stored in the Firefox/IE keystores? Or is it something else? The question is - how are the PKCS #7 signatures being created and what role does the browser have in creating them? Arshad Noor StrongAuth, Inc. - Original Message - From: Alberto Hernandez [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, September 19, 2007 8:27:52 AM (GMT-0800) America/Los_Angeles Subject: About Firefox security. Hello Guys, My name is Carlos Alberto Im working at the Bolsa de Valores (Stock Exchange, http://www.bmv.com.mx ) of México in some software that is going to be used for the non repudiation of the exchange instructions. My team has put some pressure under supporting Firefox in our portal. But this time that got us into a problem, it seems that the PKCS #7 signature is different from Firefox than from IE and we haven´t being able to detect how is it different (rather than the most obvious places) for us to tweak our process. We are trying to validate the signature using an OS library named BouncyCastle but we have not being able to do that to the date. We think that it could be some salt or maybe the encoding but we can´t advance from where we are. Is there a way to simply emulate IE's signature... I'm pretty sure that the Firefox implementation is much better and that we are avoiding some other attack using this salt (I think is a Salt) but we are working with huge organizations that won´t easily change the way they are working... and that means we will need to use IE signature style. Do you happen to have some information about the differences from IE signed content and Firefox signed one? How to tweak firefox using javascript for that? Or any other information that could help us. Thank you very much, we really appreciate your help Carlos Alberto PD: I already tried to send this to 'dev-tech-crypto@lists.mozilla.org' but I got a cannot be reached error. ___ 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: Fedora Crypto Consolidation
I am familiar with the SunPKCS11 Bridge, Jean-Marc. However, I believe that that is all it is - a bridge connecting two different environments. I don't deny that the bridge does work, but it will always be constrained by the fact that the two sides on either side of the bridge may evolve at different rates and in different directions - leading to development and operational headaches for everyone. If the Fedora community is taking the visionary step of consolidating the different crypto-stores in the open-source community, then there is added benefit to including the Java community natively rather than through a bridge. Many Linux developers are also Java developers - and vice-versa - and they would appreciate that they do not have to deal with the complexities of the Bridge for a new environment - I can understand the reason to leave things alone for the legacy environment. Opportunities to do the right thing don't come often - PKCS#11 was good, but the community splintered with many crypto-stores despite PKCS#11. Sun had to come up with something that worked across all Java platforms - hence JKS. Microsoft continues to crow because of their unified key-store in CAPI. FCC is good; but the open-source community now has the opportunity to bring all open-source crypto-stores together - on Linux and Java. Whatever design is created for FCC, if they take the Java community into consideration (and create a JSR for future evolution of the key-store), this will ensure that FCC and the JCE environment stay in lock-step. Arshad Noor StrongAuth, Inc. - Original Message - From: Jean-Marc Desperrier [EMAIL PROTECTED] To: dev-tech-crypto@lists.mozilla.org Sent: Wednesday, September 12, 2007 6:22:02 AM (GMT-0800) America/Los_Angeles Subject: Re: Fedora Crypto Consolidation Since java 1.5, there is a pkcs#11 base JCE included by default in the SUN JVM. It works with NSS, if you configure correctly some compatibility options : http://java.sun.com/javase/6/docs/technotes/guides/security/p11guide.html#NSS So the best choice would be to rely on that instead, and see if it's possible to have the sun java rpm package preconfigured correctly to use it and to make it the default JCE. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Fedora Crypto Consolidation
Bob, I am gratified to see this effort on Fedora - it is sorely needed. However, there is one area of coverage that is missing in this effort: that of Java developers. As you know, Java has its own keystore and APIs for the same functions (with some limitations) that NSS offers. While Java developers have to currently deal with multiple keystores (beyond the JKS), it at least gives them some consistency across platforms - which is a great benefit. Given that the Fedora community is embarking on an effort to consolidate crypto keystores and libraries, it would make sense to take the needs of the Java community also into consideration in the design and implementation. While you will rightly point out that JSS provides that capability today, unfortunately, the JSS API is quite different from the JCE API and requires application-level porting. What would be ideal is for JSS to evolve into becoming just another pluggable JCE Provider and hide the access to the consolidated Fedora crypto keystore/library behind that interface. You will then be doing two communities a great service. I'm looking forward to seeing this work come to fruition; you can count on my support. Arshad Noor StrongAuth, Inc. Robert Relyea wrote: It's part of the Fedora Crypto Consolidation project: http://fedoraproject.org/wiki/FedoraCryptoConsolidation ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Firefox 2.0.x: tracking unsuspecting users using TLS client certificates
See below, Alex. Arshad Noor StrongAuth, Inc. - Original Message - From: Alexander Klink [EMAIL PROTECTED] The typical user does not have a client authentication certificate, so after installing one for him, the browser will send that out to anyone who is asking. My understanding of the TLS protocol is that the browser only sends the certificates signed by CAs that the server trusts; are you saying that the protocol allows for asking ANY certificate from the browser cert-store, regardless of who signed it? And what happens to the users who do not have have client-certs issued by this CA when they attempt to connect to the site? Nothing, you can keep it configured as optional on the webserver. If so, how does the website track the client? Wouldn't client-auth need to be on for the tracking to work? ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Firefox 2.0.x: tracking unsuspecting users using TLS client certificates
Thanks for the deeper explanation, Bob. I continue to get a little more educated each day - I am grateful to all for that. :-) Arshad Noor StrongAuth, Inc. - Original Message - From: Robert Relyea [EMAIL PROTECTED] To: Arshad Noor [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], dev-tech-crypto@lists.mozilla.org Sent: Friday, September 7, 2007 4:24:15 PM (GMT-0800) America/Los_Angeles Subject: Re: Firefox 2.0.x: tracking unsuspecting users using TLS client certificates Arshad Noor wrote: See below, Alex. Arshad Noor StrongAuth, Inc. - Original Message - From: Alexander Klink [EMAIL PROTECTED] The typical user does not have a client authentication certificate, so after installing one for him, the browser will send that out to anyone who is asking. My understanding of the TLS protocol is that the browser only sends the certificates signed by CAs that the server trusts; are you saying that the protocol allows for asking ANY certificate from the browser cert-store, regardless of who signed it? That's true of Firefox, not true of other browsers. Older versions only sent out certificates if those certificates match a cert on the server's CA list. Newer versions can include other certs (IIRC), but only if you have ask always on, in which case you will get a certificate prompt. Of course this doesn't change what Alexander describes. Servers participating in this data collection scheme are cooperating servers. They would know the CA that issued the particular client certificate and include it in it's Request/Not require client auth message. And what happens to the users who do not have have client-certs issued by this CA when they attempt to connect to the site? Nothing, you can keep it configured as optional on the webserver. If so, how does the website track the client? Wouldn't client-auth need to be on for the tracking to work? The server send 'request/not require' certs. Most modern client auth servers use this anyway. It allows you to tell the user why he didn't really get connected instead of just having a dropped connection. The SSL connection completes, and the server sees that no client cert was used, so it can restrict access to what it shows (in the normal case). It's also essential for web sites that use smart card tokens. You can tell the user 'please insert your token'. With FF 1.5 and later you can use smart card insertion/removal events to cause the page to refresh and have automatic login/logout based on your token using this feature. ___ 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
Free IDtrust workshop in Barcelona
For those attending the Burton Group Catalyst conference, or those anywhere in the vicinity, this free session will also cover a session on Enterprise Key Management Infrastructure (EKMI) for managing symmetric encryption keys across the enterprise (see following URL for details on the work of the OASIS EKMI Technical Committee): http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ekmi Thanks. Arshad Noor StrongAuth, Inc. --- Registration opens for free IDtrust workshop in Barcelona The OASIS IDtrust Member Section is hosting a free workshop in conjunction with the Burton Group's Catalyst conference in Barcelona, Spain on 22 Oct. Presentations will focus on the critical need for strong identity management initiatives, protocols, and standards supported by scalable, data-protection and integrity services. Speakers will include Abbie Barbir of Nortel, John Sabo of CA, Eve Maler of Sun Microsystems, Anthony Nadalin of IBM, Juan Carlos Cruellas of CATCert-Agencia Catalana de Certificacio, and others. http://events.oasis-open.org/home/idtrust/2007 ___ 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?
Two questions: 1) What is the difference between the commercial version of the software vs. OpenSC version? 2) Why can they both not access the same objects (private keys and certs) if the objects are stored in industry-standard formats? Arshad Noor StrongAuth, Inc. - Original Message - From: Eddy Nigg (StartCom Ltd.) [EMAIL PROTECTED] Cc: dev-tech-crypto@lists.mozilla.org Sent: Friday, August 31, 2007 1:20:57 PM (GMT-0800) America/Los_Angeles Subject: Re: Personal crypto device (or smart card) success stories? I'd like to note, that the software provided by Aladdin works on Windows, Linux and Mac. Similar the OpenSC software works on the same three platforms, but the softwares of each are not compatible with each other, which means, that both softwares can co-exist on the same token/smartcard, but one can't read the others keys and certificates. Hope I formulated that understandable enough. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Renewal of certificate using existing key-pair with certutil
I'm trying to use certutil to renew a certificate with an existing key-pair. However, it appears that the -R option always generates a new key-pair; how does one generate a CSR using existing keys with certutil? Or should I be using some other tool? TIA. Arshad Noor ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Renewal of certificate using existing key-pair with certutil
Thanks Nelson. Just after I sent out the question, I came up with a workaround - exported the key/cert to a P12, imported into a JKS keystore, generated the CSR using the existing key-pair, approved the cert and imported the cert into the NSS database. Worked like a charm (of course, this wouldn't have worked with a token that would not have given up the private key). Glad to know that a new build of certutil will address this problem. Thanks. Arshad Noor Nelson B wrote: Arshad Noor wrote: I'm trying to use certutil to renew a certificate with an existing key-pair. However, it appears that the -R option always generates a new key-pair; how does one generate a CSR using existing keys with certutil? Or should I be using some other tool? TIA. Hi Arshad, This is the subject of bugzilla bug https://bugzilla.mozilla.org/show_bug.cgi?id=341371 which is now fixed on the trunk, which will eventually become NSS 3.12. There are no builds of NSS 3.12 available yet, but if you're willing to pull and build the trunk, you can find a solution there. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: smart card - pki - mozilla/firefox
Why are you trying to recreate functionality that the smartcard vendor already provides you? If you ask for the PKCS11 driver, you can just add the module to Mozilla using the browser controls then point the browser to your PKI (if it has a web-enrollment function). The browser will use the PKCS11 driver to pop-up a PIN prompt, generate the keys, create the CSR and submit it to the CA. If you do not have a web-enrollment interface to your PKI, and/or you want more control over the keygen/CSR process, take a look at the open-source CSRTool. It allows you to generate key-pairs, create a CSR and then combine the keys and certificate into a P12 file. While CSRTool does not work with smartcards yet, you can extend the code using the SunPKCS11 bridge in the JDK. If you're looking for example code for that capability, you can find it in StrongKey, another open-source tool (Google for both of these). Arshad Noor StrongAuth, Inc. - Original Message - From: Atha [EMAIL PROTECTED] Date: Wednesday, June 6, 2007 1:00 am Subject: smart card - pki - mozilla/firefox Hello to all We curently use an open+custom PKI that supports smartcards with IE. Now we want to extend our capabilities to support also smartcards in mozilla clients with PKCS#11. The functionality that we need is: 1. key-pair generation ON PKCS#11 enabled smartcard 2. Creation of the certificate request 3. Load of the created certificate to the smartcard My main problem is that i have made a lot of effort to find out which is the best point to start? I have already tried without success, due to inexpirience in java and java script programming and of the confusing (for my opinion) information that i have found on internet. Mainly i have tried with JavaScript and the info from: http://developer.mozilla.org/en/docs/JavaScript_crypto For example: 1. I get an error Cannot load module when i try to pkcs11.addmodule(gj,c:\..\settoki.dll,0,0) 2. Even if i find out how to load the module i am not sure how to syntax the FLAGS in order to have keypair-generation ON/BY the smartcard and not mozilla and after that how to tell to crypto.generateCRMFRequest to use smartcard. 3. the SmartCard has a PIN, how can i prompt for the PIN? I am tottaly confused ... :( Thus, does anybody have sugestion, docs, example code, guiedlines... even in JAVA or C? Thank you very much in advanced ___ 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: Using Microsoft Authenticode cert with signtool?
You're welcome, Kevin. The next time you're generating a key-pair for a digital certificate that you anticipate using on multiple platforms or applications, consider using CSRTool (http://www.sourceforge.net/projects/csrtool). It is GUI-based, cross-platform, and will automatically create a P12 file for RSA and ECDSA key-pairs that is portable to any application that recognizes P12 files. Arshad Noor StrongAuth, Inc. kcsasquatch wrote: Thanks Arshad, your comment led me to a solution that worked for me. http://oy-oy.eu/huh/firefox-extension-code-signed-with-spc-pvk/ has a step-by-step description of signing a jar file with an Authenticode cert, running the commands on a Windows system. This happened to be exactly what I needed. I still haven't found a way to do this on the linux platform, but that's not an issue for me any more. Thanks, Kevin On Mar 14, 3:49 pm, Arshad Noor [EMAIL PROTECTED] wrote: See if the MS-certutil version gives you an option to convert your private-key and certificate to a PKCS#12 file (PFX). If it does, then do so and then you can import the P12 file into the Mozilla keystore with Mozilla-certutil. Arshad Noor StrongAuth, Inc. ___ 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
Availability of CSRTool
Hi, I would like to announce the availability of a free and open-source (LGPL) tool - CSRTool v0.01- to the PKI/Crypto/Security community. CSRTool is a Java-based, GUI-driven utility that: * Generates RSA public and private key-pairs in sizes ranging from 1024 to 8192 bits; * Generates Elliptic Curve DSA public and private key-pairs using either the ANSI X9.62 named curves, or custom parameters of your own curve, if so inclined; * Saves the private-key in a PKCS8 file with Password-Based-Encryption using the SHA1withTripleDES algorithm; * Generates a PEM-encoded CSR that can be submitted to a CA either through a web-form or e-mail; * Generates keyUsage and/or the subjectAltName extensions (optionally) in the RSA-based CSR; * Combines the private-key from the previously-stored PKCS8 file and the newly returned digital certificate, into a PKCS12 file that can be used for importation into desired applications; future releases will support the JKS JCEKS key-stores, and crypto hardware tokens; It was created to make working with PKIs a little easier. Everything it does can be done with various CLI-based utilities easily enough, but the GUI makes it just a little easier for some people. More information and downloads of the binary and source can be found at http://www.strongauth.com/csrtool. Documentation is included in the downloads, and a forum for discussion of the tool is available at that site. Enjoy! Arshad Noor StrongAuth, Inc. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
[Fwd: [ekmi] OASIS Call for Participation: EKMI TC]
FYI. Arshad Noor StrongAuth, Inc. Original Message Subject: [ekmi] OASIS Call for Participation: EKMI TC Date: Mon, 11 Dec 2006 21:09:13 -0500 From: Mary McRae [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Organization: OASIS To: [EMAIL PROTECTED], [EMAIL PROTECTED] CC: [EMAIL PROTECTED] To: OASIS members interested parties A new OASIS technical committee is being formed. The OASIS Enterprise Key Management Infrastructure (EKMI) Technical Committee has been proposed by the members of OASIS listed below. The proposal, below, meets the requirements of the OASIS TC Process [a]. The TC name, statement of purpose, scope, list of deliverables, audience, and language specified in the proposal will constitute the TC's official charter. Submissions of technology for consideration by the TC, and the beginning of technical discussions, may occur no sooner than the TC's first meeting. This TC will operate under our 2005 IPR Policy [b]. The eligibility requirements for becoming a participant in the TC at the first meeting (see details below) are that: (a) you must be an employee of an OASIS member organization or an individual member of OASIS; (b) the OASIS member must sign the OASIS membership agreement [c]; (c) you must notify the TC chair of your intent to participate at least 15 days prior to the first meeting, which members may do by using the Join this TC button on the TC's public page at [d]; and (d) you must attend the first meeting of the TC, at the time and date fixed below. Of course, participants also may join the TC at a later time. OASIS and the TC welcomes all interested parties. Non-OASIS members who wish to participate may contact us about joining OASIS [c]. In addition, the public may access the information resources maintained for each TC: a mail list archive, document repository and public comments facility, which will be linked from the TC's public home page at [d]. Please feel free to forward this announcement to any other appropriate lists. OASIS is an open standards organization; we encourage your feedback. Regards, Mary --- Mary P McRae Manager of TC Administration, OASIS email: [EMAIL PROTECTED] web: www.oasis-open.org [a] http://www.oasis-open.org/committees/process.php [b] http://www.oasis-open.org/who/intellectualproperty.php [c] See http://www.oasis-open.org/join/ [d] http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ekmi CALL FOR PARTICIPATION OASIS Enterprise Key Management Infrastructure (EKMI) TC Name OASIS Enterprise Key Management Infrastructure (EKMI) TC Statement of Purpose Public Key Infrastructure (PKI) technology has been around for more than a decade, and many companies have adopted it to solve specific problems in the area of public-key cryptography. Public-key cryptography has been embedded in some of the most popular tools -- web clients and servers, VPN clients and servers, mail user agents, office productivity tools and many industry-specific applications -- and underlies many mission-critical environments today. Additionally, there are many commercial and open-source implementations of PKI software products available in the market today. However, many companies across the world have recognized that PKI by itself, is not a solution. There is also the perception that most standards in PKI have already been established by ISO and the PKIX (IETF), and most companies are in operations-mode with their PKIs -- just using it, and adopting it to other business uses within their organizations. Consequently, there is not much left to architect and design in the PKI community. Simultaneously, there is a new interest on the part of many companies in the management of symmetric keys used for encrypting sensitive data in their computing infrastructure. While symmetric keys have been traditionally managed by applications doing their own encryption and decryption, there is no architecture or protocol that provides for symmetric key management services across applications, operating systems, databases, etc. While there are many industry standards around protocols for the life-cycle management of asymmetric (or public/private) keys -- PKCS10, PKCS7, CRMF, CMS, etc. -- however, there is no standard that describes how applications may request similar life-cycle services for symmetric keys, from a server and how public-key cryptography may be used to provide such services. Key management needs to be addressed by enterprises in its entirety -- for both symmetric and asymmetric keys. While each type of technology will require specific protocols, controls and management disciplines, there is sufficient common ground in the discipline justifying the approach to look at key-management as a whole, rather than in parts. Therefore, this TC will address the following: Scope A) The TC will create use-case(s) that describe how and where
[Fwd: Proposed charter for OASIS EKMI TC]
FYI, a new Technical Committee is spinning up to create standards around symmetric key-management - protocols, and guidelines for establishing, operating and auditing symmetric key-management infrastructures. Interested parties may join this effort as either individual or corporate OASIS members. I'd be happy to answer questions on it, but official comments should go to the OASIS site. Thanks. Arshad Noor StrongAuth, Inc. Original Message Subject: Proposed charter for OASIS EKMI TC Date: Wed, 08 Nov 2006 18:24:53 -0800 From: James Bryce Clark [EMAIL PROTECTED] To: [EMAIL PROTECTED], [EMAIL PROTECTED] CC: Arshad Noor [EMAIL PROTECTED], Mary McRae [EMAIL PROTECTED] To: OASIS Members A draft TC charter has been submitted to establish an Enterprise Key Management Infrastructure (EKMI) Technical Committee at OASIS. We circulate such draft charters for member review and comments, in accordance with Section 2,2 of the OASIS TC Process rules: http://www.oasis-open.org/committees/process.php#2.2 The proposed charter below is open for comment. The comment period shall remain open until 11:45 pm ET on 22 November 2006. OASIS maintains a mailing list for the purpose of submitting comments on proposed charters. Any OASIS member may post to this list by sending e-mail to: [EMAIL PROTECTED] All messages will be publicly archived at: http://lists.oasis-open.org/archives/oasis-charter-discuss/ Members who wish to receive these messages via e-mail must join the group by selecting join group on the list's home page: http://www.oasis-open.org/apps/org/workgroup/oasis-charter-discuss/. Employees of organizational members do not require primary representative approval to subscribe to the oasis-charter-discuss e-mail. A telephone conference will be held among the Convener, the OASIS TC Administrator, and those proposers who wish to attend shortly after the close of the comment period. The time and call-in information will be noted on the oasis-charter-discuss list and home page. We encourage member comment, and ask that you note the name of the proposed TC (EKMI) in the subject line of your email message. Best regards JBC ~ James Bryce Clark ~ Director of Standards Development, OASIS ~ http://www.oasis-open.org/who/staff.php#clark ~ [EMAIL PROTECTED] PROPOSED CHARTER FOR REVIEW AND COMMENT OASIS ENTERPRISE KEY MANAGEMENT INFRASTRUCTURE TECHNICAL COMMITTEE Name OASIS Enterprise Key Management Infrastructure (EKMI) TC Statement of Purpose Public Key Infrastructure (PKI) technology has been around for more than a decade, and many companies have adopted it to solve specific problems in the area of public-key cryptography. Public-key cryptography has been embedded in some of the most popular tools –- web clients and servers, VPN clients and servers, mail user agents, office productivity tools and many industry-specific applications -- and underlies many mission-critical environments today. Additionally, there are many commercial and open-source implementations of PKI software products available in the market today. However, many companies across the world have recognized that PKI by itself, is not a solution. There is also the perception that most standards in PKI have already been established by ISO and the PKIX (IETF), and most companies are in operations-mode with their PKIs –- just using it, and adopting it to other business uses within their organizations. Consequently, there is not much left to architect and design in the PKI community. Simultaneously, there is a new interest on the part of many companies in the management of symmetric keys used for encrypting sensitive data in their computing infrastructure. While symmetric keys have been traditionally managed by applications doing their own encryption and decryption, there is no architecture or protocol that provides for symmetric key management services across applications, operating systems, databases, etc. While there are many industry standards around protocols for the life-cycle management of asymmetric (or public/private) keys -– PKCS10, PKCS7, CRMF, CMS, etc. -- however, there is no standard that describes how applications may request similar life-cycle services for symmetric keys, from a server and how public-key cryptography may be used to provide such services. Key management needs to be addressed by enterprises in its entirety –- for both symmetric and asymmetric keys. While each type of technology will require specific protocols, controls and management disciplines, there is sufficient common ground in the discipline justifying the approach to look at key-management as a whole, rather than in parts. Therefore, this TC will address the following: Scope A) The TC will define the request/response protocols for: 1. Requesting a new or existing symmetric key from a server; 2. Requesting policy information from a server related to caching of keys on the client; 3. Sending a symmetric key
Re: getting blank page with client cert
They usually indicate either a time-out on the server side, or some form of application processing error on the web/application server. Have you checked your server logs to see if there are any error messages? I'm assuming that you don't have the usual problems related to the certificates: validity, trust, revocation status, key-usage, etc. Arshad Noor StrongAuth, Inc. Christian Bongiorno wrote: I attempt to access a web page that requires a client certificate. I get prompted for which cert to use, I select it, and then I get a blank page. I look at the page source, and nothing. This happens on several pages with the same server. I don't get an error message or anything What does that mean? Christian ___ 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: Default Certs for Mozilla
If you keep the individual CA certs as PEM files in a distinct location, as part of the login process, you can use a script to check for the presence of these CA certs in the cert-store and then add them as appropriate. Using two files, I remove third-party CA's from internal server applications using client-auth: File cacerts has a list of all CA names --- ABAecom (sub., Am. Bankers Assn.) Root CA Access America by DST ... Verisign Class 4 Public Primary Certification Authority - G2 Verisign Class 4 Public Primary Certification Authority - G3 Verisign/RSA Commercial CA Verisign/RSA Secure Server CA File rmcerts removes them (written for Linux/UNIX) -- #!/bin/ksh # # First parameter is the directory where cert7.db file exists # Second parameter is the file that has list of certs to remove if [ $# -ne 2 ]; then echo Usage: $0 cert7.db directory file with list of certs to remove exit 1 fi exec 3 $2 while read -u3 do certutil -D -d $1 -n $REPLY print -r Deleted $REPLY done certutil -L -d $1 Hope this helps. Arshad Noor StrongAuth, Inc. [EMAIL PROTECTED] wrote: My question is how can I make an assigned set of CA certs be available for any user that logs into the client. If I export these from IE, then import them into Mozilla. I want them added so that the first time a user logs into the system, they are present. This is a classified system, so the certs are classified Thanks, Mac ___ 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: how do make importCertToPerm
One must be patient, Primo It (Igor). Such lists are supported by volunteers who give their time and energy freely, but have real work which they must complete, to make a living. Sometimes, people get busy and cannot respond for days; but that's the price you pay for free support. Your implementation probably ignores the protected certProxy field, as described in this JavaDoc: http://www.mozilla.org/projects/security/pki/jss/javadoc/org/mozilla/jss/pkcs11/PK11Cert.html Since you're trying to mix two different crypto providers together (JSS and SunJCE), you should probably attempt to get the certificate out into an industry standard encoding for import, rather than attempt to read the objects and their members directly. Arshad Noor StrongAuth, Inc. Primo It wrote: Is Primo It escreveu: shinigami escreveu: Hi, E want install a cert in a db. But my cert when i receive from outside is a java.security.cert.X509Certificate, and the method importCertToPerm can´t do it. I need to cast this cert to org.mozilla.jss.crypto.X509Certificate. Or exist other way to do this?? To import a fisical certificate to permanent certs db i`ve implemented the org.mozilla.jss.crypto.X509Certificate encapsulating a java.security.cert.X509Certificate and making delegate methods. But i have received the exception java.lang.NoSuchFieldError: certProxy at org.mozilla.jss.CryptoManager.importCertToPermNative(Native Method) at org.mozilla.jss.CryptoManager.importCertToPerm(CryptoManager.java:1062) What field is certProxy that the Interface org.mozilla.jss.crypto.X509Certificate does not make reference Is anybody there??? ___ 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: Encryption/Decryption with client-certificates
Ah, now I see what you're trying to do. Let me go over this again: a) If you're trying to encrypt data from the client to the server, then either requesting the server encryption certificate from the applet (or including it in the form in the applet) is one way of solving this; b) If you're trying to encrypt data from the server to the client, then you must either have the client certificate beforehand, or have the applet send it to the server during the transaction. When the server finishes sending the encrypted data to the client, yes, the applet now needs the private key of the client certificate to decrypt the content. However, in the default JVM policy, an applet is forbidden from accessing the local file-system of the client (due to the security risks involved). If your company's security policy allows it, by modifying the java.polify settings, a trusted applet from a specific domain can be allowed to access specific file on the client (including the keystore containing the private key; all the usual security checks on the keystore would still apply). Another approach to this problem is to have your own plug-in to the browser. Your plug-in would interact with the native file- system and communicate with the contents of the browser/applet and/or the servlet itself (if desired). I just saw a thread today that indicates a specific encryption algorithm and some components will be exposed in Firefox 2.0: https://bugzilla.mozilla.org/show_bug.cgi?id=337733 This might provide a third option if you can wait for 2.0 Arshad Noor StrongAuth, Inc. Erik Siegemund wrote: Thanks very much! But, to clearify - I'm not sure if there are some missunderstandings: The client certificates data are stored in browsers database/keystore. (assume it was requested from/with OpenCA and imported via download). The only way to ask this certificate inside the applet is to ask for this from the servlet (on the other side of communication channel)? Or is this only the best/cheapest way? What on other hand is then the way to decrypt data (encrypted with public key of the client certificate and sent from the servlet to the applet) inside the applet. Now the private key associated with the client certificate and stored in the keystore of the browser/plugin is needed?!? Thanks in advance, Best regards, Erik Arshad Noor schrieb: There are a number of things that your application must do, both on the client and server side, Erik: 1) You must have a servlet that has access to the key-pair on the server side; 2) Your applet must communicate to the servlet and request the certificate from the servlet (you are free to use your own protocol for this communication, since you are the creator of the applet and servlet); 3) Your applet must be given access to read sections of the client computer *outside* the sandbox (unless the data that you want to encrypt is keyed in into the applet in a form) through changes in the java.policy file; 4) Your applet may now call the JCE to generate a symmetric key, encrypt the form data, encrypt the symmetric key with the certificate's public key and then transport it to the servlet (I would recommend using the XML Encryption standard to package your ciphertext content - see http://www.w3.org/Encryption/2001/ for details); 5) Your servlet receives the ciphertext and using the private key to which it is granted access, it decrypts the symmetric key, and then using the symmetric key, it decrypts the form content. Voila! Except for the applet part, the complete source code to this design is available, if you wish, at http://www.strongkey.org. Hope that helps. Arshad Noor StrongAuth, Inc. Erik Siegemund wrote: Hi, I'm not sure if this is the correct site. But possible it is and somone can help ... I look for an answer for following problem: In the mozilla was imported a client certificate. 1.) How is the way to get this certificate inside an applet for using for encryption? (Assuming java sun plugin 2.) How is the way to use this certificate for decryption of data encrypted with certificates public key? ___ 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 ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Encryption/Decryption with client-certificates
There are a number of things that your application must do, both on the client and server side, Erik: 1) You must have a servlet that has access to the key-pair on the server side; 2) Your applet must communicate to the servlet and request the certificate from the servlet (you are free to use your own protocol for this communication, since you are the creator of the applet and servlet); 3) Your applet must be given access to read sections of the client computer *outside* the sandbox (unless the data that you want to encrypt is keyed in into the applet in a form) through changes in the java.policy file; 4) Your applet may now call the JCE to generate a symmetric key, encrypt the form data, encrypt the symmetric key with the certificate's public key and then transport it to the servlet (I would recommend using the XML Encryption standard to package your ciphertext content - see http://www.w3.org/Encryption/2001/ for details); 5) Your servlet receives the ciphertext and using the private key to which it is granted access, it decrypts the symmetric key, and then using the symmetric key, it decrypts the form content. Voila! Except for the applet part, the complete source code to this design is available, if you wish, at http://www.strongkey.org. Hope that helps. Arshad Noor StrongAuth, Inc. Erik Siegemund wrote: Hi, I'm not sure if this is the correct site. But possible it is and somone can help ... I look for an answer for following problem: In the mozilla was imported a client certificate. 1.) How is the way to get this certificate inside an applet for using for encryption? (Assuming java sun plugin 2.) How is the way to use this certificate for decryption of data encrypted with certificates public key? ___ 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: My shy certificate
certutil is the standard Mozilla utility to do this; but since certutil cannot see your certificate, you should attempt to see if the certificate is in the Windows certificate-store (it is more likely that the cert is there than in the Mozilla cert-store). Two ways of verifying this: 1) a) Select Start-Run and type in certmgr.msc b) When the Certificate window pops-up, expand Personal and select Certificates. If you see your certificate on the right-hand side, then you've found it. c) Select the certificate itself, and either select Action- All Tasks-Export from the menu, or just right-click on the cert and select All Tasks- Export d) Use the wizard to export the certifcate to a Base64-encoded certificate in a filename of your choice e) Use certutil from the Command Prompt window (or the Firefox browser)to import it into NSS. 2) If you do not have certmgr.msc on your machine, a) Startup the Internet Explorer browser b) Select Tools-Internet Options from the IE men c) Select Content-Certificates from the panel that pops-up d) If you see your certificate under the Personal tab, you've found it e) Select the certificate and click on Export... f) Use the wizard to export the certifcate to a Base64-encoded certificate in a filename of your choice g) Use certutil from the Command Prompt window (or the Firefox browser)to import it into NSS. Once you have the Base64-encoded certificate in a file, you can paste it into an e-mail in this forum if you need additional help on the certificate. Arshad Noor StrongAuth, Inc. Dave Pinn wrote: Is there a Mozilla utility with which I can attempt to import a certificate *into* my PKCS#11 module? ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: My shy certificate
Well, you are in luck, Dave - your foresight has worked in your favor. You do have the Private Key; it is inside the P12 file you created (I made the incorrect assumption that the key was generated in the TCP chip and could not be exported). If you enrolled for the certificate using IE, then your certificate was definitely in the Windows cert-store, and the two methods I wrote a little while ago would have shown them to you. Now that you have the P12 file, you can import it back again into ProtoectTools. You can also export just the certificate from your IE/Windows cert-store and import it into Thunderbird. Once Thunderbird has your certificate, *and* it sees the TCP module, it will see the certificate as one for which you have the Private Key, thus allowing you to sign and/or receive encrypted e-mails. Good luck. Arshad Noor StrongAuth, Inc. Dave Pinn wrote: But if you did delete it from ProtectTools, where did you find a certificate to import it into Thunderbird? I obtained the certificate from Verisign, using IE, from which I exported a .p12 file. I cunningly saved the .p12 file for just an emergency. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Enterprise Key Management Infrastructure (EKMI) software
Friends, I am aware that there are ethics about posting self-serving commercials in forums such as these. However, I hope my transgression will be over- looked, given that the software I am about to mention, is *free and open-source* (under the LGPL). StrongAuth, Inc., the company I am affiliated with, has just announced the availability of StrongKey(tm), a software product that can be used to centrally manage symmetric keys for an enterprise. Details about the software - as well as downloads - are available at http://www.strongkey.org. The software is designed to address the problem of managing symmetric encryption keys across different operating systems, databases, applications and devices, while providing for centralized policy- definition, strong access controls and very strong protections of the data (given that these comprise encryptions keys). It is a building- block of, what we call, an Enterprise Key Management Infrastructure (EKMI). The reason for my posting this message in this forum is that StrongKey specifically uses the NSS libraries through the SunPKCS11 Bridge in the JCE, and we believe that information may be of interest to some. The software has many other features and I invite you take a look at the website and take it for a spin, if it interests you. I thank you for your indulgence, and apologize in advance to anyone who may be offended by this posting - but I took the chance in the hope that the inforamtion may be useful to some people. Regards Arshad Noor StrongAuth, Inc. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Enterprise Key Management Infrastructure (EKMI) software
Thank you, Wan-Teh. Yes, we chose not to use JSS directly for a couple of reasons: 1) The JSS interface does not map closely to the JCE in J2SE5 and required us to write JSS-specific code. This was something we wanted to avoid, to keep our focus above the abstraction layer provided by JCE. 2) We wanted to take advantage of the excellent work done by the people at Mozilla and Sun on the PKCS11 interface and the SunPKCS11 bridge, respectively, and minimize our reinventing the wheel. I believe we have achieved both these objectives. StrongKey uses no provider-specific code directly and with just a change in the properties file of the application, it can use either the SunJCE, NSS, BouncyCastle, one specific vendor's smartcard or one-specifc vendor's HSM for crypto capabilities. (We're integrating most major HSMs into the software). With JDK6, we expect to go one step further by using the new SunCAPI bridge and using Windows-specific drivers of CSP's for which no PKCS11/JCE interface exists. Arshad Noor StrongAuth, Inc. P.S. If you believe that JSS is evolving to map to the JCE interfaces completely, and if there are specific advantages to going to JSS directly instead of the SunPKCS11 bridge, do let us know. We would be interested in hearing them. Thanks. Wan-Teh Chang wrote: Arshad, Congratulations on the product launch. You said that your product, StrongKey, specifically uses the NSS libraries through the SunPKCS11 Bridge in the JCE. I'd like to know why you don't use the default JCE provider, and why you don't use JSS or the Mozilla-JSS provider as the interface to NSS. You are only using the softoken PKCS #11 library (libsoftokn3.so) of NSS, right? 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: Verify signText() on server
While it is possible to verify CMS messages using the Java Security APIs directly, the Mozilla JSS and the BouncyCastle providers provide CMS-specific classes that encapsulate a lot of the lower-level APIs, making it easier to deal with CMS objects. http://www.mozilla.org/projects/security/pki/jss/javadoc/org/mozilla/jss/pkix/cms/package-summary.html http://www.bouncycastle.org/docs/docs1.5/index.html Arshad Noor StrongAuth, Inc. Nelson B wrote: Ian Coates wrote: I used crypto.signtext() method on FireFox 1.5 to sign a Text, now I want to verify that signature on a Java server. I looked the documentation but I don't understand how to verify the signature without the signer certificate. I suppose the certificate comes in the signature, but I don't know how to access it. The signature conforms to CMS (Cryptographic Message Syntax, RFC 3369), which is a superset of PKCS#7 v1.5. The signature produced by signtext is an external signature (a term defined in those standards, also known as a detached signature). I'm sure there is some standard java class/method for checking these CMS signatures, but off hand I don't know what it is named. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Sign/Verify text in FireFox
Anders Rundgren wrote: An inherent problem with this suggestion is that it is not backed by a specification that can be translated into code. The point is that the XMLSEC code already exists and conforms to W3C standards (the Java version conforms to two different JSRs). Whats missing is the integration of such a library into Mozilla/Firefox, and the JavaScript functions to expose the API. Once defined and shaken out, the JS functions can be proposed to ECMA for inclusion into the standard. I also believe that the market-perception is questionable. If there actually is a strong demand for this functionality within the enterprise, how come that none of the standards bodies have something along those lines on their menu? I don't believe that an advancement in technical capability has to be preceded by a standard from a standards body. (If memory serves me right, ironically, we are discussing this issue in a forum whose core technology - SSL - established a new bar for web security before the standard was created - TLS). Standards bodies are useful for creating structure in established markets; they don't necessarily lead markets. Any thoughts from the people at Mozilla/Firefox? Arshad Noor StrongAuth, Inc. snip So, let me throw out a suggestion to the committers of Mozilla/Firefox: given that Apache has a C++ library that supports the W3C XMLSignature/ XMLEncryption standard (http://xml.apache.org/security/), what are the chances of having this library integrated into Mozilla/Firefox with some new JavaScript functions expose this API to developers? This will solve many problems for enterprise applications: - message level security, rather than transport-level; - integrated signing/encryption functionality in the browser (and perhaps the Apache HTTP server?); - eliminating a major barrier for corporate desktop support groups to support this functionality; While I know that many PKCS7 afficionados will not see much benefit to duplicating capabilities inherent in PKCS7, given the way corporate applications are being developed today (they rely on XML very heavily) and trends in future application development (BPEL, XML databases) there is a natural predilection for developers to use tools that support XML natively. I think Mozilla/Firefox will set new standards in applications and security by supporting such a capability natively. Comments? Arshad Noor StrongAuth, Inc. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Client Authentication Problem (and solution!)
While the traditional definition of a digital certificate is taken to be the binding of a name to a public key, why would you issue certs with duplicate serial numbers? Was this an oversight or a design decision? If the latter, it would help the forum to understand the business/technical requirements leading to such a decision. Thanks. Arshad Noor StrongAuth, Inc. Michael Pratt wrote: I'm cross posting this to crypto and ldap in the hopes nobody else will waste months of effort on a simple issue :) Those of you that frequent these boards have probably seen several posts from me dating back to January regarding problems with client authentication and Sun directory server. We've been trying to set up our apps using Mozilla Java and C APIs and have them authenticate with using SASL / External. The problem was when multiple users would run at the same time, one of them would fail to authenticate on the directory server and return error -12271: SSL peer cannot verify your certificate. The problem was with the directory server (5.2 patch 4, Solaris 8) and how it handles client certificates (or possibly in how we created the certificates). Apparently if the same DS machine receives two certifcates at the same time with the same serial number value, only one will be succesfully processed and the other will return the error above. This was pointed out to us by a Sun engineer, and it wasn't clear if this is a bug in the version or if this is how DS was intended to work. Regardless, once we changed each user's cert to have a unique serial number the problem dissapeared. Mike ___ 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: Client Authentication Problem (and solution!)
PKIX standards (RFC 3280) state the following about Serial Numbers: 4.1.2.2 Serial number The serial number MUST be a positive integer assigned by the CA to each certificate. It MUST be unique for each certificate issued by a given CA (i.e., the issuer name and serial number identify a unique certificate). CAs MUST force the serialNumber to be a non-negative integer. Given the uniqueness requirements above, serial numbers can be expected to contain long integers. Certificate users MUST be able to handle serialNumber values up to 20 octets. Conformant CAs MUST NOT use serialNumber values longer than 20 octets. Note: Non-conforming CAs may issue certificates with serial numbers that are negative, or zero. Certificate users SHOULD be prepared to gracefully handle such certificates. If the product you were using to generate certificates was a commercial product, I'm surprised that it generated certificates with duplicate serial numbers (this is like having multiple records in a relational DB table with the same primary key). Thanks for the clarification. Arshad Noor StrongAuth, Inc. Michael Pratt wrote: It was an oversight. Our SAs created a script to automatically generate certs for all users, and when it came to assigning a value to serial number they couldn't find any documentation or guidance on how to properly assign this value. Plus the fact that our combined experience with LDAP and SSL was close to zero when we started. So yeah, it was definitely an oversight on our part, but it would still be nice if this was documented. I couldn't find in any of the docs ( http://docs.sun.com/app/docs/coll/S1_DirectoryServer_52) where it stated DS would behave that way if the serial number wasn't unique. Of course, this may be such common practice (or even the standard) that documenting it seems silly, I don't know. Mike On 5/2/06, Arshad Noor [EMAIL PROTECTED] wrote: While the traditional definition of a digital certificate is taken to be the binding of a name to a public key, why would you issue certs with duplicate serial numbers? Was this an oversight or a design decision? If the latter, it would help the forum to understand the business/technical requirements leading to such a decision. Thanks. Arshad Noor StrongAuth, Inc. Michael Pratt wrote: I'm cross posting this to crypto and ldap in the hopes nobody else will waste months of effort on a simple issue :) Those of you that frequent these boards have probably seen several posts from me dating back to January regarding problems with client authentication and Sun directory server. We've been trying to set up our apps using Mozilla Java and C APIs and have them authenticate with using SASL / External. The problem was when multiple users would run at the same time, one of them would fail to authenticate on the directory server and return error -12271: SSL peer cannot verify your certificate. The problem was with the directory server (5.2 patch 4, Solaris 8) and how it handles client certificates (or possibly in how we created the certificates). Apparently if the same DS machine receives two certifcates at the same time with the same serial number value, only one will be succesfully processed and the other will return the error above. This was pointed out to us by a Sun engineer, and it wasn't clear if this is a bug in the version or if this is how DS was intended to work. Regardless, once we changed each user's cert to have a unique serial number the problem dissapeared. Mike ___ 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 ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Fwd: cacert.org
Has the Mozilla Foundation considered using a self-audit in the form of a Jurat? There are some advantages to doing so for the CA operator, as well as for the MF. To those unfamiliar with the term, a Jurat is any document, where the signer swears to the veracity of its contents, signs the document in front of a licensed Notary Public (NP) and has the NP sign stamp the document. (While this is true of most states in the US, I can only speak for California). Once the Jurat is signed by the NP, it is a legal document. Any signer who knowingly signs the document while swearing to false information in it, has committed a felony per California law. The Relying Party (MF in this case) now has a hold on the signer that goes beyond even a WebTrust audit - the threat of sending the signer to jail if the Jurat has false information in it. Advantages to the CA opertor? 1) They don't need to divulge details of the operation to anyone outside the company; 2) They know their PKI better than anyone else, and can perform the audit rapidly; 3) There is no audit cost other than the time spent writing the self audit and the NP's fee (less than US $25 if you go to the NP's office); Advantages to MF? 1) A legal document that carries the weight of civil law behind it (and the threat of jail to offenders); 2) No need to authorize auditors if CA operators are willing to perform self-audits and submit the documentation in the form of a Jurat; 3) With a slightly modified architecture to Mozilla, it could even lead to some interesting revenue opportunities for MF, allowing it to fund future development and some vexing security problems on the Internet. Arshad Noor StrongAuth, Inc. Frank Hecker wrote: I didn't envision this as being something that a person would just do as an independent activity, with the Foundation in essence certifying people to do this sort of work. It's more something that would be done in the context of a particular CA and its application for inclusion, and then only if a) the CA weren't doing a formal WebTrust audit (or similar formal audit done by an authorized auditor), and b) the CA were willing to grant the person in question the necessary access to its internal operations. Thus far the only CA that's fit criterion (a) has been CAcert, and they're still figuring out who they want to help them. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Help with invalid certificate problem
This is definitely an Entrust product question. Usually, you will not see the certificate extensions when you're approving a CSR (unless the PKI builders chose to make it visible to you). Configuring the CA to tweak the key-usage bits requires going into some configuration mode (perhaps through an administrative interface/console) and then setting the appropriate bits for key-usages for specific certificate types. Arshad Noor StrongAuth, Inc. Nelson B wrote: Vivek Kumar wrote: Could anyone please tell me how to change the extension of the server cert to include Key encipherment for KeyUsage? When creating the server cert I did not see any options to modify the attribute.. We have setup the CA using Entrust and uisng IIS 6.0 as the web-server,.. Please help, very new to CA/ SSL security,.. Your question is how to set up an SSL server with an Entrust CA product or service. That's really a question about the product or service, more than a question about certificates. I don't know if anyone on this list has any Entrust CA experience, or not. But this seems like a question that an Entrust customer would ask of Entrust's tech support. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
