Telechat Review of draft-gutmann-scep-08

Request Review of draft-gutmann-scep
Requested rev. no specific revision (document currently at 16)
Type Telechat Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2018-03-06
Requested 2018-01-25
Authors Peter Gutmann
Draft last updated 2018-01-25
Completed reviews Opsdir Telechat review of -10 by Susan Hares (diff)
Genart Telechat review of -08 by Christer Holmberg (diff)
Genart Last Call review of -09 by Christer Holmberg (diff)
Assignment Reviewer Christer Holmberg
State Completed
Review review-gutmann-scep-08-genart-telechat-holmberg-2018-01-25
Reviewed rev. 08 (document currently at 16)
Review result Ready with Nits
Review completed: 2018-01-25


I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please wait for direction from your
document shepherd or AD before posting a new version of the draft.

For more information, please see the FAQ at


Document: draft-gutmann-scep-08
Reviewer: Christer Holmberg
Review Date: 2018-01-25
IETF LC End Date: None
IESG Telechat date: 2018-03-08

Summary: The document is well written, and almost ready for publication. However, there are some issues (mostly editorial) that I would like the authors to address.

Major issues: None

Minor issues: None

Nits/editorial comments: 

Section 1:


The text says:

   “While widely deployed, this protocol omits some certificate
   management features, e.g. certificate revocation transactions, which
   may enhance the security achieved in a PKI.”

I suggest to remove the “While widely deployed” part. I assume you refer to the Cisco protocol that SCEP is based on. If so, I suggest that you move the following sentence from the Abstract to the Introduction:

   “SCEP is the evolution of the enrolment protocol sponsored by Cisco Systems, which
   enjoys wide support in both client and server implementations, as
   well as being relied upon by numerous other industry standards that
   work with certificates.”

In the Abstract, I think it is enough to keep the following: 

   "SCEP is the evolution of the enrolment protocol sponsored by Cisco Systems."

Then, you can also remove the following from the Introduction:

   "so that it enjoys widespread support and ready interoperability across a range of platforms"

…or combine it with the sentence above.


Doesn’t the "While implementers are encouraged to…" sentence belong to the Security Considerations?

Section 2.1.2:


The text says:

   "A CA MAY enforce any arbitrary policies and apply them to certificate
   requests, and MAY reject any request."

The "MAY reject any request" parts sounds unfinished. I assume it’s refers to cases where the client don’t support such arbitrary policies? If so, I suggest to explicitly say so. 

Currently it sounds like a generic CA-may-reject-any-request statement, which I assume is not what you intend to say :)

Section 2.1.3:


As the text talks about certificate distribution, is this really a subsection to section 2.1? 


The 4th paragraph contains a couple of SHOULDs. Is there a reason they can’t be MUST?

Section 4.1:


The 5th paragraph talks about how early versions of the draft used GET messages for all communication.

The text also says: 

“If the remote CA supports it, any of the CMS-encoded SCEP messages SHOULD be sent via HTTP POST instead of HTTP GET.”

If the remove CA supports what? HTTP POST?

Why SHOULD, and not MUST?

…and later:

   "If a client or CA uses HTTP GET and encounters HTTP-related problems
   such as messages being truncated, seeing errors such as HTTP 414
   ("Request URI too long"), or simply having the message not sent/
   received at all, when standard requests to the server (for example
   via a web browser) work, then this is a symptom of the problematic
   use of HTTP GET.  The solution to this problem is typically to move
   to HTTP POST instead."

If the client understands to use POST if GET fails, why can’t it use POST to begin with?

In general, what is the reason for having this text about early versions of the draft? Backward compatibility with CAs that will only support GET?

Section 5:


The title of the section talks about state transitions, but then the text says that the section contains examples.

Is there a reference to the state machine(s) that are represented in the examples? OR, does the section define the state machine(s)?

If the main purpose of the section is to show example flows, I think the title of the section should be "Examples".

Section 6:


The text says “previous editors” and “earlier editors”. Please pick one and use it in both places :)