Andre,
Now that I have had a few days to look over your approach, it has some merit.
The main issues are:
No one appears to have a card that supports EC and PKCS#15. This
complicates testing.
The Latest official RSA PKCS#15 documents that deals with EC appear to
be from 2000, and is very vague about EC and its parameters.
(Do you have anything more recent?)
The PKCS#11 documents are more up to date and do go into EC
parameters. Even these have changes from V2.01 in 1998, to V2.30
drafts on 2009.
RSA has no parameters associated with the public key, where as
EC, DSA and GOSTR have additional parameters. In the EC case
it could be an OID of a named curve, or a lot of big numbers.
(Even PKCS#11 passes these parameters as DER encoded.)
OpenSC was written to support RSA and support for parameters was
not needed, until GOSTR added some support, and then I don't think
it is complete.
Even with the EC support on the PIV card, only 2 named curves are
supported, so even it is not complete.
The term and variable pubkey is used throughout OpenSC to refer to
PKCS#11, pubkey, PKCS#15 pubkey, RSA pubkey and anything related
to a "pubkey" and since RSA does not have parameters, if the "pubkey"
has parameters are they included or not in a "pubkey"?
As you pointed out below, the ObjectValue is a CHOICE between PATH, RAW
and SubjectPublicKeyInfo and in OpenSC only the PATH choice is supported
today. Whereas a SPKI includes the algorithm and parameters.
There is some support to create a "pubkey" from SPKI from a certificate,
but is this what a real card with EC would use?
So before making any additional changes I suggest that a developer
should have a PKCS#15 card with EC, DSA or GOSTR to use in testing
and see if the card can support SPKI.
Until then I would like to leave the "emulated" variable as is because
the pkcs15-piv.c is creating a sc_pkcs15_pubkey which has the
algorithm, parameters and ecpoint included.
On 12/1/2010 4:05 PM, Andre Zepezauer wrote:
> On Wed, 2010-12-01 at 13:31 -0600, Douglas E. Engert wrote:
>>
>> On 12/1/2010 12:31 PM, Andre Zepezauer wrote:
>>> On Wed, 2010-12-01 at 11:34 -0600, Douglas E. Engert wrote:
>>>>
>>>> On 12/1/2010 9:10 AM, Andre Zepezauer wrote:
>>>>> On Wed, 2010-12-01 at 08:31 -0600, Douglas E. Engert wrote:
>>>>>>
>>>>>> On 11/30/2010 8:16 PM, Andre Zepezauer wrote:
>>>>>>> On Tue, 2010-11-30 at 16:16 -0600, Douglas E. Engert wrote:
>>>>>>>>
>>>>>>>> On 11/30/2010 3:22 PM, Andre Zepezauer wrote:
>>>>>>>>> Hello Douglas,
>>>>>>>>>
>>>>>>>>> for problem you tried to solve with r4901 there is a more general
>>>>>>>>> solution. That solution would involve the mapping of the ASN1 type
>>>>>>>>> ObjectValue to the corresponding C-structures.
>>>>>>>>>
>>>>>>>>> In the case related to r4901, the hook would be
>>>>>>>>> sc_pkcs15_pubkey_info_t->path. The underlying ASN1 type of that
>>>>>>>>> variable
>>>>>>>>> is ObjectValue. Which is defined by PKCS#15 as a CHOICE between PATH,
>>>>>>>>> RAW and SubjectPublicKeyInfo. Only the PATH choice is supported yet.
>>>>>>>>>
>>>>>>>>> In the long term that should be completed and 'path' should be
>>>>>>>>> replaced
>>>>>>>>> by 'value' with a type capable to hold one of PATH, RAW or
>>>>>>>>> SubjectPublicKeyInfo.
>>>>>>>>>
>>>>>>>>> I could implement that. But not before 0.12 is out. Because it
>>>>>>>>> requires
>>>>>>>>> some changes on asn1-decoders. In the mean time it's better to place
>>>>>>>>> the
>>>>>>>>> variable 'emulated' on sc_pkcs15_pubkey_info_t. Then the function
>>>>>>>>> sc_pkcs15_read_pubkey could be modified to handle the two cases (path
>>>>>>>>> or
>>>>>>>>> emulated) transparently.
>>>>>>>>
>>>>>>>> Sounds interesting, but today, the "emulated" works with the EC code I
>>>>>>>> am working on using the PIV card that is emulating the pubkey
>>>>>>>
>>>>>>> You are going to emulate something that hasn't to be emulated at all.
>>>>>>> The use-case where the whole public key is included within the meta-data
>>>>>>> is already defined by PKCS#15. Public-key-meta-data is mapped to
>>>>>>> sc_pkcs15_pubkey_info_t and so the pubkey as DER-encoded SPKI should
>>>>>>> reside there.
>>>>>>>
>>>>>>>> I would like to leave it the way it is, at least until I get all the EC
>>>>>>>> code committed.
>>>>>>>
>>>>>>> You could commit to a specialised branch and merge to trunk when 0.12 is
>>>>>>> released. In the mean time, things could be integrated better if
>>>>>>> necessary.
>>>>>>
>>>>>> Let me point out that no code is using the mod today, and will only
>>>>>> be used by the PIV to start with. As you point out the the pubkey
>>>>>> for EC at least could be a SPKI, and this looks promising.
>>>>>
>>>>> SPKI-encoding is common to all keys. In the specific case of EC,
>>>>> DER-encoded ECPoint is possible too. See the ASN1 definitions of
>>>>> {KEY-TYPE}PublicKeyChoice in PKCS#15.
>>>>>
>>>>> KEY-TYPE := RSA | EC | DH | DSA | KEA
>>>>>
>>>>> According to the specs, exactly one out of {path, url, raw, spki} is
>>>>> always included in meta-data.
>>>>>
>>>>
>>>> But as I have said, I don't have a true PKCS#15 card that can do EC,
>>>> only cards with the PIV applet that is not PKCS#15. I would suggest that
>>>> a good test environment using a card with PKCS#15 and EC should be
>>>> available
>>>> before making that type of change. If you have such a card, then please
>>>> propose the change.
>>>
>>> Look at the beginning of this thread: "for the problem you tried to
>>> solve with r4901 there is a more general solution."
>>>
>>> The problem is, that the card doesn't have a file system. So, why are
>>> you always talking about EC?
>>>
>>>> The PIV card actually has no directory but only a predefined set of objects
>>>> including some that contain a certificate. It also have a matching private
>>>> key on the card which can not be read. The only way to get any information
>>>> about the algorithm, parameters and public key is to read and parse the
>>>> certificate which includes the SPKI. During card initialization the
>>>> certificates have to be read and cert, pubkey and privkey PKCS#15 objects
>>>> are emulated at that time.
>>>
>>> The dependency on the flag EMULATED clearly indicates that your approach
>>> is wrong. No other emulator does something similar!
>>
>> They all use RSA, where it not an issue. I did not need this with the PIV
>> card for the last 5 years as it too was RSA only. Extra code in the pkcs15
>> needs to be added to process the PKCS15 pubkey file as an SPKI, and that
>> code is not there. (Much of the parsing is there from r4805 on 10/12.)
>>
>> With a lot of extra code, I think we could do what you want, but not right
>> now.
>
> That extra code is attached.
--
Douglas E. Engert <deeng...@anl.gov>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
_______________________________________________
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
