On 20/04/12 00:41 AM, helpcrypto helpcrypto wrote:
My "solution" to this is to treat all PKI-using applications as complete
applications running in trusted code. W3C tries to do something different,
we'll see how that pans out...
Ok Anders, but you are -again- talking much about your protocol, not
answering my question (or at least, i didnt get it as clear as water).
I think, this must be a communication problem between my spanish and
yours swedish (?). I really sorry for that.
No, don't be boring. No tiene nada que ver con el idioma, tu ingles es
ma'o'menos perfecto :P
The problem is that Anders is steeped in the theoretical and
intellectual models of the area, and has internalised more than we can
imagine. He leaps quickly from area to area.
He's saying the same thing as me - but using his formal language. You
will find the same problem between any set of cross-domain geeks talking
two domain languages over a common natural language.
Where he says "trusted code" I say "peer to peer". It's the same thing
viewed from a different angle.
Im talking about something much more simpler: "Detect a card insertion
and be sure the card is doing the operation i requested".
My guess is: that sort of info likely won't ever be exposed by Mozilla
to websites because (developers think) it can be abused as part of an
attack. The way Firefox is constructed in security terms is that less
information is better, even at the risk of unreliability and system fail.
Try debugging basic SSL protocol failures; both sides send
incomprehensible numbers to each other, and the browser reports these to
the user with smugness. "The server is misconfigured because it said
12345 which means goobledygook from the fligimidigget."
You're asking for something that appears to you reasonable - as an app
developer. But it is a long way away from where the software mindset is
- for the browser developer. Now you're talking in a foreign language
to them :)
For example:
Within a browser, i click on "dear card, please, RSA sign this data" button.
I doubt that would pass the security review at Mozilla. That's what I
thought you were trying to do. It's a non-starter.
The webserver that instructs the browser isn't a peer. So, basically
you are saying that any webserver or any browser can instruct the card
to sign anything.
(The browser isn't a peer to a smart card, but it pretends to be. And
it is so unconfident of its work that it jealously guards everything to
itself, even at the risk of failure. Given all that, why bother with a
smart card? These are self-fulfilling prophecies...)
IIUC, you say "that should not be done" or "that is not good for ~ reasons".
And that is want to know.
The reason is you cannot control other agents owned by attackers doing
the same thing. So your signature is worthless, because as soon as
someone adds value to your signature, others will come and steal the
value away.
Hypothetically, at a minimum, I'd be looking for the request to come
signed by some other peer RSA key. (partial answer only... but it is
meaningful to the developer?)
Which means that the smart card has to mediate the request, or there
needs to be some standard approach to this from PKIX or somewhere.
Which there isn't, as far as I know.
Why, if i request a certificate using a webpage (=generate keypair), i
cant control if the operation is performed within the card (not in
softokn)?
There is "generate keypair" and there is "request a certificate". These
are entirely different.
1. The "generate keypair" thing (keygen?) is only for the Software
Security Device as an assist in the process of turning it into a
CA-signed cert.
It is *only* for creating a keypair and not for creating certificates
because otherwise it would go against the CA business model - all certs
must be signed by CAs - and that is sacrosanct in Mozilla security
model. In short, you can request a keypair, but you must then take it
out as a CSR and get it CA-signed.
It can't be for the smart card because that would mean there was a
standard provisioning service (some words used to describe getting the
right certs onto the smart card securely) available in the standards
world. There isn't. As far as I know. Ask Anders, he's authoritive on
this.
I know I'm not telling you *why it is like this* ... the first part
necessary is to understand how the world is.
2. When you request a (completed) certificate, it is the user's choice
where it comes from. It is considered part of the user's rights and
freedoms. (Or so, Mozilla would view it.)
If you could specify which certificate, you could also map out the
user's identity framework, and this would be a breach of privacy.
(Indeed, there are filed bugs because servers can silently request certs
from users of Firefox, if a certain button is clicked in them which is
recommended to be clicked all the time otherwise the users gets spammed
by popups :( )
What you can do is examine the cert supplied for various EKUs, OIDs, and
for the CA signing chain, etc. That's because in PKI theory the
certificate carries a /claim/ as signed by a /CA/ and the claims should
be substitutable on their wordings. You are meant to rely on the claim,
in PKI theory. So asking for a particular security model is the wrong
question, you should be examining the certificate presented at the
user's choice for a /claim/ signed by a CA that you trust to say that
"this certificate is certified by the CA as being duly protected to
smart card standards" or whatever other claim you are looking for.
E.g., Qualified Certificates will try and do this.
That's according to PKI theory. I'm not offering any opinions about
that :) Just trying to explain the world as it is.
(Using latest build, i can do that operation, but i cant control where
is done...)
Here, you mean the keygen operation? I think it has to be the Software
Security Device. aka, the soft-token ?
Actually, if i access an untrusted SSL site, i see a warning "you are
about to enter on an untrested site..."
Why i could not see "this page wants to use the smartcard..." warning?
Some UI tests have shown 99% of those warnings to be ignored. Some
optimistic tests have shown only 60% are ignored... Some active
teaching experiences have shown they can get it down to 30% with
training, but the test repeated after 3 months shows return to bad habits :)
Is your application so valueless that you can cope with that? When
using smart card systems, you'll notice there are no warnings... because
the smart card designers at least know that if they rely on warnings,
it's game-over.
The economic problem of smart cards is that they cost a lot of money.
So they can only be used to ... protect a lot of money. So they cannot
use the "cheap-no-value-ignorable" tricks that browsers use like
spamming the user with 4 clicks to get to her cert. That's because, if
the trick doesn't work, the user loses money. If the user loses money,
she gets very upset, and the multiplier effect is such that the entire
ecosystem stops within short order.
Mind you, we don't know how valuable or valueless your application is.
Perhaps you could tell us what the key pair or signature is used for?
Maybe, this discussion should be on private to avoid spamming
dev-tech-crypto list...?
Well, others will chime in and say their bored if they're bored :)
iang
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
