Re: NSS support for RFC7512 PKCS#11 URIs
On 04/05/15 21:53, David Woodhouse wrote: 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? You mean the 2015 instance is a re-signing of the same certificate? Isn't the signature included in the distinct bytes, meaning it's still a new certificate which needs a new serial number, even if it's based on the same request and the request is signed by the same key. (If it's a re-issue with the same CA signature, same validity dates, and same everything else, then including CKA_VALUE won't make it distinct either, and there's no point in having two copies with different labels. It's the same object, imported twice.) However, I would expect both CKA_SUBJECT and CKA_ID to be the same for a re-signed certificate. (But that the CKA_SUBJECT and CKA_ID pair will uniquely identify the private key that both certificates apply to. Years of working with HSMs have left me with the attitude that the private key is the important bit, and any certificate is someone else's problem, so issuer and serial number are irrelevant :-) But I do realize that's not the typical application view.) -- http://www.brocade.com/products/all/application-delivery-controllers/index.page -- 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 Sun, 3 May 2015, David Woodhouse wrote: Hello David, 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. 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(). overloading the existing function so that old applications just works seems like a way to go. It would be nice to have a new function for new code with a name that would better describe the current situation. I assume both searching by a nickname and URI will be needed in the future. 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. Referring to the mini-howto at https://bugzilla.redhat.com/1217727#c1 (a bug against the pesign utility) which shows how to deal with the NSS issues around PKCS#11 usability, this would basically *solve* the lack of URI support without having to touch pesign at all. Then we only need to deal with the fact that NSS doesn't load the system-configured PKCS#11 tokens by default, which is an orthogonal issue probably outside the scope of your interest, Jan. Don't know much about NSS. Wrote some code years ago, was curious how it worked, but probably forgot even that little bit I learned about it :-) Cheers, Jan. -- 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: NSS support for RFC7512 PKCS#11 URIs
On Tue, May 5, 2015 8:55 am, David Woodhouse wrote: I'm talking about the serial numbers of the certs issued *by* the two My CAs. Good to have that clarification :) Different CAs (in as much as different public keys), but with the same DER-encoded subject name (not necessarily the same DER-encoded issuer name, but that's irrelevant), and the same starting serial number (1). The question is how to distinguish certificate (or public key) objects between the two, so that we could construct an unambiguous identifier. I'm ignoring AKI/SKI - they're not unique disambiguators, even though some people use them as such. Treat them as optional, untrusted. That it works for you is great, but same problem here - not guaranteed. We'll call them CA 1 and CA 2, even though they share the same subject, because they share different public keys. Let's look at the PKCS#11 attributes for the CKO_CERTIFICATE object type with CKC_X_509 CKA_SUBJECT - required. Will be identical for the two objects CKA_VALUE - required if CKA_URL is absent; unique CKA_URL - required if CKA_VALUE is absent; unique if the certs are different CKA_SERIAL_NUMBER - optional (CKA_ID is optional, as are CKA_HASH_OF_[SUBJECT/ISSUER]_PUBLIC_KEY, the latter two wouldn't be sufficient under same-CA rekey though) So to uniquely identify a certificate, you look up for *all* CKA_SUBJECT matches, then get the CKA_VALUE/CKA_URL to do the comparisons. Does that work for PKCS#11 URLs? Absolutely not. That's because there IS NOT a unique disambiguator that can be provided apriori if you don't know the certificate. As Bob notes, it's entirely valid for two objects to have the same CKA_ID and distinct CKA_SUBJECTs. In fact, that's *explicitly* called out in the description of CKC_X_509 Since the keys are distinguished by subject name as well as identifier, it is possible that keys for different subjects may have the same CKA_ID value without introducing any ambiguity. Further, I'm having a hard time finding a normative reference in any of the PKCS#11 RFCs that require the CKA_ID values be unique for a given CKA_SUBJECT (only non-normative descriptions that they should be, or are intended to be). Is this a problem in practice? Unknown. But it does indicate that the PKCS#11 URIs are not in and of themselves sufficient to uniquely and unambiguously identify an object, per spec. -- 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 Tue, 2015-05-05 at 09:47 -0700, Ryan Sleevi wrote: On Tue, May 5, 2015 8:55 am, David Woodhouse wrote: I'm talking about the serial numbers of the certs issued *by* the two My CAs. Good to have that clarification :) Different CAs (in as much as different public keys), but with the same DER-encoded subject name (not necessarily the same DER-encoded issuer name, but that's irrelevant), and the same starting serial number (1). The question is how to distinguish certificate (or public key) objects between the two, so that we could construct an unambiguous identifier. To be honest, I wasn't really asking that question — I was mostly just objecting to the suggestion that 'CKA_ISSUER + CKA_SERIAL_NUMBER' was an *answer* to it. So to uniquely identify a certificate, you look up for *all* CKA_SUBJECT matches, then get the CKA_VALUE/CKA_URL to do the comparisons. Assuming you *have* the issuer in your local database, of course. Which you might not. Does that work for PKCS#11 URLs? Absolutely not. That's because there IS NOT a unique disambiguator that can be provided apriori if you don't know the certificate. As Bob notes, it's entirely valid for two objects to have the same CKA_ID and distinct CKA_SUBJECTs. In fact, that's *explicitly* called out in the description of CKC_X_509 Since the keys are distinguished by subject name as well as identifier, it is possible that keys for different subjects may have the same CKA_ID value without introducing any ambiguity. Further, I'm having a hard time finding a normative reference in any of the PKCS#11 RFCs that require the CKA_ID values be unique for a given CKA_SUBJECT (only non-normative descriptions that they should be, or are intended to be). CKA_ID is supposed to match the X509v3 Subject Key Identifier. From §4.6.3 of v2.40 of the PKCS#11 specification: Note that with the version 3 extensions to X.509 certificates, the key identifier may be carried in the certificate. It is intended that the CKA_ID value be identical to the key identifier in such a certificate extension, although this will not be enforced by Cryptoki. I don't see any reason to believe the SKI should be unique for any given CKA_SUBJECT. Why *not* re-use the private key and just issue a new CSR and get a new certificate to go along with it? Is this a problem in practice? Unknown. But it does indicate that the PKCS#11 URIs are not in and of themselves sufficient to uniquely and unambiguously identify an object, per spec. No, for now I'd say it's definitely not a problem in practice. There *might* be some motivation to extend the URI scheme to allow the creation of guaranteed-unique URIs (but oops, this list's broken¹ Reply-To: setting just dropped the person most likely to undertake that). But in the meantime, in *practical* usage, it's perfectly fine. Sure, it's *possible* to construct a scenario where you can't create an unambiguous string that specifies the object you want. But that was already true for PK11_GetCertByNickname() anyway. And in the common case where the user just has a cert in a hardware crypto token, or wants to reference a cert in their GNOME keyring or NSS database, the CKA_ID is almost *always* going to be entirely sufficient. -- dwmw2 ¹ http://david.woodhou.se/reply-to-list.html 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 Tue, 2015-05-05 at 12:29 +0100, Alan Braggins wrote: On 04/05/15 21:53, David Woodhouse wrote: 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? You mean the 2015 instance is a re-signing of the same certificate? Isn't the signature included in the distinct bytes, meaning it's still a new certificate which needs a new serial number, even if it's based on the same request and the request is signed by the same key. Nonono, forget the CKA_SERIAL_NUMBER on the 'My CA' objects. Those are irrelevant — and yes, if those two were actually issued by the same ancestor CA then you're quite right that they'll need to have different serial numbers. That wasn't what I was talking about though. I'm talking about the serial numbers of the certs issued *by* the two My CAs. Let's assume each CA starts at '1' — that in each case the CKA_SERIAL_NUMBER of the first cert issued *by* 'My CA' is 1. Now, since each of those CAs issues a cert with CKA_SERIAL_NUMBER=1, and in both cases the CKA_ISSUER of that issued cert is 'My CA', that means the combination of CKA_ISSUER and CKA_SERIAL_NUMBER does *not* uniquely identify a certificate, surely? (Unless the two CAs in question are expected to use *disjoint* number spaces for the CKA_SERIAL_NUMBER of certificates that they themselves issue?) (But that the CKA_SUBJECT and CKA_ID pair will uniquely identify the private key that both certificates apply to. Years of working with HSMs have left me with the attitude that the private key is the important bit, and any certificate is someone else's problem, so issuer and serial number are irrelevant :-) But I do realize that's not the typical application view.) Right. And this is what we have the X509v3 Subject Key Identifier and Authority Key Identifier for :) That's exactly my point above. CKA_ISSUER doesn't uniquely specify the issuer. The X509v3 Authority Key Identifier is a whole lot better. This is precisely the background which made me object to the statement about CKA_ISSUER+CKA_SERIAL_NUMBER being unique. I'm *sick* of people assuming that CKA_ISSUER is meaningful :) My employer has a habit of creating new CAs with the same subject as old ones. So I've dealt with a number of bugs where validation fails because some piece of code assumes that it can find the issuer of a given certificate by looking for the first CA in the database whose CKA_SUBJECT matches the CKA_ISSUER of the certificate in question. Depending on the order of the certs in the ca-trust file, OpenSSL used to select the *wrong* one of the many CAs with matching subject, then check the signature and declare it invalid (which I fixed in RT#1942). It also used to send the wrong one on the wire in an SSL exchange, and I have code in the OpenConnect VPN client to explicitly add the *right* ones. When doing validation from a PKCS#11 trust database like p11-kit -trust, GnuTLS also had a similar issue which I fixed more recently. I found another such bug just *yesterday* in the pesign tool when I was looking at the issues with NSS's lack of integration with the system PKCS#11 configuration. So you'll forgive me if I object to Bob's assertion that 'the only unique way to identify a cert is CKA_ISSUER and CKA_SERIAL_NUMBER even though it's a digression from the real topic at hand. It pushes my buttons :) -- 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 05/05/15 16:55, David Woodhouse wrote: On Mon, May 4, 2015 1:25 pm, David Woodhouse wrote: 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) 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? [My confusion over CA and ancestor CA serials elided.] I'm talking about the serial numbers of the certs issued *by* the two My CAs. Let's assume each CA starts at '1' — that in each case the CKA_SERIAL_NUMBER of the first cert issued *by* 'My CA' is 1. Now, since each of those CAs issues a cert with CKA_SERIAL_NUMBER=1, and in both cases the CKA_ISSUER of that issued cert is 'My CA', that means the combination of CKA_ISSUER and CKA_SERIAL_NUMBER does *not* uniquely identify a certificate, surely? (Unless the two CAs in question are expected to use *disjoint* number spaces for the CKA_SERIAL_NUMBER of certificates that they themselves issue?) My reaction is that if there are two different CAs, there ought to be two different issuers, and if there is one CA using two different certificates, it ought to use disjoint spaces for the serial numbers. (And if there were two issuers, presumably the subjects in the initial example would have been different.) But I would be totally unsurprised to find that reality doesn't work like that... My employer has a habit of creating new CAs with the same subject as old ones. So I've dealt with a number of bugs where validation fails because some piece of code assumes that it can find the issuer of a given certificate by looking for the first CA in the database whose CKA_SUBJECT matches the CKA_ISSUER of the certificate in question. Oh look, reality doesn't always work like I think it should. Guess how unsurprised I am :-) -- http://www.brocade.com/products/all/application-delivery-controllers/index.page -- 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 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: 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: 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
Re: NSS support for RFC7512 PKCS#11 URIs
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? -- http://www.brocade.com/products/all/application-delivery-controllers/index.page -- 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 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. 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. -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation 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
