Re: [Sidrops] require signing-time in draft-ietf-sidrops-signed-tal objects?

[Job Snijders <[e-mail]>]

Hello Ties,

On Wed, Mar 08, 2023 at 01:56:39PM +0100, Ties de Kock wrote:
> >>> In Section 4 add something along the lines of:
> >>> 
> >>>  * The CMS Signing-Time Attribute MUST be present in the
> >>>    signedAttrs in the signerInfos.
> >> 
> >> Could you use NotBefore and serial number of the EE certificate -
> >> since those are always present?
> > 
> > The presence of the signing-time attribute would not affect the
> > validity of the signed object, in contrast to the X.509 NotBefore.
> > Using signing-time adds more resolution to the TAK generation &
> > publication process.
> 
> I am do not think it adds additional information over notBefore (which
> ought to be present).

But it does, it is additional metadata offering insight into the signing
process. Take for example this object:
https://sola.sobornost.net/repository.lacnic.net/rpki/lacnic/003bf825-b144-476d-89c7-4987bdc328da/b99c2d0aaf83f09f48e194657d6d608a8273fa7d.roa.html

X.509 Validity, Not Before: Fri 24 Apr 2022 03:00:00 +0000
CMS Signing time:           Fri 13 Jan 2023 23:31:02 +0000

The object was first observed in the rpkiviews archives in this snapshot: 
http://josephine.sobornost.net/josephine.sobornost.net/rpkidata/2023/01/14/rpki-20230114T000632Z.tgz
(the previous snapshot, rpki-20230113T233631Z.tgz did not contain this ROA)

> But both notBefore and signing-time would contain a very similar time?

Perhaps, perhaps not. The above example shows notBefore and signing-time
differ significantly. The rpkiviews data suggests the CMS signing time
indeed very likely was the time the object was signed.

> > RFC 6488 2.1.6.4.3 / 2.1.6.4.4 already specifies the CMS attribute
> > is optional, so all draft-ietf-sidrops-signed-tal has to do is make
> > it non-optional for TAK objects.
> 
> My experience when I was working with the BBN conformance objects was
> that the implementation of signed attribute validation in RPs is weak.

Can you elaborate on what exactly the weaknesses were?

> An implementor explained that that in some cases this had to do with
> APIs not being available in libraries; 6488 has very specific
> requirements, and especially binary signing time has extremely limited
> support.

Yeah, not a single CA in the RPKI ecosystem is using binary signing
time. However *all* Signed Objects contain a CMS signed signing-time
attribute. I would not recommend to mandate binary signing-time.

> I would not rely on signing time if possible.

RFC 6488 states in Section 3 requirement g: "the signing-time
attribute MAY be present, but they are not required"

If the TAK specification indicates the signing-time attribute is
non-optional, I can rely on the data field's existence.

Ofcourse, I can't rely on the contents of the field being 'true' (it is
not a trusted timestamp) - but the contents can aid in debugging and
monitoring efforts.

All (~189,000) Signed Objects under the 5 RIRs contain a CMS
signing-time attribute. My suggestion merely is to make the CMS
signing-time attribute non-optional in the case of TAKs.

Kind regards,

Job