W3C home > Mailing lists > Public > www-xkms@w3.org > January 2005

RE: XKMS about done...and what (if anything) next?

From: Hallam-Baker, Phillip <pbaker@verisign.com>
Date: Thu, 27 Jan 2005 10:26:12 -0800
Message-ID: <C6DDA43B91BFDA49AA2F1E473732113E010BEF77@mou1wnexm05.vcorp.ad.vrsn.com>
To: "'Stephen Farrell'" <stephen.farrell@cs.tcd.ie>, "Www-Xkms (E-mail)" <www-xkms@w3.org>

This is good news.

I think that there are important things to be done with XKMS, but we
probably need to focus on those rather than working on the XKMS core. We now
have a mechanism for key management and distribution that can plug into any
PKI there is. What we now need to pay attention to is making use of that
mechanism in applications.

The most urgent problem is email security. The phishing gangs are running
riot and we need to get some basic authentication infrastructure in place.
In the short term the approach is going to be to use the DNS for lightweight
key distribution as in Domain Keys. I think this is a good starting point
(Domain keys is after all a key centric PKI), but it would be a shame if it
was also the ending point.

What I would like to see is domain keys becoming the first step on a
deployment ladder that takes us to a fully secure email infrastructure.

Step 1 Domain based authentication.
	Simple authentication of email to a domain name, so mail from
microsoft.com can be verified as really coming from microsoft.com. This
scheme would support multiple keys per domain but would not define a key
registration system.

Step 2 Per user keying using XKMS
	Support for the whole key lifecycle through XKMS. Allow end users to
register their own signature keys.

Step 3 Opportunistic encryption support
	Add in support for encryption using a choice of either S/MIME or PGP
as the message encapsulation format. The encryption key would be provided
either through the DNS or through XKMS. Eventually we would need to support
DRM type encryption formats that provide for more comprehensive control.

Step 4 Intelligent deduction of security requirements.
	Make it possible for either an email application or an edge server
to deduce the necessary level of security for a particular communication
using authenticated assertions (e.g. using SAML).


Throughout the security protocol would support both the edge and the end
implementation models. So it would be possible to enforce an enterprise
security policy through an edge server. 



> From: www-xkms-request@w3.org 
> [mailto:www-xkms-request@w3.org] On Behalf Of Stephen Farrell

> Hi all,
> 
> During today's call, those present agreed with Jose's mail
> that we're about done with XKMS interop (and I echo Jose's 
> congratulations and thanks to the implementers!). The minutes 
> will reflect this decision/agreement (so yell if you disagree!).
> 
> This means that we're (Jose, Shivaram and I) now going to
> start the process of getting the XKMS spec promoted to PR
> in the W3C process. I'd expect that to take a couple of
> weeks for us to tidy up documents, and then some more weeks
> to do W3C process stuff, maybe a month or so in total, all 
> going well. If you, or your company, care about this for 
> product, marketing or PR reasons then you might want to take note.
> 
> Lastly, this means that unless people want to suggest 
> re-chartering this group/activity to do some other work it'll 
> effectively go into hibernation fairly soon now. So, if 
> there's something related to the XKMS activity that you'd 
> like this group to tackle, please make suggestions now, so we 
> can discuss them on the list and if there's anything that 
> gets consensus we can see if re-chartering along the relevant 
> lines is possible. (If you think this group ought to simply 
> hibernate, no harm saying that either!)
> 
> Regards,
> Stephen.
> 
> PS: I [1] should probably have included loads of links
> in this mail, but I [1] didn't:-)
> 
> [1] http://www.cs.tcd.ie/Stephen.Farrell/
> 
> 
> 
Received on Thursday, 27 January 2005 18:26:28 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:31:43 UTC