Key fixes #154
Key fixes #154
Conversation
|
This sits on top of #153 |
Codecov Report
@@ Coverage Diff @@
## main #154 +/- ##
==========================================
+ Coverage 90.87% 91.30% +0.42%
==========================================
Files 12 12
Lines 1611 1633 +22
==========================================
+ Hits 1464 1491 +27
+ Misses 109 104 -5
Partials 38 38
... and 1 file with indirect coverage changes 📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
setrofim
force-pushed
the
setrofim
branch
3 times, most recently
from
2de9dd1 to
efc9cd7
Compare
qmuntal
left a comment
qmuntal
left a comment
There was a problem hiding this comment.
I don't see that this PR fixes my first point from #151 (comment).
This is addressed by d591f36
|
The alg parameter is unnecessary, and makes these functions more awkward to use. The input PublicKey/PrivateKey is now identified via a type switch, and the algorithm is derived from it. Signed-off-by: setrofim <[email protected]>
RFC8152 allows for unregistered curves, therefore we should not fail key validation if a curve is not recognised when marshalling. We should only fail when a known curve is used with an incorrect key type. Signed-off-by: setrofim <[email protected]>
Ensure that the KeyType is the expected one for the Curve when creating crypto.PublicKey or crypto.PrivateKey. Signed-off-by: setrofim <[email protected]>
RFC8152 allows public parts to be omitted from private keys, as they could be derived (though it recommends that they are present). crypto.PrivateKey implementations require for them to be present. Signed-off-by: setrofim <[email protected]>
Add test for String() calls not exercised by other test cases to placate Codecov. Signed-off-by: setrofim <[email protected]>
Signed-off-by: setrofim <[email protected]>
A number of spec compliance fixes and interface adjustements for
COSE_Key.This address points 1, 3, 4, and 5 in #151 (comment)