CKA_ID and pkcs15 ID

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

CKA_ID and pkcs15 ID

Tarasov Viktor
Nils Larsch wrote:

> Tarasov Viktor wrote:
> ...
>
>> Now, the pkcs15init's rule for the object ID generation is different
>> from the Mozilla's one.
>
>
> Mozilla doesn't create pkcs15 ids it creates pkcs11 CKA_IDs (and there
> are afaik no rules or recommendation for pkcs15 ids)

and then the sc_pkcs15init_change_attrib() is called to set the pkcs15
id with the value of CKA_ID.

>
>> Mozilla (and others) use SHA1 of the modulus as ID for PrKey, PubKey,
>> and Cert objects.
>
>
> well for CKA_IDs it's recommended (however it's not a must) to use
> the subject key identifier from the x509 certificate, if present, as
> id value (of course how the subject key identifier is calculated is
> not really standardized, there's only a recommendation (see rfc 3280)).

Thank you.
Afais, in x509, the subject key identifier is (can be) the SHA1 of the
ASN1 sequence of modulus and exponent.
Mozilla uses the CKA_ID that is equal to SHA1 of the modulus, (which is
not completely as recommended by PKCS#11).
(That's why, I think that it would be nice to have some degree of
flexibility with the pkcs15 IDs.)

>> Pkcs15init use (AFAIS) linear schema, one byte ID, starting from '45',
>> with the possibility of reusing.
>
>
> this is of course simpler and more useful if you use command line
> options


>> So, my humble question is:
>> in the nearest future, do you envisage to change pkcs15init ID
>> generation rule,
>
>
> perhaps as an optional feature, btw: for on-card generated keys this
> somewhat difficult as you don't know the hash before creating the key.

Mozilla sets the CKA_ID of private and public key after the key was
generated.
(And thus, overwrites the pkcs15init ID.) Why not for pkcs15init to do
the same?

>
>> or, at least, to supply the card specific side with possibility to
>> choose object ID (card specific 'select_id')?
>
>
> certainly not something card specific as this is not card specific

Agree.

>
>>
>> IMHO, there are several advantages of this step:
>> 1. No need to create public key object, when generating private key.
>
>
> why ?

I have not much experience with the differentes cards,
does the oncard public card is really used?
I guess, it can safely be replaced with the certiifcate.
The main reason to create it, is to find out the corresponding private key,
when importing certificate.
So, with the ID derived from the key, we do not need the public key
pkcs15 object.

>
>> 2. More then one key can be generated and certificate imported with
>> Mozilla.
>> 3. Natural correspondance between PrKey, PubKey, and Cert objects. (For
>
>
> this depends on the definition of 'natural'. Normally the the exact
> value of the id shouldn't matter (as long as the values are the same).

For me, it's the ID, that is sufficient to find out the correspondance,
without scanning all the objects,
(and without knowledge about the card's pkcs15 structure).

BTW, now, when importing certificate with the pkcs15-init tool,
to set the correspondence with the private key,
the ID has to be supplied 'manually'.
We don't need it with the ID derived from the key.
 

>
>> exemple, right now,
>> I have a problem with deleting of public key, when importing with
>> Mozilla the corresponding certificate.)
>

> a bug in mozilla ?


Sorry, it was my fault:
C_SetAttribute for the public key's ID, executed by Mozilla, was not
working properly.

>
> Nils

Best regards,
Viktor.

>
> PS: Some time ago I wanted to raise this question as well, but I
>     forgot it.
>
> PPS: wrong thread

Sorry.

_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: CKA_ID and pkcs15 ID

Nils Larsch
Tarasov Viktor wrote:
...

>>>Mozilla (and others) use SHA1 of the modulus as ID for PrKey, PubKey,
>>>and Cert objects.
>>
>>
>>well for CKA_IDs it's recommended (however it's not a must) to use
>>the subject key identifier from the x509 certificate, if present, as
>>id value (of course how the subject key identifier is calculated is
>>not really standardized, there's only a recommendation (see rfc 3280)).
>
>
> Thank you.
> Afais, in x509, the subject key identifier is (can be) the SHA1 of the
> ASN1 sequence of modulus and exponent.

yep, that's how it's done in openssl

> Mozilla uses the CKA_ID that is equal to SHA1 of the modulus, (which is
> not completely as recommended by PKCS#11).
> (That's why, I think that it would be nice to have some degree of
> flexibility with the pkcs15 IDs.)

ack, where should be decided how to calc the id ?

>>>So, my humble question is:
>>>in the nearest future, do you envisage to change pkcs15init ID
>>>generation rule,
>>
>>
>>perhaps as an optional feature, btw: for on-card generated keys this
>>somewhat difficult as you don't know the hash before creating the key.
>
>
> Mozilla sets the CKA_ID of private and public key after the key was
> generated.
> (And thus, overwrites the pkcs15init ID.) Why not for pkcs15init to do
> the same?

we could add an option for this (for example it would make sense to use
the subject key identifier if present when importing a certificate)

>>>IMHO, there are several advantages of this step:
>>>1. No need to create public key object, when generating private key.
>>
>>
>>why ?
>
>
> I have not much experience with the differentes cards,
> does the oncard public card is really used?
> I guess, it can safely be replaced with the certiifcate.
> The main reason to create it, is to find out the corresponding private key,
> when importing certificate.
> So, with the ID derived from the key, we do not need the public key
> pkcs15 object.

hmm, normally you create a key, sign a pkcs10 request with this key, let
a ca sign this request and then store the certificate on the token =>
we need a public key unless we have a certificate.

...
> BTW, now, when importing certificate with the pkcs15-init tool,
> to set the correspondence with the private key,
> the ID has to be supplied 'manually'.
> We don't need it with the ID derived from the key.

makes sense

Nils
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: CKA_ID and pkcs15 ID

Tarasov Viktor
Nils Larsch wrote:

> Tarasov Viktor wrote:
> ...
>
>>>> Mozilla (and others) use SHA1 of the modulus as ID for PrKey, PubKey,
>>>> and Cert objects.
>>>
>>>
>>>
>>> well for CKA_IDs it's recommended (however it's not a must) to use
>>> the subject key identifier from the x509 certificate, if present, as
>>> id value (of course how the subject key identifier is calculated is
>>> not really standardized, there's only a recommendation (see rfc 3280)).
>>
>>
>>
>> Thank you.
>> Afais, in x509, the subject key identifier is (can be) the SHA1 of the
>> ASN1 sequence of modulus and exponent.
>
>
> yep, that's how it's done in openssl
>
>> Mozilla uses the CKA_ID that is equal to SHA1 of the modulus, (which is
>> not completely as recommended by PKCS#11).
>> (That's why, I think that it would be nice to have some degree of
>> flexibility with the pkcs15 IDs.)
>
>
> ack, where should be decided how to calc the id ?

It can be done in profile,
three possible values for the 'pkcs15id-calculation':
native (actual one byte ID),
subject-key-id (x509 subjectKeyIdentifier -- recommended by pkcs#11) and
mozilla-id (SHA1(modulus) -- used by mozilla).

But there is still a problem with the object file's xFID -- it should be
independent from the object ID.
Personally me, I do this separation in the card specific part. (That's
why I still use the old style API.)
For the common solution,
I guess that some 'object_index' should be added to sc_pkcs15_object_t,
and then, when instantiating the template,
the objects of the given type are scanned to find out the first
available index. (Thus, index reusing is implemented.)

>
>>>> So, my humble question is:
>>>> in the nearest future, do you envisage to change pkcs15init ID
>>>> generation rule,
>>>
>>>
>>>
>>> perhaps as an optional feature, btw: for on-card generated keys this
>>> somewhat difficult as you don't know the hash before creating the key.
>>
>>
>>
>> Mozilla sets the CKA_ID of private and public key after the key was
>> generated.
>> (And thus, overwrites the pkcs15init ID.) Why not for pkcs15init to do
>> the same?
>
>
> we could add an option for this (for example it would make sense to use
> the subject key identifier if present when importing a certificate)

Yes, this can be implemented like a 'perfect' ID , but,
to be compatible with Mozilla, it would be nice to have possibility
of Mozilla-like ID.

>
>>>> IMHO, there are several advantages of this step:
>>>> 1. No need to create public key object, when generating private key.
>>>
>>>
>>>
>>> why ?
>>
>>
>>
>> I have not much experience with the differentes cards,
>> does the oncard public card is really used?
>> I guess, it can safely be replaced with the certiifcate.
>> The main reason to create it, is to find out the corresponding
>> private key,
>> when importing certificate.
>> So, with the ID derived from the key, we do not need the public key
>> pkcs15 object.
>
>
> hmm, normally you create a key, sign a pkcs10 request with this key, let
> a ca sign this request and then store the certificate on the token =>
> we need a public key unless we have a certificate.

Let's imagine that you import the private key, and then,
in the next session (other place, operator, application, ...),
you sign pkcs10 and import the certificate.
To find out correspondence, you need to remember the ID of private key
object or
to have the oncard public key, that has the same ID as private key.

I agree, this advantage is not very significant, but,
IMHO, the unique object ID, derived from the object data itself,
and independent from the card's pkcs15 structure is more
appropriate to the differents possibles card life cycles.

>
> ...
>
>> BTW, now, when importing certificate with the pkcs15-init tool,
>> to set the correspondence with the private key,
>> the ID has to be supplied 'manually'.
>> We don't need it with the ID derived from the key.
>
>
> makes sense
>
> Nils

Kind wishes,
Viktor.

_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: CKA_ID and pkcs15 ID

Nils Larsch
Tarasov Viktor wrote:
...

>>>Mozilla uses the CKA_ID that is equal to SHA1 of the modulus, (which is
>>>not completely as recommended by PKCS#11).
>>>(That's why, I think that it would be nice to have some degree of
>>>flexibility with the pkcs15 IDs.)
>>
>>
>>ack, where should be decided how to calc the id ?
>
>
> It can be done in profile,
> three possible values for the 'pkcs15id-calculation':
> native (actual one byte ID),
> subject-key-id (x509 subjectKeyIdentifier -- recommended by pkcs#11) and
> mozilla-id (SHA1(modulus) -- used by mozilla).

I would prefer something like:

"default" one byte unless a subject key id has been specified in
           certificate
"rfc3280" the first method suggest in rfc3280 (don't know if second
           method is widely used)
"mozilla" as described above

> But there is still a problem with the object file's xFID -- it should be
> independent from the object ID.
> Personally me, I do this separation in the card specific part. (That's
> why I still use the old style API.)
> For the common solution,
> I guess that some 'object_index' should be added to sc_pkcs15_object_t,
> and then, when instantiating the template,
> the objects of the given type are scanned to find out the first
> available index. (Thus, index reusing is implemented.)

the more I think about the new style api the more I think the file
based approach in it is rather problematic.

...
>>we could add an option for this (for example it would make sense to use
>>the subject key identifier if present when importing a certificate)
>
>
> Yes, this can be implemented like a 'perfect' ID , but,
> to be compatible with Mozilla, it would be nice to have possibility
> of Mozilla-like ID.

ok

>>hmm, normally you create a key, sign a pkcs10 request with this key, let
>>a ca sign this request and then store the certificate on the token =>
>>we need a public key unless we have a certificate.
>
>
> Let's imagine that you import the private key, and then,
> in the next session (other place, operator, application, ...),
> you sign pkcs10 and import the certificate.
> To find out correspondence, you need to remember the ID of private key
> object or
> to have the oncard public key, that has the same ID as private key.

this would be reason to use the subject key identifier as issued by the
CA, hence most likely the subject key identifier as recommended in
rfc 3280 and not for example mozilla like ids (note: this only really
works if you know beforehand which alg to use).

> I agree, this advantage is not very significant, but,

depends on the usage scenario

> IMHO, the unique object ID, derived from the object data itself,
> and independent from the card's pkcs15 structure is more
> appropriate to the differents possibles card life cycles.

Cheers,
Nils
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel