[sidr] #11: Nit Report - provisioning protocol

["sidr issue tracker" <trac at tools.ietf.org>]

#11: Nit Report - provisioning protocol
-----------------------------------+----------------------------------------
 Reporter:  gih at …                  |       Owner:     
     Type:  defect                 |      Status:  new
 Priority:  medium                 |   Milestone:     
Component:  rescerts-provisioning  |     Version:     
 Severity:  In WG Last Call        |    Keywords:     
-----------------------------------+----------------------------------------
 Oppose..

 Firstly, my initial observation is that the 'XML in ANS1 in CMS (signed)'
 transported in mutually validated and authenticated(*) HTTPS/TLS sessions
 appears somewhat weighty to cover MiTM/Repla given other parts of the
 entire
 RPKI system don't seem to have been given the same attention and remain
 untrusted?

 (*) you mean cross-certified? or some other way of mutually authenticated?

 Secondly, since this uses a PKI of some description, where is the
 description of the PKI (and CP?) for the signing of the CMS blobs and the
 PKI (and CP) for the TLS sessions. Are they the same? not the same? RPKI
 certs used? etc.

 Are there multiple fully interoperable server and client codebases based
 on
 this? Why I ask is the XML and the basic operations (list, issue, revoke)
 is
 simple enough - the killer space would be getting the multiple signing
 events right. ie which cert is used for the CMS, which is used for the
 TLS..
 and the ASN.1/CMS combo in order.

 lastly, the draft suggests "the server MUST NOT accept a client's request
 unless it has generated and sent a response to the client's previous
 request" - it appeard the _assumption_ made is that the client deals with
 the resources of only one entity. What if it deals with more? What if the
 ISP is representative of multiple organisations and wishes to do multiple
 updates in parallel?

 On to my nits:

 section 3.2:

 Please specify here the version of XML schema that this draft in its
 common
 message format uses (not just describes) and the section (section 4) that
 contains the xml schema. I think that it needs to be done prior to the
 introduction of the template and template values.

 http://www.apnic.net/specs/rescerts/up-down/ responds with a 404 (a pretty
 404, but a 404 nevertheless) So the namespace is invalid.

 I think I would like to see a summary table of all of the HTTP response
 codes used by this protocol.

 Section 3.5.1

 Looks like a wayward "]":

        ski="encoded hash of the subject public key]" />


 Cheers
 Terry

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/sidr/trac/ticket/11>
sidr <http://tools.ietf.org/sidr/>