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

[Job Snijders <[e-mail]>]

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.

> 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.

> 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.

> 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.

Kind regards,

Job