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. Regards Andre _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
