Subject: RE: [security-services-comment] XASP: Permitting use of Subject Alt Names?
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:firstname.lastname@example.org] Sent: Monday, May 05, 2008 2:02 PM To: Kemp, David P. Cc: email@example.com 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? > >