TUF expiry contains microseconds

[jku]

From TUF specification:

The expected format of the combined date and time string is "YYYY-MM-DDTHH:MM:SSZ". Time is always in UTC, and the "Z" time zone designator is attached to indicate a zero UTC offset. An example date-time string is "1985-10-21T01:21:00Z".

To me this says that the expiry string should not contain microseconds. Current sigstore metadata contains microseconds: https://github.com/sigstore/root-signing/blob/main/repository/repository/2.root.json#L27

I'm not sure if defining expiry this strictly in the spec is useful but the definition seems clear and in python-tuf we currently implement the spec strictly so fail to deserialize this metadata.

The related python-tuf issue (we'll have to decide if we should support msecs or not): theupdateframework/python-tuf#1858

[asraa]

Oooh nice! Thank you for finding this -- I can set to truncate at seconds

[tetsuo-cpp]

@jku When you truncated to seconds, did you end up getting this error in python-tuf?

ValueError: ('Could not deserialize key data. The data may be in an incorrect format, it may be encrypted with an unsupported algorithm, or it may be an unsupported key type (e.g. EC curves with explicit parameters).', [_OpenSSLErrorWithText(code=151584876, lib=9, reason=108, reason_text=b'error:0909006C:PEM routines:get_name:no start line')])

I'm just wondering whether that's what caused you to open theupdateframework/python-tuf#1866 or whether I'm hitting a different issue.

[jku]

I mean yes I found both issues while I was doing a manual interop testing round -- the issue you found is a related one: our error handling was quite poor.

Current state to my knowledge is:

• metadata with ecdsa keys created by go-tuf is not specification compliant: ecdsa keyval.public format is hex-encoded DER, should be PEM theupdateframework/go-tuf#223
• python-tuf does not have workarounds to support this non-compliant format: compatibility: go-tuf ecdsa key format is incompatible theupdateframework/python-tuf#1859. I'm not completely opposed to adding support if it's possible to handle in an obviously correct way

[tetsuo-cpp]

Ah thanks @jku, that makes sense. I missed the key format issues.

[asraa]

Going to make a separate issue about the ECDSA key format -- this will be tough because root keys will have different key IDs if we immediately switching the encodings.