>However, there are some issues (mostly editorial) that I would like the
>authors to address.
One comment on this, I didn't write the original text so I'll try and
accommodate as much as possible, but in some cases I've had to guess at what
the original authors intended. Also, the explanations for several of the
points raised in the questions is "it was like that when I got here". So in
the following, when I respond with another question, it's because I'm not sure
myself what should go in there, and I'm welcoming any suggestions...
Another general point, because this has spent close to twenty years in draft
status, it's been a de facto standard for most of that time so there are
"standards-compliant" implementations that have been in use for more than a
decade based on the draft. Because of this, I've had to be very careful to
avoid breaking things by introducing a MUST or MUST NOT after nearly two
decades of something not being a MUST. This is why, in some places, there's a
SHOULD with strong hints rather than a MUST.
The primary goal for this was to make it bits-on-the-wire compatible (apart
from the unavoidable single DES + MD5 -> AES + SHA-2), and to minimise
(ideally not to have any) breakage with deployed code. So there are places
where there are weasel-words ("we know you've been doing this for fifteen
years but you probably shouldn't any more"), and others where I've retained
text that I wouldn't have put in there if I'd been the one writting the doc.
>Q1:
>
>[Editing changes]
I've had a go at changing this, but no matter what I do just ends up as the
same wording shuffled around, I end up just moving bits from one location to
another (it's already gone through a number of re-wordings across different
drafts). If there's a specific goal that you're aiming for with the changes I
can try and hit that, but I just ended up saying more or less the same thing
with different phrasing.
>Q2:
>
>Doesn’t the "While implementers are encouraged to…" sentence belong to the
>Security Considerations?
It's not a security consideration, unless I'm missing something it only
discusses functionality and interoperability issues.
>Q3:
>
>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 :)
That's exactly what it's meant to say: "You can ask for anything you want, but
the CA isn't obligated to comply with your request".
(Also: "It was like that when I got here").
>Q4:
>
>As the text talks about certificate distribution, is this really a subsection
>to section 2.1?
"It was like that when I got here". I can make it a non-subsection if it
reads better that way.
>Q5:
>
>The 4th paragraph contains a couple of SHOULDs. Is there a reason they can’t
>be MUST?
There are many ways to verify certs, those are just suggestions. For example
they may be hardcoded into the client (that's actually not uncommon in SCADA
use), in which case there's nothing to verify.
>Q6:
>
>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?
Yes, fixed.
>Why SHOULD, and not MUST?
See the note about introducing breakage.
>If the client understands to use POST if GET fails, why can’t it use POST to
>begin with?
It was meant to say (subtly) "if you're seeing these problems then perhaps
it's time you updated your code". I've changed the text to make this more
explicit:
The solution to this problem is to update the implementation to use HTTP
POST instead.
>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?
Yes. Not just CAs but major implementations like Microsoft's NDES.
>Q7:
>
>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)?
"It was like that when I got here". It's supposed to illustrate state
transitions, so it's both a diagram and an example of what's supposed to
happen. I'm reluctant to start rewriting that to any extent because, well,
would you want to start poking around in there?
>Q8:
>
>The text says “previous editors” and “earlier editors”. Please pick one and
>use it in both places :)
It's actually "earlier authors", and it was deliberate, to distinguish between
the people who wrote it (authors) and those who came later and merely edited
the original authors' work (editors).
Peter.
________________________________________
From: Christer Holmberg <christer.holmberg@xxxxxxxxxxxx>
Sent: Friday, 26 January 2018 07:19
To: gen-art@xxxxxxxx
Cc: draft-gutmann-scep.all@xxxxxxxx; ietf@xxxxxxxx
Subject: [FORGED] Genart telechat review of draft-gutmann-scep-08
Reviewer: Christer Holmberg
Review result: Ready with Nits
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
<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
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:
----------
Q1:
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.
Q2:
Doesn’t the "While implementers are encouraged to…" sentence belong to the
Security Considerations?
Section 2.1.2:
--------------
Q3:
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:
--------------
Q4:
As the text talks about certificate distribution, is this really a subsection
to section 2.1?
Q5:
The 4th paragraph contains a couple of SHOULDs. Is there a reason they can’t be
MUST?
Section 4.1:
------------
Q6:
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:
----------
Q7:
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:
----------
Q8:
The text says “previous editors” and “earlier editors”. Please pick one and use
it in both places :)