- From: Hallam-Baker, Phillip <pbaker@verisign.com>
- Date: Thu, 27 Jan 2005 10:26:12 -0800
- 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