RE: WebID-ISSUE-26: [WebID Spec]

The paraphrase talks about the insides of the SSL handshake protocol. I was trying to say something a little different. But, moving beyond CGI interfaces, and the very notion of peer trust, we get to perhaps build our conceptual framework some more.
 
Once the handshake has happened (usually in a socket provider), the CGI "application" may wish to do super-processing of trust processes (some type of which the socket has already completed, completely satisfying the state machine dealing with the SEF known as "peer entity authentication"). The socket provider doesnt know what the application will now do with the client cert that it has released; its not part of the TLS state machine (which is now in complete state, no further processing required).
 
Look at it that the CGI is an observer of the handshake, not a part of it. It gets now to impose its own "trust representation" on the now negotiated TLS tunnel, even though TLS the handshaking has already applied one trust representation already (probably PKIX), when securing its handshake for its own assurance claims.
 
For example:
 
PKIX processing in the midst of handshaking occurs, as implemented by the SSL handshake or two ...that completes by raising the usual CGI or servlet event.  An HTTP request's FORM post is from IP address X authenticated using the earlier handshake, say SSL to CGI consumer. The facts about IP address, and form post bindings to teh client's IP addresses, is assured to be true.
 
CGI processing using the entities client cert (a PKIX-conforming cert remember) says: but that entity is on my site's CRL and thus I reject the form post. Im love the fact you tell me its from IP address, but certs bound to "malware" IP address are exactly what I put on my private CRL - where I defined malware-ness
 
What just happened? the authority known as the CA issues one CRL ("relied upon" by the handshake "closely" to assert a security truth in SEF land). But the CGI/severlet app super-imposes a second CRL, one issued not by the CA authority but some other party (perhaps itself). This latter CR makes "relying community" representations about the validity of the cert, which the "issuing" authority CRL implies is valid (in its eyes). And, the part managing this third party-CRL makes and distributes it to others with OR without the consent of the CA, making references of course to the CA's "managed-names", and making meta-statements that may contradict what the authority asserts.
 
What we have now done - if you are with me - is understood the notion of a Validation Authority. The notion and role of the "VA" is partly exposed by IETF PKIX WG (in the form of the OCSP protocol), but they focus on the ensuring a CA as "master-authority" always has the power to "authorize" such third party "VAs" to make references, and then issue/assert meta-statements about validity/reliance. Here, we might not want to enforce or project that IETF authority-relationship apparatus (or perhaps use the cert onotlogy to do it). Its designed to constrain WHO can and WHEN anyone can issue meta-statements about certs - and linked foaf profiles in the webid case, by extension.
 
Perhaps this really fits more in the revocation and lifecycle management topic.
 > To: public-xg-webid@w3.org
> From: sysbot+tracker@w3.org
> Date: Wed, 2 Feb 2011 13:51:44 +0000
> Subject: WebID-ISSUE-26: [WebID Spec]
> 
> 
> WebID-ISSUE-26: [WebID Spec]
> 
> http://www.w3.org/2005/Incubator/webid/track/issues/26
> 
> Raised by: Henry Story
> On product: WebID Spec
> 
> On 2 Feb 2011, at 00:51, Peter Williams wrote:
> 
> > So what really matters, I implore, is focus of the design here is 
> > on the properties of the handshake ( a well defined SEF), not the cert. 
> > The cert is just one side-effect output thereof - upon which one then 
> > can do exactly what you did - fashion a means of searching the graph 
> > of profiles to chain together trust points that talked to each other 
> > "about" the subjects of certs (URIs).
> 
> Ok, attempting to paraphrase the above. 
> 
> When the TLS client responds with a Certificate or CertificateURL message it then needs to follow that by a CertificateVerify message where it proves that it owns the private key of the public key, that was (previously) named by a URL [1] or passed by value (SSLv3 default). 
> 
> The public key is found one way or another. In future extensions it could be found in the remote Profile document in one of a number of content negotiated formats, as suggested in ISSUE-19, and so there may be no need for X509 at all.
> 
> The spec text may need to take account of the possibility of the TLS v2 client_certificate_url extension [1], but without making it overly complicated to read.
> 
> This would be a minimal TODO arising out of ISSUE-19.
> 
> [1] http://tools.ietf.org/html/rfc4366#page-12
> 
> 
> 
>