Re: [Sidrops] [[e-mail]: New Version Notification for draft-spaghetti-sidrops-cms-signing-time-00.txt]

[Job Snijders <[e-mail]>]

On Wed, Jun 07, 2023 at 04:07:22PM +0200, Ties de Kock wrote:
> > On 7 Jun 2023, at 02:36, Job Snijders <job=[e-mail]> wrote:
> > The below internet-draft provides a reference for the concept outlined
> > in https://mailarchive.ietf.org/arch/msg/sidrops/I4-3BPR-r0vd6CguWxV-cLs3fyY/
> > 
> > This internet-draft describes a use-case for the CMS signing-time
> > attribute. From my perspective this internet-draft is complementary to
> > Tim & Ties' draft-timbru-sidrops-publication-server-bcp-00 document.
> > 
> > The main takeaways are:
> > 
> > - set the file's mod-time to the CMS signing-time on publisher and RP side
> > - CMS signing-time becomes mandatory for Signed Objects
> > - CMS binary-signing-time no longer is allowed
> > - 100% backwards compatibility with all CA operations in the field
> 
> I assume that you also want to change this MUST in RFC6488 2.1.6.4.3 (and
> the similar statement in 2.1.6.4.4):
> 
>    The signing-time attribute MAY be present.  Note that the presence or
>    absence of the signing-time attribute MUST NOT affect the validity of
>    the signed object (as specified in Section 3).  The attrType OID for
>    the signing-time attribute is 1.2.840.113549.1.9.5.

Thanks for catching that. We've updated the internet-draft accordingly.

> To me this process feels like a search for a use case for signing
> time.

It was suggested that the CMS signing-time attribute couldn't be used
for any purpose because it isn't mandatory. This internet-draft
addresses that, based on the observation that in practise the CMS
signing-time attribute is included by all CA operations anyway.

> In the intermediate period, tools writing consistent time need to
> fallback to not before. This makes not before a more elegant (as in,
> simple & neat) solution.

There are many ways to produce a 'consistent time', but more importantly:
(as far as I know) there never was a documented requirement in any RFC
for 'consistent time' on the RSYNC service. I suspect that in the past
people might have relied on implicit behavior, unaware of a future in
which RRDP came into existence which challenged some assumptinons.

The lack of specification in this regards seems to have resulted in:

* Some Publishers simply don't touch the files after signing as long as
  they aren't changed (another fine approach, rpki.net is an example)

* Some Publishers use notBefore (a valid option, as that indeed helps
  produce a consistent mod-time)

* and some Publishers appear to reset the mod-time of all objects every
  time an object is added/removed from their repository (not fine, as
  this produces the least seamless RRDP -> RSYNC failover)

> If you propose alternate behaviour for the transition, could you
> elaborate on it?

As far as I'm concerned there is no concept of a 'transition', other
than going from unspecified to specified behaviour.

CAs & Publishers might choose to wait until this internet-draft is
published as RFC before making any changes to how they do things, that's
up to them.

On the other hand, knowing that there now is at least one RP
implementation that actively attempts to do seamless RRDP -> RSYNC
failovers using the CMS signing-time attribute, Publishers could already
today take advantage of that by setting the mod-time to the CMS
signing-time, if it is present, and if absent - which seems unlikely -
do something else (like today).

> I do not think backdating is an argument against using not before. In
> your proposal, backdating MUST also be applied to not before.

Perhaps there is a misunderstanding. It wasn't my intention to express a
position (for or against) on the practise of backdating itself, the
reference to backdating in this context was intended to highlight that
operators using POSIX 'ls' to inspect the local cache might prefer and
expect to see a timestamp related to when the Signed Object purportedly
came into existence, rather than a (potentially backdated or
forward-dated) notBefore value.

> In practice, we have observed one of the faster RP implementations
> (rpki-prover) reject objects because due to minimal clockskew where
> validation started _the second before_ they were valid (RP ran on a
> machine using multiple stratum 1 NTP appliances as time server).
> 
> If a CA publishes fast, it must backdate to mitigate this issue if it
> wants to be resilient to minimal clock skew.

Yes.

Kind regards,

Job