jschlyter
commented
3 years ago Online Lookup
I proposed that we drop any requirement to be able to look up a certificate online given the kid. The system is designed to operate in offline mode so validators must be able to operate on a downloaded trusted list anyway.
Classic JWT/CWT Validation
- Retrieve
kidfrom token (JWT/CWT) - Find all keys where
key.kid==token.kid(there can be more than one since kid does not need to be unique) - Try to validate token signature using all found keys
- For the first validation that succeeds, extract issuer from token
issclaim. - Look up issuer metadata (e.g., display name) via
iss
X.509 to iss/kid Mapping
Issuer
- I would prefer a simple mapping from certificate Distinguished Name to
iss. this processing only needs to be performed when constructing the trusted list, so it does not need to be known by generic validators. hcert issuers needs to set the correctissof course.
Key Identifier
- Why not simply use the Subject Key Identifier as kid? Either directly of truncated. Or, since
kidis not defined to be unique, the certificate serial number (most modern CAs use random serial numbers so risk of collision should be minimal).
Razumain
fredriklj
One important aspect of the hcert is the binding between the signing key and the issuer of the hcert.
The KeyID is used as a universal identification key that allows the verifier to locate and find the signer certificate holding the signer key.
Once the trusted signer key has been located and used to validate the hcert, we then need to establish the identity of the signer.
KeyID Both of these tasks can easily be accomplished by incorporating the signer identity in both the KeyID as well as in the hcert issuer information. But textual information about the hcert issuer in the form of a Distinguished Name (DN) according to X.500 requires quite some data space, which we want to minimise. So the question is how we can do better, but still retain the necessary functionality as well as international interoperability.
The first task to find the optimal solution is to determine what use-cases we need to support in the process to locate the signer key/certificate based on the KeyID. Whatever the solution is, it is absolutely essential that the format of KeyID is standardised and harmonised among the participating countries. Without such harmonisation we can't guarantee that a verifying application can locate the correct signing key/certificate.
The master storage space for keys/certificates is the ICAO PKD (Public Key Directory) which is an LDAP directory. LDAP directories uses DN to locate objects in the directory. In absence of a DN, you can't make a direct lookup in the directory. So the first task is to determine if we need to be able to locate a key/certificate using an LDAP lookup using a DN as the lookup key. If the answer to this question is YES, then the KeyID must contain the DN, or at the least, it must be possible to derive the DN from the KeyID. If tis is to be done off-line, we then need to encode/compress the DN in a way that it can be reassembled and used to make an LDAP lookup.
If the answer to this question is NO, then we can do much better by deriving an arbitrarily small identifier that can be matched against a key/certificate in the directory.
The discussions so far has concluded that it is NOT necessary to allow direct LDAP lookup based on a DN. It appears that the common practice is to simply download all certificates from the PKD and build your own "hash-table" where you can do your own local indexing to locate an appropriate certificate. The amount of data and keys is small enough to make this task trivial.
The first conclusion here is therefore that the KeyID does NOT have to contain the DN of the hcert issuer.
The second question is whether KeyID must be unique. If the answer is yes, then we need a longer KeyID than if the answer is no. The conclusion here is that KeyID does not have to be unique. It only need to be unique enough to limit the number of potential keys in a meaningful way. It is not the KeyID itself, but the actual key and how that 1) can be verified and 2) matches the signature on the hcert, that determines if it is the right key or not. There is no threat or attack made possible caused by KeyID collisions. It only makes the matching process a little bit harder since more than one key may have to be tested.
PROPOSAL on KeyID: The proposal for a KeyID algorithm is to use the well known hash Algorithm SHA 256 to hash the certificate from the PKD that was intended to be used with this hcert. This hash value MAY be truncated to an arbitrary size. However the size MUST not be shorter than 8 bytes. When KeyID is truncated, it always represent the first bytes of the hash value of the certificate.
Issuer name binding Once the Hcert is validated the verifier need to obtain the identity of the issuer. This can be stored in the Hcert, but as we have gone through efforts to obtain and verify the signing certificate of the Hcert signer, and because we consequently always will have such verified certificate available, we could just refer to the issuer identity located in that certificate.
A short issuer identity in the Hcert can be accomplished either by setting up naming restrictions ensuring short issuer names, or by simply allowing a simple short reference the the issuer name in th issuer certificate.
PROPOSAL on Issuer name binding: The proposal for issuer name in the Hcert is to have a choice between either a short explicit identifier according to some set rules for constrained issuer identities, or to include a hash of the DN in the associated issuer certificate.
The defined process to validate a hcert is: