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

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

Hi Job,

> On 19 Jan 2024, at 11:41, Job Snijders <job=[e-mail]> wrote:
> 
> On Fri, Jan 19, 2024 at 10:52:58AM +0100, Ties de Kock wrote:
>>> On 18 Jan 2024, at 23:03, Job Snijders <job=[e-mail]> wrote:
>>> Another pass was made over the text to improve the structure of the
>>> document and complete the surgery updates to RFC 6488. The
>>> "Implementation Status" section was also updated.
>> 
>> Can you clarify why the document now mandates that binary signing is
>> disallowed?
> 
> The document has consistently contained a proposal to disallow the
> binary signing-time attribute since its very first version, even before
> working group adoption (draft-spaghetti-sidrops-cms-signing-time-00,
> June 2023). The working group adopted that proposal.

I missed it and only this latest diff made it explicit. And this diff raises
more questions because imo the handling is now inconsistent.

>> This has significantimpact on implementations that are fully
>> conforming to rfc6488 and has a significant impact on those
>> implementations, effectively invalidating their test set of objects.
> 
> Indeed, RFC 6488 is updated and simpified. Preventing invalidation of a
> set of private objects which solely exist for regression testing seems a
> non-goal to me? It seems unsurprising to me that a full coverage test
> suite for 6488 objects may need to be updated if 6488 is updated.

I am fine with mandating the existence of signing time. That provides value now
that we have found a goal for that attribute that was unused until last year.

Based on the document, the reason to go further than mandating signing time is
aesthetics imo. In my opinion, based on the document, we lack motivation for
the further changes.

>> It also invalidates objects generated by public CA implementations if
>> a feature is enabled.
> 
> Extensive long-term quantitative research showed that no public
> Certification Authorities issue and publish Signed Object with a CMS
> binary signing-time attribute. The complete absence of the binary
> signing-time attribute in the global RPKI is a positive signal that it
> is feasible to formally disallow the attribute. I suspect that lack of
> support for binary signing-time in commonly used libraries contributed
> to binary signing-time's lackluster fashionability in the field.

I agree that implementations of 6488 have generally skipped the checks mandated
on signing time.

> 
>> Please elaborate on the improvement in security posture this gives iff
>> any.
> 
> There are more angles to consider than just security posture:
> disallowing the binary signing-time attribute simplifies implementations
> on both the signer and the RP side: instead of enumerating, parsing,
> checking for duplicate attributes, and also comparing the encoded
> timestamps against each other for both normal & binary signing-time
> attributes; after publication of this draft RPs merely need to confirm
> the absence of the binary signing-time attribute. To me this seems is a
> welcome simplification.

Now we are getting to the core of what confuses me. My read of the draft is that
binary signing time can still be present, just not in the set of signed
attributes (this would not comply to RFC6019, but implementations have ignored
RFC6019 in general so far). This draft may even introduce malleability this way.

How about:
  * Mandating that the binary signing time attribute MUST NOT be present (signed or unsigned).
    Yes, this is in RFC6019. But we no longer refer to that. And as you said,
    some RPs have not implemented those MUSTs because of a lack of library support.
  * Clarifying in security considerations that the previous profile allowed objects
    to have ambiguous singing time if the implementation was not standard
    compliant and this document prevents objects from having ambiguous signing time?