Re: [secdir] SecDir review of draft-ietf-sidr-publication-09

[Rob Austein <[e-mail]>]

Hi, Paul.  Thanks for the review!  Sorry about taking so long to get
back to you on it, but there was a bit more to yours than just "fix
these few nits".

I'm not going to attempt to answer point by point, because that would
drive us both nuts.  Instead, I'm going to answer a few specific
points, then let you see if the text changes I made are satisfactory.

Overall, this required a bit more new text than I would have preferred
at the end of Last Call, but I think you identified some missing
background information that needed adding, and none of the new text is
intended to change the protocol itself in any way, so I'm hoping this
will be acceptable to all parties.

To specific points, in no particular order:

* Authentication was covered in the doc, but I added a bit more text
  to make it a bit more obvious.  Authorization is a private matter
  between client and server operators (just as it would be when
  signing up for any application protocol, eg, an IMAP account), but I
  added a bit of text to make that more obvious too.

* See the new ASCII art in the introduction for how this protocol fits
  into the overall picture, and, in particular, why this protocol is
  indeed mostly concerned just with shipping RPKI objects between
  certificate engines and publication servers rather than what the
  RPKI relying parties do with those objects.

  Many thanks to Randy Bush for providing the ASCII art.

* We've been calling this the "RPKI publication protocol" for about
  ten years now, so, with respect, we would prefer not to change that.
  One could quibble about whether the ability to withdraw published
  objects is implied by the ability to publish both new and updated
  objects, but, really, it's a name, and it is what it is.

* Certificate Transparency is an interesting idea, and if somebody had
  raised it a year ago I might have been interested in exploring it,
  but we're dealing with a protocol that should have shipped years
  ago, which is now part of a bundle of other RPKI-related protocols,
  and which is trying to keep its use of CMS compatible with RFC 6492,
  so I'd really rather not go back to the drawing board on this one
  right now.  My preference would be to leave this as a topic for
  future work, to be handled in an updated specification if and when
  somebody gets a chance to look into it properly.

* "PDU" stands for "Protocol Data Unit". it's an old ITU term which
  entered the IETF lexicon via SNMP, IIRC.  Anyway, it's an
  RFC-Editor-blessed abbreviation, see:

  https://www.rfc-editor.org/materials/abbrev.expansion.txt

* We use [SHS] as the reference for SHA-256 because that's what
  somebody advised us to do, years ago.  I'm fine with changing that
  to RFC-4634 if that's what the IESG wants us to do this year.

* I did not take your recommendation on changing the examples.
  There's a very specific reason why we wrote the examples the way we
  did: because they're syntactically correct XML, we can run them
  through the RelaxNG schema checker to make sure we didn't mess up
  the syntax.  Your preferred form ("hash=<SHA256-Hash>" or whatever)
  would not pass that syntax check, so we'd be back to (error-prone)
  manual checking of the example syntax.  Been there, broke that.

  In an attempt to meet you part way on this, I added XML comments to
  some of the examples, which I hope will suffice to address this.

* The text already said that the various DER blobs are encoded in
  Base64, as does the schema.  Syntax of hash attributes is nailed
  down pretty tightly as hexadecimal in the schema but was not
  explicit in the text (oops): fixed, thanks!

* "<client/>" was an editorial oversight, it was old text that should
  have been removed at the same time as the mechanism to which it was
  referring was taken out (at the WG's request).  Thanks for catching
  that.

* "tags" in this protocol are transaction IDs, modeled roughly on the
  tags in IMAP4.   I added some text making this more explicit.


I have not yet submitted the updated I-D (-10).  Will do so tomorrow
unless I hear loud screaming, as our AD wants an updated I-D this
week.  For the moment, you can see the updated version and a diffs at:

https://subvert-ietf.hactrn.net/sidr-publication/draft-ietf-sidr-publication-10.txt
https://subvert-ietf.hactrn.net/sidr-publication/draft-ietf-sidr-publication-10-from-09.diff.html