Automatic X.509 certificate issuance and publication using Federation API

[peppelinux]

According to @fmarino-ipzs 's perspective, the most smart proposal appears to be the following below:

During the entity registration (onboarding procedure) we issue one X.509 certificate for all the Federation Entity Keys, providing therefore one or more JWK including the x5c parameter valued with the X.509 Certificates in Base64(DER) format.

The application specific jwks, included in each application specific metadata, would be self-issued by leafs using the private cryptographic key of one of the Federation Entity Keys with x5c.

This approach makes every leaf as an X.509 certificate issuer about itself.

Below an X.509 Certificate Chain example:

1. Trust Anchor/CA X.509 Self issued Certificate (iss: ta, sub: ta),
2. X.509 Certificate issued by TA/CA about an Intermediate (if any) (iss: ta, sub: immediate descendant)
3. X.509 Certificate issued by the immediate superior entity above about the Leaf (iss: immediate superior, sub: immediate descendant)
4. X.509 Certificate issued by the Leaf about the one of the metadata jwk under its control (iss: itself, sub: itself)

[peppelinux]

This approaches enables:

• freedom in each participant in issuing all about themselves according to the verifiable evidences provided with the trust chain about themselves
• opportunity to RP instances (ISO 18013-5 verifiers apps belonging an RP domain)
• scalability, every participants using the chain provided with the federation entity keys, are enabled in issuing whatever certificates they needs

[peppelinux]

This would require every participants issuing X.509 certificates about itself, to provide X.509 certificates revocations (CRL) and any other certificate transparency endpoints.

[Razumain]

Am I correct to assume that this is an attempt to get around the requirements in the implementing acts enforcing entities to be represented by a certificate?

I don't think this will do it, as each issuer must be a trustworthy CA.

My thinking along these lines is that we would setup one CA that issues certificates to all entities that needs a certificate according to the regulation. This will only require one certificate in the trusted list (The one CA:s certificate).

I think this will satisfy the requirements and allows participants to choose what trust infrastructure they want to use.

But I may have completely missed the reason for this proposal. But making every entity a CA seems like a lot of overhead.

[peppelinux]

Am I correct to assume that this is an attempt to get around the requirements in the implementing acts enforcing entities to be represented by a certificate?

this is the solution allowing an automatic issuance of X.509 certificates, required for legacy applications, using the trust established using federation.

I don't think this will do it, as each issuer must be a trustworthy CA.

using the proposed solution each federation entity is free to issue a signed statement, therefore an X.509 certificate, about itself because this is verifiable using a trust chain about it. This is the same approach we use for the Entity Configurations.

My thinking along these lines is that we would setup one CA that issues certificates to all entities that needs a certificate according to the regulation. This will only require one certificate in the trusted list (The one CA:s certificate).

this doesn't scale, it is problematic thinking about a PKI without intermediaries. For this level of awareness I might leave to you the floor as the author of RFC5280

But I may have completely missed the reason for this proposal. But making every entity a CA seems like a lot of overhead.

the reasons are:

• enabling x.509 certificates for legacy applications that require it
• enabling automatic and self-issued certificate issuance using a verifiable mechanism
• enabling a total scalability using the delegation pattern without loose of responsability or security

[Razumain]

Thank you.

I still struggle to understand the use-case. I feel that I got invited in the middle of a conversation where I don't understand the problem at hand.

My understanding of the current situation is that we all want to use OpenID federation. When you use that, no certificates are needed. The trust in each entity certificate is provided by signed Entity Statements.

I'm not fully sure what you mean by "Legacy applications here". In the context of wallets I'm not sure what that is.

But if I would interpret that as an application that is not using OpenID federation, and expects a certificate to represent an entity that they can validate using Trusted List instead, then my thinking applies.

An application that is not using OpenID federation will have a hard time validating chains according to your proposal, and it creates a huge number of entities that have to be acting as a CA.

This makes me believe that your use-case is something else. If you elaborate, then perhaps I can provide more relevant thoughts.

[peppelinux]

@Razumain the CA is still and always the trust anchor.

Every entity that issues a certificate must exposes the required and typical resources about X.509 for revocation checks.

entities such as federation leaves that issues certificates are not CA, but intermediates for the issuance of certificates about themselves, using an appropriate naming constraint.

Naming constraints used by immediate superiors within the certificates issued to the leaf that issues certificates only about itself

     [ name_constraints ]
     permitted;URI.1=http://rp.example.com

To revoke a leaf's certificate the Intermediate revokes the certificate about the leaf, invalidating the entire chain. This is the x5c parameter within the JWKs about the Federation Entity Keys.