Re: [Sidrops] I-D Action: draft-ietf-sidrops-cms-signing-time-03.txt

[Russ Housley <[e-mail]>]

Thanks for the flurry of messages discussing this document.  Please post a new version of the document.  Once that appears, we can begin a WG Last Call.

For the SIDRops Chairs,
 Russ


> On Jan 19, 2024, at 9:28 AM, Ties de Kock <[e-mail]> wrote:
> 
> Hi Job,
> 
>> On 19 Jan 2024, at 15:23, Job Snijders <[e-mail]> wrote:
>> 
>> On Fri, Jan 19, 2024 at 02:19:57PM +0100, Ties de Kock wrote:
>>>> Aren't all bets off when implementations are noncompliant? :-)
>>>> 
>>>> I think I agree with the gist of what you're saying, but I'm not
>>>> entirely sure what to add that's not already covered by existing
>>>> literature.
>>> 
>>> Let’s add the local improvement somewhere in the doc, maybe security
>>> considerations? “the status quo is that most implementations are not compliant
>>> with RFC 6019, this causes signing time to be ambiguous when interoperating
>>> between implementations"
>> 
>> How about this?
>> 
>> https://github.com/job/draft-sidrops-cms-signing-time/commit/9f43dfa84f7293dc547d46154f0f5296fd5533fe
>> 
>> -----------------------------------------
>> 5.  Security Considerations
>> 
>>  No requirement is imposed concerning the correctness of the signing
>>  time attribute.  It does not provide reliable information on the time
>>  the signature was produced and it bears no relevance for seamless
>>  switchover between RRDP and rsync.
>> 
>>  While the Security Considerations in [RFC6019] mandate that the
>>  signing-time and binary-signing-time attributes, if both present,
>>  MUST provide the same date and time; a potential for ambiguity is
>>  removed by restricting the RPKI Signed Object profile to have only
>>  one field to store the purported signing time.
>> -----------------------------------------
> 
> Nice one. For me this expresses the the motivation for this more clearly in this
> document.
> 
> -Ties