`aki` compares the keyIdentifier against the whole AuthorityKeyIdentifier
Nobody has claimed this yet.
- Dominant language
- Shell
- Stars
- 112
- Forks
- 38
- Avg merge
- 12d 19h
- Merged PRs (30d)
- 4
Description
Section 6.1.1.1 defines the aki value and its matching rule in one sentence:
Contains the KeyIdentifier of the AuthorityKeyIdentifier as defined in Section 4.2.1.1 of [RFC5280], encoded as base64url. The raw byte representation of this element MUST match with the AuthorityKeyIdentifier element of an X.509 certificate in the certificate chain present in the Credential
The first half defines the value as the KeyIdentifier. The second half requires it to match the AuthorityKeyIdentifier. Those are a member and its container: RFC 5280 defines AuthorityKeyIdentifier as a SEQUENCE of three optional fields, of which KeyIdentifier is one.
In a certificate they differ in length. The extension value carries DER wrapping around the identifier, and may also carry the two other optional fields, so it is always longer than the identifier alone. A Wallet that does what the second half says, comparing the supplied value against the extension, cannot match for any certificate.
The example in this same section is the field rather than the container: s9tIpPmhxdiuNkHMEWNpYim8S8Y decodes to 20 bytes, the length of a bare key identifier with no wrapping. So the example and the sentence disagree, and the example looks correct.
The consequence is not confined to this section, because 6.4.2 says of a non-matching Credential:
Credentials not matching the respective constraints expressed within credentials MUST NOT be returned, i.e., they are treated as if they would not exist in the Wallet.
So a Wallet implementing the sentence literally reports that the End-User holds no matching Credential when they do, with nothing distinguishing that from genuinely not having one.
RFC 5280 itself has phrasing that distinguishes them, in Section 4.2.1.1: "The keyIdentifier field of the authorityKeyIdentifier extension".
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Read Section 6.1.1.1 alongside RFC 5280 Section 4.2.1.1, then check how Section 6.4.2 depends on the matching rule. Update the specification so aki consistently refers to the KeyIdentifier rather than the AuthorityKeyIdentifier container, preserving the example's intended meaning.
Written by the indexing model from the issue text.
Assessment
- Domain
- documentation, security
- Issue type
- Documentation
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 68/100