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

[Job Snijders <[e-mail]>]

On Fri, Jan 19, 2024 at 12:25:56PM +0100, Ties de Kock wrote:
> >> 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.

On the contrary - while revisiting 6488's formal signing time
requirements, it makes a lot of sense to simplify closely related data
fields. For example removing the requirement for RPs to (if both of
these attributes are present), check whether they provide the same date
and time is a welcome simplification. On top of that the binary
signing-time attribute does not appear in the global RPKI, so no CAs
become noncompliant, making this an easy win.

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

RFC 6488 section 2.1.6.7 already forbids the presence of unsigned
attributes entirely. The draft at hand does not change this requirement.
Rpki-client checks for the presence of unsigned attributes and treats
objects as invalid if the count is non-zero.

Additionally, RFC 6019 forbids binary signing-time to be an unsigned
attribute, unauthenticated attribute, or unprotected attribute.

RFC 5652 section 11.3 explicitly forbids normal signing-time to be an
unsigned attribute, unauthenticated attribute, or unprotected attribute.

I don't see how malleability is introduced.

>   * 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?

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.

Kind regards,

Job