RE: WebID-ISSUE-22: Key Pair Revocation / WebID reset [WebID Spec]

This is a scoping issue - as certs are (formally) out of scope of SSL, in TLS spec terms and the underlying (SSL only) patent controlled by IESG. What is normally termed "key management" or "certificate lifecycle management" is distinct from enabling the now-keyed entities to establish secure channels (https) or secure flows (webid protocol , or https' as I want to keep calling it).
 
 
Here we need to focus on the profile doc, not the cert. The cert is a way of "getting browsers to do the security primitive" called the SSL handshake. its nothing more. Arguably, the cert communciates the webid, and cert enrollment at least ties the webid URI to the public key, in a self-signed blob.  One NICE thing about having ClientHello communicate the webid is ...it DEPRIVES the wolrd of PKI the excuse to try yet again to sell client cert lifecycle management processes, forcing them to focus on the profile doc instead.
 
here is my current wish list for an skeleton ideal scheme (due PURELY to the discusions held here, which I find stimulating).
 
1. clientHello communicates webid claim
 
2. EE cert for client auth is ephemerally  minted and (self-)signed by browser, thereby authenticating clientHello and its webid claim
 
3. new "cert type" defined per the TLS spec with help from IETF, in which that ephemeral EE cert is NOT ASN.1 on the wire but an xmldsig-signed datum. Other certs in the SSL message's client cert chain (if any) retain their ASN.1 value, to bring valuable legacy interoperability to bear while ensuring ensuring we do not project legacy formats further.
 
4. client cert support in CGI and page javascript APIs support client certs in ASN.1 and xmldsig, to drive new generation of apps.
 

 
> Date: Tue, 1 Feb 2011 12:01:47 +0000
> From: nathan@webr3.org
> To: henry.story@bblfish.net
> CC: public-xg-webid@w3.org
> Subject: Re: WebID-ISSUE-22: Key Pair Revocation / WebID reset [WebID Spec]
> 
> Henry Story wrote:
> > On 1 Feb 2011, at 11:54, WebID Incubator Group Issue Tracker wrote:
> > 
> >> The WebID Protocol does not currently define how users should react to lost or stolen key pairs, the equivalent in other technologies would be certificate revocation or "password reset".
> >>
> >> The action(s) a user should take to "disable" the validity of a key pair, or the methods implementers should provide to cater for this, must be defined by the protocol.
> > 
> > It is in fact very easy to do: just remove the public key from the Profile Document, and the next SSL connection should be invalidated.
> 
> indeed, but this also ties in with for instance ISSUE-21 ..
> 
> > This ties into a few other issues: how long should the profile document represenations be valid for? And when should the server go back to the remote server instead of using information in the cache?
> 
> .. and ISSUE-23 , and ISSUE-18 (cache wss or xmpp?) - many of these 
> are inter-related, and the resolution of one depends on the resolution 
> of the other(s).
> 
> Best,
> 
> Nathan
> 
> 
>