Re: On the need for presence service identifiers

"Peterson, Jon" <[email protected]> writes:

> More promising - I think we may be honing in on a few important
> points here.

Yes.  Things look more promising this morning.  It appears we agree
that a presence service identifier will only appear in the
subjectAltName of an X.509 V3 Certificate.  No other part of the
protocol will use it, and systems not using X.509 V3 Certificates will
never see it.  This means the only location in the CPIM document that
will need to be changed to support presence service identifiers is a
section on certificates that is X.509 specific, and states that a V3
certificate may be used to sign a notification request when the
subjectAltName contains either the target's presentity identifier or
the target's presence service identifier.

We disagree on the type of identifier.  You prefer the use of a DNS
name, and I prefer a URI.  Your argument for the use of a DNS name
follows. 

> The justification that I offered for this choice over a pres URI (even a URI
> of the form 'pres:domainname') was enrollment. Today, it is very common for
> mitre.org to possess a certificate for 'mitre.org'. If you go to a CA and
> ask for a site certificate, that are rules that dictate whether or not you
> will be issued that certificate that are well understood. There are no such
> rules or practices today (to my knowledge, anyway) for certificates bound to
> a 'pres' URI. It isn't clear that any CA would have proper policies to
> handle enrolling new parties into the PKI that would prevent bad guys from
> getting certificates.

The point of adding text to the CPIM document about presence service
identifiers is to define standard naming conventions for
subjectAltName's that relate to instant messaging and presences.  We
SHOULD be telling CA's how to do this so that everyone does it in an
interoperable way.

> Now, we all know that such policies could be developed, and so
> on. The question is, if there is something we could recommend to
> encode in the subjectAltName that works with existing CA practices,
> shouldn't we recommend it?

As stated above, we should tell CA's the syntax they should use for
presence service identifiers, so that everyone uses the convention.

Let me tell you why the inclusion of of a DNS name does not solve the
presence server identifier problem.  What a CA wants to do is have an
identifier that is specific to presence service.  Only its inclusion
in a certificate gives its owner the authority to sign and act in the
role of a presence service.  A DNS name can appear in an X.509 V3
Certificate for a variety of reasons, and a user may have one in their
certificate even when they are not approved to provide presence
service.

For this reason, I think a presence service identifier should be a
PRES URI whose scheme specific part contains only a domain name.

************

Let me conclude by describing a use for presence service identifiers
in a situation in which notification requests are not timestamped.

Assume the Widget Corporation has deployed a standards base
implementation of SIMPLE inside the company.  The company has enabled
SIMPLE's authentication mechanisms, which I gather, is
challenge/response based.

Inside the company, a few people are security conscious, so they have
X.509 V3 Certificates, but most employees can't be bothered.  The
company is not worried about employees spoofing each other.

The company's customers require that notifications that leave the
company be signed so they can authenticate them.  The company solves
this problem by adding a component to its firewall that wraps a
signature around any outgoing presence information that is not already
signed.  The customers know to accept this signature, because the
associated certificate contains the presence service identifier.

John



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