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

From: Robert Wilton via Datatracker <[email-masked]>
Date: Thu, 03 Feb 2022 04:02:45 -0800

Robert Wilton has entered the following ballot position for
draft-ietf-sidrops-6486bis-09: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-sidrops-6486bis/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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.

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?

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?

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

Regards,
Rob

---

From: Job Snijders <[email-masked]>
Date: Fri, 11 Feb 2022 14:18:19 +0100

Dear Robert,

Thank you for you review and comments.

Do you have a suggestion?

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

> Would numerical object identifier, or numerical OID, be better than numerical

OK! thanks, changed.

> 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

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Fri, 11 Feb 2022 16:00:50 +0000

Hi Job,

Please see inline ...

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

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

> working group: https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-rpki-

OK, makes sense.

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

>                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