Why do PIV key and cert labels not match?

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

Why do PIV key and cert labels not match?

David Woodhouse
It's almost like this stuff is *designed* to be hard to use.

OK, in my ignorance I happened to suggest once in documentation that
"the [PKCS#11] URLs for the key and the cert should differ only in that
the key will contain the attribute ';object-type=private', while the
certificate will have ';object-type=cert'."

.... and thus I suggested that users strip the object-type= part from
the URI and just use that, and the application can use it for finding
both cert and key.

This is of course wrong for PIV where the labels differ too:

Object 0:
        URL: pkcs11:model=PKCS%2315%20emulated;manufacturer=piv_II;serial=06b508843810d7f6;token=PIV_II%20%28PIV%20Card%20Holder%20pin%29;id=%01;object=PIV%20AUTH%20key;object-type=private
        Type: Private key
        Label: PIV AUTH key
        Flags: CKA_WRAP/UNWRAP; CKA_PRIVATE; CKA_SENSITIVE;
        ID: 01

Object 2:
        URL: pkcs11:model=PKCS%2315%20emulated;manufacturer=piv_II;serial=06b508843810d7f6;token=PIV_II%20%28PIV%20Card%20Holder%20pin%29;id=%01;object=Certificate%20for%20PIV%20Authentication;object-type=cert
        Type: X.509 Certificate
        Label: Certificate for PIV Authentication
        ID: 01

And thus I just had to help a very confused user...
http://lists.infradead.org/pipermail/openconnect-devel/2014-December/002452.html

Should the application have said "oh, there is a key matching that
specification but no cert; I'll try dropping the explicitly specified
label and see if I can find a matching cert then...?"  I can implement
that logic, but by $DEITY it'll make me sad...

--
David Woodhouse                            Open Source Technology Centre
[hidden email]                              Intel Corporation

------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel

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

Re: Why do PIV key and cert labels not match?

Douglas E Engert
In short, the Cert labels are taken from NIST 800-73 tables.
NIST does not define any labels for keys, so I made them up.


On 12/4/2014 6:51 AM, David Woodhouse wrote:
> It's almost like this stuff is *designed* to be hard to use.

Sort of. A lot of it is based on the CAC card, and other previous versions.
PKCS#11 or PKCS#15 (AFAIK) were not considered  by NIST.

>
> OK, in my ignorance I happened to suggest once in documentation that
> "the [PKCS#11] URLs for the key and the cert should differ only in that
> the key will contain the attribute ';object-type=private', while the
> certificate will have ';object-type=cert'."

The PIV was not designed to be a PKCS#15 or PKCS#11 based card.
There is no way to determine that a private key exists on a
card, other then to:
(1) try to use it (and then you don't know if it is RSA or ECC or the size.)
   (This would also require the use if the PIN for most keys.)

(2) Infer it exists, and it type and size from the matching SPKI in a certificate.

>
> .... and thus I suggested that users strip the object-type= part from
> the URI and just use that, and the application can use it for finding
> both cert and key.
>
> This is of course wrong for PIV where the labels differ too:
>
> Object 0:
>          URL: pkcs11:model=PKCS%2315%20emulated;manufacturer=piv_II;serial=06b508843810d7f6;token=PIV_II%20%28PIV%20Card%20Holder%20pin%29;id=%01;object=PIV%20AUTH%20key;object-type=private

This URL is not part of PKCS#11 standards, and is not generated by any OpenSC code.

>          Type: Private key
>          Label: PIV AUTH key
>          Flags: CKA_WRAP/UNWRAP; CKA_PRIVATE; CKA_SENSITIVE;
>          ID: 01
>
> Object 2:
>          URL: pkcs11:model=PKCS%2315%20emulated;manufacturer=piv_II;serial=06b508843810d7f6;token=PIV_II%20%28PIV%20Card%20Holder%20pin%29;id=%01;object=Certificate%20for%20PIV%20Authentication;object-type=cert
>          Type: X.509 Certificate
>          Label: Certificate for PIV Authentication
>          ID: 01

Note the IDs for cert and key all match, as suggested by PKCS#11 v2.20:
"The CKA_ID attribute is intended as a means of distinguishing multiple publickey/
private-key pairs held by the same subject..."

I made these CKA_ID attributes up too for OpenSC: 01, 02, 03, 04, ... NIST 800-73 has no ordering.

The ID, Labels, model, manufacturer, token, pin prompt are all hardcoded in card-piv.c
as theae are not on the card.

>
> And thus I just had to help a very confused user...
> http://lists.infradead.org/pipermail/openconnect-devel/2014-December/002452.html

And as you noted in your note:

  -c 'pkcs11:manufacturer=piv_II;id=%01'


*BUT* the p11tool is not part of OpenSC, it from gnuTLS.

PKCS#11 V2.20 does define a CKA_URL as optional, so certificates can be stored
off line, but that is the only URL defined and only for certificates. Keys do not have a URL.

CKA_LABEL is optional, and is: "The CKA_LABEL attribute is intended to assist users in browsing."

I also don't recall that the PKCS#11 label of a cert and key have to match.

You may want to ask on the gnuTLS list about use of the p11tool and URL.


>
> Should the application have said "oh, there is a key matching that
> specification but no cert;

Should not happen, as the OpenSC PKCS#11 code will only show you a key if there is
a matching  certificate on the card. (See above as how it uses the cert SPKI to get the key parameters.)

> I'll try dropping the explicitly specified
> label and see if I can find a matching cert then...?"  I can implement
> that logic, but by $DEITY it'll make me sad...

That would be in the application, or the p11tool.

>
>
>
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
>
>
>
> _______________________________________________
> Opensc-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>

--

  Douglas E. Engert  <[hidden email]>


------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Why do PIV key and cert labels not match?

Nikos Mavrogiannopoulos-2
On Thu, Dec 4, 2014 at 3:50 PM, Douglas E Engert <[hidden email]> wrote:

>> Object 0:
>>          URL: pkcs11:model=PKCS%2315%20emulated;manufacturer=piv_II;serial=06b508843810d7f6;token=PIV_II%20%28PIV%20Card%20Holder%20pin%29;id=%01;object=PIV%20AUTH%20key;object-type=private
> This URL is not part of PKCS#11 standards, and is not generated by any OpenSC code.
[...]
> PKCS#11 V2.20 does define a CKA_URL as optional, so certificates can be stored
> off line, but that is the only URL defined and only for certificates. Keys do not have a URL.

The PKCS #11 standard body cannot define URLs, they have no authority
on them. The URI namespace is managed by IETF, and currently they are
in the process of having the pkcs11: URL standardized [0]. It would be
nice if OpenSC would use them too.

regards,
Nikos

[0]. http://www.ietf.org/mail-archive/web/saag/current/msg05834.html

------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Why do PIV key and cert labels not match?

David Woodhouse
In reply to this post by Douglas E Engert
On Thu, 2014-12-04 at 08:50 -0600, Douglas E Engert wrote:
> > Object 0:
> >          URL: pkcs11:model=PKCS%2315%20emulated;manufacturer=piv_II;serial=06b508843810d7f6;token=PIV_II%20%28PIV%20Card%20Holder%20pin%29;id=%01;object=PIV%20AUTH%20key;object-type=private
>
> This URL is not part of PKCS#11 standards, and is not generated by any OpenSC code.

This is a PKCS#11 URI as discussed in
https://tools.ietf.org/html/draft-pechanec-pkcs11uri-16

This is the form in which the application in question (the OpenConnect
VPN client) accepts an instruction to use keys/certs from PKCS#11.

Should the application have been expecting something *different*?

This is basically made simple by p11-kit. Available modules are
configured automatically and we just need to select the appropriate
object from the appropriate token, by a URI which specifies the required
attributes.

I can install a modern Linux system, plug a device in, invoke
OpenConnect with an appropriate pkcs11: URI and it Just Works™.

> Note the IDs for cert and key all match, as suggested by PKCS#11 v2.20:
> "The CKA_ID attribute is intended as a means of distinguishing multiple publickey/
> private-key pairs held by the same subject..."
>
> I made these CKA_ID attributes up too for OpenSC: 01, 02, 03, 04, ... NIST 800-73 has no ordering.
>
> The ID, Labels, model, manufacturer, token, pin prompt are all hardcoded in card-piv.c
> as theae are not on the card.

CKA_ID is ideally supposed to match the X509v3 Subject Key Identifier of
the cert, isn't it? But I suppose that's a bit much to expect...

> >
> > And thus I just had to help a very confused user...
> > http://lists.infradead.org/pipermail/openconnect-devel/2014-December/002452.html
>
> And as you noted in your note:
>
>   -c 'pkcs11:manufacturer=piv_II;id=%01'
>
>
> *BUT* the p11tool is not part of OpenSC, it from gnuTLS.
It does indeed. Does OpenSC provide a tool which can list the available
objects and their PKCS#11 URI?

> PKCS#11 V2.20 does define a CKA_URL as optional, so certificates can be stored
> off line, but that is the only URL defined and only for certificates. Keys do not have a URL.

I don't think this is related.

> CKA_LABEL is optional, and is: "The CKA_LABEL attribute is intended to assist users in browsing."
>
> I also don't recall that the PKCS#11 label of a cert and key have to match.

Nothing *has* to match. I can use key and cert from entirely different
tokens, with entirely different IDs and labels. I've done that, and I've
tried it with the key in a TPM and cert in PKCS#11 and all kinds of
bizarre combinations. :)

But I was previously under the impression that the label on a matching
key and cert *would* match. It doesn't make much sense for them not to.

I suppose what I need is something that'll filter out the redundant
attributes and give me a "canonical" PKCS#11 URI for referencing the
object(s) in question.

> > Should the application have said "oh, there is a key matching that
> > specification but no cert;
>
> Should not happen, as the OpenSC PKCS#11 code will only show you a key if there is
> a matching  certificate on the card. (See above as how it uses the cert SPKI to get the key parameters.)

It shows me the key because there *is* a matching certificate on the
card. But if my match criteria include 'CKA_LABEL=PIV AUTH key' then
there's no certificate matching *that* criterion, even though there is a
key that does.

So it sounds like my application, when looking for a key to match a
given cert, should *not* be assuming that the label will be the same.

> > I'll try dropping the explicitly specified
> > label and see if I can find a matching cert then...?"  I can implement
> > that logic, but by $DEITY it'll make me sad...
>
> That would be in the application, or the p11tool.

The application is mine. I'm trying to make it do the right thing for
the users, to make life as easy as possible.

--
dwmw2

------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel

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

Re: Why do PIV key and cert labels not match?

Douglas E Engert


On 12/4/2014 9:32 AM, David Woodhouse wrote:

> On Thu, 2014-12-04 at 08:50 -0600, Douglas E Engert wrote:
>>> Object 0:
>>>           URL: pkcs11:model=PKCS%2315%20emulated;manufacturer=piv_II;serial=06b508843810d7f6;token=PIV_II%20%28PIV%20Card%20Holder%20pin%29;id=%01;object=PIV%20AUTH%20key;object-type=private
>>
>> This URL is not part of PKCS#11 standards, and is not generated by any OpenSC code.
>
> This is a PKCS#11 URI as discussed in
> https://tools.ietf.org/html/draft-pechanec-pkcs11uri-16
>
> This is the form in which the application in question (the OpenConnect
> VPN client) accepts an instruction to use keys/certs from PKCS#11.
>
> Should the application have been expecting something *different*?

After quick reading of the draft I would say yes.

PKCS#11 v2.20 at least does not require the CKA_LABEL attributes of keys and certs
to match. The example in Section 4 implies that you can do a search
keeping the object= from the cert and expect the same object to match the
key. These are derived from the CKA_LABEL of the cert and key.

Are there later PKCS#11 drafts that say the labels should match?

Other PKCS#11 implementations, may or may not follow this same label convention.

I will get on the mailing list for the IETF WG in the next few days.

Is there a way to query the cert using the object= to get the id=
of the cert (which will then match the key,
then use this id= without the object= to locate the key?

I will get on the mailing list for the IETF WG in the next few days.

>
> This is basically made simple by p11-kit. Available modules are
> configured automatically and we just need to select the appropriate
> object from the appropriate token, by a URI which specifies the required
> attributes.
>
> I can install a modern Linux system, plug a device in, invoke
> OpenConnect with an appropriate pkcs11: URI and it Just Works™.
>
>> Note the IDs for cert and key all match, as suggested by PKCS#11 v2.20:
>> "The CKA_ID attribute is intended as a means of distinguishing multiple publickey/
>> private-key pairs held by the same subject..."
>>
>> I made these CKA_ID attributes up too for OpenSC: 01, 02, 03, 04, ... NIST 800-73 has no ordering.
>>
>> The ID, Labels, model, manufacturer, token, pin prompt are all hardcoded in card-piv.c
>> as theae are not on the card.
>
> CKA_ID is ideally supposed to match the X509v3 Subject Key Identifier of
> the cert, isn't it? But I suppose that's a bit much to expect...

No that I can tell. In PKCS#11 v2.20 it says:

"The CKA_ID attribute is intended as a means of distinguishing multiple publickey/
private-key pairs held by the same subject (whether stored in the same token or not).
(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.)"

This was just a quick response, will look closer later.
If you can find some reference that PKCS#11 requires the labels to match, we can look
at changes...


>
>>>
>>> And thus I just had to help a very confused user...
>>> http://lists.infradead.org/pipermail/openconnect-devel/2014-December/002452.html
>>
>> And as you noted in your note:
>>
>>    -c 'pkcs11:manufacturer=piv_II;id=%01'
>>
>>
>> *BUT* the p11tool is not part of OpenSC, it from gnuTLS.
>
> It does indeed. Does OpenSC provide a tool which can list the available
> objects and their PKCS#11 URI?
>
>> PKCS#11 V2.20 does define a CKA_URL as optional, so certificates can be stored
>> off line, but that is the only URL defined and only for certificates. Keys do not have a URL.
>
> I don't think this is related.
>
>> CKA_LABEL is optional, and is: "The CKA_LABEL attribute is intended to assist users in browsing."
>>
>> I also don't recall that the PKCS#11 label of a cert and key have to match.
>
> Nothing *has* to match. I can use key and cert from entirely different
> tokens, with entirely different IDs and labels. I've done that, and I've
> tried it with the key in a TPM and cert in PKCS#11 and all kinds of
> bizarre combinations. :)
>
> But I was previously under the impression that the label on a matching
> key and cert *would* match. It doesn't make much sense for them not to.
>
> I suppose what I need is something that'll filter out the redundant
> attributes and give me a "canonical" PKCS#11 URI for referencing the
> object(s) in question.
>
>>> Should the application have said "oh, there is a key matching that
>>> specification but no cert;
>>
>> Should not happen, as the OpenSC PKCS#11 code will only show you a key if there is
>> a matching  certificate on the card. (See above as how it uses the cert SPKI to get the key parameters.)
>
> It shows me the key because there *is* a matching certificate on the
> card. But if my match criteria include 'CKA_LABEL=PIV AUTH key' then
> there's no certificate matching *that* criterion, even though there is a
> key that does.
>
> So it sounds like my application, when looking for a key to match a
> given cert, should *not* be assuming that the label will be the same.
>
>>> I'll try dropping the explicitly specified
>>> label and see if I can find a matching cert then...?"  I can implement
>>> that logic, but by $DEITY it'll make me sad...
>>
>> That would be in the application, or the p11tool.
>
> The application is mine. I'm trying to make it do the right thing for
> the users, to make life as easy as possible.
>

--

  Douglas E. Engert  <[hidden email]>


------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Why do PIV key and cert labels not match?

Douglas E Engert
This is a NOT a PIV only issue. Other OpenSC developers may want to get involved.

The draft RFC below is expecting a matching key and cert CKA_LABEL attributes to be the same.
This does not appear to be a PKCS#11 requirement, and I suspect many card drivers use
different labels.



On 12/4/2014 10:32 AM, Douglas E Engert wrote:

>
>
> On 12/4/2014 9:32 AM, David Woodhouse wrote:
>> On Thu, 2014-12-04 at 08:50 -0600, Douglas E Engert wrote:
>>>> Object 0:
>>>>           URL: pkcs11:model=PKCS%2315%20emulated;manufacturer=piv_II;serial=06b508843810d7f6;token=PIV_II%20%28PIV%20Card%20Holder%20pin%29;id=%01;object=PIV%20AUTH%20key;object-type=private
>>>
>>> This URL is not part of PKCS#11 standards, and is not generated by any OpenSC code.
>>
>> This is a PKCS#11 URI as discussed in
>> https://tools.ietf.org/html/draft-pechanec-pkcs11uri-16
>>
>> This is the form in which the application in question (the OpenConnect
>> VPN client) accepts an instruction to use keys/certs from PKCS#11.
>>
>> Should the application have been expecting something *different*?
>
> After quick reading of the draft I would say yes.
>
> PKCS#11 v2.20 at least does not require the CKA_LABEL attributes of keys and certs
> to match. The example in Section 4 implies that you can do a search
> keeping the object= from the cert and expect the same object to match the
> key. These are derived from the CKA_LABEL of the cert and key.
>
> Are there later PKCS#11 drafts that say the labels should match?
>
> Other PKCS#11 implementations, may or may not follow this same label convention.
>
> I will get on the mailing list for the IETF WG in the next few days.
>
> Is there a way to query the cert using the object= to get the id=
> of the cert (which will then match the key,
> then use this id= without the object= to locate the key?
>
> I will get on the mailing list for the IETF WG in the next few days.
>
>>
>> This is basically made simple by p11-kit. Available modules are
>> configured automatically and we just need to select the appropriate
>> object from the appropriate token, by a URI which specifies the required
>> attributes.
>>
>> I can install a modern Linux system, plug a device in, invoke
>> OpenConnect with an appropriate pkcs11: URI and it Just Works™.
>>
>>> Note the IDs for cert and key all match, as suggested by PKCS#11 v2.20:
>>> "The CKA_ID attribute is intended as a means of distinguishing multiple publickey/
>>> private-key pairs held by the same subject..."
>>>
>>> I made these CKA_ID attributes up too for OpenSC: 01, 02, 03, 04, ... NIST 800-73 has no ordering.
>>>
>>> The ID, Labels, model, manufacturer, token, pin prompt are all hardcoded in card-piv.c
>>> as theae are not on the card.
>>
>> CKA_ID is ideally supposed to match the X509v3 Subject Key Identifier of
>> the cert, isn't it? But I suppose that's a bit much to expect...
>
> No that I can tell. In PKCS#11 v2.20 it says:
>
> "The CKA_ID attribute is intended as a means of distinguishing multiple publickey/
> private-key pairs held by the same subject (whether stored in the same token or not).
> (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.)"
>
> This was just a quick response, will look closer later.
> If you can find some reference that PKCS#11 requires the labels to match, we can look
> at changes...
>
>
>>
>>>>
>>>> And thus I just had to help a very confused user...
>>>> http://lists.infradead.org/pipermail/openconnect-devel/2014-December/002452.html
>>>
>>> And as you noted in your note:
>>>
>>>    -c 'pkcs11:manufacturer=piv_II;id=%01'
>>>
>>>
>>> *BUT* the p11tool is not part of OpenSC, it from gnuTLS.
>>
>> It does indeed. Does OpenSC provide a tool which can list the available
>> objects and their PKCS#11 URI?
>>
>>> PKCS#11 V2.20 does define a CKA_URL as optional, so certificates can be stored
>>> off line, but that is the only URL defined and only for certificates. Keys do not have a URL.
>>
>> I don't think this is related.
>>
>>> CKA_LABEL is optional, and is: "The CKA_LABEL attribute is intended to assist users in browsing."
>>>
>>> I also don't recall that the PKCS#11 label of a cert and key have to match.
>>
>> Nothing *has* to match. I can use key and cert from entirely different
>> tokens, with entirely different IDs and labels. I've done that, and I've
>> tried it with the key in a TPM and cert in PKCS#11 and all kinds of
>> bizarre combinations. :)
>>
>> But I was previously under the impression that the label on a matching
>> key and cert *would* match. It doesn't make much sense for them not to.
>>
>> I suppose what I need is something that'll filter out the redundant
>> attributes and give me a "canonical" PKCS#11 URI for referencing the
>> object(s) in question.
>>
>>>> Should the application have said "oh, there is a key matching that
>>>> specification but no cert;
>>>
>>> Should not happen, as the OpenSC PKCS#11 code will only show you a key if there is
>>> a matching  certificate on the card. (See above as how it uses the cert SPKI to get the key parameters.)
>>
>> It shows me the key because there *is* a matching certificate on the
>> card. But if my match criteria include 'CKA_LABEL=PIV AUTH key' then
>> there's no certificate matching *that* criterion, even though there is a
>> key that does.
>>
>> So it sounds like my application, when looking for a key to match a
>> given cert, should *not* be assuming that the label will be the same.
>>
>>>> I'll try dropping the explicitly specified
>>>> label and see if I can find a matching cert then...?"  I can implement
>>>> that logic, but by $DEITY it'll make me sad...
>>>
>>> That would be in the application, or the p11tool.
>>
>> The application is mine. I'm trying to make it do the right thing for
>> the users, to make life as easy as possible.
>>
>

--

  Douglas E. Engert  <[hidden email]>


------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Why do PIV key and cert labels not match?

David Woodhouse
In reply to this post by Douglas E Engert
On Thu, 2014-12-04 at 10:32 -0600, Douglas E Engert wrote:

>
> On 12/4/2014 9:32 AM, David Woodhouse wrote:
> > On Thu, 2014-12-04 at 08:50 -0600, Douglas E Engert wrote:
> >>> Object 0:
> >>>           URL: pkcs11:model=PKCS%2315%20emulated;manufacturer=piv_II;serial=06b508843810d7f6;token=PIV_II%20%28PIV%20Card%20Holder%20pin%29;id=%01;object=PIV%20AUTH%20key;object-type=private
> >>
> >> This URL is not part of PKCS#11 standards, and is not generated by any OpenSC code.
> >
> > This is a PKCS#11 URI as discussed in
> > https://tools.ietf.org/html/draft-pechanec-pkcs11uri-16
> >
> > This is the form in which the application in question (the OpenConnect
> > VPN client) accepts an instruction to use keys/certs from PKCS#11.
> >
> > Should the application have been expecting something *different*?
>
> After quick reading of the draft I would say yes.
>
> PKCS#11 v2.20 at least does not require the CKA_LABEL attributes of keys and certs
> to match. The example in Section 4 implies that you can do a search
> keeping the object= from the cert and expect the same object to match the
> key. These are derived from the CKA_LABEL of the cert and key.
"The" example in §4 of the I-D? Which example?

Certainly *my* example was making that assumption but that's not a
fundamental limitation or assumption of the PKCS#11 URI scheme.

However the user provides their search criteria for finding cert+key,
what you're saying is that they *shouldn't* be including CKA_LABEL if
they differ.

Instead of telling the user to 'find the URI for the cert and strip the
type attribute', it should be '…and strip the type and label attributes'

> Are there later PKCS#11 drafts that say the labels should match?
>
> Other PKCS#11 implementations, may or may not follow this same label convention.
>
> I will get on the mailing list for the IETF WG in the next few days.
>
> Is there a way to query the cert using the object= to get the id=
> of the cert (which will then match the key,
> then use this id= without the object= to locate the key?

I can do that, yes.


> > CKA_ID is ideally supposed to match the X509v3 Subject Key Identifier of
> > the cert, isn't it? But I suppose that's a bit much to expect...
>
> No that I can tell. In PKCS#11 v2.20 it says:

http://docs.oasis-open.org/pkcs11/pkcs11-base/v2.40/cs01/pkcs11-base-v2.40-cs01.html#_Toc399255293
says:

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

> If you can find some reference that PKCS#11 requires the labels to match, we can look
> at changes...

No, I'll change my code to stop making that assumption. If the user
happens to include CKA_LABEL in their match criteria for the cert and if
we can't find a key matching those criteria, we'll drop the CKA_LABEL
match criterion, add the CKA_ID of the cert we found, and search again
for the key.

Still wouldn't have helped the user in question who gave the CKA_LABEL
of the *key* not the cert, but it's a start :)

--
dwmw2

------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel

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

Re: Why do PIV key and cert labels not match?

Douglas E Engert


On 12/4/2014 11:02 AM, David Woodhouse wrote:

> On Thu, 2014-12-04 at 10:32 -0600, Douglas E Engert wrote:
>>
>> On 12/4/2014 9:32 AM, David Woodhouse wrote:
>>> On Thu, 2014-12-04 at 08:50 -0600, Douglas E Engert wrote:
>>>>> Object 0:
>>>>>            URL: pkcs11:model=PKCS%2315%20emulated;manufacturer=piv_II;serial=06b508843810d7f6;token=PIV_II%20%28PIV%20Card%20Holder%20pin%29;id=%01;object=PIV%20AUTH%20key;object-type=private
>>>>
>>>> This URL is not part of PKCS#11 standards, and is not generated by any OpenSC code.
>>>
>>> This is a PKCS#11 URI as discussed in
>>> https://tools.ietf.org/html/draft-pechanec-pkcs11uri-16
>>>
>>> This is the form in which the application in question (the OpenConnect
>>> VPN client) accepts an instruction to use keys/certs from PKCS#11.
>>>
>>> Should the application have been expecting something *different*?
>>
>> After quick reading of the draft I would say yes.
>>
>> PKCS#11 v2.20 at least does not require the CKA_LABEL attributes of keys and certs
>> to match. The example in Section 4 implies that you can do a search
>> keeping the object= from the cert and expect the same object to match the
>> key. These are derived from the CKA_LABEL of the cert and key.
>
> "The" example in §4 of the I-D? Which example?

I looked close at draft-pechanec-pkcs11uri-16 examples in section 4,
I had misread:

     pkcs11:object=my-pubkey;type=public
and
     pkcs11:object=my-key;type=private?pin-source=/etc/token

The object name is different in each, I had read it as they were the same
and assumed it was trying to show searching by expecting the object= to be
the same in matching cert/pubkey/privkey.

So the draft looks good. (That's what I get for a quick read.)

>
> Certainly *my* example was making that assumption but that's not a
> fundamental limitation or assumption of the PKCS#11 URI scheme.

Correct, it was you example was assuming they would be the same.

http://www.gooze.eu/fr/forums/support/howto-connect-to-cisco-anyconnect-vpn-using-openconnect-and-pki-token

also says:

"Remove the ;object-type=xxx part from the URL"

So Gooze was aware that CKA_LABEL don't have to match.

>
> However the user provides their search criteria for finding cert+key,
> what you're saying is that they *shouldn't* be including CKA_LABEL if
> they differ.

Yes. id= CKA_ID is designed to be the way to find
matching certs, pubkey and privkey that could be left in the query.

>
> Instead of telling the user to 'find the URI for the cert and strip the
> type attribute', it should be '…and strip the type and label attributes'

Yes.

>
>> Are there later PKCS#11 drafts that say the labels should match?
>>
>> Other PKCS#11 implementations, may or may not follow this same label convention.
>>
>> I will get on the mailing list for the IETF WG in the next few days.
>>
>> Is there a way to query the cert using the object= to get the id=
>> of the cert (which will then match the key,
>> then use this id= without the object= to locate the key?
>
> I can do that, yes.
>
>
>>> CKA_ID is ideally supposed to match the X509v3 Subject Key Identifier of
>>> the cert, isn't it? But I suppose that's a bit much to expect...
>>
>> No that I can tell. In PKCS#11 v2.20 it says:
>
> http://docs.oasis-open.org/pkcs11/pkcs11-base/v2.40/cs01/pkcs11-base-v2.40-cs01.html#_Toc399255293
> says:
>
> "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."
>
>> If you can find some reference that PKCS#11 requires the labels to match, we can look
>> at changes...
>
> No, I'll change my code to stop making that assumption. If the user
> happens to include CKA_LABEL in their match criteria for the cert and if
> we can't find a key matching those criteria, we'll drop the CKA_LABEL
> match criterion, add the CKA_ID of the cert we found, and search again
> for the key.
>

http://www.gooze.eu/fr/forums/support/howto-connect-to-cisco-anyconnect-vpn-using-openconnect-and-pki-token

also says:

"Remove the ;object-type=xxx part from the URL"

So they were aware that they don't have to match.


> Still wouldn't have helped the user in question who gave the CKA_LABEL
> of the *key* not the cert, but it's a start :)
>

There is still some ambiguity as to what PKCS#11 means by:

CKA_ID  -  Byte array -  Key identifier for public/private key pair (default empty)

PKCS#11 v2.20 also says:
"(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.)"

Having the CKA_ID unique on a token for matching cert, pubkey and privkey appears
to match the intent on PKCS#11, as well as the draft-pechanec-pkcs11uri-16.

http://www.ietf.org/rfc/rfc3280.txt
talk about keyIdentifer and two methods to do this, but this addresses a more global perspective
and places the keyIdentifier in the certificate.


--

  Douglas E. Engert  <[hidden email]>


------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Why do PIV key and cert labels not match?

David Woodhouse
On Thu, 2014-12-04 at 14:00 -0600, Douglas E Engert wrote:

> On 12/4/2014 11:02 AM, David Woodhouse wrote:
> > Certainly *my* example was making that assumption but that's not a
> > fundamental limitation or assumption of the PKCS#11 URI scheme.
>
> Correct, it was you example was assuming they would be the same.
>
> http://www.gooze.eu/fr/forums/support/howto-connect-to-cisco-anyconnect-vpn-using-openconnect-and-pki-token
>
> also says:
>
> "Remove the ;object-type=xxx part from the URL"
>
> So Gooze was aware that CKA_LABEL don't have to match.

Note "object-type" not "object". In an older version of the I-D they
used "object-type" instead of "type". So that bit *isn't* about
CKA_LABEL.

In fact that post is actually a forum post by me, updated today so that
it *does* reflect the fact that the labels don't always match.

--
dwmw2

------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel

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

Re: Why do PIV key and cert labels not match?

David Woodhouse
In reply to this post by David Woodhouse
On Thu, 2014-12-04 at 17:02 +0000, David Woodhouse wrote:
>
> No, I'll change my code to stop making that assumption. If the user
> happens to include CKA_LABEL in their match criteria for the cert and if
> we can't find a key matching those criteria, we'll drop the CKA_LABEL
> match criterion, add the CKA_ID of the cert we found, and search again
> for the key.

I've done this.
http://git.infradead.org/users/dwmw2/openconnect.git/commitdiff/8af8f5473

I can now connect with just
 openconnect -c 'pkcs11:object=Certificate%20for%20PIV%20Authentication' $SERVER

It now finds a cert with that label in the PIV token, then:
 - fails to find a cert with that label without logging in
 - logs into the PIV token in which it found the cert
 - still fails to find a cert with that label
 - drops the label from its criteria and uses the CKA_ID it found in the cert
 - succeeds

Using PKCS#11 certificate pkcs11:object=Certificate%20for%20PIV%20Authentication;object-type=cert
Trying PKCS#11 key URL pkcs11:object=Certificate%20for%20PIV%20Authentication;object-type=private
Trying PKCS#11 key URL pkcs11:model=PKCS%2315%20emulated;manufacturer=piv_II;serial=108421384210c3f5;token=PIV_II%20%28PIV%20Card%20Holder%20pin%29;object=Certificate%20for%20PIV%20Authentication;object-type=private
PIN required for PIV_II (PIV Card Holder pin)
Enter PIN:
Trying PKCS#11 key URL pkcs11:model=PKCS%2315%20emulated;manufacturer=piv_II;serial=108421384210c3f5;token=PIV_II%20%28PIV%20Card%20Holder%20pin%29;id=%01;object-type=private
Using PKCS#11 key pkcs11:model=PKCS%2315%20emulated;manufacturer=piv_II;serial=108421384210c3f5;token=PIV_II%20%28PIV%20Card%20Holder%20pin%29;id=%01;object-type=private
Using client certificate 'Woodhouse\, David'


--
dwmw2

------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel

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

Re: Why do PIV key and cert labels not match?

David Woodhouse
In reply to this post by Douglas E Engert
On Thu, 2014-12-04 at 14:00 -0600, Douglas E Engert wrote:
>
> So the draft looks good.

I see engine_pkcs11 has a scheme of its own for passing object
information through a simple string:


supported formats: <id>, <slot>:<id>, id_<id>, slot_<slot>-id_<id>, label_<label>, slot_<slot>-label_<label>\n");
where <slot> is the slot number as normal integer,
and <id> is the id number as hex string.
and <label> is the textual key label string.


It would be really interesting to make it compatible with PKCS#11 URIs.
A string starting 'pkcs11:' would be unambiguous with the strings which
are already accepted.

In GnuTLS I can easily specify keys and certs with a string which is
either a filename or a PKCS#11 URI. It would be great if it were so
simple in OpenSSL too.

--
dwmw2

------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel

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

Re: Why do PIV key and cert labels not match?

Douglas E Engert
In reply to this post by David Woodhouse


On 12/4/2014 3:36 PM, David Woodhouse wrote:

> On Thu, 2014-12-04 at 17:02 +0000, David Woodhouse wrote:
>>
>> No, I'll change my code to stop making that assumption. If the user
>> happens to include CKA_LABEL in their match criteria for the cert and if
>> we can't find a key matching those criteria, we'll drop the CKA_LABEL
>> match criterion, add the CKA_ID of the cert we found, and search again
>> for the key.
>
> I've done this.
> http://git.infradead.org/users/dwmw2/openconnect.git/commitdiff/8af8f5473
>
> I can now connect with just
>   openconnect -c 'pkcs11:object=Certificate%20for%20PIV%20Authentication' $SERVER
>
> It now finds a cert with that label in the PIV token, then:
>   - fails to find a cert with that label without logging in
>   - logs into the PIV token in which it found the cert
>   - still fails to find a cert with that label
>   - drops the label from its criteria and uses the CKA_ID it found in the cert
>   - succeeds
>
> Using PKCS#11 certificate pkcs11:object=Certificate%20for%20PIV%20Authentication;object-type=cert
> Trying PKCS#11 key URL pkcs11:object=Certificate%20for%20PIV%20Authentication;object-type=private
> Trying PKCS#11 key URL pkcs11:model=PKCS%2315%20emulated;manufacturer=piv_II;serial=108421384210c3f5;token=PIV_II%20%28PIV%20Card%20Holder%20pin%29;object=Certificate%20for%20PIV%20Authentication;object-type=private
> PIN required for PIV_II (PIV Card Holder pin)
> Enter PIN:
> Trying PKCS#11 key URL pkcs11:model=PKCS%2315%20emulated;manufacturer=piv_II;serial=108421384210c3f5;token=PIV_II%20%28PIV%20Card%20Holder%20pin%29;id=%01;object-type=private
> Using PKCS#11 key pkcs11:model=PKCS%2315%20emulated;manufacturer=piv_II;serial=108421384210c3f5;token=PIV_II%20%28PIV%20Card%20Holder%20pin%29;id=%01;object-type=private
> Using client certificate 'Woodhouse\, David'

Great.

Do you have any other cards that OpenSC supports?

Do you want to ask OpenSC users to try the new openconnect with cards they have?


>
>

--

  Douglas E. Engert  <[hidden email]>


------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Why do PIV key and cert labels not match?

Douglas E Engert
In reply to this post by David Woodhouse


On 12/4/2014 4:10 PM, David Woodhouse wrote:

> On Thu, 2014-12-04 at 14:00 -0600, Douglas E Engert wrote:
>>
>> So the draft looks good.
>
> I see engine_pkcs11 has a scheme of its own for passing object
> information through a simple string:
>
>
> supported formats: <id>, <slot>:<id>, id_<id>, slot_<slot>-id_<id>, label_<label>, slot_<slot>-label_<label>\n");
> where <slot> is the slot number as normal integer,
> and <id> is the id number as hex string.
> and <label> is the textual key label string.

Yes, that has been around since at least 2004. Label was added in more recent times.

With the PIV, since the ID is fixed, id_01 gets you the Certificate for PIV Authentication, and its matching key
for the card in the slot. Makes it easy to use in scripts...

>
>
> It would be really interesting to make it compatible with PKCS#11 URIs.
> A string starting 'pkcs11:' would be unambiguous with the strings which
> are already accepted.

Mods are welcome...

>
> In GnuTLS I can easily specify keys and certs with a string which is
> either a filename or a PKCS#11 URI. It would be great if it were so
> simple in OpenSSL too.

One issue with the OpenSSL engine, for ECC is still outstanding.
I have mods to the OpenSC engine to use with ECDSA, and ECDH,
but it requires access to the internal OpenSSL header files:
    src/crypto/ecdsa/ecs_locl.h and  src/crypto/ecdh/ech_locl.h

http://rt.openssl.org/Ticket/Display.html?id=2459&user=guest&pass=guest

The proposals in the above ticket have stalled.

David,
Do you have any interest in getting this Ticket moving again?

If not does GnuTLS offer an engine capability? The main use I have for
the engine is in signing certificate requests. Others may use it for more then that.

I have tried to use GunTLS in the past, as a substitute for OpenSSL, with
dismal results. That has been a while and maybe things have changed.
OpenSC depends heavily on OpenSSL at least for provisioning, and hashing.
Trying to use both OpenSSL and GnuTLS in the same application can be next to impossible.
(Think of smart card login, where login is the applications, calling PAM
that could be using Kerberos (PKINIT calling PKCS#11), AFS, SAMBA, and who knows what else...)
So I am not pushing to use GnuTLS in OpenSC, but others might. This
ECC and engine issue is just another strike against OpenSSL.


>

--

  Douglas E. Engert  <[hidden email]>


------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Why do PIV key and cert labels not match?

David Woodhouse
In reply to this post by Douglas E Engert
On Fri, 2014-12-05 at 07:51 -0600, Douglas E Engert wrote:
>
> Great.
>
> Do you have any other cards that OpenSC supports?

As well as the PIV on the Yubikey NEO, I have a Feitian ePass PKI token
(which does give me matching labels for key and cert).

I've also tested with SoftHSM and GNOME keyring tokens.

> Do you want to ask OpenSC users to try the new openconnect with cards
> they have?

That would be great. I'm in the process of writing up some coherent
instructions for using it with PKCS#11, based on that gooze.eu forum
posting I made before.

People don't even need an account on a server; you can point it at
https://www.facebook.com/ and tell it to use your cert, and see if it
works.

It does some self-tests to check that it *is* using a matching key and
cert pair, signing some test data and then validating the signature. So
as long as it can make a TCP connection (doesn't even need to be TLS) to
the 'server' you point it at, it can do a valid test of the PKCS#11
support.

So as long as your PKCS#11 token is correctly installed for p11-kit to
find it (e.g. /usr/share/p11-kit/modules/opensc.module exists),
something like this ought to work:

 openconnect -c 'pkcs11:id=%01' www.facebook.com

If you need to (for example you have multiple tokens present), you can
be more specific in your URL than that, of course.

As long as it gets as far as "Using client certificate 'xxxx'" that's a
successful test of the functionality.

The interesting part really is *how* I tell users to work out the
PKCS#11 URI to use. I suppose that with the latest changes I made to
OpenConnect, it should be OK to cut and paste the *full* URI which will
be given by 'p11tool --list-all-certs' for the cert you want.


Once I've got this settled, and perhaps once the I-D has become an RFC,
I'd really like to do a bombing run through all the major applications
in Linux distributions that are capable of using X.509 certificates, and
make sure they all behave consistently w.r.t. PKCS#11 URIs. So the
OpenConnect behaviour isn't just one application; I'd like to set the
standard for how *everything* is expected to behave.

This may of course require working on engine_pkcs11 :)

--
dwmw2

------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel

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

Re: Why do PIV key and cert labels not match?

David Woodhouse
In reply to this post by Douglas E Engert
On Fri, 2014-12-05 at 08:24 -0600, Douglas E Engert wrote:
> With the PIV, since the ID is fixed, id_01 gets you the Certificate
> for PIV Authentication, and its matching key
> for the card in the slot. Makes it easy to use in scripts...

It does sound like using the X509v3 key ID would make life harder in
this case. Especially in my PIV where all four slots have the *same*
cert (and hence same ID).

> One issue with the OpenSSL engine, for ECC is still outstanding.
> I have mods to the OpenSC engine to use with ECDSA, and ECDH,
> but it requires access to the internal OpenSSL header files:
>     src/crypto/ecdsa/ecs_locl.h and  src/crypto/ecdh/ech_locl.h
>
> http://rt.openssl.org/Ticket/Display.html?id=2459&user=guest&pass=guest
>
> The proposals in the above ticket have stalled.

Seriously, OpenSSL needs to have *native* PKCS#11 support. Let's just
move engine_pkcs11 into OpenSSL itself, and then we don't have to worry
about the export issues.

We need to be able to just use PKCS#11 URIs in place of filenames to
functions like SSL_CTX_use_certificate_file(). Like we can in the
equivalent GnuTLS functions.

> David,
> Do you have any interest in getting this Ticket moving again?

Yeah, kind of. Although working on OpenSSL is kind of soul-destroying.
Much *more* so since I've got kind of used to how responsive and helpful
Nikos is when working on GnuTLS.

> If not does GnuTLS offer an engine capability? The main use I have for
> the engine is in signing certificate requests. Others may use it for more then that.

Yes, GnuTLS offers this kind of thing. I use it for TPM support,
providing my own signing functions using an opaque 'privkey' object, and
invoking the TSS functionality myself as appropriate.

> I have tried to use GunTLS in the past, as a substitute for OpenSSL, with
> dismal results. That has been a while and maybe things have changed.
> OpenSC depends heavily on OpenSSL at least for provisioning, and hashing.

I'd be interested to hear what issues you had, and I'm sure Nikos also
would be.

Personally, I *hate* going back to OpenSSL these days. But if I'm on a
mission to get coherent application behaviour for PKCS#11 across the
board, I suppose I'm going to have to hold my breath and poke at it :)

--
dwmw2

------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel

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

Re: Why do PIV key and cert labels not match?

Martin Paljak-4
In reply to this post by David Woodhouse
On Thu, Dec 4, 2014 at 5:32 PM, David Woodhouse <[hidden email]> wrote:
> CKA_ID is ideally supposed to match the X509v3 Subject Key Identifier of
> the cert, isn't it? But I suppose that's a bit much to expect...


The way I see it is that CKA_LABEL is for humans to read and humans
need to make a difference, what is a key and what is a certificate
(even if the software that lists them does not filter for some reason
by type), thus the labels can be and even should be different.

CKA_ID at the same time needs to match for related objects but is an
implementation detail of PKCS#11 and thus should be treated as opaque
value that may or may not be related to similar unique fields in
certificates or not.

Looking at the usage patterns of 10 years of PKI cards in the hands of
grandmothers and such, people usually speak about "certificates" and
sometimes even "PIN-s" (assuming that different operations are
protected by different PIN codes), now knowing what is behind the
technology. Just FYI, for UX considerations.

But great to see some PKCS#11 URL thing moving, that's something that
is greatly needed in Linux world to make configuration "as simple as
on ... other operating systems".


--
Martin
+372 515 6495

------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Why do PIV key and cert labels not match?

David Woodhouse
In reply to this post by David Woodhouse
On Fri, 2014-12-05 at 14:39 +0000, David Woodhouse wrote:
> That would be great. I'm in the process of writing up some coherent
> instructions for using it with PKCS#11, based on that gooze.eu forum
> posting I made before.

http://www.infradead.org/openconnect/pkcs11.html

Feedback very much welcomed.

--
dwmw2

------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel

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

Re: Why do PIV key and cert labels not match?

Nikos Mavrogiannopoulos
In reply to this post by Douglas E Engert
On Fri, 2014-12-05 at 08:24 -0600, Douglas E Engert wrote:

> I have tried to use GunTLS in the past, as a substitute for OpenSSL, with
> dismal results. That has been a while and maybe things have changed.
> OpenSC depends heavily on OpenSSL at least for provisioning, and hashing.
> Trying to use both OpenSSL and GnuTLS in the same application can be next to impossible.
> (Think of smart card login, where login is the applications, calling PAM
> that could be using Kerberos (PKINIT calling PKCS#11), AFS, SAMBA, and who knows what else...)

I'm not quite sure I understand what you mean above. OpenSSL and GnuTLS
work perfectly well in the same application. From your description in
the parenthesis I think that you mean that engine_pkcs11 of opensc may
not work well with gnutls. That is an issue of engine_pkcs11, as for
example GnuTLS works very well with NSS even in the same process and
accessing the same PKCS #11 modules. That is because both can use
p11-kit [0], which among others "... solves problems with coordinating
the use of PKCS#11 by different components or libraries living in the
same process.".

regards,
Nikos

[0]. http://p11-glue.freedesktop.org/p11-kit.html



------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel