Re: [Sidrops] Robert Wilton's No Objection on draft-ietf-sidrops-6486bis-09: (with COMMENT)

[Job Snijders <[e-mail]>]

Dear Robert,

Thank you for you review and comments.

On Thu, Feb 03, 2022 at 04:02:45AM -0800, Robert Wilton via Datatracker wrote:
> ----------------------------------------------------------------------
> 
> Thanks for this document, just a couple of minor comments:
> 
> 1) Section 4.2.1. Manifest
> 
>    nextUpdate:
>       This field contains the time at which the next scheduled manifest
>       will be issued.  The value of nextUpdate MUST be later than the
>       value of thisUpdate.  The specification of the GeneralizedTime
>       value is the same as required for the thisUpdate field.
> 
>       If the authority alters any of the items that it has published in
>       the repository publication point, then the authority MUST issue a
>       new manifest.  Even if no changes are made to objects at a
>       publication point, a new manifest MUST be issued before the
>       nextUpdate time.  Each manifest encompasses a CRL, and the
>       nextUpdate field of the manifest SHOULD match that of the CRL's
>       nextUpdate field, as the manifest will be re-issued when a new CRL
>       is published.  When a new manifest is issued before the time
>       specified in nextUpdate of the current manifest, the CA MUST also
>       issue a new CRL that revokes the EE certificate corresponding to
>       the old manifest.
> 
> Although this last sentence is not wrong, am I right in thinking that this
> sentence isn't specific to when the manifest is issued, i.e., isn't it the case
> that that CA MUST issue a new CRL whenever a new manifest is issues for any
> reason (e.g., as per 5.1, step 2)?  If so, perhaps this sentence could be
> tweaked to make that clearer.

Do you have a suggestion?

> 2) 5.2.  Considerations for Manifest Generation
> 
>    A new manifest MUST be issued and published before the nextUpdate
>    time.
> 
> Should any guidance be given about how far before the nextUpdate time
> a new manifest should be issued.  E.g., is publishing right at the
> nextUpdate time (e.g., 1 millisecond before) sufficient , or does it
> make sense to publish it a bit earlier than the nextUpdate time?

Such guidance is perhaps better provided through the "Timing Parameters"
internet-draft effort which is currently being progressed through the
working group: https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-rpki-rov-timing

Compared to RFC 6486, the -bis guidance provides clarity on the aspect
that a new version of the manifest must be issued *before* nextUpdate,
and not on the collapse of the event horizon. CA operators understand
that takes it takes anywhere between 10 minutes and 2 hours to
distribute newly generated signed information to RPs; but this is still
an area of study and active research by R. Bush et al.

> Nits:
> 
> 4.1.  eContentType
> 
>    The eContentType for a manifest is defined as id-ct-rpkiManifest and
>    has the numerical value of 1.2.840.113549.1.9.16.1.26.
> 
> Would numerical object identifier, or numerical OID, be better than numerical
> value here?

OK! thanks, changed.

> 4.2.  eContent
> 
> I would have preferred for "file" to be "filename" in the structure, but I
> presume that this can't be changed at this stage anyway ...

I too would've preferred that, however...

               https://sobornost.net/~job/ship.gif ;-)

Kind regards,

Job