On 6/14/2011 2:58 AM, Viktor Tarasov wrote: > Le 14/06/2011 00:20, Douglas E. Engert a écrit : >> With all of this discussion about the non-repudiation flags >> in PKCS#15 vs PKCS#11, it appears to me that RSA may have intended >> for a non-repudiation flag at one time, but did not implement it >> in PKCS#11. >> >> As I recall from my PKIX IETF meetings, non-repudiation was a hot >> topic. From a legal view point one can always repudiate that a >> signature was valid, i.e. the the user intentionally signed a document. >> Its more a a legal term, then an attribute. It would be up to some court >> to determine if the signature is valid and was the intent of the user. >> So even if a card or certificate claimed "non-repudation" is was >> meaning less. >> >> http://www.ietf.org/rfc/rfc2459.txt >> >> >> The PKCS#15 v 1.1 document is from June 2000. >> >> http://www.rsa.com/rsalabs/node.asp?id=2141 >> says: >> "Since January 2004, a formal IC card standard exists which is based on >> PKCS#15, >> namely ISO/IEC 7816-15. RSA Laboratories therefore has decided to not do any >> further development on the IC card related parts of PKCS #15, but rather >> refer >> those interested in this technology to the ISO/IEC version, which will be >> maintained and evolved by ISO." >> >> PKCS#11 on the other hand, has at least these versions (I have copies of >> these): >> V2.01 December 1997 >> V2.11 November 2001 >> V2.20 June 2004 >> V2.30 July, 2009 (Draft 7) >> >> As far as I can tell, only 2.11 says anything about non-repudiation, >> and that is in tables 27 and 35, and overloads the CKA_SIGN_* and CKA_VERIFY* >> attributes. If there was ever any intention to define a non-repudiation >> PKCS#11 attribute, tables 27 and 35 would have been the place to do it, >> >> I do not have a copy of the ISO/IEC 7816-15 so can not say if the >> non-repudiation flag is still there. If its not, then we shoul not be trying >> to add it back in to PKCS#15, or PKCS#11. (Anyone have a copy?) > > I have draft of ISO7816-15 > ISO/IEC JTC 1/SC 17; Date: 2002-04-15; ISO/IEC FCD 7816-15; ISO/IEC JTC 1/SC > 17/WG 4 > > It's there. > >> >> From what I was reading in your notes, you have two certificates/keys >> one of which you are referring to as 'signature' and 'qualified signature' >> and you want to treat one as more secure them the other, and thus want >> to use the 'non-repudiation' on the more secure cert/key? (Which one >> is more secure?) > > No, > I have pre-allocated key slots, where only keys with the restricted usage can > be placed.
Are there different user PINs for each requires a PKCS#11 slot? Most of the following is assuming only one user PIN, and it applies to both of your keys. The card I am most familiar with is the PIV card, with 4 primary certificates and keys but with only one user PIN, and thus uses only one slot: Certificate Key x509 keyUsage Other attributes for PIV Authentication 9A Digital Signature msLogin, msUPN for Digital Signature 9C Digital Signature+NonRepudiation, E-mail for Key Management 9D Key Encipherment Email for Card Authentication 9E Digital Signature (card authenticates itself, no PIN) The 9A key is used for authentication by browsers, and login once the PIN is entered once. The 9C key is used for signing e-mail and requires the PIN immediately before each use, and is enforced by the card and the pkcs15-piv.c code sets the CKA_ALWAYS_AUTHENTICATE. Thunderbird can handle the CKA_ALWAYS_AUTHENTICATE. So what I am reading, is your 'signature' is like the 9A key, and your 'qualified signature' is like the 9C key? The point I am trying to make, is that it might be possible to not need extra flags but using the CKA_ID value to indicate its a 'qualified signature' key, or you might be able to pass in the CKA_ALWAYS_AUTHENTICATE to your generate key routine, to indicate to create a 'non-repudiation' key. > > >> >> Since PKC#11 does not appear to support a non-repudiation flag, >> what applications would you expect to use such a flag if you added it >> to the PKCS#15 ond PKCS# attributes? > > Application that is looking to create a key in the key-slot with the > restricted key usage. > > >> It sounds like you want to use this flag when generating a key to tell >> the card to add it to the PKCS#15 flags. > > > Yes, I do not see other usage of the key usage CKA_ attributes . > And you? > > >> Is there some way based on the a >> PKCS#11 parameter, attribute, ( LIKE CKA_ID=some special value or range) >> that your card driver could use as as a flag to generate the key >> and set the PKCS#15 attribute? > > I will consider you suggestion, but for a while, > > I wonder where, according to you, pass the frontier between 'allowed' and > 'not-allowed' . > - use PKCS#11 to create key; > - use PKCS#11 to create key with the usage restricted to 'decryption' (or > 'signature'); > - use PKCS#11 to create key with the usage restricted to 'signature with > non-repudiation'. What is on the card to detect if the key is being used as expected? I know the PKCS#15 non-repudiation bit would be there, but does this signal the card to do something different? I only see two ways for the card to convey to the user the sense of 'non-repudation' The card enforcing CKA_ALWAYS_AUTHENTICATE to force the user to enter the PIN just before the signature operation, or the use of a different PIN for different keys. It still comes down to the relying-party verifying the signature against the certificate and it keyUsage. > >> >> After generation the client you use the x509 keyUsage non-repudiation >> flag in the certificate to find the correct key, and never needs to >> look for the PKCS#15 non-repudiation key attribute. > > I have told much more then once -- it's going about creation of the key. > > Nothing changes for the key using, > because the key usage restricted by the device > will correspond to the key usage derived from certificate. > > -- 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
