I agree with Eve here, I think that the decision to be restrictive about the
subject was unnecessary. I certainly did not experience the confusion that
some thought might be created.
However we discussed this on several conference calls and F2Fs and several
votes were taken which I lost so I don't think we should reopen the issue in
last call.
Phillip Hallam-Baker FBCS C.Eng.
Principal Scientist
VeriSign Inc.
781 245 6996 x227
> -----Original Message-----
> From: RL 'Bob' Morgan [mailto:]
> Sent: Thursday, January 31, 2002 5:04 AM
> To: Hallam-Baker, Phillip
> Cc: OASIS Security Services TC
> Subject: Re: [security-services] The multiple subject issue
>
>
>
> On Wed, 30 Jan 2002, Hallam-Baker, Phillip wrote:
>
> > A statement can have exactly ONE subject that may be desribed by a
> > Name Identifier alone, OR a Name Identifier and subject confirmation
> > OR a subject confirmation alone.
>
> Thanks for clarifying this. I found the discussion of
> multiple subject
> names on the last conf call deeply puzzling because I was under the
> impression that we had agreed to the model you describe here,
> which makes
> concerns about the semantics of multiple subject names per statement
> simply go away because multiple subject names don't exist.
> It was this
> clarification we sought when discussing this at the last F2F and I'm
> hoping we have found it.
>
> The flip side of this is the claim, which I think Eve was
> championing on
> the last call, that multiple subject names in a statement
> would be a good
> and useful thing in some situations, and in particular that the Java
> "principal" concept needs this. While I'm not intimate with the Java
> model for this stuff, let me suggest that the expression of security
> properties and relationships among multiple named entities (eg, "the
> entity 'cn=Joe,ou=foo,dc=example,dc=com' with subjectConfirmation
> publickey XXX also has the name '' with
> subjectConfirmation
> kerbTGT YYY") is the sort of thing that can and should be
> supported either
> with authentication statement extensions with well-defined
> semantics, or
> with attribute statements. Having a single subject per statement will
> allow us to avoid this semantic quicksand for now and get our
> spec out the
> door.
>
> - RL "Bob"
>
>
