Should we allow unrecognized fields for the signatures dictionaries? #1802
Comments
MVrachev
added
the
discussion
|
Lets decide this before 1.0 release (with the understanding that we might just decide to postpone) |
|
Quoting myself in sslib issue:
Because of this I think allowing unrecognised fields in signature does not significantly increase risk Oh and the reason why we might want to do this: I believe supporting fulcio certificates/signatures requires extending the metadata. If unrecognised fields are not supported that would mean python-tuf 1.0 might not be able to read metadata written by python-tuf 1.x with fulcio support |
|
cc @asraa who may have insight into the Fulcio signatures. When using canonical json, it's true that adding an additional field doesn't increase the risk, because we are already doing some somewhat risky parsing. If we switch to a format like DSSE, we'll want to avoid adding additional fields to the signature that could make the implementation vulnerable to a canonicalization attack. |
|
To complete the options here: If we allow unrecognised_fields in Signature then there's nothing preventing allowing them in Metadata itself as well. |
It was majorly convenient adding a cert field to the signature -- +1 |
|
Together in a discussion with @jku and @lukpueh we agreed that it makes sense to implement unrecognized fields inside |
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]>
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]>
|
|
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]>
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]>
|
Okay, my bad, I misunderstood. |
|
I will close this issue as it's related to a |
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]>
Description of issue or feature request:
In ADR 8 we follow the Document formats section of the specification and allow unrecognized fields at each level of the metadata files.
The question is do we want to allow unrecognized fields inside the
signaturesdictionaries?Are there possible security issues to that?
For context see the specification issue on the matter: theupdateframework/specification#203
The text was updated successfully, but these errors were encountered: