[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ietf-pkix
Subject:    Re: Random PKI critiques [was: Rationales for CA clearance constraints]
From:       "Anders Rundgren" <anders.rundgren () telia ! com>
Date:       2008-10-30 17:16:20
Message-ID: 64A60A2591CD469ABB9838D9AAEC4011 () AndersPC
[Download RAW message or body]


Tim's statement regarding JVM is indeed correct and actually you
have to *install* the applet (I.e. accepting a signed software)
which doesn't work well in some environments.

I also wonder if Microsoft would be terribly interested in establishing
Java as a web signature standard (although we are almost there...).

Regarding HTML5 and signatures, I recently received a note from
one of the core developers who said they had tabled that item.
IMHO that was the right thing to do, because before progress
can be done, the integration of signatures in information systems
must be specified otherwise it won't deliver.

If somebody wonders what this is about I can give you a hint:
In a browser-session a "signature" today means hitting an OK
button or similar while being shown a static view of something
(purchase, doctor appointment, end-user agreement etc.) which
means that the user-view is just a presentation not the actual transaction.
Actually, the user-view is not even a presentation of a transaction,
but a transaction *request*; the transaction itself is *optionally*
performed *after* receival of the OK.  IMHO, a web-browser
signature scheme should be aligned with this notion although there
surely are people who object to that since this has few if any
simularities with signed e-mail.  OTOH; On-line <<>> off-line.

Anders

----- Original Message ----- 
From: "Scott Rea" <Scott.Rea@Dartmouth.EDU>
To: "Timothy J. Miller" <tmiller@mitre.org>
Cc: "Anders Rundgren" <anders.rundgren@telia.com>; <swilson@lockstep.com.au>; <ietf-pkix@imc.org>
Sent: Thursday, October 30, 2008 14:37
Subject: Re: Random PKI critiques [was: Rationales for CA clearance constraints]


G'day Tim,

I appreciate your perspective - see my responses inline...

Regards,
-Scott

Timothy J. Miller wrote:
> Scott Rea wrote:
>
>> Anders Rundgren wrote:
>
>>> The Java applet etc. solution you refer to is in fact the kind of 
>>> stuff I
>>> (rightly or wrongly), refer to as proprietary.  
>
>> I'm not sure I would call Stephen's solution proprietary - from a 
>> browser perspective (which I believe is what was started out talking 
>> about) java is supported quite healthily across the spectrum. 
>
> I think Anders' point is when you do this you're not really in the 
> browser any more, you're in the JVM.  That puts us in the mobile code 
> arena, which invokes all kinds of paranoia in some environments.
>
> What Anders is asking for is a standard invoke PKI operations via 
> standard markup.  E.g., something like <form 
> enctype="application/pkcs7-mime" cmstype="enveloped-data"> and <form 
> enctype="application/pkcs7-mime" cmstype="signed-data"> would be very, 
> very powerful to have.
OK, I can appreciate that - I have had to deal with my share of client 
paranoia in my time. I am 100% behind your standard mark-up suggestion - 
HTML5??
>
>>                                 One issue is a standard way to access 
>> private keys which are stored in multiple keystores - but I think the 
>> later versions of java available in major browsers do a pretty goos 
>> job of that these days.
>
> This is still a PITA for anything other than software keystores.
>
>> I thought PKCS11 was pretty standard in this space...
>
> Yes, but making even this work isn't trivial for the vast majority of 
> users.  While *I* can load a module into NSS in a heartbeat, my wife 
> wouldn't be able to do so.  In a controlled deployment environment 
> this is less of a problem, but for any uncontrolled environment (e.g., 
> trying to support a community of retired employees) it's a serious 
> problem. And when you start talking cross-platform, oy vey...
So here at Dartmouth we have been working on a library that we hope will 
trivialize this for most folks - libPKI - ref : 
https://www.openca.org/projects/libpki/
>
>> Most that I have talked to who understand the ROI of going paperless 
>> are quite interested in anything that saves them time & money.
>
> Do they understand the hidden costs of archiving records in a 
> paperless environment?  :)
This is not a hidden cost - perhaps sometimes forgotten cost by parties 
involved, but there is also arguments for positive ROI in this aspect 
also. In fact, many projects have been undertaken to address just this 
aspect (convert paper records to electronic for storage purposes only) 
for just that reason of the available benefits of doing so.
>
> -- Tim
>
>

-- 
Scott Rea
Director, HEBCA Operating Authority
Dartmouth College Sr PKI Architect
Peter Kiewit Computing Services
Dartmouth College
HB 6238, #058 Sudikoff
Hanover, NH 03755

Em: Scott.Rea@Dartmouth.edu
Ph#(603) 646-0968
Ot#(603) 646-9181
Ce#(603) 252-7339 

[prev in list] [next in list] [prev in thread] [next in thread]