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

From: Christer Holmberg <[email-masked]>
Date: Thu, 1 Feb 2018 13:42:09 +0000

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

---

From: Peter Gutmann <[email-masked]>
Date: Sun, 4 Feb 2018 14:39:58 +0000

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.

>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 <[email-masked]>
Sent: Friday, 2 February 2018 02:42
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: [FORGED] Re: [Gen-art] Genart telechat review of draft-gutmann-scep-08

Hi,

---

Ok.

---

---

---

---

Ok.

---

---

Ok.

Regards,

Christer

---

From: Peter Gutmann <[email-masked]>
Date: Sun, 4 Feb 2018 14:42:02 +0000

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.

Peter.

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 4 Feb 2018 16:52:05 +0000

Hi,

(I include your reply to yourself in this reply)

Summary: All my issues have been addressed. 

>>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:
>
> 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.
>
> 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 ...
>

Your suggestion above solves my issue. Thanks!

>>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 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.

>>I think it would be good. 

Thanks!

>  such as a direct comparison with a locally-stored copy of the certificate.

Looks good.

> 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:
>

Looks good.

>> Couldn't the section simply be called "SCEP Transaction Examples", or something?
>
> Good idea, fixed.

Thanks!

Regards,

Christer

Hi,

>>However, there are some issues (mostly editorial) that I would like 
>>the authors to address.
>
>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
>not sure  myself what should go in there, and I'm welcoming any 
>suggestions...
>
>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.
>
>(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.

---

>>the Security Considerations?
>

Ok.

---

>>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 :)
>
>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.

---

>>subsection to section 2.1?
>

---

>>can¹t be MUST?
>example they may be hardcoded into the client (that's actually not 
>uncommon in SCADA use), in which case there's nothing to verify.

---

>>SHOULD be sent via HTTP POST instead of HTTP GET.²
>>
>>POST to begin with?
>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?
>

---

>>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)?
>
>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 :)
>
>between  the people who wrote it (authors) and those who came later and 
>merely edited  the original authors' work (editors).

Ok.

Regards,

Christer