[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