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
_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
