Re: NSS support for RFC7512 PKCS#11 URIs
On Fri, 1 May 2015, David Woodhouse wrote: On Fri, 2015-05-01 at 11:35 +0100, Alan Braggins wrote: On 30/04/15 17:56, David Woodhouse wrote: Has anyone looked at implementing RFC7512 support, allowing an object to be specified by a PKCS#11 URI? I don't suppose you know why RFC 7512 uses CKA_ID but not CKA_SUBJECT, when PKCS#11 says The*CKA_ID*attribute is intended as a means of distinguishing multiple public-key/private-key pairs held by the same subject and it is possible that keys for different subjects may have the same*CKA_ID*value without introducing any ambiguity? That question would be better directed to the authors of the RFC. I've added Jan to Cc. Yes, in isolation both CKA_SUBJECT and CKA_ID are ambiguous since multiple certificates can exist with the same subject, and multiple certificate can exist with the same private key (hence the same CKA_ID). I'm not quite sure of the motivation for omitting CKA_SUBJECT from the URI specification. Perhaps because it's redundant to a *certain* extent with CKA_LABEL — in the relatively rare case that CKA_ID isn't actually unique, hopefully CKA_LABEL is sufficient to disambiguate. Hi David, that's a very good question. It was a deliberate decision back in the days of filing the first I-D in March 2010. I didn't want to delve into a certificate. I know there is a key ID in X.509 v3 which is expected to be in CK_ID if present in the cert, but I didn't want to go beyong an id. Any other component path attributes are directly PKCS #11 related. I thought about adding CK_SUBJECT there while writing 00 based on what we were doing with Darren (cc'ed) in Solaris those days. But then, CKA_START_DATE and CKA_END_DATE could be useful as well, to pick valid certificates, for example, and also CKA_SERIAL_NUMBER and CKA_ISSUER, and even CKA_HASH_OF_SUBJECT_PUBLIC_KEY. Possibly something else. The scheme definition would grow significantly and in general we were concerned that the more complex the scheme would become to be, the more difficult would be to use it. Using the object attribute seemed like the best way to identify a key, with an ID if needed, and possibly library attributes. Also note that comparing URIs would become more difficult as the subject attribute would need to be normalized (how exactly?). So, we started with a basic list of attributes we thought were enough to identify an object or token and expected people to tell us what else was useful for them. That's how we added library-* and slot-* attributes (after a long discussion a few years ago, we deliberately decided not to use a slot since its ID is not stable across PKCS #11 module initialization, but then again, someone asked for it and we thought that it was just better to add it), and we also added query component attributes, including the PIN in the URI, which we also initially opposed to have but were convinced to add by early adopters. And in those more than 5 years since the draft 00, no one asked for the CKA_SUBJECT attribute. Having said that, I assumed that other URI attributes might be needed in the future, possibly with new versions of the PKCS #11 standard; I didn't see anything new in upcoming 2.40 useful to be added to the URI though. So, if there is a strong feeling about a new attribute, there is always a way of patching the parser and filing an I-D to extend the scheme, and let the community decide. In this situation though, I still believe that it's better not to put the certificate subject in there, due to the reasons mentioned above. Regards, Jan. And perhaps because there's a long history of people making the mistake of assuming that the X.509 subject is unique (I've fixed bugs in certificate chain validation in both OpenSSL and GnuTLS because of that), as well as jumping through hoops to present the full trust chain on the wire in the OpenConnect VPN client, because the Cisco ASA had the same issue). So by omitting CKA_SUBJECT we make it harder for people to make the same mistake. Those are just guesses though. -- Jan Pechanec jan.pecha...@oracle.com -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Problems with FF and internal certificates
Posting to mozilla-dev-tech-crypto instead. firefox-dev to bcc. On Apr 27, 2015, at 2:03 PM, Michael Peterson michaelpeterson...@gmail.com wrote: Firefox does not like our internal certificates. I'm trying to figure out why... tl;dr - Our internal IIS servers, signed with our internal CA, present a Secure Connection Failed page, with technical details that say Connection Not Encrypted. The certificate is installed in Firefox's internal certificate store. Here are our certificates https://www.highlands.edu/site/is-certification-authority Unfortunately, we can't expose said internal servers for you to see the exact error page. Here are screenshots though. https://imgur.com/a/dmMdG The weird part of all this is that our internal certificates work fine on Apache (suggesting that the problem is IIS). However, our IIS servers work fine with any other certificates, such as third party (GeoTrust) or self signed (suggesting that the problem is the cert). If I add an exception, such as someinternal.highlands.edu under the about:config page to the security.tls.insecure_fallback_hosts then the site works. If I look at IIS error logs I see the following two errors over and over when I hit it with FireFox (but not Chrome, IE, Safari, etc) An TLS 1.2 connection request was received from a remote client application, but none of the cipher suites supported by the client application are supported by the server. The SSL connection request has failed. A fatal alert was generated and sent to the remote endpoint. This may result in termination of the connection. The TLS protocol defined fatal error code is 40. The Windows SChannel error state is 1205. Now, in the album I posted above (https://imgur.com/a/dmMdG), the last two screenshots show a packet capture from Wireshark. It appears that Firefox does not support SHA512, which is kind of supported by this article (http://blogs.technet.com/b/silvana/archive/2014/03/14/schannel-errors-on-scom-agent.aspx). I'm not exactly sure this is true, and it seems like a silly thing for Firefox to drop support though (this previously worked), especially if every other browser in the world supports this. So there's everything we've found, and some of my assumptions. Does anyone know what is actually going on with Firefox. Is this a bug? Are we doing something wrong? How do we fix this? ___ firefox-dev mailing list firefox-...@mozilla.org https://mail.mozilla.org/listinfo/firefox-dev -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Problems with FF and internal certificates
On Friday 01 May 2015 12:11:00 Tanvi Vyas wrote: On Apr 27, 2015, at 2:03 PM, Michael Peterson michaelpeterson...@gmail.com wrote: Firefox does not like our internal certificates. I'm trying to figure out why... tl;dr - Our internal IIS servers, signed with our internal CA, present a Secure Connection Failed page, with technical details that say Connection Not Encrypted. The certificate is installed in Firefox's internal certificate store. Here are our certificates https://www.highlands.edu/site/is-certification-authority The root cert is self signed with SHA-512, if it uses SHA-512 also for EE certificates, you're likely hitting MZBZ#1155922 interoperability issue caused by change introduced by MS14-066 in Windows. You don't see this problem with Nginx or Apache because they send the certificate even if the extensions advertised by client don't match the certificate the server has (they let the client decide if it will trust the cert or not), OTOH, IIS decides for the client that it won't be able to handle certificate, so it doesn't send any and aborts connection without telling client why (thus the incomprehensible error message). -- Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic signature.asc Description: This is a digitally signed message part. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: NSS support for RFC7512 PKCS#11 URIs
On 05/03/2015 02:17 AM, David Woodhouse wrote: On Sat, 2015-05-02 at 18:33 -0700, Jan Pechanec wrote: On Fri, 1 May 2015, David Woodhouse wrote: On Fri, 2015-05-01 at 11:35 +0100, Alan Braggins wrote: On 30/04/15 17:56, David Woodhouse wrote: Has anyone looked at implementing RFC7512 support, allowing an object to be specified by a PKCS#11 URI? I don't suppose you know why RFC 7512 uses CKA_ID but not CKA_SUBJECT, when PKCS#11 says The*CKA_ID*attribute is intended as a means of distinguishing multiple public-key/private-key pairs held by the same subject and it is possible that keys for different subjects may have the same*CKA_ID*value without introducing any ambiguity? That question would be better directed to the authors of the RFC. I've added Jan to Cc. Yes, in isolation both CKA_SUBJECT and CKA_ID are ambiguous since multiple certificates can exist with the same subject, and multiple certificate can exist with the same private key (hence the same CKA_ID). I'm not quite sure of the motivation for omitting CKA_SUBJECT from the URI specification. Perhaps because it's redundant to a *certain* extent with CKA_LABEL — in the relatively rare case that CKA_ID isn't actually unique, hopefully CKA_LABEL is sufficient to disambiguate. Hi David, that's a very good question. It was a deliberate decision back in the days of filing the first I-D in March 2010. I didn't want to delve into a certificate. I know there is a key ID in X.509 v3 which is expected to be in CK_ID if present in the cert, but I didn't want to go beyong an id. Any other component path attributes are directly PKCS #11 related. I thought about adding CK_SUBJECT there while writing 00 based on what we were doing with Darren (cc'ed) in Solaris those days. But then, CKA_START_DATE and CKA_END_DATE could be useful as well, to pick valid certificates, for example, and also CKA_SERIAL_NUMBER and CKA_ISSUER, and even CKA_HASH_OF_SUBJECT_PUBLIC_KEY. Possibly something else. The scheme definition would grow significantly and in general we were concerned that the more complex the scheme would become to be, the more difficult would be to use it. Using the object attribute seemed like the best way to identify a key, with an ID if needed, and possibly library attributes. Also note that comparing URIs would become more difficult as the subject attribute would need to be normalized (how exactly?). So, we started with a basic list of attributes we thought were enough to identify an object or token and expected people to tell us what else was useful for them. That's how we added library-* and slot-* attributes (after a long discussion a few years ago, we deliberately decided not to use a slot since its ID is not stable across PKCS #11 module initialization, but then again, someone asked for it and we thought that it was just better to add it), and we also added query component attributes, including the PIN in the URI, which we also initially opposed to have but were convinced to add by early adopters. And in those more than 5 years since the draft 00, no one asked for the CKA_SUBJECT attribute. Having said that, I assumed that other URI attributes might be needed in the future, possibly with new versions of the PKCS #11 standard; I didn't see anything new in upcoming 2.40 useful to be added to the URI though. So, if there is a strong feeling about a new attribute, there is always a way of patching the parser and filing an I-D to extend the scheme, and let the community decide. In this situation though, I still believe that it's better not to put the certificate subject in there, due to the reasons mentioned above. Regards, Jan. Hi Jan, Thanks for the prompt response (as ever), which I've cited in its entirety since I'm not sure it made it to the list. For the case of NSS, I suspect the lack of CKA_SUBJECT shouldn't be a real problem. I've just started looking at NSS with a view to fixing it to take PKCS#11 URIs, and it looks like the common way of specifying a certificate is by its nickname, which is CKA_LABEL, using the PK11_FindCertFromNickname() function. So in NSS, CKA_LABEL is simply a short cut to CKA_SUBJECT. That is NSS looks up a cert from the nickname and picks all the certs that match that cert's subject. The idea (back 2 decades ago when this was implemented) was that nickname was the user facing name for the cert 'identity'. Multiple certs made up that identity (auth certs, non-repudiation certs, key exchange/encryption certs, expired versions of the above). As a result CKA_LABEL is not unique to a cert (anymore than a subject is). LABEL is not required as well (certain intermediate CA's may not have a label associated with them). Currently the only unique way to identify a cert is CKA_ISSUER and CKA_SERIAL_NUMBER unless you want to include the value. The PKCS #11 working group is active again at OAISIS. If we want a unique object identifier I think we just need to either extend
Re: Problems with FF and internal certificates
On Fri, May 1, 2015 at 9:11 AM, Tanvi Vyas tv...@mozilla.com wrote: On Apr 27, 2015, at 2:03 PM, Michael Peterson michaelpeterson...@gmail.com wrote: Now, in the album I posted above (https://imgur.com/a/dmMdG), the last two screenshots show a packet capture from Wireshark. It appears that Firefox does not support SHA512, which is kind of supported by this article ( http://blogs.technet.com/b/silvana/archive/2014/03/14/schannel-errors-on-scom-agent.aspx). I'm not exactly sure this is true, and it seems like a silly thing for Firefox to drop support though (this previously worked), especially if every other browser in the world supports this. So there's everything we've found, and some of my assumptions. Does anyone know what is actually going on with Firefox. Is this a bug? Are we doing something wrong? How do we fix this? SHA-384 is SHA-512 truncated to 384 bits. I guess your ECDSA certificate is using the P-384 curve. If so, your SHA-512 digest is truncated to ~384 bits in order to work with the P-384 curve. (If you are using the P-256 curve, then it is truncated to ~256 bits.) Consequently, there's no advantage to using SHA-512 instead of SHA-384. Cheers, Brian -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Problems with FF and internal certificates
On 05/04/2015 10:09 AM, Brian Smith wrote: On Fri, May 1, 2015 at 9:11 AM, Tanvi Vyas tv...@mozilla.com wrote: On Apr 27, 2015, at 2:03 PM, Michael Peterson michaelpeterson...@gmail.com wrote: Now, in the album I posted above (https://imgur.com/a/dmMdG), the last two screenshots show a packet capture from Wireshark. It appears that Firefox does not support SHA512, which is kind of supported by this article ( http://blogs.technet.com/b/silvana/archive/2014/03/14/schannel-errors-on-scom-agent.aspx). I'm not exactly sure this is true, and it seems like a silly thing for Firefox to drop support though (this previously worked), especially if every other browser in the world supports this. I think this was an NSS bug where we didn't include the SHA512 hash in the advertized list of supported hashes. It wasn't dropped support. In previous versions of TLS you didn't advertise which hashes you supported, so things signed with SHA512 just worked. Now you need to advertise it, and NSS was just missing the hash (it's fixed in the latest version of NSS). So there's everything we've found, and some of my assumptions. Does anyone know what is actually going on with Firefox. Is this a bug? Are we doing something wrong? How do we fix this? SHA-384 is SHA-512 truncated to 384 bits. Not exactly. SHA-384 is mechanically the same algorithm as SHA-512, with a truncation, but it's not the same bits. SHA-384 has a unique set of initializers so if you do a SHA-512 and truncate it to 384 bits and the do a SHA-384 on the same data, you have the same security and performance characteristics, but not the same bits. (I think Brian knows this, and that his point is from a security point of view, they are exactly identical, both in performance and in the actual security of the hash. For the uninitiated, though, the actual bits on the wire are different). I guess your ECDSA certificate is using the P-384 curve. If so, your SHA-512 digest is truncated to ~384 bits in order to work with the P-384 curve. (If you are using the P-256 curve, then it is truncated to ~256 bits.) Consequently, there's no advantage to using SHA-512 instead of SHA-384. Other than compatibility with someone that chose to sign using SHA-512. bob Cheers, Brian smime.p7s Description: S/MIME Cryptographic Signature -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: NSS support for RFC7512 PKCS#11 URIs
On Mon, 2015-05-04 at 09:21 -0700, Robert Relyea wrote: So in NSS, CKA_LABEL is simply a short cut to CKA_SUBJECT. That is NSS looks up a cert from the nickname and picks all the certs that match that cert's subject. Hm... so if I have two certificates; one with: CKA_SUBJECT: My CA CKA_LABEL: My CA (2010 instance) and the other: CKA_SUBJECT: My CA CKA_LABEL: My CA (2015 instance) ... you're saying that if I use PK11_FindCertFromNickname() with the nickname My CA (2015 instance) I'm actually going to get *both* of those certs returned rather than only the one which actually matches? That seems a bit odd, but as long as we can keep that behaviour only to the 'old-style' lookup based on token:nickname, and don't have to tolerate it in lookups based on a PKCS#11 URI, it's fine. Currently the only unique way to identify a cert is CKA_ISSUER and CKA_SERIAL_NUMBER unless you want to include the value. Surely that's not unique? Using the above example, surely the first certificate issued by the 2010 instance of 'My CA', and the first certificate issued by the 2015 instance, are both going to have identical CKA_ISSUER and CKA_SERIAL_NUMBER, aren't they? I think we just need to either extend PK11_FindCertFromNickname() to spot when the string it's given starts with 'pkcs11:' and treat it as a URI instead, or add a new parallel function PK11_FindCertFromURI(). If we are OK for the URI to return multiple certs, then use of CKA_ID or CKA_LABEL/CKA_SUBJECT is fine. Yes, I think that's perfectly acceptable. The documentation at https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/SSL_functions/pkfnc.html#1035673 suggests that it doesn't return multiple certs, but returns the newest of the certs which match. I can live with that behaviour. I note that same documentation also contradicts (my interpretation of) what you said above about CKA_LABEL. It just says that the nickname is an alias for the certificate subject. I'm inclined to favour the former, since it means that applications which take nicknames on the command line would Just Work when given RFC7512 URIs, without needing to modify the applications at all. Assuming that the application doesn't have any tokens named 'pkcs11'. The current nickname spec in NSS is 'token:nickname'. I think that that is a fair assumption, but we just need to be clear That is what is happening. OK, I'll see if I can come up with a patch. Then all I really need to fix in NSS is the fact that it doesn't load the tokens specified in the system's p11-kit configuration. I realise I had only filed that in Red Hat bugzilla, so I've also filed it at https://bugzilla.mozilla.org/show_bug.cgi?id=1161219 now. -- dwmw2 smime.p7s Description: S/MIME cryptographic signature -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: NSS support for RFC7512 PKCS#11 URIs
On Mon, May 4, 2015 1:25 pm, David Woodhouse wrote: Surely that's not unique? Using the above example, surely the first certificate issued by the 2010 instance of 'My CA', and the first certificate issued by the 2015 instance, are both going to have identical CKA_ISSUER and CKA_SERIAL_NUMBER, aren't they? No, every subject and serial must be unique. If the 2010 and 2015 instance are distinct bytes, they need distinct serial numbers. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: NSS support for RFC7512 PKCS#11 URIs
On Mon, May 4, 2015 1:25 pm, David Woodhouse wrote: Surely that's not unique? Using the above example, surely the first certificate issued by the 2010 instance of 'My CA', and the first certificate issued by the 2015 instance, are both going to have identical CKA_ISSUER and CKA_SERIAL_NUMBER, aren't they? No, every subject and serial must be unique. If the 2010 and 2015 instance are distinct bytes, they need distinct serial numbers. I was speaking of the serial numbers of certificates issued *by* those two separate CAs. Or are you suggesting that those sets of serial numbers muat be disjoint? -- dwmw2 -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
