Textual Encodings of PKIX, PKCS, and CMS Structures
draft-josefsson-pkix-textual-10
Yes
(Kathleen Moriarty)
No Objection
(Alia Atlas)
(Alissa Cooper)
(Benoît Claise)
(Jari Arkko)
(Joel Jaeggli)
(Martin Stiemerling)
(Spencer Dawkins)
(Ted Lemon)
Note: This ballot was opened for revision 08 and is now closed.
Kathleen Moriarty Former IESG member
Yes
Yes
(for -08)
Unknown
Richard Barnes Former IESG member
Yes
Yes
(2014-12-17 for -09)
Unknown
I could not ballot YES more emphatically. I can't tell you the number of times I've looked for a spec for "PEM formatted $FOO". With that in mind: Should this document formally update PEM, and become the new official spec for PEM-encoded objects? Have the relevant communities been involved to make that a reasonable option? Section 3: Is there a way to modify the "base64finl" production to ensure it maxes out at 64 characters? I'm not enough of an ABNF wizard to know.
Stephen Farrell Former IESG member
(was Discuss)
Yes
Yes
(2014-12-15 for -09)
Unknown
- intro, para about alg agility - why is this here? I'd say it could be deleted. - intro, the example about cut'n'paste of cert chains is misleading isn't it? What format actually allows that? Isn't the actual practice that the whole chain is b64 encoded and so can't just be catenated? - intro, s/M. Rose/Marshall Rose/ would be better - [X509SG] reference - I thought Peter had a more easily referencable version of this published somewhere. That might help with the RFC editor. I'd suggest asking Peter if there's a better ref to use in addition. (I'd also say that that URL has been stable for quite a long time when you're asked, but I'm sure the RFC editor will nonetheless be unhappy with it for the usual not-bad reasons:-) - section 2, 2nd para: you say it's ok if the labels on the BEGIN and END don't match, but then you say that there (implicitly) MUST be 5 dashes at the end - why is laxity ok for one part of the END line but not another? - section 8: degenerative is wrong unless pkcs#7 has a bone disease or something:-) "specific" would do instead I'd say. - section 14, last para: "namely" is wrong, I think you only need to say "e.g.," as there could be mnay possible canonical forms, not just DER. Or saying "most commonly, DER" would also be ok I think. - The author's way of handling the comments doesn't work for me to track the secdir review [1] responses, but the I don't think there was anything there that can't be handled between author and reviewer. [1] https://www.ietf.org/mail-archive/web/secdir/current/msg05268.html
Adrian Farrel Former IESG member
No Objection
No Objection
(2014-12-14 for -09)
Unknown
The Abstract says: This document is intended to articulate the de-facto rules that existing implementations operate by, and to give recommendations that will promote interoperability. ...yet the document is on the Standards Track. Actually, I think that Standards Track is fine, but that this wording is too floppy. You could have... This document articulates the de-facto rules by which existing implementations operate, and defines them so that future implementations can interoperate.
Alia Atlas Former IESG member
No Objection
No Objection
(for -09)
Unknown
Alissa Cooper Former IESG member
No Objection
No Objection
(for -09)
Unknown
Barry Leiba Former IESG member
No Objection
No Objection
(2014-12-13 for -08)
Unknown
Pete has this in hand -- particularly the discussion of the ABNF for "label".
Benoît Claise Former IESG member
No Objection
No Objection
(for -09)
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
(for -09)
Unknown
Joel Jaeggli Former IESG member
No Objection
No Objection
(for -09)
Unknown
Martin Stiemerling Former IESG member
No Objection
No Objection
(for -09)
Unknown
Pete Resnick Former IESG member
No Objection
No Objection
(2014-12-13 for -08)
Unknown
Mostly editorial, but a couple of substantive comments on the ABNF: 2 - OLD Whitespace MAY appear between the pre-encapsulation boundary and the base64, but generators SHOULD NOT emit such whitespace. NEW Whitespace, carriage returns, and linefeeds can appear between the pre-encapsulation boundary and the base64, but generators SHOULD NOT emit such characters. It's not clear that "CR" and "LF" are included in the word "Whitespace". Also notice the change from "MAY" to "can"; that MAY appears to contradict the SHOULD. If you want, you can add a "MUST ignore" for parsers. 3 - A reference to RFC 5234 would be useful, noting that you are importing ALPHA, DIGIT, WSP, CR, LF, and CRLF. There is no "::" in ABNF. A slight simplification: OLD label ::= labelchar *(labelchar / labelchar "-" / SP) labelchar NEW label = labelchar *(labelchar ["-"] / SP) labelchar So, do you really want to require a minimum of 2 labelchars? If not, you could instead have: label = labelchar [*(labelchar ["-"] / SP) labelchar] That would allow for a single labelchar label. Also, do you really want to allow as many spaces as desired between the first labelchar and the last? If you only want to allow one space: label = labelchar *(labelchar ["-" / SP]) labelchar And again put everything after the first labelchar in square brackets if you want to allow for a single labelchar. Editorial: OLD This specification RECOMMENDS that new implementations emit the strict format (Figure 2) specified above. NEW New implementations SHOULD emit the strict format (Figure 2) specified above. 5.1, 6, 7, 10, 11, 12, 13 - Editorial: OLD (DER [strongly] preferred) NEW (DER [strongly] preferred; see Appendix B) 5.1 - Editorial: OLD are NOT RECOMMENDED to NEW SHOULD 5.3 - Editorial: OLD This Internet-Draft RECOMMENDS that the extension ".crt" be used NEW the extension ".crt" SHOULD be used 6 and 8 - Editorial: OLD Parsers are NOT RECOMMENDED to NEW Parsers SHOULD NOT
Spencer Dawkins Former IESG member
No Objection
No Objection
(for -09)
Unknown
Ted Lemon Former IESG member
No Objection
No Objection
(for -09)
Unknown