Usage/application property for cert:Key

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

Received on Sunday, 5 February 2012 23:19:34 UTC