Textual Encodings of PKIX, PKCS, and CMS Structures
RFC 7468

Note: This ballot was opened for revision 08 and is now closed.

(Richard Barnes) Yes

Comment (2014-12-17 for -09)
No email
send info
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) (was Discuss) Yes

Comment (2014-12-15 for -09)
No email
send info
- 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

(Kathleen Moriarty) Yes

(Jari Arkko) No Objection

(Alia Atlas) No Objection

(Benoît Claise) No Objection

Alissa Cooper No Objection

(Spencer Dawkins) No Objection

(Adrian Farrel) No Objection

Comment (2014-12-14 for -09)
No email
send info
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.

(Joel Jaeggli) No Objection

Barry Leiba No Objection

Comment (2014-12-13 for -08)
No email
send info
Pete has this in hand -- particularly the discussion of the ABNF for "label".

(Ted Lemon) No Objection

(Pete Resnick) No Objection

Comment (2014-12-13 for -08)
No email
send info
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

(Martin Stiemerling) No Objection