Re: Presence service identifiers

At 10:14 AM 7/26/02 -0400, John D. Ramsdell wrote:
> > It seems to me that the presence service is implicitly that for the
> > domain of the presentity -- the presentity identifier indicates a
> > service, which is the same service for different presentities in the
> > same domain.
>
>To allow signing presence services to prove only they are allowed to
>use an given identity, they must have an identity no one else can
>use.  For strong end-to-end authentication, it is critical that
>principals identify only one subject.  See the other note I sent to
>this list today for details.

OK, I read through that.  Let's see if I'm separating the right principle 
(sic) from the details...

First, what you propose:  (a) move details of the principal whose presence 
information is provided into the <presence> structure, replacing 
'entityInfo' -- previously this was the target in the <notify> 
element;  (b) make the source of the <notify> element be the presence 
service that provides the information.  So what was:
[[
           <notify watcher='pres:[email protected]'
           target='pres:[email protected]'
           transID='1234'>
           <presence entityInfo='http://www.example.com/fred/'>
           <tuple destination='im:[email protected]' status='open'
           />
           </presence>
           </notify>
]]
becomes:
[[
           <notify watcher='pres:[email protected]'
           source='pres:[email protected]'
           transID='1234'>
           <presence entity='pres:[email protected]'>
           <tuple destination='im:[email protected]' status='open'
           />
           </presence>
           </notify>
]]

Hmmm... I'm not sure:  the DTD in the revised document doesn't match that.

(I must confess, I'm not entirely recollecting what purpose was previously 
served by 'entityInfo' in the original document, but I think it may have 
been a hook for providing additional information about the entity whose 
presence information is provided.  I can't offhand think of a reason that 
it's loss would be a problem.)

The goal seems to be to allow the authenticated entity to be separate from 
the authorized entity?  The certificate (via alternate subject name values) 
provide the chain of authority?  Thus, the signing identity may be 
different from the identity of the subject (principal) that is authorized 
to perform an operation on the object?

And I think you are saying there are pertinent security reasons that 
require this separation to be possible (at least, if the presence service 
is doing the signing on behalf of a subject)?

(Leaving aside signing) in your model, the 'source' entity is simply 
authorized to submit a notify operation to the watcher object entity?

And if I'm understanding correctly, one advantage of your proposal is that 
it means the same authorization framework applies to both IM and presence 
notification?

But, I'm sorry to say, I'm still not getting it.  I think this paragraph 
might need some work:
[[
      The CPIM protocol has been designed so that the 'From' header of
      an instant message or a presence notification can be used as an
      alternative name for the request's originator.  When using X.509
      V3 Certificates [?], these alternative names can be bound to a
      public key by including them in the certificate's Subject
      Alternative Names.  Clients and servers receiving signed requests
      with an X.509 V3 Certificate, can determine if the sender is
      allowed to place the given alternative name in the 'From' header
      of the request.  When employed, this check prevents spoofing by
      limiting the use of an alternative name to only the possessor of
      the certificate's private key.  In secure applications, this
      check should be employed whenever the 'From' header names a
      trusted entity.
]]

It's not clear to me who is meant here by the "request's originator", and 
what the From header is an alternative to.  Would it change the meaning 
significantly if you just said:
[[
The CPIM protocol has been designed so that the 'From' header of an instant 
message or a presence notification identifies the request's originator.
]]
?

I think the text dealing with what protocol element identifies what would 
usefully be separated from discussion of X.509 certificates.  To understand 
this properly, I think I'd need to understand how the authorization (access 
control) model works independently of any authentication mechanism.

At this point, I've just re-read your longer message - I think I'm getting 
closer to understanding but I still think the text needs improving.  I 
think that giving a clear (and brief) discussion of authorization (access 
control) in terms of the from: header, and completely separately discussing 
the use certificates and other paraphernalia to authenticate/validate the 
from: header would be helpful here.

I find myself in a peculiar position here:  I think I find your suggested 
changes are reasonable, but I'm still not fully convinced I understand them 
so I cannot be sure.  Hence this  picking over the wording ahead of 
formally agreeing with the intent.

#g

-------------------
Graham Klyne
<[email protected]>



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