Hi Douglas, I'm fine with that. I already changed our card driver to provide the r||s format anyway.
After 0.13.0 we should work on the issue. Did anyone already considered implementing support for PKCS#1 PSS format ? We have support for it in the SmartCard-HSM and want to add it to OpenSC. Andreas Am 13.08.2012 00:45, schrieb Douglas E. Engert: > > 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 >> -- --------- CardContact Software & System Consulting |.##> <##.| Andreas Schwier |# #| Schülerweg 38 |# #| 32429 Minden, Germany |'##> <##'| Phone +49 171 8334920 --------- http://www.cardcontact.de http://www.tscons.de http://www.openscdp.org _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
