Presence service basics

I feel overwhelmed again.  Rather than responding to the many messages
in my inbox, let me observe that I think there are hidden assumptions
people are making that are causing confusion on this topic.  Let me
try to expose the assumptions that I think I may be making, and
thereby clarify my position.

In this note, let me adopt the convention that a word in all caps is
to be interpreted as defined in RFC 2778.  Thus the word PRINCIPAL
means a "human, program, or collection of humans and/or programs that
chooses to appear to the PRESENCE SERVICE as a single actor, distinct
from all other PRINCIPALS".

To discuss the issues around authentication, we must adopt some basic
terms from computer security.  In particular, I will use the term
subject to refer to a person or a service that invokes operations on
objects.  

Subjects may be known by many identifiers.  In computer security
circles, the term principal is often used for a subject's identifier,
but to avoid confusion, let me call one of these identifiers a subject
name.

Subjects possess private keys.  One of the reasons I must define some
terms is because RFC 2778 does not have a term for the things that
possess private keys.  In particular, both PRINCIPALS and PRESENCE
SERVICES may possess private keys.

RFC 2778 presents a model for presence service in which there are
three kinds of operations and two kinds of objects.  Objects are
either PRESENTITIES or WATCHERS.  A subject may apply the subscribe
operation to a PRESENTITIY.  Since we are not addressing subscription
authentication now, I'll ignore this operation.  A subject may apply a
notification operation to a WATCHER.  Finally, a subject may apply an
update operation to a PRESENTITY.  This is used to change the PRESENCE
INFORMATION in a PRESENTITY.  RFC 2778 does not name this operation,
but the diagram in Fig 6 shows a human updating a PRESENTITY via a
PRESENCE USER AGENT.

Certificates provide subjects with names.  When used with digital
signatures, subjects can prove they are authorized to use the name.
As long as a subject protects its private key, no other subject can
demonstrate that they may use this name.

X.509 Certificates provide a subject with something called a
Distinguished Name (DN).  In the example from message

   http://www.imppwg.org/ml-archive/IMPP-WG/200208/msg00007.html

the Goose Dog's DN is

   C=US, ST=MA, L=Bedford, O=The MITRE Corporation,
   CN=Kato the Goose Dog/[email protected]

X.509 Version 3 Certificates provide a subject with alternative names.
Goose Dog's alternative names are:

   X509v3 Subject Alternative Name: 
       URI:im://[email protected], URI:pres://[email protected]

Let me describe how many organizations assure that private keys are
matched with the appropriate subject when the subject is a person.

The person requests a certificate, and when the certificate is made by
the certificate authority, visits the people that distribute
certificates.  The person shows a picture ID, and receives a floppy
that contains the certificate, the private key, and probably the
certificate authority's root certificate.  The person installs the
private key in a protected area on a machine they can physically
protect, and then places the floppy under lock and key.  The private
key should never leave the machine.  The certificate will be
distributed, and is often made available to all with an LDAP server.

A reason I have explained this processes in such detail is to address
the issue of who signs PRESENCE INFORMATION.  If a person signs it,
then it must be done via a PRESENCE USER AGENT on a machine over which
the person has physical control, so that the private key is available.
It is unreasonable to assume this machine will be constantly available
to distribute PRESENCE INFORMATION, so PRESENCE INFORMATION signed by
a person cannot be modified when the person turns of their machine.

The only alternative is to have a service sign PRESENCE INFORMATION.
A service can sign PRESENCE INFORMATION when it changes, or when it is
requested.  I hardly makes much difference to the service.  In both
cases, it must possess the private key.

If a service has the ability to modify PRESENCE INFORMATION, than it
must be able to sign it.  For example, if a user goes off line without
updating their PRESENCE INFORMATION, one would hope that the service
would detect and modify the PRESENCE INFORMATION to reflect the user's
change in status.  In summary, it is trivial to timestamp notification
requests except in the case in which people sign PRESENCE INFORMATION.
Surely it is wrong to forbid services from providing this information
just because some PRESENCE INFORMATION is signed by people.

Let me change the topic to Subject Alternative Names.  Let me describe
how certificates with Subject Alternative Names are often distributed.
The certificate obtained with a physical visit I described above is
called one's identity certificate.  It usually has no Subject
Alternative Names other than an Email address.  As shown in the Goose
Dog's certificate, the Email address may also be placed in the Common
Name (CN) field of the subject's DN.  This is an ugly hack to make up
for the fact that Version 1 certificates do not contain Subject
Alternative Names.

Jon Peterson, this part is for you.  To obtain an application specific
certificate, encrypted Email can be used with the identity
certificate.  For instant messaging, one would send an encrypted
request for a new certificate that duplicates most fields in the
original certificate, but adds the person's INSTANT INBOX and
PRESENTITY identifiers as Subject Alternative Names.  Application
specific certificates are easily created and distributed once identity
certificates have been distributed.

In a previous note, I said the following about a presentity set
identifier:

    The identifier names the set of presentities that are identified
    by PRES URI's that share the same domain name part.  I think this
    name is more in line with RFC 2778.  A person or service that
    possesses an X.509 V3 Certificate with a PRES URI in its
    subjectAltName can sign for the named presentity.  A person or
    service that possesses an X.509 V3 Certificate with a presentity
    set identifier in its subjectAltName can sign for any presentity
    that is named by an element of the set.

The final point I would like to make is that the _only_ thing a
presentity set identifier does is allow a subject to have an infinite
number of subject names.  It gives a subject the authority to use any
PRESENTITY identifier that shares its domain name.  There is nothing
more to it.

John



  [reminder: [email protected] for non-technical discussions, please]