[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: WebSign. was: [pki-tc] Groups - Draft Minutes PKI TC August 17 2005
Anders, see below.
Anders Rundgren wrote:
> Arshad,
> I would indeed like to talk to you over the phone.
> Note: I cannot post to the list anymore.
>
This is the main number of the hotel where I will be staying
in Tampere; I will let you know which day will work best for
me on Monday:
HOTEL - CUMULUS KOSKIKATU HOTEL
TELEPHONE: 358-3242-4111
> It seems that you have already jumped into the mine-field known as
> "requirements" when you state that XML encryption is a must.
>
> Although encryption is indeed a requirement, I do not fully understand
> why and how message encryption is to be used in an on-line signature
> scenario. That is, who's public key is to be used? Why would not https,
> which is typically used for encrypting the rest of the session suffice?
>
I am interested in getting XMLEncryption into this capability
for two reasons, Anders:
1) If we're going to put in sufficient effort to make the crypto
capability available for form-signing, then it makes sense to
have the ability to do encryption too, so that this problem
does not have to be revisited later;
2) I am talking to some people who are more interested in the
ability to encrypt web-transactions - not for protecting
data-in-transit, but for protecting data-at-rest - but with
some interesting requirements for who is authorized to view
the decyrpted data that make pure back-end solutions complex
to implement. I intend to write these up and share it with
with the list in due course.
> These differences are in my opinion directly related to the fact that there
> currently is little common ground for what we actually are dealing with
> which is one important reason for having a conference call. My own
> requirements ("preferences" may be a better word at this humble stage),
> are based on schemes already used by millions of people in the EU.
>
> If we continue down "specification lane", I have another thing for you that may
> seem small, but is actually the opposite and that is how you actually invoke the
> signature mechanism in the client environment. Essentially five methods are available:
> 1) The most common is through an proprietary API, often in the form of
> an ActiveX control. Windows only
> 2, Use a Java(r) applet. Makes Microsoft leave the table
> 3) Through a web redirect operation to a local "web-server" doing signatures
> outside of the browser. Poor integration but workable
> 4) Extend EcmaScript/JavaScript
> 5) Use a specfic MIME type
>
I view option #4 as the optimal one. Towards this end, I'm
trying to work with people who have influence in the Mozilla
foundation over the crypto capabilities, who may make this
possible with the appropriate justification. I recognize
that this is a non-trivial task, but over the long term,
this appears to be the most feasible one. I would welcome
hearing other opinions on this.
> My "input specification", WASP (Web Activated Signature Protocol) uses the
> latter alternative as it gives a uniform GUI, simple browser integration and the
> most efficient operation as "the whole signature request thing" can be put in a
> single HTTP response. The latter also means that embedded images are always
> loaded at the same time as the rest of the document is shown.
>
When you say "latter alternative" which one are you
referring to, Anders?
> Proof-of-concept Demo
> Note: requires no downloading of code whatsoever.
>
> WASP can also be used in a"portal mode" where it does signatures
> in the same way as SAML is used for authentications. I encourage
> you to try out the demo as it will give some real input to what at
> least I mean by "Web Signing".
>
> http://sid.the-demo-bank.com/eGovernment
>
> Citizen code: 19750710-1518 (see in grey right-down in the login form)
> One time code: 6-8 arbitrary characters
>
> There are some icons with 01010 that you can click to get the actual
> XML behind the requests.
This does look interesting; I am curious how this functions
without any downloaded applet/plug-in. Is this using a
proxy signer? The XML appears to be using the XMLSignature
standard, but I cannot verify if it is the current version.
We would definitely welcome your input in the SC, as you do
have more experience with this in Sweden that we do in the US.
So, I hope you will join the SC formally so we can get this
rolling.
Arshad
P.S. Why can you now post to the mailing list? Are you not an OASIS
member?
>
> BankID would then in a local (browser) implementation be replaced
> by a dialog window with similar contents although you would not use
> passwords but specify sigining certificate (in the portal mode the
> certificate is residing in the portal only).
>
> regards
> Anders
>
> ----- Original Message -----
> From: "Arshad Noor" <arshad.noor@strongauth.com>
> To: "Anders Rundgren" <anders.rundgren@telia.com>
> Cc: "Sabo, John T" <John.T.Sabo@ca.com>; "Stephen Wilson" <swilson@lockstep.com.au>; "Steve Hanna" <shanna@funk.com>; "PKI
> Application Guidelines" <pki-guidelines@lists.oasis-open.org>
> Sent: Friday, August 19, 2005 01:48
> Subject: Re: WebSign. was: [pki-tc] Groups - Draft Minutes PKI TC August 17 2005
>
>
> Anders,
>
> A conference call is definitely feasible; however, I hope it
> can wait till the week of Aug 29th - I'm traveling to Europe
> next week on business. (Actually, I'm going to be in your
> timezone I think - Tampere, Finland. If you would like to do
> a one-on-one call next week, I could send you my hotel number
> by e-mail when I get there, and we could talk one evening).
>
> If you have any documentation - aside from the one mentioned
> by John Sabo in the minutes - please feel free to send it to
> the pki-guidelines list so that everyone in that group can
> benefit from it.
>
> your presentation describes the problem appropriately, and
> hints at the solution; however, the solution is not described
> in there. I trust you have that in other documents.
>
> I would encourage you to join the Applications Guidelines
> subcommittee and give us the benefit of your thinking. I've
> done a reasonable level of research, but am stymied by having
> to pay my bills and unfortunately, must work now & then :-).
>
> There are some requirements that I have identified, and some
> things I'm doing in the background to get some browser vendors
> aligned with us. For example:
>
> * The subcommittee must focus on encryption as well as signing,
> since we cannot afford to revisit this problem later; better
> to solve it right the first time when people are focused on
> security;
>
> * I have chosen to focus on XMLSignature and XMLEncryption as
> the means for accomplishing this. There is a tremendous
> amount of momentum around XML and we want to win the hearts
> and minds of the developers who're building sophisticated
> web applications. Without XML, you will never get them.
>
> Secondly, XMLSignature and XMLEncryption are final standards,
> with a standardized Java API and reference implementation
> available for the former, and the latter imminent (through
> the JSR process);
>
> * I've just had a conversation with someone who has a fair
> amount of influence with the Mozilla crypto group, and he is
> keen to get requirements that will help him build the case
> to get this done;
>
> So, all in all, there is some work happening - albeit slowly -
> around this effort. If you have a different perspective on
> this, you should get actively involved now so we can move this
> forward.
>
> I tend to do most of my work through e-mail - haven't seen the
> need for a conference call with the SC yet; but if that's
> preferable, I will schedule one early next month.
>
> Arshad Noor
> StrongAuth, Inc.
>
>
> Anders Rundgren wrote:
>
>>John,
>>This sounds OK to me.
>>It IS hard to delineate the problem but I suggest a conf call
>>with "PKI app subcom" if possible, to sort of see where we stand
>>on various issues including legal stuff. Another thing which I
>>consider extremely critical is how to confront the browser
>>vendors. I.e. a standard that does not get deployed has no
>>value IMO. Even if it is brilliant.
>>
>>BTW, I consider my own work simply as "input" to a TC. It
>>would be up to a TC to define the actual scope, technology
>>etc. However, I think it is better to start with some information
>>and suggestions than going to an empty table. It is even nice
>>to have something to say no to!
>>
>>I have information on quite a range of Web sign signature initiatives.
>>These are all European as it seems that Web sign is currently
>>primarily a European concern as well as activity. The reason
>>for that is that in Europe PKI has a strong consumer/citizen bias,
>>making the web is the natural channel. In the enterprise, custom
>>applications are more frequent and these do not depend as much
>>on standards as the web does.
>>
>>best
>>Anders
>>
>>----- Original Message -----
>>From: "Sabo, John T" <John.T.Sabo@ca.com>
>>To: "Anders Rundgren" <anders.rundgren@telia.com>; "Stephen Wilson" <swilson@lockstep.com.au>; "Steve Hanna" <shanna@funk.com>;
>>"Arshad Noor" <arshad.noor@strongauth.com>
>>Sent: Thursday, August 18, 2005 14:50
>>Subject: RE: WebSign. was: [pki-tc] Groups - Draft Minutes PKI TC August 17 2005
>>
>>
>>Anders,
>>
>>Thanks very much. I have been very guilty in not following up sooner,
>>but have the usual work related reasons. It is not for lack of interest!
>>
>>Should the first step, given the role of the TC and our subcommittees,
>>perhaps be for you to work with Arshad as part of the Applications
>>Subcommittee to clearly delineate the problem space and identify current
>>work underway to develop standards for Web signatures, including your
>>own proposal? In addition to the technical work, a piece of this
>>potentially could include any laws or legal opinions related to "what"
>>is being signed (e.g., as suggested in your "dry signature" vs. "Wet
>>Signature" example below), although that is perhaps optional work for
>>someone on the committee.
>>
>>Based on Arshad's report at yesterday's meeting, it appears that we at
>>least need to understand the current landscape, and then consider moving
>>forward with a new TC under the PKI MS umbrella.
>>
>>Let me know what you think, and I'm also interested in Arshad's views.
>>
>>Best regards,
>>
>>John
>>
>>------------------------------------------------------------------
>>John T. Sabo, CISSP
>>Director, Security and Privacy Initiatives
>>Computer Associates International
>>2291 Wood Oak Drive
>>Herndon, Virginia, 20171
>>USA
>>Phone: +1 703-708-3037
>>Mobile: +1 443-629-6198
>>------------------------------------
>>This e-mail message is for the sole use of the intended recipient(s) and
>>may contain confidential and/or privileged information. Any unauthorized
>>review, use, disclosure or distribution is prohibited. If you are not
>>the intended recipient, please contact the sender by reply e-mail and
>>destroy all copies of the original message.
>>
>>
>>
>>-----Original Message-----
>>From: Anders Rundgren [mailto:anders.rundgren@telia.com]
>>Sent: Thursday, August 18, 2005 3:36 AM
>>To: Stephen Wilson; Steve Hanna; Arshad Noor; Sabo, John T
>>Subject: WebSign. was: [pki-tc] Groups - Draft Minutes PKI TC August 17
>>2005
>>
>>Hi Guys,
>>I saw in an earlier minutes that you had planned to contact me for
>>further discussions regarding my two requests. I'm ready :-)
>>
>>I noted that Arshad has looked on XFORMS as a way to introduce Web Sign.
>>Rather than debating this, I would say that this is one option among
>>many.
>>
>>Personally, I work with schemes that follows how existing Web services
>>work which basically is as follows:
>>1. The user in a service provider defined way creates "transaction data"
>>2. The user at some point decides that he/she is ready and in a service
>> provider defined way accepts an aggregated "transaction request"
>>I call this "dry signatures", which is signing frozen data that the
>>server (service provider) already has a copy of (=waiting on
>>acknowledgment).
>>The actual document format then becomes of no importance except that it
>>of course must be readable. That is, you can sign HTML with embedded
>>images, PDFs, JPEGs or whatever a browser can display. What you sign is
>>then really only hashes of the shown document rather than sending back
>>the document back again.
>>
>>The opposite to this is signing forms with edit fields, radio buttons
>>etc.
>>I call this "wet signatures". This requires that the document + data
>>itself is sent back and hopefully input validation is fully performed
>>locally, otherwise a signature could be rejected due to syntax error
>>etc.
>>
>>As you hopefully see, there is an ocean of interesting questions and
>>design options that begs for some answers.
>>
>>regards
>>Anders Rundgren
>>Principal Engineer
>>RSA Security, although here acting on my own
>>
>>----- Original Message -----
>>From: <john.t.sabo@ca.com>
>>To: <pki-tc@lists.oasis-open.org>
>>Sent: Wednesday, August 17, 2005 19:33
>>Subject: [pki-tc] Groups - Draft Minutes PKI TC August 17 2005
>>(oasispkitc-minutes08172005[draft 1].doc) uploaded
>>
>>
>>Draft minutes from August 17 PKI TC meeting for review.
>>
>> -- Mr John Sabo
>>
>>The document named Draft Minutes PKI TC August 17 2005
>>(oasispkitc-minutes08172005[draft 1].doc) has been submitted by Mr John
>>Sabo to the OASIS Public Key Infrastructure (PKI) TC document
>>repository.
>>
>>Document Description:
>>Draft minutes of August 17 2005 OASIS PKI TC meeting for review.
>>
>>View Document Details:
>>http://www.oasis-open.org/apps/org/workgroup/pki/document.php?document_i
>>d=14087
>>
>>Download Document:
>>http://www.oasis-open.org/apps/org/workgroup/pki/download.php/14087/oasi
>>spkitc-minutes08172005%5Bdraft%201%5D.doc
>>
>>
>>PLEASE NOTE: If the above links do not work for you, your email
>>application
>>may be breaking the link into two pieces. You may be able to copy and
>>paste
>>the entire link address into the address field of your web browser.
>>
>>-OASIS Open Administration
>>
>>
>
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]