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 On 30/10/09 7:57 AM, "Sandra Murphy" <sa...@sparta.com> wrote: > This WG chair has received a Working Group Last Call request from an > author of > > A Protocol for Provisioning Resource Certificates > > draft-ietf-sidr-rescerts-provisioning-05.txt > > which has an intended status of Standard Track. > > > All versions, past and present, are available at > > http://tools.ietf.org/wg/sidr/draft-ietf-sidr-rescerts-provisioning > > The Last Call will end as of the close of business on Monday 23rd November > - this is a longer period than a conventional 2 week last call period in > order to include the forthcoming SIDR WG meeting at IETF 76. > > As usual, please address all comments to the WG mailing list, and please > be clear in your comments to this last call if you are supporting the > document's submission to the IESG or if you are opposed, or if you are not > expressing a view either way. > > As for the other Standards Track documents, the chairs would like to > request the document's authors to prepare an interoperability report. > > > > --Sandy > > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
