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] ISSUE: Format attribute for Issuer also



I wrote on 04 Mar 2002:

> I think the reasoning that justifies the "Format" attribute for Subject
> NameIdentifier applies equally well to Issuer, since Issuer names also
> will come in the same several standard formats as well as non-standard
> ones, and it would be useful for RPs to be able to distinguish these.  I
> note that this is consistent with RFC 2459, which specifies the use of
> GeneralName syntax for IssuerAltName too.
> 
> So I suggest (as an ISSUE) that the schema for Issuer be modified to
> permit the inclusion of the "Format" attribute for it too (sorry my schema
> skills are limited, so I can't suggest the mod).

This is now Issue DS-8-06.  There has been some discussion.  In the 
interest of closing issues expeditiously, I'm inclined to withdraw it.  

I think the interest here, in addition to flexible handling of Issuer
names, is in consistency between Subject and Issuer names, or at least not
having gratuitous inconsistency.  While I still think Issuer would be
better with some indication of format, I'm disinclined to define a
distinct "IssuerNameIdentifier" type that would have just a Format
attribute, or to say that Issuer should just be of NameIdentifier type and
hence also include NameQualifier, or to recast NameIdentifier type to be
able to separate NameQualifier and Format.

There was one comment in favor of changing Issuer and one against.  Unless 
someone else wants to argue in favor of changing it (and proposes a 
specific way of doing it, probably one of the above choices) then I 
suggest we close the Issue.

One off-list response I got to bringing up this Issue was "uh, what's
Issuer for anyway?" since protection of an assertion is done by means
outside of the assertion itself, and the identity of the asserting party
is effectively made via the protection method (xmldsig, TLS, etc) rather
than this field in the assertion.  This is a much deeper issue, and
probably needs to be addressed somewhere in our documents, perhaps in the
Security Considerations document.  But I don't have text to offer at this
point.

 - RL "Bob"





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


Powered by eList eXpress LLC