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