A Publication Protocol for the Resource Public Key Infrastructure (RPKI)
draft-ietf-sidr-publication-11

Summary: Has 2 DISCUSSes. Has enough positions to pass once DISCUSS positions are resolved.

Terry Manderson Discuss

Discuss (2017-01-17 for -10)
Updating after reading sidr-oob-setup-06.

I see that the publisher wins as per Section 5.2.4 <repository_response/>

My original discuss us below, so you may omit the concern about negotiating the URI. The remainder stands.

Thanks
T.

=-=-=-=-=-=-=-=-
Thanks for finally bringing this protocol forward.

I support Alissa's and Alexey's concerns.

I only have one discuss for this draft.

Looking at section 4, operational considerations I was expecting to see a review of any considerations as to how this protocol works, the interaction between the layers of HTTP, CMS, and XML and any implementation differences/difficulties that exist between the 2 known implementations. Instead there is a discussion on laying out the repository structure under the mandatory to implement _retrieval_ mechanism (RSYNC) and the nuances of RSYNC itself. This appears to be misplaced as the protocol (HTTP/CMS/XML) interactions here are simply about publication from a certificate authority operator to a repository operator, and in that space surely the publication protocol (this doc) is agnostic to the exact repo structure.

In both a database world (not a file based one) and where multiple RPKI fetch mechanisms (rsync, http, torrent, etc ...) are used, how is the exact URI meaningful for sidr-publication? There might be a deeper problem here regarding any potential collisions and negotiation of the URI space between the certificate authority operator and the publication repository operator. (sure, in a situation where Alice does both, no problem.) So you may wish to address issues like that in the operational considerations section as opposed to dealing with RSYNC (in)efficiencies.

Alexey Melnikov Discuss

Discuss (2017-01-18 for -10)
I support Alissa's DISCUSS point on versioning.

I find the document to be a bit short on normative references and some implementation details. Other than that the document looks fine. My specific questions and concern are as follows:

1) Please add a normative reference for HTTP, URI and RelaxNG on first use.

2) Base64 needs a normative reference (including the section number, as there are 2 variants).

3) Section 2 says that all payloads use CMS. None of your examples show CMS. Can you please elaborate on how CMS is used?

4) How can URI of the service be discovered?
Comment (2017-01-18 for -10)
In 2.5: is the list of error reasons extensible?

Was Relax NG schema validated with a tool?

In Section 5 you should reference this document (and not just section numbers), as IANA registrations cut & pasted to IANA website as separate files.

Joel Jaeggli Yes

Alvaro Retana Yes

Jari Arkko No Objection

Alia Atlas No Objection

Deborah Brungard No Objection

Ben Campbell No Objection

Comment (2017-01-18 for -10)
Most of my comments have already been made by others. But with the questions about upgrade paths, I see there is in fact a "version" element defined. How is that expected to be used? I don't see a version related error code.

Benoit Claise No Objection

Alissa Cooper (was Discuss) No Objection

Comment (2017-02-22)
Thanks for addressing my DISCUSS.

Spencer Dawkins No Objection

Stephen Farrell (was Discuss) No Objection

Comment (2017-02-22)
Thanks for addressing my discuss about alg agility.

Suresh Krishnan No Objection

Mirja K├╝hlewind No Objection

Comment (2017-01-16 for -10)
My only question is why this is a sidr wg doc? This seems like a general mechanism that cannot only be used in the routing infrastructure. Has this doc been at least reviewed by other wgs?

Kathleen Moriarty No Objection

Comment (2017-01-18 for -10)
Thanks for addressing the security directorate review.

As for Alissa's comment on transport, more language added to the Security Considerations section would be helpful to explain why the CMS signature is sufficient.  I am assuming that the only exposure would be to public information during transport that is protected from tampering, unless I missed something in reading the draft (I don't think you are transferring private keys and didn't see that in the text).

Security controls being managed according to the CA policy mentioned earlier in the document is appropriate, having run CAs before - there are strict requirements already depending on the level you plan to run the CA.