Conversation
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #638 +/- ##
==========================================
- Coverage 97.34% 97.01% -0.34%
==========================================
Files 32 32
Lines 3357 3446 +89
==========================================
+ Hits 3268 3343 +75
- Misses 89 103 +14 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
cwt/utils.py
Outdated
| raise ValueError(f"Unsupported or unknown alg: {v}.") | ||
| v = algs[v] | ||
| else: | ||
| v = v.encode("utf-8") if isinstance(v, str) else v |
There was a problem hiding this comment.
I apologise in advance for offering unsolicited feedback here, which I hope will be useful still.
It is uncommon, and fairly recent, but one soon-to-be standard parameter may only have a tstr value: 260 (payload-location), requested in cose-hash-envelope.
A user passing a protected header {"payload-location": "http://..."} would have their payload-location converted to a bstr by line 191, which although practically harmless, could be rejected by a strict parser/verifier.
Since the code below applies per-key validation, it may be that having per-key conversion logic is desirable. Another edge case may be the use of not-yet supported values for 1 (alg) or 16 (typ), which allow tstr for that purpose. A user may want to pass {"alg": "NEWCRYPTOALGO"}, and a strict verifier may enforce int / tstr and reject a bstr-encoded b"NEWCRYPTOALGO".
- Split HPKE into integrated (HPKE-0..7) and key encryption (HPKE-0-KE..7-KE) - Update algorithm IDs and COSE recipient algorithms - Add hpke_info parameter to encrypt - Relax key_ops validation for HPKE private keys - Update README and docs references to draft-23 Made-with: Cursor
dajiaji
changed the title
dajiaji
force-pushed
the
follow-core-hpke-15
branch
from
2796c14 to
dc0d194
Compare
2 participants
No description provided.