Last Call Review of draft-josefsson-pkix-textual-07

Request Review of draft-josefsson-pkix-textual
Requested rev. no specific revision (document currently at 10)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2014-12-01
Requested 2014-11-06
Authors Simon Josefsson, Sean Leonard
Draft last updated 2014-12-04
Completed reviews Genart Last Call review of -07 by Suresh Krishnan (diff)
Genart Telechat review of -08 by Suresh Krishnan (diff)
Secdir Last Call review of -07 by Magnus Nystrom (diff)
Assignment Reviewer Magnus Nystrom 
State Completed
Review review-josefsson-pkix-textual-07-secdir-lc-nystrom-2014-12-04
Reviewed rev. 07 (document currently at 10)
Review result Has Nits
Review completed: 2014-12-04


I have reviewed this document as part of the security directorate's 
ongoing effort to review all IETF documents being processed by the 


 These comments were written primarily for the benefit of the security 
area directors. Document editors and WG chairs should treat these 
comments just like any other last call comments.

This memo documents textual encodings of various well-established PKI-related data structures and formats. The document is intended to be published as a Standards-Track RFC.

Comments and suggestions:

Section 5.1:

 - For clarity and common keyword usage, suggest replacing "The encoded data MUST be a BER (DER strongly preferred) encoded ASN.1..." with: "The encoded data MUST be BER and SHOULD be a DER encoded ASN.1..." (In fact this comment goes for all places where you have text like "MUST be a BER (DER [strongly] preferred" - better to use established RFC 2119 language).

- I wonder why you state "Parsers are NOT
   equivalent to "CERTIFICATE", but a valid exception may be for
   backwards compatibility (potentially together with a warning)" since to my knowledge, they all refer to the same structure and in the spirit of "strict in issuance, generous in receipt", it would seem to be better to state: ""Parsers MAY treat ... as equivalent to "CERTIFICATE" " ?

- I also wonder about the warning above since if the structure indeed does parse as a certificate, what value would the warning bring (and to whom)?

Section 5.3:

I disagree with the deprecation of .cer in favor of .crt. The .cer convention is used broadly. I would suggest updating the text to recommend use of .crt OR .cer. Better yet, remove the section, since this document specifically is about textual encodings and not file extension naming and you do not discuss extension naming elsewhere.

Section 6:

Same comments as for Section 5.1 above, but for CRLs...

Section 7:

Same comment as my first for Section 5.1. I note that you have the same language with regards to parser flexibility here that I have suggested for Section 5.1 and Section 6.

Security Considerations:

No particular comments.


-- Magnus