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

[Christer Holmberg <[e-mail]>]

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 <[e-mail]>
Sent: Friday, 2 February 2018 02:42
To: [e-mail]; [e-mail]
Cc: [e-mail]; [e-mail]
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