On 4. 1. 2011 22:23, Robert Relyea wrote:
On 01/03/2011 01:04 PM, Anders Rundgren wrote:
Hi,
I'm in the starting phase upgrading Firefox so that it can provision
credentials in a way that that banks and governments require which
among many things include E2ES (End-to-End Security) and issuer-
specified PIN-codes (or just policies for user-defined dittos).
The plan is mainly focusing on (enhanced) HW-tokens which NSS due
to its PKCS #11 heritage doesn't support with any of the above.
However, for "soft tokens" where all is running in user-space, the
distinction between middleware and the container is mostly academic
so it could be an idea supporting the NSS softtoken. Unfortunately, I
know rather little about NSS so I wonder if the idea is feasible or not.
Q1: Is is correct that you can only have a single PIN for all soft
tokens?
You have a single pin per 'slot'. Any PKCS #11 module can implement
multiple slots. You can even cause the NSS softoken to have multiple slots.
I also think that there is a definition on how to do key specific pins
in the later versions of PKCS #11. I think it involves using a special
user type, with the key operation already selected in the current
session. I'd have to go back and look, it might also just be I'm
remembering the AUTHENTICATE_ALWAYS semantic.
Yes, it's CKA_ALWAYS_AUTHENTICATE attribute set to TRUE for a private
key and, unfortunately, NSS currently does not support this.
Q2: Is it possible to add arbitrary data attributes to a key? I need
such
in order to support credential logotypes and information cards.
If these general token types, I suggest getting them added to the PKCS
#11 working group.
PKCS #11 also allows vendor defined attributes and objects. We use these
to supply NSS specific operations and objects, that aren't generally
interesting to the PKCS #11 group as a whole. If the ideas are generally
usable by a myriad of tokens, then trying to get them defined in the
working group is best.
CKA_VENDOR_SPECIFIC (0x8000000) and above. For example, NSS uses some
vendor-specific attributes such as the value of CKO_NETSCAPE_CRL for
CKA_CLASS attribute. You can implement such vendor-specific attribute as
well.
There is also an already define generic 'data' object.
If these objects aren't really attached to the key , then it's own
object type would make more sense.
bob
thanx,
Anders
M. Kurpel
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
