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

[peter williams]

Here is another idea, leveraging crypto properties of SSL to the nature of
the semweb specifically.

 

Let's address the observation that the central difference between https and
the proposed webid protocol, for the browser-only category of trust
providers, is: the key management (certs) are inband to the SSL handshake in
https, and out of band in webid protocol. 

 

So, how can we extend the SSL handshake to cover those external
PPDs/documents whose public keys must be verified when handling the messages
of the SSL handshake protocol?

 

Well, we already discussed the core technique in the previous memo, using in
RSA-OAEP a now parameterized H(w), where type(w) isa claim isa webid isA URI
hasa scheme == 'https'  This at least ties the protocol run to a particular
document instance.

 

In military systems, folks have long tagged encryption ciphertexts with
usually hidden tags, known as security labels. That is: this subset of
messages in an SSL record is topsecret/SI, whereas the other is
restricted/FOUO. Other subsets within the record are usually enciphered
noise (or deception plaintexts.) that exist mostly to just break up the
structured relationship between ciphertext and plaintext. For APDUs, dynamic
compression is also negotiable in SSL and when used in combination with data
encipherment the tokenising compression method adds in a dynamic codebook.

 

We might now put several of these ideas together, focused on the finished
messages of the SSL handshake exchanges. These are best encrypted using a
stream cipher negotiated by the changeCipherSuite message (and exist to
prove certain crypto-secrets are known to the other party(s)).

 

Well, before encrypting these finished msg plaintexts (which are small),
perhaps apply a padding scheme (based on OAEP). Again, the idea is to
exploit plaintext awareness. The padding of the respondent's finished msg
might use a parameterized H(Ws)  (where Ws is the server's webid). Or, the
bytes of Ws in encoding X might be used where 0s are used conventionally
when preparing G (or G(Ws) now). Or, if one wants to ensure that client MUST
have obtained the current respondent's FOAF card before starting the webid
protocol, once again one might use a H(Wr) in the originator's finished
message padding, where Wr comes from the peers' FOAF cards. 

 

Obviously, there are lots of potential variants, applying the flexibility of
finished messages and parameterized H() and G() such as: time-attached to
triples, quad values attached to named graphs, random numbers assigned to
named graph statements, and then names and hashes that include data from the
DNSsec naming record or server cert naming record.

 

Now the nice thing about such a minor modification the SSL handshake is that
it applies to any RDF graph, not just FOAF cards. Assuming that FOAF however
is asserting semi-trustworthy propositions, SSL + OAEP is basically
providing probabilistic authentication that adapts to the real world.

 

Now, formally, one is not using RSA-OAEP at this point. One would be using a
more generalized case of OAEP "padding", treating the Mac of the SSL
integrity channel over the finished messages as the one-way function that
protects the pad bytes, where the seqnum and the mac keys from the
connection's security association are the trapdoor release values. 

 

 

 

From: peter williams [mailto:home_pw at msn.com] 
Sent: Saturday, December 25, 2010 9:10 AM
To: 'foaf-protocols at lists.foaf-project.org'
Subject: RE: [foaf-protocols] some ssl + HTTP security-related design issues
specific to webid protocol

 

.

OAEP <http://en.wikipedia.org/wiki/Optimal_Asymmetric_Encryption_Padding>
was the grand-daddy of this topic area, but it's the _application_ that VISA
made that we might  learn from. We might be able to apply the design
principles the Set team used in designing application-specific crypto
primities to the webid protocol.

.

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.foaf-project.org/pipermail/foaf-protocols/attachments/20101225/ce0dcf47/attachment-0001.htm