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

[Ties de Kock <[e-mail]>]

Hi Job,

> On 7 Jun 2023, at 17:15, Job Snijders <job=[e-mail]> wrote:
> 
> 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).
> 

There is one edge case in this behaviour that a mail from Tom made me think
off. It is far-fetched, but given that rsync not fetching a file likely breaks
a repository (and at a publication point that is likely to have many updates,
so high in the tree), I think it is worth considering.

It is similar to [0]: Multiple updates for an object per second (most likely
due to automation) can occur. They can occur in any timestamp in the object.

The only value almost guaranteed to be different between two objects is the
hash (p=1^(2^length)). We have serial numbers in objects, but in practice,
these may have a construction of `[serial][random-trailing-bits]`, which means
using part of them as-is is also fragile.

And, of course, we can mix approaches (e.g. [1], possibly leading to an
acceptable chance of a collision with semi-readable modification times.

Do we want to consider the time-collision case? Do we want to aim to have a
deterministic modification time resistant to collisions?

Kind regards, Ties

[0] https://mailarchive.ietf.org/arch/msg/sidrops/nFbjWawZ8R8uulSNCRLBVARtd_s/
[1] ((int(time.time()) >> 16) << 16) | (int.from_bytes(hashlib.sha256(b"object_payload").digest(), byteorder='big') %
2**16)