-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Specifying key ID's format #1
Comments
The fingerprint could be calculated using the following formula RFC4880#12.2:
This should be possible to use for both non-resident (derived) and resident keys. Optionally, if we allow to use multiple derived keys per domain, additional integer number would be required from the JS application, so we could avoid costly searching it (by generating public key for each number), e.g. 2 additional bytes to allow 64k keys per domain. To identify specific device having given key (e.g. in case user would have multiple ones), a device ID could be added to the full fingerprint produced by the device, which then would be parsed/stored in the JS API memory. References: |
Here's the relevant conversation.
...
|
See also #17 for a related design discussion. |
Here is the key ID format keybase uses, that might be a good model also using RFC4880 - https://keybase.io/docs/api/1.0/kid Might not need to store the full 32 byte fingerprint in hardware, if space is an issue last 8 bytes seems like it would be enough for checking, I think that is what keybase uses - |
@onlykey Thank you for linking this. Keybase format looks easy to compute on the device, so we can support it easily. I agree that partial ID could be handy in the case of limited storage. @tomholub As for the derived keys, the idea is to have part of the key source data (e.g. 64 random bytes) on the webservice server (similar to the FIDO U2F/FIDO2 case). That solution allows to manage unlimited keys through the device. This also mean that besides the message and the device, an external server is requred to solve the mapping |
@szszszsz Thank you for looping me in, I have some questions to clarify.
When you say webservice server, you mean our own server-side database where we keep track of derived keys for the client browser - which in turn communicates with the token?
This likely answers my question above. If this is your design decision, we'll have to work with it. I'd prefer to not store information for our users if not necessary, but there appears to be no way around it for both resident and derived keys, because even for resident keys I can't pull a list of longids from the device :-/ |
@tomholub Sorry for the delay. We are in discussion with Jan about that. Will write shortly. |
@tomholub Regarding the derived keys, I have made a little confusion here, specifically with external key handle storage, sorry. Let me try to clear that out. I think this would cover better openpgp.js. What is your opinion? |
This sounds good to me. Thanks for clearing it up! |
Sign
andDecrypt
operations require the to-be-used key ID as a parameter. How exactly should this key ID look like? @tomholub noted, that it should be compatible to OpenPGP's long ID as specified in RFC 4880 to make it usable with OpenPGP.The text was updated successfully, but these errors were encountered: