[foaf-protocols] some ssl + HTTP security-related design issues specific to webid protocol

peter williams home_pw at msn.com
Thu Dec 23 03:43:02 CET 2010

Here is a list of issues that come for webid protocols, due to the nature of
the SSL and (FOAF) documents.


1.       SSL for webid protocol..but not general HTTP encryption


AS discussed in the Google "optimization" discussion, SSL is an example of
what is termed an indirect authenticated key management handshake. Its
defined as having used the shared key to prove the other party (in pairwise
SSL profiles) has knowledge of it. One this is done, one has completed
authentication. Thereafter, one might leverage the derived keys to exchange
enciphered information for such as posting requests, or pulling documents.
Or, one might not bother. Data enciphered by the derived material within the
handshake protocol - used to confirm the knowledge rule - is not formally


There are 2 relevancies here: (1) SSL can be used purely as an
authentication mechanism, showing that identities have been "accepted"
merely by using the session-key-leveraging handshake protocol (where the
those particular derived keys are NOT by policy then used for further data
exchange), and (b) in good design, no party should encipher information
until it knows its peer has knowledge of the shared secret. Google's
optimization of https interferes with both benefits: the semantics of the
secure protocol definition, and prior restraint on ciphering until one has
evidence of consent to its use.


2.       Time


SSL has the option to use time in its handshakes - noting that time tends to
required synchronization with a common source. One should note that the time
exchange is typically not enciphered, leading to easy record keeping of "who
is exchanging time with whom"? SSL has the option to mask these times
exchanges (by having one handshake be peformed under the security context of
another, immediately preceeding it).


In the webid world, beyond the topic of part 1 above, we know there is a
necessary act of deferencing a URI  to obtain a document of some type. And,
we know that under the HTTP thesis, such documents are to be subject to
caching - a time-dependent process.


Now, in the caching world, time doesn't need to be carefully synchronized.
If used in SSL handshake, it has to be synchronized.


In the case that webid protocol ties its key management to the document
obtained upon URI dereferencing, there is a judgement to be made based on
time. one should be considering: are key management related triples (such as
key expiry?) time sensitive? The relationship and synchronization properties
of time in triples, HTTP headers, and SSL handshakes will need to be
considered, since the webid protocol (unlike https) does not depend on
inband key management.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.foaf-project.org/pipermail/foaf-protocols/attachments/20101222/8ce7bf27/attachment.htm 

More information about the foaf-protocols mailing list