OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: RE: [security-services] The multiple subject issue

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:rlmorgan@washington.edu]
> 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 'joe@example.com' 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"

Phillip Hallam-Baker (E-mail).vcf

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC