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

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

> On 19 Jan 2024, at 13:17, Job Snijders <job=[e-mail]> wrote:
> 
> 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.

I was going off my memory here. Our implementation of PRKI parsing in rpki
commons (and thus the ripe validator if anyone still runs that, if so: migrate
from this unsupported software ASAP) treats CMS with unsigned attributes as
invalid as well.

For those using the BBN conformance objects,
538 SigInfoUnSigAttrs        # has unsigned attribute 6488#2.1.6.7

I could easily update a test environment to use unsigned attributes in the top
level manifest if there is any interest in that.

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

Iff people implemented RFC 6019 there would be no downside in having either
type possible.

We effectively live in a world where, for most implementations, RFC 6019 does
not exist. That makes that I would not want to rely on anything in that
document.

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

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"