Skip to content
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

keyid is not Optional in securesystemslib Signature #416

Open
PradyumnaKrishna opened this issue Jul 1, 2022 · 3 comments
Open

keyid is not Optional in securesystemslib Signature #416

PradyumnaKrishna opened this issue Jul 1, 2022 · 3 comments
Labels
discussion Issues that require discussion docs

Comments

@PradyumnaKrishna
Copy link
Contributor

Description of issue or feature request:
As per DSSE signing-spec keyid field must be optional and treated the same as set-but-empty. Currently, securesystemslib Signature and Key Schema don't have keyid as optional. create_signature() and verify_signature() method in keys.py require them to create and verify signatures.

Current behavior:
There is no support for keyid as optional field in securesystemslib formats for SIGNATURE, or KEY_SCHEMA (e.g. ANYKEY_SCHEMA in formats.py).

ANYKEY_SCHEMA = SCHEMA.Object(
object_name = 'ANYKEY_SCHEMA',
keytype = KEYTYPE_SCHEMA,
scheme = SCHEME_SCHEMA,
keyid = KEYID_SCHEMA,
keyid_hash_algorithms = SCHEMA.Optional(HASHALGORITHMS_SCHEMA),
keyval = KEYVAL_SCHEMA,
expires = SCHEMA.Optional(ISO8601_DATETIME_SCHEMA))

Expected behavior:
securesystemslib should mark keyid field as optional, which can be any string not just hex? or provide good alternatives to current methods for creation or verification of signatures that doesn't requires keyid.

Linked Discussion: in-toto#2 (comment)

@lukpueh
Copy link
Member

lukpueh commented Jul 6, 2022

Related to #409 (comment)

@lukpueh
Copy link
Member

lukpueh commented Jul 7, 2022

Thanks for posting this issue, @PradyumnaKrishna! Here's what I think:

  • Re securesystemslib's schema/formats facility: I'd like to deprecate it for the reasons outlined in #183. We don't have to do this now, but I'd also rather not put any efforts into improving it.

  • Re create_signature: The DSSE spec does not require us to support keyid-less signing. This means it should be okay if all Signature objects returned with e.g. Signature.sign and serialized into a DSSE envelope with e.g. Signature.to_dict include a keyid. So no need to change anything there.

  • Re verify_signature: The DSSE spec does, however, require us to support keyid-less signature verification. This means we need to be able to deserialize keyid-less signatures from DSSE envelopes with e.g. Signature.from_dict and verify them with e.g. Key.verify. Currently, the latter is not possible due to the internal use of keys.verify_signature, which does require a keyid on the passed signature.Let's, in a first iteration, just make a note that we are not fully DSSE spec compliant in this regard, and, in a second iteration, port the keys.verify_signature functionality to SSlibKey.verify.

@lukpueh
Copy link
Member

lukpueh commented Jul 21, 2022

My comment above only talks about keyids in signatures, but the issue description also seems to discuss keyids in public keys.

FYI: I captured some thoughts about the latter in #310 (comment)

@lukpueh lukpueh added discussion Issues that require discussion docs labels Mar 14, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discussion Issues that require discussion docs
Projects
None yet
Development

No branches or pull requests

2 participants