RE: [security-services-comment] XASP: Permitting use of Subject Alt Names?

["Kemp, David P." <DPKemp@missi.ncsc.mil>]

Tom,

The problem with using DNs as subjectNames is that they usually contain
too much information.  DN syntax isn't the issue - in principle a proper
Directory Information Tree could be used.  But the reality is that most
CAs do not issue DNs linked to a proper DIT, they throw in whatever the
customer wants, including attributes like email addresses and common
names.

Assume the data model:

Entity/Principal (person, physical device, "legal person" i.e.
corporation)
  |
  v
Identity (relationship of an entity to an IdM, e.g. employee, customer)
  |
  v
DN (identity may have multiple DNs due to common name changes, email,
...)
  |
  v
Credential (DN used in multiple credentials: signing/encryption,
renewal)


If a full certificate is used as a Subject, attributes are tied to that
specific certificate and die (or need to be remapped) when the
certificate is renewed.  My goal is to be able to move in the opposite
direction, up the chain, so that authorization attributes are tied to an
identity regardless of how many DNs exist for that identity.

Yes, it would be possible for an IdP to have an internal mapping
mechanism that would take a full certificate from the query message and
extract whatever information is needed to form a subject name.  But it
would be preferable to define a standard mapping so that the subject
name appears explicitly in the query protocol.  That way vendors have
something to develop and test against, and customers have a standard to
point to in their requirements.

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.

Dave   


-----Original Message-----
From: Tom Scavo [mailto:trscavo@gmail.com] 
Sent: Monday, May 05, 2008 2:02 PM
To: Kemp, David P.
Cc: security-services-comment@lists.oasis-open.org
Subject: Re: [security-services-comment] XASP: Permitting use of Subject
Alt Names?

This is yet another reason to define a new BaseID type that carries
the complete certificate.  This was discussed briefly on saml-dev
awhile ago.  I proposed the details of such a change to the OGF
AuthZ-WG but they weren't interested since it meant basically starting
the specification process from scratch, and so it was a matter of
(bad) timing for them.

FWIW, I'd be interested in exploring this further.

Tom Scavo
NCSA

On Mon, May 5, 2008 at 12:49 PM, Kemp, David P. <DPKemp@missi.ncsc.mil>
wrote:
> The SAML Attribute Sharing Profile for X.509 Authentication-Based
>  Systems, 28 March 2006, says that the <AttributeQuery> <Subject>
element
>  must contain a <NameID> with the value of the Subject DN with the
>  nameid-format of X509SubjectName.
>
>  Some certificates may contain null Subject DNs, and for others there
is
>  not a 1-1 correspondence between an entity identified by a unique ID
>  contained in the Subject Alternative Name and varying DNs that may
also
>  be issued to that entity contemporaneously or over a period of time.
>  For example, FIPS 201 identifies subjects using the Federal Agency
Smart
>  Card Number (FASC-N) contained in SAN, RFC 4043 specifies a permanent
>  identifier intended to be stable regardless of changes in DNs, and
>  non-person entities such as devices or service providers may be
>  identified using IPv6 addresses, RFC 4122 UUIDs, or other UIDs
contained
>  in SAN.
>
>  Has there been any discussion of updating XASP to permit requesting
>  attributes using a stable entity identifier contained in SAN?  If
not,
>  is there a forum for XASP where such a change proposal could be
>  discussed?
>
>