>'since you obviously shouldn't have different PKI UIs for signatures
>and authentication'? What crack are you smoking?
>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.
I was probably unclear but with *PKI* UI I refer to certificate
selection/information, not to the rest of the application. In fact,
the "compatibility" between signatures and authentication also
goes down to the technical part of certificate selection ("filtering")
which has been a long-winding issue in FireFox's TLS c-c-a
implementation.
Related issue:
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-March/018919.html
Anders
----- Original Message -----
From: "Kyle Hamilton" <aerow...@gmail.com>
To: "mozilla's crypto code discussion list" <dev-tech-crypto@lists.mozilla.org>
Sent: Friday, March 20, 2009 22:30
Subject: Re: client certificates unusable?
'since you obviously shouldn't have different PKI UIs for signatures
and authentication'? What crack are you smoking?
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.
-Kyle H
On Fri, Mar 20, 2009 at 11:29 AM, Anders Rundgren
<anders.rundg...@telia.com> wrote:
>>This is a stupid comment.
>
> Pardon me. I just don't agree with the majority of this list since
> many governments and banks in the EU are working in another
> direction. This may be due to ignorance but I insists that there
> is a problem having *two* competing session mechanisms in
> web-apps; one [IMO] may have to go.
>
> The other problem is that the signature stuff that the Mozilla
> community continuously downplays actually lives and this thingy
> also works contra TLS-c-c-a as since you obviously shouldn't
> have different PKI UIs for signatures and authentication.
> We are talking about investments in the range of $100M/Y.
>
> happy weekend
> Anders
>
> 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, and there's no way -- unlike IPSEC
> -- to require that a connecting client authenticate itself before the
> server decides to let its identity be known, among others).
>
> It seems pretty clear that the "common case" for authentication, as
> implemented by banks, utility companies, phone companies, PayPal, etc
> is to authenticate once and then let that authentication continue for
> as long as the session holds -- and by 'session' I mean a cookie
> either as a separate header or as a part of the URL -- and expire
> those sessions after 10 or 15 minutes of inactivity.
>
> The most important part to remember is that *ALL OF THIS CAN BE
> CONFIGURED ON THE SERVER AT THE TLS LAYER WITHOUT THE CLIENT KNOWING
> OR SUGGESTING ANYTHING ABOUT IT*. Sessions can be reset to 0-seconds
> idle when they're used, or not, at the server security configurator's
> whim.
>
> We've been living with the same set of assumptions for over ten years,
> and the client side of the authentication equation hasn't taken off.
> (The server side of the equation hasn't, either, really -- we're stuck
> with the same type of user interface that we had 10 years ago, with
> the most important [and only] advance being The Green Bar Of EV.)
> 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.
>
> -Kyle H
>
> On Fri, Mar 20, 2009 at 12:32 AM, Anders Rundgren
> <anders.rundg...@telia.com> wrote:
>> This is a stupid discussion.
>>
>> Authentication schemes in general begin with authenticating the user.
>> How long the authentication should be considered as valid is
>> not something the client-end has anything to do with unless it
>> has gotten some kind of expiration data from the server.
>>
>> It seems pretty clear that the real culprit is the TLS protocol itself.
>>
>> Fortunately a lot of people are working hard to establish schemes
>> that use the good part of TLS (server-auth) and leave the unwieldy
>> part to a community that won't be able fix it.
>>
>> Anders
>>
>>
>> ----- Original Message -----
>> From: "Nelson B Bolyard" <nel...@bolyard.me>
>> To: "mozilla's crypto code discussion list"
>> <dev-tech-crypto@lists.mozilla.org>
>> Sent: Friday, March 20, 2009 07:57
>> Subject: Re: client certificates unusable?
>>
>>
>> Kyle Hamilton wrote, On 2009-03-19 23:07:
>>
>>> My reason for the conservative time suggestions is because that's what
>>> banks tend to use (my bank times me out after 15 minutes of
>>> inactivity, as does my phone company, and my electric company, and
>>> PayPal, and...).
>>
>> But those are *minutes of inactivity*. SSL session lifetimes typically
>> do not take activity (or inactivity) into account. If you set a 10
>> minute lifetime, then 10 minutes later, that session will end, and you
>> must reauthenticate again. So, 10 minutes means reauthenticating 6
>> times each hour, 48 times per work day. :(
>>
>>> IE7 does have a "forget sessions" button. I'd like to see a
>>> reasonable thing implemented as well in Firefox.
>>
>> FF has had this feature for years.
>>
>> --
>> dev-tech-crypto mailing list
>> dev-tech-crypto@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-tech-crypto
>> --
>> dev-tech-crypto mailing list
>> dev-tech-crypto@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-tech-crypto
>>
> --
> dev-tech-crypto mailing list
> dev-tech-crypto@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-crypto
> --
> dev-tech-crypto mailing list
> dev-tech-crypto@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-crypto
>
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
