Trusted entitlements: Use new signature verification format#1111
Conversation
Codecov Report
@@ Coverage Diff @@
## main #1111 +/- ##
==========================================
- Coverage 85.16% 85.12% -0.05%
==========================================
Files 186 186
Lines 6554 6568 +14
Branches 929 932 +3
==========================================
+ Hits 5582 5591 +9
- Misses 601 603 +2
- Partials 371 374 +3
|
There was a problem hiding this comment.
Currently nonce will never be null if shouldSignResponse, but that will change with the new static endpoints we want to sign. Right now I can't add tests to this change due to that limitation.
There was a problem hiding this comment.
A separate PR for that is fine 👍🏻
There was a problem hiding this comment.
I wasn't sure whether to add these, but I thought it might be useful if we need to debug things. Also, they are test keys, not real keys so I think it should be fine.
There was a problem hiding this comment.
Note that now we aren't using the real root key but a new test key. It was difficult to test using the real key since the current responses may become outdated once the intermediate key expires. Still plan to add some integration tests that test this against the backend.
There was a problem hiding this comment.
Hmm how so? The expiration is also encoded in the signature.
There was a problem hiding this comment.
Right but we don't have the real root private key in order to create a signed intermediate key with an expiration date far in the future. If not, we would need to be changing the signature every time the intermediate key expires I think? I guess maybe we could get a signature that expires far into the future but not sure if that would have any security concerns... Probably not but I will think about that a bit more
There was a problem hiding this comment.
Oooh I see. I got around that by creating fake private and public root keys in some of these tests.
There was a problem hiding this comment.
Right, that's what I'm doing here. I basically used test private/public keys to generate signatures with different values that I need. But we are not testing using the real production key as we were before... But I think it's fine if that's covered by integration tests that actually hit the backend.
There was a problem hiding this comment.
This was unused now so I removed it
|
Marking it as ready for review but we need to hold this until the backend is deployed. |
NachoSoto
left a comment
There was a problem hiding this comment.
Just a question about the double-layer architecture.
There was a problem hiding this comment.
A separate PR for that is fine 👍🏻
There was a problem hiding this comment.
I think it's slightly weird that this has both of these types. Why would IntermediateSignatureHelper not be inside SignatureVerifier?
There was a problem hiding this comment.
Oh I see SigningManager is the type on top. But it seems like it only uses IntermediateSignatureHelper though?
There was a problem hiding this comment.
Yeah, the root key is only used by the IntermediateSignatureHelper so we can probably just remove the signatureVerifier from here.
There was a problem hiding this comment.
I removed the signatureVerifier field from the enum here: 9efce80. Lmk what you think!
There was a problem hiding this comment.
Hmm how so? The expiration is also encoded in the signature.
There was a problem hiding this comment.
I'm not sure if this check is needed, but it makes sense to me.
There was a problem hiding this comment.
Yeah I didn't do this but it makes sense.
There was a problem hiding this comment.
Right but we don't have the real root private key in order to create a signed intermediate key with an expiration date far in the future. If not, we would need to be changing the signature every time the intermediate key expires I think? I guess maybe we could get a signature that expires far into the future but not sure if that would have any security concerns... Probably not but I will think about that a bit more
There was a problem hiding this comment.
Yeah I didn't do this but it makes sense.
e2cd630 to
01e5594
Compare
9efce80 to
0533130
Compare
|
Merging into integration branch for now |
Description
Third PR for SDK-3200
Based on #1109 and #1110.