Re: Notification authentication -- more things left out of the PI DF draft

Wayne,

It is unclear to me how XML Digital Signatures helps the problem at
hand.  There are various approaches to attaching a signature to
content.  The CPIM-MSGFMT document shows an approach commonly used in
email.  My guess is that you know how to make XML Digital Signatures
perform the same role.  I am willing to believe you, however, my
message was aimed at addressing a different problem.

Recall that the goal is to let clients and servers make access control
decisions for notifications based on the identity of the originating
presence server as described in the 'From' header of the notification.
A client or server may choose to simply trust the contents of the
'From' header of every notification, and make access control decisions
based on it.  In this case, no digital signatures are required.

Alternatively, a client or server may designate a set of presence URIs
as suspect.  When a client or server receives a notification that
claims it is from one of these suspect URIs, it can require that the
originator of the request prove it is identified by the presence URI
by including a digital signature, and a certificate that links itself
to the contents of the 'From' header.

In many SIMP deployments, such as the one at Strong Resolve, all
presence URIs are suspect, so all unsigned notifications are ignored.

Perhaps I misunderstood your message.  Please respond with more
details if possible.

John

"Carr, Wayne" <[email protected]> writes:

> Since pidf allows extensions from any other namespace (in several places),
> XML Digital Signatures can be used in what is available already in the
> current draft.
> 
> > -----Original Message-----
> > From: [email protected] [mailto:[email protected]]
> > Sent: Thursday, May 16, 2002 6:03 AM
> > To: [email protected]
> > Cc: [email protected]; [email protected]
> > Subject: Re: Notification authentication -- more things left 
> > out of the
> > PIDF draft
> > 
> > 
> > Let me spell out in detail how the PIDF draft can be changed to be
> > supportive of digitial signatures.  It turns out that little need be
> > done.  The only change that really must be made is that the section
> > titled "Wrapping 'application/cpim-pidf+xml' Data" that was present in
> > draft version 2 should be added back with one simple modification.
> > The description of the 'From' header should be vague enough to allow a
> > signing presence server the ability to place a presence URI in that
> > header that does not name the PRESENTITY of the contents.
> > 
> > Consider using this text:
> > 
> > 5.1.1. The 'From' header
> > 
> >    The 'From' header contains a presence URI that names the origin of
> >    the PRESENCE INFORMATION.  Any application compliant to this
> >    specification MUST recognize the 'From' header.
> > 
> >    The contents of the 'From' header may differ from the presentity
> >    attribute of the <presence> element in the presence document.  This
> >    header is needed when the presence server explicitly states the
> >    publisher regardless of the content of presence documents, or when
> >    the presence server is signing content.
> > 
> > Once this change is made, the Security Consideration section could be
> > amended to include text something like:
> > 
> > 6. Security Considerations
> > 
> > ....
> > 
> > The CPIM Presence Information Data Format provides a SUBSCRIBER means
> > of identifying and authenticating the PRESENCE SERVICE that is
> > supplying notifications using digital signatures.  The use of both
> > digital signatures and the PIDF provides a protocol with a strong
> > mechanism to meet the requirement for authentication stated in
> > [RFC2779, Section 5.3.3].  Failure to provide some mechanism to
> > authenticate notification requests makes a SUBSCRIBER vulnerable to
> > being spoofed by a PRESENCE SERVICE or other entity.
> > 
> > A SUBSCRIBER MAY make access control decisions based on the presence
> > URI in the 'From' header of a notification request, and the existence
> > of a valid signature.  To ensure that the 'From' header identifies the
> > signer, a signed request SHOULD include a certificate that binds it to
> > the presence URI in the 'From' header.  For example, when using X.509
> > Version 3 Certificates [X.509V3], the presence URI in the 'From'
> > header SHOULD be one of the certificate's Subject Alternate Names.
> > 
> > .... [ Added Reference ]
> > 
> > 
> > [X.509V3]
> >    R. Housley, W. Polk, W. Ford, and D. Solo, "Internet X.509 
> > Public Key
> >    Infrastructure Certificate and Certificate Revocation List (CRL)
> >    Profile", RFC 3280, April 2002.
> > 
> > ....
> > 
> > John


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