On Thu, Apr 26, 2012 at 12:32 AM, helpcrypto helpcrypto <helpcry...@gmail.com>
wrote:
Supporting smart cards in the spec and first implementations is not a goal,
however, I think a lot of the base work we are doing will help in a future
iteration. For instance, I hope that this Gecko 'internal API' will help
extension and browser developers to experiment with smartcards, crypto keys,
etc.
Really happy to hear. Keep us updated when some work is made!
Are you saying you base64 encode the data to be signed before the signature is
created?
No. Let me show you an example.
Consider you provide this API:
sign(keyId, data)
IMHO, the correct way of invoking wil be:
sign(1,"ZGF0YXRvYmVzaWduZWQ=")
Inseatd of (cause it can end in encoding translation problem)
sign(1,"datatobesigned")
I observe that yes, this is "base64 encoding the data to be signed before the
signature is created".
Public key as a privacy risk? I don't imagine we will have an address bound the
the public key.
My X509 cert has my name, surname, identity ID...i dont want ANY site,
(except those requiring SSL client authentication like Tax ministry)
have any access to it.
My public key has a unique hash that could (easily) be used to track a
user. I dont want that either.
Huh. Someone who thinks like I do. This information has value, thus this
information must be protected.
Fortunately, I have something for that. Behold: the Identity Escrow Agent. This is a certifier who would take { your full certificate, a new public key }, the set signed with both asserted keys (axiomatic binding), then create a certificate around the new public key which says "I know who this is, but I shall not tell anyone except legitimate state authority."
The idea is that site owners would be able to start requiring this kind of
certificate, so that they can hold spammers and vandals accountable -- without
becoming private information trustees and becoming subject to various states'
felonization of handling personal information with less than PCI 2.0 controls.
This is a use which is far less dangerous to the broad swath of Mozilla's users
than the false google.com certificate, and which has a much smaller exposure if
the service is ever compromised. There would be no authoritative binding
information within the escrow certificate, which would mean that it could only
really be appropriate for establishing new non-fiduciary service relationships
-- but this is a usage which has no current expression, and which I think would
bypass many if not most of the issues preventing consumers and site owners from
seriously looking at cryptographic solutions. (It would definitely bypass all
of mine.)
-Kyle H
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
