Re: e-mail encryption usage/application property for cert:Key

Thanks Bergi,

      That is a good issue you bring up. One could solve this
in a number of ways. One way would be to give the key a URL, so that
the e-mail could point directly to the key, that was used
to sign it, key1 in the example below.

  :me cert:key :key1 .
  :key1 cert:modulus ...

     The other way around brings up another issue: I want
to send someone an encrypted e-mail, but I don't know what is the
key they use for that purpose. There I think some way of defining
the usage of a key would do the trick.

   This also comes together with the issue of putting validity
times on keys, since one should not encrypt something with a key
that is no longer valid, and people also may wish to publish old
keys they used to have - for signature verification on older documents
I suppose.  

This last piece risks altering the way our verifiers are implemented 
though,  because now finding the cert:key relation is no longer enough, 
you also have to find if it has date stamps that are  valid. Essentially 
our key is no longer a mathematical object, it becomes a time slice of a 
mathematical object, and one has to do a little bit of temporal reasoning. 
If there is a risk of that temporal reasoning being done wrongly 
often  enough, then it won't be worth the effort of inserting it.
Which is why in that case I thought of introducing a different
relation in those cases such as cert:oldKey .

So back to the usage of the key. One could type the key itself, which
moves us away from the mathematical nature of the key, and kind of
feels a bit odd. It would be like saying:

    3 a NumberOfDoors .

So it is true that we have astronomical numbers for our keys and these
are very rare numbers (but then every number is rare, only appearing
once in the number sequence).  A clean relation would be one that relates
the user to the use he puts that key to.

   :me decryptionkey :key1 .

I think in rdfa now it is easy to put a number of relations from one 
thing to the same object, which means that typing these relations like
that is no longer weird.

  Just some thoughts.

	Henry


On 6 Feb 2012, at 00:18, bergi wrote:

> Danny Ayers ask on Google+ what's necessary to sign emails with your
> WebID using S/MIME. The discussion to the post was very interesting, so
> you may have a look at it [1].
> 
> I have extracted a smaller problem out of this discussion about key
> discovery, which is required if the email should be also encrypted. No
> matter how the WebID of the receiver is discovered, you don't know which
> key is used by the email program for decryption. A WebID Profile can
> contain more than one key. Some of them could be used by specific
> programs, others may be used temporary in an internet cafe. For the
> email encryption case we have a different scenario. Here a little
> overview what we have and what we need:
> 
> Client authenticates on a TLS service:
>  Known:
>    - WebID
>    - Public Key
>  Outcome:
>    - Public Key matches one of the keys in the WebID Profile
> 
> Client sends encrypted data to another client:
>  Known:
>    - WebID
>  Outcome:
>    - a list of Public Keys
>  Needed outcome:
>    - a Public Key for a specific application
> 
> I would propose a new property for cert:Key class to identify the Public
> Key in the second scenario. cert:usage or cert:application should be
> good candidates. To keep it open for other usages I would not limit the
> valid values via rdf:range, but we should define at least the email
> usage at the beginning.
> 
> This looks very similar to some X509 flags, but unlike these flags this
> property does not limit the usage of the key!
> 
> This topic may be a little out of scope for the current spec, but
> hopefully there is a simple solution and it's worth to show WebIDs
> possibilities.
> 
> [1] https://plus.google.com/u/0/112609322932428633493/posts/8NJLQecBwFe
> 

Social Web Architect
http://bblfish.net/

Received on Monday, 6 February 2012 14:33:22 UTC