search

auth0-lab / mdl

Parse and validate MDOC CBOR encoded binaries according to ISO 18013-5.
Apache License 2.0
83 stars 5 forks source link

Validity timestamp truncation #21

Closed dalebowie closed 1 month ago

dalebowie commented 1 month ago

As a caller to the library I can addValidityInfo that includes specific timestamps. It appears during encoding these timestamps are truncated. Whilst one could interpret this truncation as broadly in alignment with the standard's guidance around linkability (see second-last paragraph on page 51 of ISO/IEC 18013-5:2021(E)), should that truncation really be done when the caller's input is specifying their own values?

I admit it is a limited window where this is problematic, but in the current implementation, I can:

  1. At GMT 9am get a certificate signed for intended use with this library
  2. At GMT 3pm use this library to generate an mdoc with current timestamp and the certificate obtained above.
  3. The produced mdoc then fails to validate because its signed date is truncated to GMT midnight, well before the GMT 9am when the certificate is valid for.

My thought on a fix might be two-fold:

  1. If timestamps are specified via addValidityInfo, then no truncation should occur.
  2. At signing time, the timestamps are auto-generated and truncated if not previously supplied via addValidityInfo. Whatever timestamps are present (either auto-generated or caller-specified) are validated against the certificate timestamps to ensure an invalid mdoc isn't produced.
siacomuzzi commented 1 month ago

Let me investigate this further, given that we are using an external library for cbor encoding.

dalebowie commented 1 month ago

I figured it might have been related to the custom extension logic here for dates: https://github.com/auth0-lab/mdl/blob/main/src/cbor/index.ts#L15-L25

siacomuzzi commented 1 month ago

Let me explain why we are using that CBOR tag for Dates...

ISO 18013-5 (section 7.2.1) defines the following data elements for mDL:

Identifier Encoding format
birth_date full-date
issue_date tdate or full-date
expiry_date tdate or full-date

And it specifies "full-date" as full-date = #6.1004(tstr), where tag 1004 is specified in RFC 8943. Which is the CBOR tag for a text string representing a date without a time:

"issue_date": 1004("2018-08-09"),
"expiry_date": 1004("2024-10-20")
siacomuzzi commented 1 month ago

I guess we could include an option to use the tdate encoding format instead of full-date for issue_date and expiry_date elements.

siacomuzzi commented 1 month ago

Now, for validityInfo structure, you are right... the signed, validFrom, validUntil and expectedUpdate attributes must be tdate (Tag 0), instead of full-date:

"validityInfo": {
  "signed": 0("2022-04-15T06:23:56Z"),
  "validFrom": 0("2022-04-15T06:23:56Z"),
  "validUntil": 0("2027-01-02T00:00:00Z")
},

We have to fix that.

github-actions[bot] commented 1 month ago

:tada: This issue has been resolved in version 1.5.0 :tada:

The release is available on:

Your semantic-release bot :package::rocket: