Re: [security-services-comment] XASP: Permitting use of Subject AltNames?

[ARI.KERMAIER@oracle.com]

Actually, SubjectAltName is messier even than that -- it's really a sequence of a choice of 8 different name formats plus otherName (OID-value pair). From RFC 3280 section 4.2.1.7:

   SubjectAltName ::= GeneralNames

   GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName

   GeneralName ::= CHOICE {
        otherName                       [0]     OtherName,
        rfc822Name                      [1]     IA5String,
        dNSName                         [2]     IA5String,
        x400Address                     [3]     ORAddress,
        directoryName                   [4]     Name,
        ediPartyName                    [5]     EDIPartyName,
        uniformResourceIdentifier       [6]     IA5String,
        iPAddress                       [7]     OCTET STRING,
        registeredID                    [8]     OBJECT IDENTIFIER }

   OtherName ::= SEQUENCE {
        type-id    OBJECT IDENTIFIER,
        value      [0] EXPLICIT ANY DEFINED BY type-id }

   EDIPartyName ::= SEQUENCE {
        nameAssigner            [0]     DirectoryString OPTIONAL,
        partyName               [1]     DirectoryString }

If there are some of these that are deemed desirable additions to the NameID formats defined in [SAMLCore], then maybe it would be appropriate to define individual URIs for them. But just allowing SubjectAltName might create more problems than it solves.

As for modifying the XASP spec to allow NameID formats other than X509SubjectName, that's likely to meet with considerable resistance from its original sponsors in US government who have implemented it and consider the profile details to be carved in stone at this point. From that perspective, the only reason for being of the XASP is to tightly specify exactly those constraints on the Attribute Query protocol/profile defined in [SAMLCore] and [SAMLProf].

::Ari


> Hi Dave,
> 
> On Wed, May 14, 2008 at 10:36 AM, Kemp, David P. <DPKemp@missi.ncsc.mil> wrote:
> >
> >  Allowing a certificate as a BaseID would at least provide protocol data
> >  to enable IdP-internal mapping based on SubjectAltName, so I wouldn't be
> >  against that.  But a standard for nameid-format:X509SubjectAltName would
> >  be better.
> 
> Well, a full certificate makes most sense for the use cases I have in
> mind, but if subjectAltName is better suited for your purposes, then
> by all means submit a profile along those lines.  That said,
> subjectAltName seems problematic in that the format is not
> well-defined.  A subjectAltName can be an e-mail address, an URI, or
> practically anything with a corresponding OID.  I'm not sure how
> useful such a name identifier would be, but I'll reserve judgment
> until you've had a chance to be more precise.
> 
> Tom