Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RFC023: X509Credential #283

Open
wants to merge 13 commits into
base: master
Choose a base branch
from
Open

RFC023: X509Credential #283

Changes from 3 commits
Commits
Show all changes
13 commits
Select commit Hold shift + click to select a range
1181a20
RFC023: X509Credential
reinkrul Dec 17, 2024
2574caf
Add detailed explanation of x509 certificates in RFC
rolandgroen Dec 17, 2024
12859aa
Update RFC023 to extend x509 specification and clarify usage
rolandgroen Dec 19, 2024
6af5704
Update section title to specify UZI server certificate usage
rolandgroen Dec 19, 2024
ccdbf88
Refine X509Credential validation and add UZI mapping guide.
rolandgroen Jan 6, 2025
95a2f51
Add detailed security considerations for x509credential
rolandgroen Jan 7, 2025
9bdff45
Add example UZI certificate mapping in RFC023 documentation
rolandgroen Jan 7, 2025
6c17ad6
Refactor credentialSubject structure in RFC023.
rolandgroen Jan 7, 2025
6f72f41
Normalize attribute notation in RFC023 document.
rolandgroen Jan 7, 2025
b59d760
Update rfc/rfc023-x509credential.md
rolandgroen Jan 7, 2025
755055d
Update rfc/rfc023-x509credential.md
rolandgroen Jan 10, 2025
9257574
Rename `X509Credential` to `NutsX509Credential` in RFC023.
rolandgroen Jan 10, 2025
e8949c7
Update terminology from JWE to JWT in RFC document
rolandgroen Jan 10, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
38 changes: 28 additions & 10 deletions rfc/rfc023-x509credential.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -180,8 +180,17 @@ rules:
- The credential MUST be in JWT format.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the format is called the Proof Format.

- `type`: MUST include `VerifiableCredential` and `X509Credential`.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I ran into problems when the credential type started with an X on the json-ld playground. So perhaps we should use the NutsX509Credential type.

- `issuer`: MUST be a valid `did:x509` identifier.
- `credentialSubject`: MUST only contain fields explicitly present in the `did:x509` DID policies with the format <
policy_type>:<policy_attribute>, for example `subject:O` or `san:otherName`.
- `credentialSubject`: MUST only contain fields explicitly present in the `did:x509` DID policies with the fields mapped by each type as a separate map. An example:
```
{
"subject": {
"O" : "My Organisation"
},
"san" : {
"email" : "[email protected],"
rolandgroen marked this conversation as resolved.
Show resolved Hide resolved
}
}
```

The credential subject can be identified by any DID method (e.g. `did:web`) accepted by the credential verifier.

Expand Down Expand Up @@ -283,7 +292,10 @@ validated to ensure the credential is within its valid timeframe.

## Security Considerations

TODO: Trust, which ca-fingerprint to use, ...
The following security considerations are to be considered:
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

also state which catastrophic failure might occur when you don't do this properly


- The Root CA of the did:x509 needs to be checked against the root CA structure of the use case. For instance, in case
rolandgroen marked this conversation as resolved.
Show resolved Hide resolved
of UZI certificates the ROOT CA must match the associated root CA chain.
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
of UZI certificates the ROOT CA must match the associated root CA chain.
of UZI certificates the `ca-fingerprint` must match the hash of (name of G3 intermediate CA(s) here).


### Certificate Revocation

Expand All @@ -307,7 +319,9 @@ entity controlling the `did:x509` DID.
- [DID:X509 Method Specification](https://trustoverip.github.io/tswg-did-x509-method-specification/)
- [X.509 Certificate Revocation (OCSP/CRL)](https://datatracker.ietf.org/doc/html/rfc5280)

## PKI overheid & UZI certificates
# An application of the RFC023: UZI server certificates

## PKI overheid & UZI server certificates

The Dutch government has a Public Key Infrastructure (PKI) that is used to establish trust between parties. The PKI
framework is currently in place and makes use of PKI Overheid Certificates issued by the root CAs of the Dutch
Expand Down Expand Up @@ -349,10 +363,13 @@ contains the following information (of intrest):

## Mapping UZI certificate to X509Credential

### The ROOT Ca
The mapping of certificates to x509 is depending
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you mean mapping of certificates to an X509Credential? And what is "depending"?


### The ROOT G3

The `did:x509` specification dictates that the fingerprint of the Root CA is part of the did:x509. For mapping an UZI
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No it doesn't:

ca-fingerprint is chain[i].fingerprint[ca-fingerprint-alg] with i > 0, that is, either an intermediate or root CA certificate.

certificate to an X509Credential the ROOT CA MUST match one of the certificates in the UZI register hierarchy.
certificate to an X509Credential the ROOT CA MUST match one of the certificates in the UZI ROOT CA register hierarchy.
For G3 this is:

```asciidoc
┌────────────────────────────────────┐
Expand All @@ -368,9 +385,10 @@ certificate to an X509Credential the ROOT CA MUST match one of the certificates
└────────────────────────────────────────────┘
```

### Field mapping
The following fields are commonly used for mapping UZI cetificates to X509Credentials
* The `subject:O` the name of the holder of the certificate.
### Field mapping of the UZI credential

The following fields are commonly used for mapping UZI certificates to X509Credentials
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We are specifying it here how it should be used, not how it is used. So rephrase to something like: The following fields MUST be included in the mapping.

* The `subject:O` the name of the holder of the certificate. Maps to `subject.O` in the X509Credential.
* The `subject.L` The subject locality (city)
* The `san:otherName` a string containing `<OID CA>-<versie-nr>-<UZI-nr>-<pastype>-<Abonnee-nr>-<rol>-<AGB-code>`,
where:
Expand All @@ -382,7 +400,7 @@ The following fields are commonly used for mapping UZI cetificates to X509Creden
* `<rol>` is the role of the holder of the certificate, always "0.00"
* `<AGB-code>` is the AGB code of the holder of the certificate.

## The use of UZI server certificate in the Nuts network
## The use of UZI server certificate in the Nuts network or identifying organizations

The focus on trust in the NUTS network for organizations lies primarily on the URA number identified as the
`<Abonnee-nr>` on the UZI certificate. This number is used to identify the holder of the certificate within the Dutch
Expand Down