A Protocol for Provisioning Resource Certificates
Note: This ballot was opened for revision 11 and is now closed.
(Stewart Bryant) Yes
(Jari Arkko) No Objection
(Ron Bonica) No Objection
(Wesley Eddy) No Objection
(Adrian Farrel) No Objection
(Stephen Farrell) (was Discuss) No Objection
-- 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 188.8.131.52 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) 184.108.40.206 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 220.127.116.11 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 18.104.22.168.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 22.214.171.124 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.
(David Harrington) No Objection
(Russ Housley) No Objection
Comment (2011-08-24 for -)
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.
(Pete Resnick) No Objection
Comment (2011-08-24 for -)
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").