On trusting presence intermediaries

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]