Hi,
(I include your reply to yourself in this reply)
Summary: All my issues have been addressed.
>>Maybe some text about all that somewhere (e.g., in the Introduction
>>section, or in a dedicated "History" section)?
>
> The "Background Notes" section already contains a pretty complete (without going overboard) history and notes
> on what changed. What I can do if this will help is add a reference at the start:
>
> (see the <xref target="background">Background Notes</xref> section for more
> on the history behind SCEP and the nearly two decade-long progress of this
> standard)
>
> I think moving a large amount of text about the history of the draft into the introduction would make it a bit
> messy, particularly since the Background Notes section contains extensive comments on how things have changed
> over time, it's a couple of pages long.
>
> Replying to my own message: The proposed text would then read:
>
> This specification defines a protocol, Simple Certificate Enrolment Protocol (SCEP), for certificate management and
> certificate and CRL queries. While widely deployed (see the <xref target="background">Background Notes</xref> section
> for more on the history behind SCEP and the nearly two decade-long progress of this standard), this protocol ...
>
> which I think explains the nature of the "widely-deployed" comment while not overloading things with a huge load of historical commentary.
Your suggestion above solves my issue. Thanks!
>>Sure, but the text doesn't give any guidance on why it would reject the
>>request. Since the sentence is in the same sentence talking about
>>policies I assume the rejection would be if the policies are not fulfilled.
>
> It's up to the CA, thus the use of the catch-all "policies". It's meant to warn the client that a request won't automatically
> result in a cert being issued, but doesn't constrain the CA in any way. The CA could reject or modify the request for any
> reason, or perhaps for no reason, their HSM is offline, they're having a bad hair day, their network is down, ... it's just to
> warn the client "don't automatically expect a cert back", but I can't really enumerate all the possible reasons why a rejection could happen.
I think it's obvious (or, at least not specific to this mechanism) that a CA might reject a request (for whatever reason), but if you want to keep the text I won't argue :)
>If you like I can change the text to:
>
> A CA MAY enforce any arbitrary policies and apply them to certificate
> requests, and MAY reject a request for any reason.
>
>if that makes it clearer.
It's better :)
Not sure whether the MAYs should be with capital letters, though, as the draft doesn't define the procedures of the CA, but I'll leave that to others to comment on.
>>>"It was like that when I got here". I can make it a non-subsection if
>>>it reads better that way.
>>
>>I think it would be good.
>
>OK, fixed.
Thanks!
>>Since you use "SHOULD", it sounds more like just suggestions.
>
> OK, I've changed it to make the alternative explicit:
>
> After the client gets the CA certificate, it SHOULD authenticate the
> certificate by comparing its fingerprint with the locally configured, out-
> of-band distributed, identifying information, or by some equivalent means
> such as a direct comparison with a locally-stored copy of the certificate.
Looks good.
>>I think it would be good to mention that.
>
> I've read through it again and I think a better solution is your original one, make it a MUST. If the CA indicates
> it supports POST then there's no need to use GET, so it can be changed to a MUST:
>
> If the remote CA supports POST, the CMS-encoded SCEP messages MUST be sent
> via HTTP POST instead of HTTP GET.
Looks good.
>> Couldn't the section simply be called "SCEP Transaction Examples", or something?
>
> Good idea, fixed.
Thanks!
Regards,
Christer
________________________________________
From: Christer Holmberg <christer.holmberg@xxxxxxxxxxxx>
Sent: Friday, 2 February 2018 02:42
To: gen-art@xxxxxxxx; pgut001@DOMAIN.HIDDEN
Cc: draft-gutmann-scep.all@xxxxxxxx; ietf@xxxxxxxx
Subject: [FORGED] Re: [Gen-art] Genart telechat review of draft-gutmann-scep-08
Hi,
>>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.
Maybe some text about all that somewhere (e.g., in the Introduction section, or in a dedicated ³History² section)?
>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.
I just think it sounds weird to talk about a widely deployed protocol that you are just about to publish.
But, maybe with some history (see previous comment) it would become more clear.
---
>>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.
Ok.
---
>>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".
Sure, but the text doesn¹t give any guidance on why it would reject the request. Since the sentence is in the same sentence talking about policies I assume the rejection would be if the policies are not fulfilled.
---
>>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.
I think it would be good. The text itself doesn¹t change, soŠ
---
>>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.
Since you use ³SHOULD², it sounds more like just suggestions.
---
>>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.
Ok.
>>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.
I think it would be good to mention that.
---
>>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?
I just think it¹s strange to talk about "state transitions" without any reference to a state machine (in fact, there seems to be two state machines - one for the client and one for the CA).
Couldn¹t the section simply be called ³SCTP Transaction Examples², or something?
---
>>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).
Ok.
Regards,
Christer