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