CMS: Recipient Info (ktri vs kekri)
Nobody has claimed this yet.
- Dominant language
- TypeScript
- Stars
- 1
- Forks
- 2
- PR merge metrics
- No merged PRs in 30d
Description
The current CMS RecipientInfo libp2p/js-libp2p-cms#1 uses the ktri KeyTransRecipientInfo, with the issuer's CN containing the key's id. IPFS doesn't have distinguished names and it's basically a hack to send the key's ID.
recipientInfos:
d.ktri:
version: <ABSENT>
d.issuerAndSerialNumber:
issuer: O=ipfs, OU=keystore, CN=QmWc1hrWTsh1sWkCKn5hd5AvMD4ZhRFwEtok2MhCAzpuvx
serialNumber: 1
keyEncryptionAlgorithm:
algorithm: rsaEncryption (1.2.840.113549.1.1.1)
parameter: NULL
encryptedKey: ...
The kekri KEKRecipientInfo is more suited to IPFS; it uses a key ID instead of a distinguished name. However, the spec does state that
Recipient information using previously distributed symmetric keys
Contributor guide
No contributing guide indexed for this repository
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
Start with the current CMS RecipientInfo described in the issue, then compare its ktri structure with RFC 5652 section 6.2.3's kekri definition. Confirm whether the IPFS key ID should be represented as a KEKRecipientInfo key identifier rather than an issuer CN, and clarify the resulting implementation scope.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- typescript
- Domain
- cryptography, security
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 30/100