<!DOCTYPE HTML><html>
<head>
<meta name="Generator" content="Amazon WorkMail v3.0-4275">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<title>RE: Class 3 ssl certificate for SAML 2.0 federation</title>
</head>
<body>
<p style="margin: 0px; font-family: Arial, Tahoma, Helvetica, sans-serif; font-size: small;">Kunal,</p><p style="margin: 0px; font-family: Arial, Tahoma, Helvetica, sans-serif; font-size: small;"> </p><p style="margin: 0px; font-family: Arial, Tahoma, Helvetica, sans-serif; font-size: small;">The identity proofing in SAML as done by Shibboleth and most other interpretations is entirely by way of metadata. It's possible to include certificate validation by PKIX as part of that, but all that gains you in almost every deployment scenario is cost and the pain of rotating certificates.</p><p style="margin: 0px; font-family: Arial, Tahoma, Helvetica, sans-serif; font-size: small;"> </p><p style="margin: 0px; font-family: Arial, Tahoma, Helvetica, sans-serif; font-size: small;">This is because the certificate is in essence just a bag for an X.509 public key, while the metadata itself is the authoritative information about the provider. The information in the certificate can be used as a source of additional identity proofing, but it rarely is, so it's mostly just baggage. This is discussed in brief at:</p><p style="margin: 0px; font-family: Arial, Tahoma, Helvetica, sans-serif; font-size: small;"> </p><p style="margin: 0px; font-family: Arial, Tahoma, Helvetica, sans-serif; font-size: small;"><a href="https://wiki.shibboleth.net/confluence/display/IDP30/SecurityAndNetworking#SecurityAndNetworking-SigningKeyandCertificate" _src="https://wiki.shibboleth.net/confluence/display/IDP30/SecurityAndNetworking#SecurityAndNetworking-SigningKeyandCertificate">https://wiki.shibboleth.net/confluence/display/IDP30/SecurityAndNetworking#SecurityAndNetworking-SigningKeyandCertificate</a></p><p style="margin: 0px; font-family: Arial, Tahoma, Helvetica, sans-serif; font-size: small;"> </p><p style="margin: 0px; font-family: Arial, Tahoma, Helvetica, sans-serif; font-size: small;">You're not going to get much help from the original standards themselves, which deliberately left open the possibility of using PKIX validation or not, with the only real requirement be that you do something. A metadata interoperability profile was subsequently passed by the SAML standards committee with much more helpful language. See 2.5.1 and 2.6.1:</p><p style="margin: 0px; font-family: Arial, Tahoma, Helvetica, sans-serif; font-size: small;"> </p><p style="margin: 0px; font-family: Arial, Tahoma, Helvetica, sans-serif; font-size: small;"><a href="https://docs.oasis-open.org/security/saml/Post2.0/sstc-metadata-iop-cs-01.html" _src="https://docs.oasis-open.org/security/saml/Post2.0/sstc-metadata-iop-cs-01.html">https://docs.oasis-open.org/security/saml/Post2.0/sstc-metadata-iop-cs-01.html</a></p><p style="margin: 0px; font-family: Arial, Tahoma, Helvetica, sans-serif; font-size: small;"> </p><p style="margin: 0px; font-family: Arial, Tahoma, Helvetica, sans-serif; font-size: small;">Despite this, approaches to validation by implementation vary. You're mostly at the mercy of the implementations you're interoperating with. If they impose certificate validity requirements, you may find yourself doing a lot of arbitrary upkeep, but I see no reason otherwise to voluntarily impose this on yourself if you don't have a provider you need to interoperate with that has chosen to impose it as a requirement.</p><p style="margin: 0px; font-family: Arial, Tahoma, Helvetica, sans-serif; font-size: small;"> </p><p style="margin: 0px; font-family: Arial, Tahoma, Helvetica, sans-serif; font-size: small;">The upshot is that the binding of the key to the provider comes from the metadata, and only rarely using PKIX as a bridge. The keypair is the important thing and it's generated securely locally whether the certificate is self-signed or signed by John Hancock. You would in most cases just be paying a lot for the privilege of having to rotate certificates that contain largely unused, but vetted, data, frequently.</p><p style="margin: 0px; font-family: Arial, Tahoma, Helvetica, sans-serif; font-size: small;"> </p><p style="margin: 0px; font-family: Arial, Tahoma, Helvetica, sans-serif; font-size: small;"> </p><p style="margin: 0px; font-family: Arial, Tahoma, Helvetica, sans-serif; font-size: small;">Hope this helps,</p><p style="margin: 0px; font-family: Arial, Tahoma, Helvetica, sans-serif; font-size: small;">Nate.</p><p style="margin: 0px; font-family: Arial, Tahoma, Helvetica, sans-serif; font-size: small;"> </p><blockquote style="border-left:2px solid #b0b0b7; margin-left:5px; margin-right:0px; padding-left:5px">-----Original message-----<br /><strong>From:</strong> Kunal Shah<br /><strong>Sent:</strong> Monday, October 22 2018, 3:08 am<br /><strong>To:</strong> Shib Users<br /><strong>Subject:</strong> Class 3 ssl certificate for SAML 2.0 federation<br /> <pre style="white-space:pre-wrap; word-wrap:break-word">Hi,
For one of setups we are using SAML 2.0 federations. The CISO has made
a mandate that for all certificate requirements we use Class 3
certificates issued by third party CA.
I don't see any need for this. Especially when it is going to impact
the budget of our project. We are planning to submit an exception
request to the same. Can you please point me to some material that
helps me building my case?
I see SAML 2.0 specification. However, it does not mandate use of
Class 3 certificates, I am not finding any point that can help me make
my case stronger.
Regards
Kunal Shah
--
For Consortium Member technical support, see <a href="https://wiki.shibboleth.net/confluence/x/coFAAg">https://wiki.shibboleth.net/confluence/x/coFAAg</a>
To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net">users-unsubscribe@shibboleth.net</a>
</pre></blockquote>
</body>
</html>