Hi Terry, On 30/10/2009, at 2:00 PM, Terry Manderson wrote:
> 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? I think this has already been sufficiently discussed by the WG, I won't add further to it here. > 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. This is addressed in the final bullet point of section 2, which states that this is outside the scope of this specification. I believe Rob also addressed this in his earlier response. > 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. Again I believe Rob has talked about this. > 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? The terminology in section 1.1 defines a client as a unitary resource holder. If one ISP is representative of multiple entities it will take the part of multiple clients. > 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. The document notes in section 4 that this is a "RelaxNG compact form schema". For future note, should it become necessary to provide a reference to this schema, http://www.relaxng.org/compact-20021121.htmlis the syntax specification document for RNG-C. > http://www.apnic.net/specs/rescerts/up-down/ responds with a 404 (a pretty > 404, but a 404 nevertheless) So the namespace is invalid. The relevant observation here is that in XML the "namespace name, to serve its intended purpose, should have the characteristics of uniqueness and persistence. It is not a goal that it be directly usable for retrieval of a schema (if any exists)." [Section 3, "Declaring Namespaces", http://www.w3.org/TR/xml-names/] > I think I would like to see a summary table of all of the HTTP response > codes used by this protocol. Its not clear how a reproduction of section 10 of RFC2616 would assist the reader of this document. > Section 3.5.1 > > Looks like a wayward "]": > > ski="encoded hash of the subject public key]" /> Noted as a nit to be corrected in the next version. Thanks, Byron _____________________________________________________________________ Byron Ellacott email: b...@apnic.net Technical Area Manager, APNIC sip: b...@voip.apnic.net http://www.apnic.net phone: +61 7 3858 3100 _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
