Re: Presence notification security - catching up

Graham Klyne <[email protected]> writes:

> Catching up and reviewing the debate on notification security
> (identities and certificates and timestamps), I think I discern the
> following:
> 
> (a) there is agreement that an X.509 certificate subjectAltName value,
> or equivalent if different certificate form is used, is sufficient to
> identify the signer, and a separate copy of this same identifier in
> the envelope is not really needed.

Yes.

> (b) there is some dispute about whether a timestamp for presence
> transfer is needed separately from a timestamp for when the
> information was generated.  I have not seen a compelling case that the
> extra timestamp over and above that already in PIDF is needed.

I replied elsewhere to this.

> (c) there is some debate about the form of signing certificate
> identifier (dnsname vs URI).  A concern I see is that a particular
> domain may wish to delegate authority for different functions.  For
> example, a certificate relating to authorization to view restricted
> web pages may be issued to a different entity than authority to
> provide presence information.  Therefore, some means is needed to
> distinguish different certificates associated with a domain -- URI is
> one way to do this, but doesn't X.509 provide attribute fields that
> indicate what a cert can be used for?

I believe there is agreement on using a URI in subjectAltNames for
naming presentities and instant inboxes.  There is a disagreement on
the identifier in a subjectAltName of a certificate that is allowed to
sign for all presentities with a common domain name, and as to the
need to allow this kind of certificate.

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

> #g

John



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