Hi,
>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.
>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.
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 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.
>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.
>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.
>Couldn't the section simply be called "SCEP Transaction Examples", or
>something?
Good idea, fixed.
Peter.
________________________________________
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