OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

saml-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [saml-dev] Same certificate for https and SAML signing


Hi Vasu Y,
Although Scott's reply covered everything I will just reply from the point of view of a "regular developer".

With CA-signed certs you have so much extra work to do to validate, and every step in that process is an area where a bug could be introduced; or you may miss a step. Both the introduced bugs and the missed validation are potentials for security vulnerabilities. And even if you get everything right (or the tool/library you are using gets everything right), as Scott says you are doing things in a non-standard way and using certs for something other than their intended use.
Off the top of my head, here are the things you have to do:
1. validate the signature and expiry/not-before dates for every cert in the chain
2. validate the name on the cert matches the SAML issuer (probably through configuration, i.e. a mapping of SAML issuer to name on cert)
3. ensure the root CA cert is trusted, e.g. in your store of trusted CA certs
4. check certificate revocation lists for every cert in the chain -- something almost nobody does

To be clear, I think the problem with CA-signed certs isn't so much the CA-signed vs. self-signed characteristic. Rather, the problem is the "CA-trusted" vs. pre-shared characteristic. That is, if you decide that all certs must be pre-shared and configured into your system in order to integrate with you, you can avoid all the above validation (except checking for expiry). The simple fact that the cert was present in your configuration (database/keystore/whatever), under the issuer name, means you can trust it.

Also, keep in mind that because of #2 above, even with a CA-signed cert you still have to pre-configure the "name on cert" (certificate subject) into your configuration, so why not just pre-configure the whole cert? I think this is what Scott is getting at -- there is no way to just trust the CA-signed certs completely because there is no standard way to map "name on cert" to a SAML issuer.

Note I'm not sure if/how SAML Metadata comes into the picture here, as we've never used it.

michael lucas  |  Senior Software Developer  |  Great-West Life 




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]