Subject: Re: Small typo in UPN text?

From: "Paul B. Hill" <[email-masked]>
Date: Tue, 07 Mar 2000 10:57:56 -0500

Hi,

At 12:41 PM 2/27/2000 -0800, Doug Royer wrote:

>In:
>
>    2.5.1.  UPNs and Certificates
>
>
>    Note: If a server is validating data received via iMIP, if the
>    "ORGANIZER" or "ATTENDEE" property said (e.g.) "ATTENDEE;CN=Joe Random
>    :[email-masked]" then the "[email-masked]" part should be
>    checked against the altSubjectName field of the certificate, and the
>    "Joe Random User" part should be checked against the CN component of
>    the altSubjectName DN. This is so the "ATTENDEE" property couldn't be
>    munged to something misleading like "ATTENDEE;CN=Joe Rictus
>    [email-masked]" and have it pass validation. This validation
>    will also defeat other attempts at confusion.
>
>Had the ATTENDEE line had "User:" in the ATTENDEE lines:
>
>         "ATTENDEE;CN=Joe Random:User:[email-masked]"

Actually the typo is in "Joe Random:User:" it should have been "Joe Random 
User:", in retrospect this is confusing since "User" is also a key word. 
I'll change the examples in this section and others where the same problem 
occurs.

>         "User:Joe Random User"
>
>
>As "User:" is not part of ATTENDEE, I assumed that was a typo and
>I removed "User:".
>
>-Doug

---

From: "Paul B. Hill" <[email-masked]>
Date: Tue, 07 Mar 2000 19:54:29 -0500

At 01:03 PM 3/7/2000 -0800, Doug Royer wrote:

> > Paul,
> >
> > The IDENTIFY command is still in the CAP draft. Can you explain to Doug 
> why we
> > don't need this command anymore.
>
>I don't need an explanation, the list does. It has not seen one.

Hi,

(Note the IDENTIFY command is currently in section 2.6.2)

During the interim meeting there was discussion about removing the IDENTIFY 
command because SASL implementations should enable CUAs to specify an 
authorization identity (UPN) distinct from the authentication identity 
asserted by the client's (user's) credentials.

I was probably the major proponent of its removal. I've changed my mind. 
But request that the last paragraph of the current 2.6.2 section be 
modified. If you are interested please read on.

In general I think re-authenticating and using SASL's authorization 
identifier should be the preferred practice. However, in the case of 
server-to-server communications the removal of the IDENTIFY command from 
CAP would cause us to run into performance problems. The initiating server 
would have to constantly go back to the disconnected state, reconnect and 
re-authenticate. This is neither practical nor desirable.

Furthermore, there does not appear to be a requirement that every SASL 
implementation support a separate and distinct authorization identity. This 
means that CAP should have the capability in order to maximize 
interoperability.

I am still very worried about implementations that might abuse this 
feature. In general I don't think CUAs that typical end users have on their 
desktops should make this feature easily available.

What I really don't like about the current text of 2.6.2 is the last 
paragraph and the examples:

    The "IDENTIFY" command provides for a weak group implementation. By
    allowing multiple sets of authentication credentials belonging to
    different users to identify as the same UPN, that UPN essentially
    identifies a group of people, and may be used for group calendar
    ownership, or the granting of access rights to a group.

I don't think that this is a good path to go down. I would much rather see 
the last paragraph changed to:

The "IDENTIFY" command potentially provides for a weak group 
implementation. An implementation might enable multiple sets of 
authentication credentials belonging to different users to identify as the 
same UPN. Implementations SHOULD NOT use the IDENTIFY command to provide a 
group mechanism.

Paul