RE: On the need for presence service identifiers

Just to be clear - I am not agreeing that a presence service identifier
needs to exist as a concept in CPIM. But in order to evaluate whether or not
it does need to exist, we need to understand what it is you are asking for,
and my responses in this thread have been an attempt to help flush that out.

On this issue of dNSName vs. uniformResourceIndicator as the subjectAltName,
I wonder if you really appreciate that certificates are not just chunks of
text - they are legal documents. They are an assurance by a provider that
they have followed some policy to ascertain the identity of the party to
whom the certificate is issued. Defining and following these policies is a
somewhat arduous process at a business process level. If we were to require
a PRES URI-based subject for the certificate, we would essentially be
guaranteeing that our security mechanism would not be implemented, at least
not in any reasonable time-frame. A dNSName-based proposal would work with
existing CA policies. I highly doubt that CAs would be motivated to offer
presence-specific certificates. This is not merely a matter of standardizing
something so that everyone uses the same convention - this is a choice
between something that works with existing CAs, and something that CAs
probably will not choose to implement. Being a CA is not a public service,
it's a business - just because the IETF says 'let there be PRES URI-based
certificates' doesn't mean that any CA will create the corresponding
policies and begin issuing them.

The whole concept of who is 'approved' to provide presence service is at the
root of this matter. I believe that the administrator of the namespace (the
owner of the DNS records, say, for mitre.org) gets to say what goes on in
their namespace (mitre.org). Why do you have the PRES URI
pres:[email protected]? Doesn't mitre.org issue you the username
'ramsdell'? Didn't they delegate you the domainname linus.mitre.org? If they
don't like what you're doing, can't they take both of those away? Don't they
choose which host gets to be www.mitre.org? A URI is just part of a
namespace, and such namespaces already have a concept of authority and
administration.

If you think that the certificate for 'pres:linus.mitre.org' should be held
by someone other than the holder of the certificate for 'linus.mitre.org',
then I'd be interested to hear what you believe the policies should be for
the distribution of PRES URI-based certificates.

I also have a few notes at the end of this message about your latest
example.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: [email protected] [mailto:[email protected]]
> Sent: Thursday, August 22, 2002 5:31 AM
> To: Peterson, Jon
> Cc: [email protected]; [email protected]
> Subject: 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.
> 

SIMPLE inherits the use of Digest authentication, S/MIME and TLS from the
core SIP specification. So challenge/response (Digest) is one possibility.

> 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.
> 

You say this is useful without timestamps... although clearly the replay
attacks you are usually complaining about could target this system as well,
right?

If this were a pure SIMPLE implementation, then using TLS to connect
Widget's SIP proxy sever to the company's customers would be a far better
option - it provides all of the necessary security properties and it relies
on the certificate of the proxy server (which contains no PRES URI, in any
event). It would even protect against replay attacks. There are a number of
reasons why it is a bad idea for intermediaries to tamper with the bodies of
SIP requests, even in a (probably misguided) attempt to add security - but
this is so SIP-specific that I hesitate to go into it in detail here.

In any event, I'm not sure I understand what this viewpoint this example is
supposed to support.

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



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