[dtn] BPSec COSE Context and long-lived security

["Sipos, Brian J." <[e-mail]>]

All,

While reasoning about some of the processing needed for BPSec COSE context
[1] I ran into an interesting nuance caused by the long-lived and dynamic
nature of BP and BPSec. The situation is this:

1.	A bundle is created at some time, and it has an explicit source
timestamp
2.	Security blocks are added at some point later on
3.	Even later, a verifier needs to check a BIB containing a signature
using a public key contained in a certificate referenced by a thumbprint
(meaning it identifies the actual cert not just the subject name).
4.	Part of the verification is certificate path validation, with
details below

 

According to the procedure of Section 2.6.1.2. of [1] which defers to
Section 6 of RFC 5280, which includes basic processing step [2] of:

(a)(2) The certificate validity period includes the current time.

 

For online protocols, using the current time as a verification point is
sensible but for BPSec (as well as other store-and-forward like email) there
is not really a bounded relationship between the creation time and the time
of any other processing of the bundle (i.e. adding security blocks during
its lifetime). I would love to say "take the same behavior as S/MIME
verification" but although S/MIME does have the notion of a "signing time"
[3] that spec is silent about how the time is supposed to be used.

 

A new "security source time" parameter could be added to help verifiers to
know what time should be checked for, but this time is informational and not
really a trustworthy timestamp (not any more than the rest of the security
source data) like [6]. It looks like some implementations allow overriding
the verification time [4] but others do not [5], so maybe just mandating to
not compare certificate validity time interval is the right way to handle
it. COSE x509 parameters [7] are also silent about this aspect and I will
write the COSE WG separately about this.

 

Any thoughts, or references for similar handling in different situations?

 

[1] https://www.ietf.org/archive/id/draft-ietf-dtn-bpsec-cose-03.html

[2] https://www.rfc-editor.org/rfc/rfc5280#section-6.1.3

[3] https://datatracker.ietf.org/doc/html/rfc8551#section-2.5.1

[4]
https://github.com/openssl/openssl/blob/master/crypto/x509/x509_local.h#L23

[5]
https://github.com/Mbed-TLS/mbedtls/blob/development/library/x509_crt.c#L250
4

[6] https://www.ietf.org/id/draft-ietf-cose-tsa-tst-header-parameter-02.html

[7] https://www.rfc-editor.org/rfc/rfc9360.html