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.

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

in dsi.tee, why are cert and cacert separate fields? #9

Open
dthaler opened this issue Mar 24, 2019 · 0 comments
Open

in dsi.tee, why are cert and cacert separate fields? #9

dthaler opened this issue Mar 24, 2019 · 0 comments

Comments

@dthaler
Copy link
Collaborator

dthaler commented Mar 24, 2019

The spec has:
"tee": {
...
"cert": "",
"cacert": "",
...
}
and similar in various other places like here:
"signercert": "<The BASE64 encoded certificate data of the
TA binary application's signer certificate>",
"signercacerts": [ < The full list of CA certificate chain
including the root CA> ],

However, it also depends on JWS which has "x5c" defined as (in RFC 7515 section 4.1.6):
The "x5c" (X.509 certificate chain) Header Parameter contains the
X.509 public key certificate or certificate chain [RFC5280]
corresponding to the key used to digitally sign the JWS. The
certificate or certificate chain is represented as a JSON array of
certificate value strings. Each string in the array is a
base64-encoded (Section 4 of [RFC4648] -- not base64url-encoded) DER
[ITU.X690.2008] PKIX certificate value. The certificate containing
the public key corresponding to the key used to digitally sign the
JWS MUST be the first certificate. This MAY be followed by
additional certificates, with each subsequent certificate being the
one used to certify the previous one. …

So x5c requires a JSON array where the first entry is the leaf cert, and in contrast the rest of OTrP puts the leaf cert into a separate field and has the array only contain the rest of the chain.
This complicates the code by requiring two separate mechanisms for encoding/decoding the cert chain instead of using one common mechanism.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant