Subject: [pkix] Need for a SAML identity extension?

From: Stefan Santesson <[email-masked]>
Date: Fri, 04 Nov 2011 14:40:58 +0100

Here is something that I'm actually surprised to not have seen people
screaming for before.

But now I have come across a legitimate case where I need to issue a
certificate holding an identity that I have obtained from a SAML assertion.
AND some applications will need to recover that SAML identity from the
certificate at some point.
And just following standards, I'm left with a number of non-attractive
solutions.

The use case is electronic signatures. SAML does not cover this
functionality, so thus I need to create a signing cert holding the asserted
identity, which is captured from a SAML assertion.
In case of problems I need to recover that SAML identity in order to find
the signer through the IdP that issued the assertion.

PKI standards has put the bets on a small number of identity attributes,
which has lead to overloaded semantics. The most clear case is the
serialNumber attribute, but there are more.
SAML assertions have a much more open attitude to identity attributes which
can be much more freely defined with a lot more accurate semantics.

So if I want to assert such identity in a certificate, where and how do I
store it?

Do I convert it to the traditional subject name attributes?
Do I try to specify the original semantics using the RFC 3739
semanticsIdentifier ?
Or do I translate them to traditional subjectName attributes for backwards
compatibility AND then put the original SAML attributes in a new SAML
Attribute extension.

Well, from a development perspective, the last option is absolutely the
easiest to handle. Then the cert would pass all legacy code when validated
and when it reaches the code that needs the SAML attributes, then it would
just get them from the new extension.

Have others encountered the same issue?
How did you solve it?

Is there a need for a new extension here?

/Stefan

---

From: Jürgen Brauckmann <[email-masked]>
Date: Fri, 04 Nov 2011 15:20:07 +0100

> certificate at some point.

The GridShib project did considerable work in this area. Mission
statement: "Bridging SAML/Shibboleth and X.509 PKI for campus and grid
interoperability".

http://gridshib.globus.org/

http://dev.globus.org/wiki/SAML_in_X.509_Validation

http://gridshib.globus.org/docs/gridshib-saml-tools-0.3.0/readme.html

Hope that helps,
  Juergen

---

From: Stefan Santesson <[email-masked]>
Date: Fri, 04 Nov 2011 15:37:39 +0100

Thank you,

Very interesting indeed. I see they solved this by putting the whole SAML
assertion (or a reference to it) in a cert extension.
That might be a bit more complicated than what was looking for, but may
very well be the appropriate solution in the end.

/Stefan

---

From: Trevor Freeman <[email-masked]>
Date: Fri, 4 Nov 2011 20:55:20 +0000

Hi Stefan,

The problem you describe is not unique to X.509 and SAML as SAML has the same issues with itself as there are scenarios where a STS may issues a token based on another SAML token. This is known as Claims transformation and it is a common practice. When the new token is issued it may contain the other tokens - a progress known as "stapling".  Stapling is not common today as the relying parties' software is not mature enough to process the stapled data yet.

I don't see your example as changing the CA model. Today we trust the CAs to follow their CSP to validate the information included in the certificate. The fact that the CA got the information from a SAML token, vs. a driving licensee vs. a passport is of no interest and would not change my perception of the certificate. We don't have any granularity of good or bad data in the certificate - it is all treated the same based on the issuance policy.

The CA will have to reconcile the likely difference in validity for the SAML token vs. the certificate. Why would a CA put data into an object with a binding typically measured in months based on data from an object with a binding typically measured in hours? How would the CA know if the STS refused to issue a new token halfway through the lifetime of the certificate - what then?

Overall I would suggest you define a new SubjectAltName and stop there. The CA validated the data before it included it in the certificate. If the RP trusts the CA, they trust that process.  If the RP wants specifics about a specific certificate, then can take it up with the CA.

Trevor

From: [email-masked] [mailto:[email-masked]] On Behalf Of Stefan Santesson
Sent: Friday, November 04, 2011 6:41 AM
To: [email-masked]
Subject: [pkix] Need for a SAML identity extension?

Here is something that I'm actually surprised to not have seen people screaming for before.

But now I have come across a legitimate case where I need to issue a certificate holding an identity that I have obtained from a SAML assertion.
AND some applications will need to recover that SAML identity from the certificate at some point.
And just following standards, I'm left with a number of non-attractive solutions.

The use case is electronic signatures. SAML does not cover this functionality, so thus I need to create a signing cert holding the asserted identity, which is captured from a SAML assertion.
In case of problems I need to recover that SAML identity in order to find the signer through the IdP that issued the assertion.

PKI standards has put the bets on a small number of identity attributes, which has lead to overloaded semantics. The most clear case is the serialNumber attribute, but there are more.
SAML assertions have a much more open attitude to identity attributes which can be much more freely defined with a lot more accurate semantics.

So if I want to assert such identity in a certificate, where and how do I store it?

Do I convert it to the traditional subject name attributes?
Do I try to specify the original semantics using the RFC 3739 semanticsIdentifier ?
Or do I translate them to traditional subjectName attributes for backwards compatibility AND then put the original SAML attributes in a new SAML Attribute extension.

Well, from a development perspective, the last option is absolutely the easiest to handle. Then the cert would pass all legacy code when validated and when it reaches the code that needs the SAML attributes, then it would just get them from the new extension.

/Stefan