On 20/3/09 22:30, Kyle Hamilton wrote:
'since you obviously shouldn't have different PKI UIs for signatures
and authentication'? What crack are you smoking?
Hey Kyle, I think you are thinking way to far ahead here...
In the Real World, we have a different UI for authentication -- the
principal presenting an ID card -- than the UI for signatures -- a
piece of paper, a pen, and a unique mark made by the principal.
Having the same UI would be akin to having a post-it (or other
temporarily-adhered piece of paper) covering the upper part of the
page stating "I'm authenticating myself to this person", while the
lower part of the page doesn't have that. Then, the post-it's peeled
off to reveal that that it's a limited power of attorney that states
that it's in the signer's interest to transfer all of his assets into
the name of the person holding the document, and granting authority to
do so.
Your technical point may be correct, but it looks to me like a case of
your perfect being the enemy of Ander's good.
Right now we are discussing the presence of a single UI, and not the
separateness of the functions that the UI might handle. Right now,
Firefox has practically no or minimal user management for client
authentication *or* client signing at either level.
From this point of view, having at least a single UI for the purposes
of managing the certificates in a client authentication *and* any client
signing purposes ... would be a significant win for the user, and for
client certificates. Once we get that, we might "obviously" see that
doing a user-signing act is different and needs to be different. But we
will never get that far if we don't have the basic certificate
management interface.
The perfect is the enemy of the good... At least, let's start with the
easy tasks, client auth, and see how far that gets us towards
user-signing actions.
iang
PS: BTW/IMHO, we don't need to worry about any "wrong" user interface
for the user-signing act. We already have a decade ++ of experience
that if the UI isn't done properly, and indeed if the entire process
isn't done completely utterly properly, users will refuse it. It's the
lawyers who have ploughed this ground ahead of us: users know not to
sign anything they don't understand, and that includes any wierdo crypto
blah blah.
There are many people who think differently; I, for one, think that
server-auth is the *worse* part of TLS (because there's no branding of
what CA is responsible for the certification, there's no way to
identify when a session is re-used versus renegotiated, there's no way
to figure out what CAs are available on the client for
multiple-certification strategies,
PS2: Hmmm.... On that last point, does this mean that if Firefox is set
to automatically restart any request to client-auth to the server ...
and there are TWO certificates it could use, we would (at least in
principle, theoretically...) not know which certificate was used?
And therefore, if there is a problem, we would not know which CA was
responsible for that problem?
Hmmmm.... sounds like an auth bug?
This means that there's a problem with these assumptions -- being made
and implemented as they are without any real documented input from the
most important people of all: the users.
Yup! That's why they don't adopt.
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
