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

["Rob Wilton (rwilton)" <[e-mail]>]

Hi Job,

Please see inline ...

> -----Original Message-----
> From: Job Snijders <[e-mail]>
> Sent: 11 February 2022 13:18
> To: Rob Wilton (rwilton) <[e-mail]>
> Cc: The IESG <[e-mail]>; [e-mail]; morrowc@ops-
> netman.net; [e-mail]; [e-mail]
> Subject: Re: [Sidrops] Robert Wilton's No Objection on draft-ietf-sidrops-
> 6486bis-09: (with COMMENT)
> 
> 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?

I guess that I was thinking of something like this:

    When a new manifest is issued before the time specified in nextUpdate,
    then it also issues a new CRL that revokes the EE certificate corresponding
    to the old manifest, as described in the nextUpdate field is section 4.2.1.

I.e., it keeps the RFC 2119 MUST to just one place in the draft rather than repeating it.

Feel free to use, modify, or even disregard as you see fit.  This isn't a big issue ...


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

OK, makes sense.


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

Okay, but note that when reading this draft, I wouldn't have anticipated this being so long.  Putting something like (e.g., 10 minutes or more) might give the reader some more context.  But like the previous comment, I'm happy to leave this to the authors discretion.  Alternatively, perhaps include an informative reference to https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-rpki-rov-timing ? 

> 
> > 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 ;-)

I can't argue with that :-)

Just reading the URL was sufficient to know what the message would be ...

Thanks,
Rob


> 
> Kind regards,
> 
> Job