Martin Paljak wrote:
<snip>
It accepts ascii-numeric pins, but it is a PIN (with numbers) for
several reasons:
1. People know PIN codes and use them on ATMs => cards have PINs which
are made of numbers
2. I use pinpad readers for obvious reasons, which only have numbers
3. You are not married to your own computer, you might end up somewhere
else where the only option is to use a pinpad (like e-service computers
in local bank offices)
4. "Software legacy" - the same way it is sometimes hard to introduce
hardware cryptography to existing pieces of software, because it is
built following the "keys are in files which might need a password to
open". Same with "chip and pin" software - PIN is a numeric thing for
the masses, only in strange setups you can use something else..
</snip>
Absolutely! Here is another recent addition to the PKI GUI "trauma":
http://www.ietf.org/internet-drafts/draft-ietf-pkix-certimage-00.txt
I have in KeyGen2 selected another method for certimage which is
defining cert-images as token attributes during the key provisioning phase
to be able to support device size adaptation (mobile phones) and higher
issuer freedom for image data (images are only local, never "published").
I also made passphrase format a token attribute to get away from
middleware-defined PIN dialogs of the kind used in Windows CSPs.
The IETF I-D may prove to be hard to get traction for as it only addresses
a single problem and ignores the middleware/application "PKI GUI ownership"
issues.
I'm trying to make a scheme that unifies PKI and Information Cards
GUI-wise because they can both easily fit the "card" metaphor which
I think is more useful than DN exploration since certificates were
never really meant for human interpretation unless geeks qualify as
humans :-)
This document hopefully shows how it is supposed to work:
http://webpki.org/papers/web/multiple-credentials-in-the-enterprise.pdf
Anders
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
