Subject: [sidr] Working Group Last Call - draft-ietf-sidr-rescerts-provisioning-05.txt

From: Sandra Murphy <[email-masked]>
Date: Thu, 29 Oct 2009 17:57:29 -0400 (Eastern Daylight Time)

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

---

From: Terry Manderson <[email-masked]>
Date: Thu, 29 Oct 2009 21:00:39 -0700

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" <[email-masked]> wrote:

> _______________________________________________
> sidr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidr