On 8/11/2012 1:26 PM, Andreas Schwier (ML) wrote: > Hi Viktor and Douglas, > > I do also favour to keep the DER signature format at the interface > between the card driver and the pkcs15 framework.
OK, we could do that. I would like to wait till after 0.13.0 is released, as the current code is working. What is your scheduling requirements? > > At the card driver level we don't know the field size, but we do at the > pkcs15 framework level. And all cards I know use the DER encoded > signature format anyway. > > Maybe we can reuse Douglas code and do a conditional conversion in > sc_pkcs11_signature_final. > > Andreas > > > Am 26.06.2012 08:06, schrieb Viktor Tarasov: >> >> >> On Mon, Jun 25, 2012 at 9:22 PM, Douglas E. Engert <deeng...@anl.gov >> <mailto:deeng...@anl.gov>> wrote: >> >> Just back from vacation... >> >> >> On 6/21/2012 9:50 AM, Viktor TARASOV wrote: >> >> Hi Douglas, >> >> I'm trying to get signature with the PIV card and verify it >> with the 'openssl pkeyutl'. >> I use EC key #04 "CARD AUTH Key". >> >> It fails because of the 'raw' output format of the signature >> produced by OpenSC. >> OpenSSL expects the signature as a ASN1 sequence of two integers. >> >> I've seen in card-piv.c your comments: >> >> https://github.com/OpenSC/OpenSC/blob/staging/src/libopensc/card-piv.c#L2023 >> >> /* The PIV returns a DER SEQUENCE{INTEGER, INTEGER} >> * Which may have leading 00 to force positive >> * TODO: -DEE should check if PKCS15 want the same >> >> >> It seems that PKCS#15 really wants it. >> >> * But PKCS11 just wants 2* filed_length in bytes >> >> Can you explain more? Why it wants 'raw' data? >> >> >> PKCS#11 v2.30: says: >> >> 6.3.1 EC Signatures >> For the purposes of these mechanisms, an ECDSA signature is an >> octet string of even >> length which is at most two times nLen octets, where nLen is the >> length in octets of the >> base point order n. The signature octets correspond to the >> concatenation of the ECDSA >> values r and s, both represented as an octet string of equal >> length of at most nLen with the >> most significant byte first. If r and s have different octet >> length, the shorter of both must >> be padded with leading zero octets such that both have the same >> octet length. >> >> PKCS#11 2.20 in Section 12.3.1 says the same as above. >> >> PKCS#11 2.01 11.4.3 says basically the same thing, but assumes a >> fixed size of nLen=20. >> >> So PKCS#11 is not returning ASN1 but just the concatenation of r >> and s. >> >> >> Ok, thanks. >> >> * So we have to strip out the integers >> * if present and pad on left if too short. >> */ >> >> >> >> I would propose to keep the ASN1 encoded data at the PKCS#15 >> level, >> and, if needed, to convert it to the 'raw' format by dedicated >> procedure in the pkcs15 framework of pkcs11. >> >> >> Where do you see in PKCS#15 that a ECDSA signature is in ANS1? >> If it needs to be ASN1, then yes the conversion could be done in >> the framework. >> >> >> Ok, there is no signature in ASN.1 in pkcs#15, but there some >> practical reasons. >> >> The card itself (Oberthur's PIV) returns the signature encoded in ASN.1; >> OpenSSL, for which the pkcs15-tool have to provide data in a suitable >> format, needs also the ASN.1 encoding. >> >> So, my suggestion is to keep the encoding returned by the card at the >> pkcs#15 level, >> and change it to the 'raw' mode on the pkcs#11 side. >> >> Finally, I have no preference, if you prefer to keep it like it is >> now, we'll be living with. >> >> >> >> Kind regards, >> Viktor. >> >> >> >> >> >> >> >> >> >> >> >> -- >> >> Douglas E. Engert <deeng...@anl.gov <mailto:deeng...@anl.gov>> >> Argonne National Laboratory >> 9700 South Cass Avenue >> Argonne, Illinois 60439 >> (630) 252-5444 <tel:%28630%29%20252-5444> >> >> >> >> >> >> _______________________________________________ >> opensc-devel mailing list >> opensc-devel@lists.opensc-project.org >> http://www.opensc-project.org/mailman/listinfo/opensc-devel > > -- 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
