Re: On trusting presence intermediaries

Graham Klyne asked me questions that relate to presentity set
identifiers.  Let me respond to his questions, and then move on.  
I promise to be polite.

Let me remind you of the kind of trust one gets using digital
signatures.  PGP does not specify a policy for establishing trust.
Users have a public-key ring, which contains trusted certificates they
decide to enter.  If the user receives a messages with a certificate
that is not in the public-key ring, they must find some other means to
decide if the certificate should be trusted.

If a user receives a message with an X.509 Version 1 Certificates,
they can trust the certificate if they trust the certificate that was
used to issue it.  Assuming that the user has a valid issuing
certificate, the question is, exactly what level of trust has been
established.

Consider the situation for email.  Suppose you have the root
certificate from widget.com, and you receive a message from
[email protected] that is signed using a valid X.509 Version 1 Certificate
with a distinguished name containing a common name field of "John
Doe".  In reality, John Doe's email address is [email protected], and
your reply will go to the bad guy that forged the email's 'From'
header.

For email, this problem is addressed by appending the string
"/[email protected]" to John Doe's common name field.  The
certificate authority is telling you that you can trust this
certificate for email as long as you can prove it issued it, and the
'From' header contains [email protected], otherwise, do not trust it.

This is an instance of the well accepted security principle of least
privilege.  One should always give subjects as few privileges as
possible, so that the extra ones are not available for abuse.

For instant messaging, we want to allow certificate authorities to
issue certificates that allow their owners to use them when they
perform only a limited set of functions.  For example, we would like
to issue a certificate to a person for signing their instant messages,
and only their messages.  For example, John Doe should be the only
person that can sign anything using a certificate with a subject
alternative name that contains im:[email protected].

While this issue is straightforward for instant messaging, presence
presents problems.  In my opinion, a certificate should contain
subject alternative names that identify subjects in an actual system,
not the ones in the model defined in RFC 2778.  For example, if one
server is signing all presence information that comes from one domain,
I believe it should have one identifier that allows it to perform
this, and only this function.  There is nothing new here, we've
already been over this.

Graham seems to suggest that we could use the hierarchy implied by
certificate chains to specify certificates that can be used to sign
for all the subjects that own certificates it issued.  I believe that
hierarchy is meant to be used for another purpose.  It allows
certificates to be issued at different locations without the sharing
of private keys.  Suppose the Widget Corp. has an office in Boston,
and one in Yokohama.  There would be one trust anchor, the one used to
issue a CA certificate in each city.  You trust a certificate issued
in Boston because you have a secure way of obtaining the trust anchor,
and both the certificate, and your copy of Boston's CA certificate
validate.  In short, I cannot imagine putting IM specific subject
alternative names in a certificate that is not at the leaf of a
certificate chain.

John

Graham Klyne <[email protected]> writes:

> At 11:18 AM 8/23/02 -0400, John D. Ramsdell wrote:
> > > (d) there is debate about the trust model(s) to be supported, which
> > > might include: (i) endpoint presentity is trusted to sign
> > > notification, and/or (ii) a presence service acting on behalf of the
> > > endpoint presentity is trusted.  I can imagine scenarios in which
> > > either form is useful to deploy, and even for mixing between them.
> > > From what has been quoted in the list debate, I think the requirement
> > > is to support the end-to-end case (i).   (Using X.509, I think it is
> > > also possible given (i) to support (ii) on a per-domain basis -- I'll
> > > expand on this if it seems necessary;  mainly, I think we need to
> > > agree/reaffirm the trust model.)
> >
> >Please expand.
> 
> OK, I have two points to make at this time:
> 
> (1) I think you have made a credible case that it is important for an
> intermediary to be able to sign a presence notification, namely when
> the presentity drops offline and "closed" notifications must be sent.
> (The notifications would contain a PIDF timestamp, so they cannot be
> pre-signed by the presentity.)
> 
> (2) Is this possible using X.509?  I understand that X.509 conveys trust my providing a chained sequence of certiricates that ends in a trusted root -- 
> specifically a root that is trusted by, and whose public key is known
> to, the relying party.  Would it not be possible for a presentity to
> use its key to sign a certificate that allows some other party -- in
> this case a presence service -- to use its separate certificate to
> sign notifications for the presentity?
> 
> E.g.
> 
>    Trusted-root
>      --certifies-> domain-admin for all-domain-functions
>        --certifies-> presentity for
> presence-service-operations-using-given-ident
>          --certifies-> presence-service for
> presence-service-operations-using-given-ident
> 
> I'm dimly aware that X.509 distinguishes between certification
> authorities and other authorities, which would appear to make this
> scheme problematic, but I understand there is also provision for
> self-signed certificates that allow non-CAs to issue certificates --
> I'm guessing that could be used for the final certification stage.
> 
> Alternatively, the domain authority could issue certificates that (a)
> allow the presence service to sign on behalf of the presentity
> (i.e. using the presentity's ID as an altSubjectName), or (b) allow
> the presentity to operate as a limited CA to issue such certificates.
> 
> #g
> 
> 
> -------------------
> Graham Klyne
> <[email protected]>



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