The PKIX engines (type="PKIX", type="StaticPKIX") this Trust Engine evaluate certificates against "key names" identified in metadata and then against a set of PXIX validation rules either embedded in a metadata extension or configured locally/statically. It is a superset of the older ShibbolethTrustEngine.
| Table of Contents |
|---|
Experience has shown that this approach is significantly more complex than the ExplicitKeyTrustEngine, and it is not recommended for most deployments.
...
Attributes
Common Attributes
Name | Type | Default | Description |
|---|
type type | string | Required | Plugin type name. |
Specific Attributes (StaticPKIX only)
Name | Type | Default | Description |
|---|---|---|---|
verifyDepth | integer | 1 | Length of CA chain to permit. |
certificate | local pathname | Optional path to a file with one or more CA certificate to trust. | |
checkRevocation | "off", "entityOnly", "fullChain" | "off" | Controls the behavior of CRL checking by the trust engine. If omitted or set to "off", no CRLs are used at all. The other options require that at least one CRL be available and will fail the check otherwise. The "fullChain" option requires that a CRL be available for all untrusted certificates in the validation path, otherwise only a CRL for the end entity certificate is required. |
Child Elements
Common child Elements
Name | Cardinality | Description | |
|---|---|---|---|
<KeyInfoResolver> <KeyInfoResolver> | 0 or 1 | Advanced plugin interface for mapping | |
Specific Child Elements (StatixPKIX only)
Name | Cardinality | Description | |
|---|---|---|---|
> | 0 or 1 | A credential resolver plugin to use to load the CA certificate(s) to trust | |
Validating Signatures
This engine is predicated on the assumption that the actual signing key isn't known ahead of time. Therefore, the signature MUST carry keying material (in the form of X.509 certificates) inside an accompanying <ds:KeyInfo> element inside the signature/message.
...
The following <ds:KeyInfo> children can be resolved into key names without additional plugin support:
<ds:KeyName>
The following names from the certificate being validated are used to find a name that matches one of the key names:
subject DN in reverse/LDAP comma-separated syntax, with or without spaces (see RFC 2253)
subject CN
any DNS and URL subjectAltNames
Matches are performed in a case-insensitive way, so that for example <ds:KeyName>example.org</ds:KeyName> will match a subject CN of Example.Org, and<ds:KeyName>Example.Org</ds:KeyName> will match a subject CN of example.org.
...
The following <ds:KeyInfo> children can be resolved into trust anchors and CRLs without additional plugin support:
<ds:X509Data>/<ds:X509Certificate><ds:X509Data>/<ds:X509CRL>
Each <ds:KeyInfo> represents a single trust anchor (possibly including a chain of intermediates) along with any applicable CRLs. Multiple trust anchors should be captured in separate <ds:KeyInfo> elements.
...