Skip to content

Clarify if "signatures" can be extended #203

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.

Sign up for GitHub

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

Jump to bottom
Closed
MVrachev opened this issue Jan 27, 2022 · 2 comments
Closed

Clarify if "signatures" can be extended #203

MVrachev opened this issue Jan 27, 2022 · 2 comments

Comments

@MVrachev
Copy link
Contributor

The Document formats section of the specification says the following:

All of the formats described below include the ability to add more attribute-value fields
to objects for backward-compatible format changes.
Implementers who encounter undefined attribute-value pairs in the format must include
the data when calculating hashes or verifying signatures and
must preserve the data when re-serializing.

This implies that the specification implementations should support unrecognized fields at each place in the SIGNED portion as they will be used to calculate the hashes or do signature verification.

It's a little unclear for me if unrecognized fields are allowed in the signatures dictionaries.
Any opinions?
This was referenced Jan 27, 2022
Closed
Merged
@trishankatdatadog
Copy link
Member

trishankatdatadog commented Jan 27, 2022 •
edited
Loading

I don't think we should allow it. There are use cases in DSSE where you may want additional fields, but arguments remain open:

secure-systems-lab/dsse#39

Let's clarify the spec to reflect this.

@MVrachev
Copy link
Contributor Author

MVrachev commented Feb 7, 2022 •
edited
Loading

@mnm678, @asraa and @jku shared their opinions on the python-tuf issue theupdateframework/python-tuf#1802.
In the document section the spec currently says:
All of the formats described below include the ability to add more attribute-value fields to objects.
Now when I reread this I see it's before defining any of the formats meaning it should apply to signatures as well.

I initially thought it's applicable only to the SIGNED fields as undefined attribute-value pairs in the format must include the data when calculating hashes or verifying signatures.
This doesn't mean that the sentence before that excludes signatures as a possible place for additional fields.

I am no longer certain there is a need for any clarification...
I think I just misread it and after a discussion with a couple of people, I realized there is noting stopping unrecognized fields inside the signatures when reading the current version of the spec (version 1.0.28).

I will close the issue and if somebody thinks I am mistaken, please share why and I will reopen it.

@MVrachev MVrachev closed this as completed Feb 7, 2022
MVrachev added a commit to MVrachev/securesystemslib that referenced this issue Feb 9, 2022
@MVrachev
Add unrecognized fields support for Signature
433c8a2 
The TUF specification says the following regarding unknown fields:
"All of the formats described below include the ability to add more
attribute-value fields to objects for backward-compatible format
changes. Implementers who encounter undefined attribute-value pairs in
the format must include the data when calculating hashes or verifying
signatures and must preserve the data when re-serializing."
From: https://theupdateframework.github.io/specification/latest/#document-formats

This section is the reason ADR0008 was accepted inside python-tuf
(see here: https://github.com/theupdateframework/python-tuf/blob/develop/docs/adr/0008-accept-unrecognised-fields.md)
and we have added support for unrecognized fields for all fields
inside the SIGNED portion of the metadata.
However, this limits what the citation implies or that everywhere there
inside the metadata files including signatures we should accept
unrecognized fields. That's why I made these changes.
These changes have the approval of the community see:
- theupdateframework/specification#203
- theupdateframework/python-tuf#1802

Signed-off-by: Martin Vrachev <[email protected]>
MVrachev added a commit to MVrachev/securesystemslib that referenced this issue Feb 9, 2022
@MVrachev
Add unrecognized fields support for Signature
2afc203 
The TUF specification says the following regarding unknown fields:
"All of the formats described below include the ability to add more
attribute-value fields to objects for backward-compatible format
changes. Implementers who encounter undefined attribute-value pairs in
the format must include the data when calculating hashes or verifying
signatures and must preserve the data when re-serializing."
From: https://theupdateframework.github.io/specification/latest/#document-formats

This section is the reason ADR0008 was accepted inside python-tuf
(see here: https://github.com/theupdateframework/python-tuf/blob/develop/docs/adr/0008-accept-unrecognised-fields.md)
and we have added support for unrecognized fields for all fields
inside the SIGNED portion of the metadata.
However, this limits what the citation implies or that everywhere there
inside the metadata files including signatures we should accept
unrecognized fields. That's why I made these changes.
These changes have the approval of the community see:
- theupdateframework/specification#203
- theupdateframework/python-tuf#1802

Signed-off-by: Martin Vrachev <[email protected]>
@MVrachev MVrachev mentioned this issue Feb 9, 2022
Merged
3 tasks
MVrachev added a commit to MVrachev/securesystemslib that referenced this issue Feb 9, 2022
@MVrachev
Add unrecognized fields support for Signature
cff5daa 
The TUF specification says the following regarding unknown fields:
"All of the formats described below include the ability to add more
attribute-value fields to objects for backward-compatible format
changes. Implementers who encounter undefined attribute-value pairs in
the format must include the data when calculating hashes or verifying
signatures and must preserve the data when re-serializing."
From: https://theupdateframework.github.io/specification/latest/#document-formats

This section is the reason ADR0008 was accepted inside python-tuf
(see here: https://github.com/theupdateframework/python-tuf/blob/develop/docs/adr/0008-accept-unrecognised-fields.md)
and we have added support for unrecognized fields for all fields
inside the SIGNED portion of the metadata.
However, this limits what the citation implies or that everywhere there
inside the metadata files including signatures we should accept
unrecognized fields. That's why I made these changes.
These changes have the approval of the community see:
- theupdateframework/specification#203
- theupdateframework/python-tuf#1802

Another change I had to do, so I can add unrecognized fields support
inside Signature is to make "Signature.from_dict()" to behave the same
way as the rest of the "from_dict()" functions inside TUF or destroy
the input dictionary.
This was necessary, as that provides me with an easy way to pass the
unrecognized fields to the constructor.

Signed-off-by: Martin Vrachev <[email protected]>
MVrachev added a commit to MVrachev/securesystemslib that referenced this issue Feb 9, 2022
@MVrachev
Add unrecognized fields support for Signature
8213d77 
The TUF specification says the following regarding unknown fields:
"All of the formats described below include the ability to add more
attribute-value fields to objects for backward-compatible format
changes. Implementers who encounter undefined attribute-value pairs in
the format must include the data when calculating hashes or verifying
signatures and must preserve the data when re-serializing."
From: https://theupdateframework.github.io/specification/latest/#document-formats

This section is the reason ADR0008 was accepted inside python-tuf
(see here: https://github.com/theupdateframework/python-tuf/blob/develop/docs/adr/0008-accept-unrecognised-fields.md)
and we have added support for unrecognized fields for all fields
inside the SIGNED portion of the metadata.
However, this limits what the citation implies or that everywhere there
inside the metadata files including signatures we should accept
unrecognized fields. That's why I made these changes.
These changes have the approval of the community see:
- theupdateframework/specification#203
- theupdateframework/python-tuf#1802

Another change I had to do, so I can add unrecognized fields support
inside Signature is to make "Signature.from_dict()" to behave the same
way as the rest of the "from_dict()" functions inside TUF or destroy
the input dictionary.
This was necessary, as that provides me with an easy way to pass the
unrecognized fields to the constructor.

Signed-off-by: Martin Vrachev <[email protected]>
This was referenced Feb 9, 2022
Closed
Merged
MVrachev added a commit to MVrachev/securesystemslib that referenced this issue Feb 16, 2022
@MVrachev
Add unrecognized fields support for Signature
d15a7d2 
The TUF specification says the following regarding unknown fields:
"All of the formats described below include the ability to add more
attribute-value fields to objects for backward-compatible format
changes. Implementers who encounter undefined attribute-value pairs in
the format must include the data when calculating hashes or verifying
signatures and must preserve the data when re-serializing."
From: https://theupdateframework.github.io/specification/latest/#document-formats

This section is the reason ADR0008 was accepted inside python-tuf
(see here: https://github.com/theupdateframework/python-tuf/blob/develop/docs/adr/0008-accept-unrecognised-fields.md)
and we have added support for unrecognized fields for all fields
inside the SIGNED portion of the metadata.
However, this limits what the citation implies or that everywhere there
inside the metadata files including signatures we should accept
unrecognized fields. That's why I made these changes.
These changes have the approval of the community see:
- theupdateframework/specification#203
- theupdateframework/python-tuf#1802

Another change I had to do, so I can add unrecognized fields support
inside Signature is to make "Signature.from_dict()" to behave the same
way as the rest of the "from_dict()" functions inside TUF or destroy
the input dictionary.
This was necessary, as that provides me with an easy way to pass the
unrecognized fields to the constructor.

Signed-off-by: Martin Vrachev <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@MVrachev @trishankatdatadog