I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the


security area directors. Document editors and WG chairs should treat these comments just like any other last call comments.

This document describes a mechanism for digitally signing Routing Policy Specification Language (RPSL) objects. The digital signatures are intended to ensure authenticity and integrity protection of such objects when they are transferred to and from resource databases.

- The signature scheme is a little unusual in that the signature attribute lists the names of the attributes that are part of the signature rather than just including those attributes (and their values) as part of the signature attribute itself; I assume this is due to a need to preserve established RPSL object syntax but it doesn't seem required for this application which essentially is a transport format. The cost here is, of course, the need to duplicate the names of the signed attributes in the signed RPSL object (once for the regular attribute value and once for the value in the signature attribute).

- There is an expectation that relying parties fetch the signer's certificate based on a URL in the signature attribute. This may be a dangerous practice, since the URL needs to be contacted before the signature can be validated. A malicious party may insert a URL that will lead to an attack. I suggest this be noted in the Security Considerations section with some suggested best practice, e.g., only https and careful parsing of the retrieved resource.

- The Signature Method field - how are new algorithms identified? Is there no need for protocol action / IANA action to register new algorithm for use with this memo?

-- As for the canonicalization, this is an inherently complicated field. It does not, for example, seem as if the memo describes how to canonicalize multi-valued attributes. The ordering of such values may well be implementation-dependent post object parsing and thus, the canonicalization should cover how to order sets or sequences of values.

- The last paragraph of the Security Considerations brings up an important point but provides no guidance to an implementer how to handle this case / detect the situation. Preferably some advice should be given here.

Editorial / questions:

Section 1:

- "This means when downloading a   Routing Policy Specification Language (RPSL) object stored in this   database, one can reasonably safely claim that the object is   authentic, but for an imported object one cannot." Two points: First part of sentence likely misses a "that." Secondly, what's referred to with "this" database?

- "A maintainer   of such signed database objects MUST possess a relevant resource   certificate, which shows him/her as the legitimate holder of an   Internet number resource." Why does a maintainer of objects need to possess a resource certificate? I think the party generating signed database objects need such a certificate, but not necessarily all maintainers?

Section 2:

- "When verifying the signature of an object, the verifier has to check   whether the signature itself is valid, and whether all the specified   attributes are referenced in the signature." What "specified" attributes?

- It would be very helpful with a full example, not just an outline as in 2.3.

- Section 2.4 talks about multiple signatures. I believe this is the only place where this is done, and it is also confusing given that earlier text stated that each attribute (and the signature is an attribute too), must be present "at most once"?

Section 5:

- The certificate shouldn't be used for more than one verification - was the intent to say that the private key associated with the public key present in the certificate shouldn't be used to sign more than one RPSL object? It seems difficult to state that a certificate can be used for verification only once - multiple relying parties may verify it, for example (note: I am not too familiar with RFC 6487 so may be missing something here).

-- Magnus