NSS support for RFC7512 PKCS#11 URIs

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

NSS support for RFC7512 PKCS#11 URIs

David Woodhouse-7
Has anyone looked at implementing RFC7512 support, allowing an object
to be specified by a PKCS#11 URI?

I can now do this with both GnuTLS and OpenSSL, and it would be good
to get NSS fixed too.

I'd also very much like NSS to be able to load the default PKCS#11
tokens listed in the system's p11-kit configuration too...

--
dwmw2

--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto

smime.p7s (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: NSS support for RFC7512 PKCS#11 URIs

Alan Braggins-3
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
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto
Reply | Threaded
Open this post in threaded view
|

Re: NSS support for RFC7512 PKCS#11 URIs

David Woodhouse-7
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 Woodhouse                            Open Source Technology Centre
[hidden email]                              Intel Corporation

--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto

smime.p7s (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: NSS support for RFC7512 PKCS#11 URIs

Jan Pechanec
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 <[hidden email]>
--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto
Reply | Threaded
Open this post in threaded view
|

Re: NSS support for RFC7512 PKCS#11 URIs

David Woodhouse-7
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.

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().

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.

--
dwmw2

--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto

smime.p7s (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: NSS support for RFC7512 PKCS#11 URIs

Robert Relyea
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 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.
>
> 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.

>
> 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.
>
>
>

--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto

smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: NSS support for RFC7512 PKCS#11 URIs

David Woodhouse-7
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

--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto

smime.p7s (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: NSS support for RFC7512 PKCS#11 URIs

Ryan Sleevi
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
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto
Reply | Threaded
Open this post in threaded view
|

Re: NSS support for RFC7512 PKCS#11 URIs

David Woodhouse-7

> 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
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto
Reply | Threaded
Open this post in threaded view
|

Re: NSS support for RFC7512 PKCS#11 URIs

Jan Pechanec
In reply to this post by David Woodhouse-7
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 <[hidden email]>
--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto
Reply | Threaded
Open this post in threaded view
|

Re: NSS support for RFC7512 PKCS#11 URIs

Alan Braggins-3
In reply to this post by David Woodhouse-7
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
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto
Reply | Threaded
Open this post in threaded view
|

Re: NSS support for RFC7512 PKCS#11 URIs

David Woodhouse-7
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 CA"s.

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

--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto

smime.p7s (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: NSS support for RFC7512 PKCS#11 URIs

Ryan Sleevi
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 CA"s.

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
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto
Reply | Threaded
Open this post in threaded view
|

Re: NSS support for RFC7512 PKCS#11 URIs

David Woodhouse-7
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 CA"s.
>
> 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
--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto

smime.p7s (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: NSS support for RFC7512 PKCS#11 URIs

Alan Braggins-3
In reply to this post by David Woodhouse-7
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 CA"s.
>
> 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
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto