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