Re: [Gen-art] Genart telechat review of draft-gutmann-scep-08

[Christer Holmberg <[e-mail]>]

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