A Protocol for Provisioning Resource Certificates
draft-ietf-sidr-rescerts-provisioning-11

There are several places throughout the draft where the word "will" gets used in a strange way. I suspect it is just a writing style the authors use, but I wanted to make sure that some of these were not protocol directives, as against simple descriptions of protocol actions:

- Section 3 (note my *hilighting*):

   [...]  The server's response *will* similarly be the body
   of the response with a content type of "application/rpki-updown".

   The content of the POST, and the server's response, *will* be a "well-
   formed" CMS [RFC5652] object, encoded using the Distinguished
   Encoding Rules for ASN.1 (DER) [X.509-88], formatted in accordance
   with the CMS profile specified in the following section. [...]

   The protocol's request / response interaction is assumed to be
   reliable, in that all requests *will* generate a matching response.
 
For example, in the first, do you simply mean, "The server's response is the body of the response", or do you rather mean, "The server's response MUST be the body of the response"? In other words, are you giving directions to generating implementations here, or simply describing behavior that receiving implementations can expect?

I found similar examples in 3.3.2 (the two paragraphs after the payload definition and the last sentences of the descriptions of resource_set_as, resource_set_ipv4, resource_set_ipv6, [issuer's certificate]), 3.4.1 ("will (re)set the issuer's local record"), 3.6 ("will make a best effort" -- which sounds like a SHOULD -- and "The en-US description will always be included").

  The Gen-ART Review by Vijay Gurbani on 23-Aug-2011 includes an
  editorial suggestion:

  I think it will be helpful to identify either in the Abstract or in
  Terminology section what exactly is a "resource".  I do not think you
  mean traditional HTTP resources like files or dynamically generated
  content, etc.

-- these were discuss points but are ok as comments following discussion
Most of these are just checking if the WG thought about stuff so 
should be easily cleared up, except maybe the last one.

(1) In 3.1.1.4 the verifier is expected to be able to find CA certs
that aren't supplied. I'm not trying to insist on any particular thing 
here, but the more you specify for this the easier it is to get interop 
so did the WG consider e.g. insisting that if any CA certs are supplied
then there must be a complete path in some specific order or
something like that? The same thing applies for crls - if its
possible to be more specific then that's better. If the WG thought
about this, and the use cases are such that you can't really say
more here, then that's ok but I wanted to check.

(2) 3.1.1.5 says the crls field MUST be present. That would
preclude a signer that never sees CRLs that might include their
cert. Is that intentional? Is it a good idea? (I'll clear if you say
yes to both but wanted to check.) 

(3) In 3.1.2 you say again that the crls field has to be there, but
you never say that it has to contain a reasonable CRL - would it be
ok if I added some random CRL to this field that has nothing to do
with my signer cert? (Assuming the verifier finds the right CRLs
somehow.)

(4) You don't say that the [Binary]SigningTime has to be within the
EE cert validity, nor that it can be outside the EE cert validity.
I don't mind which you want, but saying what's allowed there would 
be good. If anything is allowed, then saying that would
be good too. Without having checked, I think I recall some other PKI
implementations that have been over strict or overly loose in this
respect in the past which led to some interop glitches.

-- these are the original comments

1) This has a relatively baroque layering, with HTTP carrying CMS
containing XML possibly containing pkcs#10 etc. I guess that design
is driven by the availability of tools and libraries for those. If
so, it'd be good to say that (and maybe even hint where to get such
tools, not sure) so the reader gets the right impression. If not,
then I'm left wondering why a new protocol doing all that with one
encoding scheme (ASN.1 or XML or whatever) wouldn't have been 
a good bit simpler.

(2) The abstract just talks about "resources" but for sidr those are
just routing and addressing information (or however you like to put
it) and not e.g. web resources. It'd be better maybe to make that
clear in the abstract in case someone picks up this RFC and thinks
they can use it for other things. (I know its clear when you get
to section 2, but it'd be nice to save people having to read that
far if they're not going to be able to use this.)

(3) In 3.1.1.4 you say that certificates MUST contain the signer
cert but you don't say it can't contain two certs for
the signer. Later in 3.1.1.6.2 you do say the sid MUST have the
skid from "the" EE cert and in 3.1.2 you say there has to be just
one, but saying so would be nice in 3.1.1.4 as well.

(4) You say that SigningTime and BinarySigningTime have to represent
the same time. I didn't check the references to be sure but do e.g.
the equivalents for "20110819"  and "201108191614" represent the
same time or not? If both have to be at 1-second granularity or
something then just saying that here would be good.

(5) What is an "operator alert error"? (in 3.2) Maybe just "error"
is enough or it ought be defined?

(6) Checks 1, 4, 5 and 6 from 3.2 (p15) replicate stuff from 3.1
which seem unnecessary.

(7) In 3.2, check 3 you say "this server's" which seems wrong for
the case where the client is checking a response.

(8) The end of p22 is the first place it says that you can't use the
same key pair for >1 resource. Could you could add a reference to
some other sidr document that describes this in more detail? It
might also be useful to state this rule earlier.

(9) 3.3 could really do with some overview text saying briefly who
sends what to whom and why. For example, in 3.3.2 it is not clear
whether the client is asking the server for a list belonging to
the client or to the server, at least not until I parsed the fairly
hard-to-get text at the end of p17;-) That overview text might 
all be in some other sidr document, but having it here would 
be good.