Introduction
InCommon accepts X.509 server certificates from the following certificate providers:
- Self-Signed
- InCommon CA
With a justification, InCommon may also accept certificates from:
- Any third-party CA
InCommon accepts this broad array of certificates because the signer of the certificate has no relevance to the trust model that secures the interactions of federation participants using supported technologies like SAML. Allowing self-signed certificates simplifies the work of participants that may be required to join multiple federations, or who support local systems that are not enrolled in the federation.
Third party certificates are discouraged because they can create interoperability issues in certain cases, and lead to configurations that mistakenly rely on the certificate signer to establish trust in the certificate. Where necessary they can be accomodated because of constraints imposed on participants from other sources.
Requirements
InCommon sets the following security and trust parameters around certificates that are included in federation metadata:
- RSA keys with a minimum size of 2048 bits
- No expired certs accepted; expired certs may be retained in the metadata at the discretion of the participant, but may cause interoprability issues with non-Shibboleth software
In the case of certificates used for SSL server authentication:
- A CN or subjectAltName matching the intended hostname(s)
- Either omission of the TLS Client and Server Authentication extensions, or inclusion of the Server Authentication extension.
In the case of certificates used for SSL client authentication:
- Either omission of the TLS Client and Server Authentication extensions, or inclusion of the Client Authentication extension.
The SSL requirements MAY be left to the discretion and responsibility of federation participants; InCommon merely highlights the requirements that are likely to cause problems if not met.
Policy
Domains in cert will be approved by InCommon?? If the TAC as a group thinks, no, john will then take it to Steering and legal to discuss the liability implications of publishing domains that have not been approved. [SC: No, we shouldn't check any certificate content other than what's listed above or can be used to identify cryptographic flaws (e.g. weak keys)]