Presence notification security - catching up
Graham Klyne <[email protected]>
| Newsgroups | gmane.ietf.impp |
|---|---|
| Message-ID | <[email protected]> |
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. (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. (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? (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.) #g ------------------- Graham Klyne <[email protected]> [reminder: [email protected] for non-technical discussions, please]