Subject: Re: [saag] Comment added to draft-gutmann-scep history

From: Alexey Melnikov <[email-masked]>
Date: Mon, 14 Jan 2019 14:04:37 +0000

Hi Peter,
My apologies of dropping the ball on this. My replies below:

On 13/07/2018 09:49, Peter Gutmann wrote:
> Alexey Melnikov <[email-masked]> writes:
> 
>> 1) I need help with you flagging to me which text was modified in the past
>> due to comment. I might agree or disagree with these changes and they might
>> be highlighting sections which might need more work anyway.
> 
> Ahhh... how much of a list do you want?  There's an awful lot of emails to go
> through (maybe two years' worth of comments) to sort it all out, and most of
> it is pretty uninteresting.  If you're OK with dealing with it on a case-by-
> case basis (e.g. "this particular bit of text was based on comments about X
> and Y") that would make it easier.
> 
>> If you can convince me that #2 is not an issue, then I suggest adding a note
>> to the document saying that it is using a bunch of MIME types that are not
>> registered (or have different registered aliases, but used here for historic
>> reasons). I am happy to suggest some text.
> 
> That would be good, thanks.  Since it's a case of "Types in this tree cannot
> be registered", I don't see how they could be registered without renaming
> them, which breaks compatibility with all existing implementations, and the
> primary goal of the draft was to keep it bits-on-the-wire identical to what's
> been in use the entire time (modulo single DES + MD5 vs. AES + SHA-2).

Add a new paragraph to the end of Introduction:

Note that SCEP doesn't follow best current practices on usage of HTTP.
In particular, it is using unregistered Media Types, it recommends
ignoring Media Types and hardcoding spefic URI paths.

> In terms of:
> 
>> 2) if I have a general Web Server that happens to return different MIME types
>> here (because there are other already registered MIME types that mean the same
>> thing), is this going to be a problem for SCEP clients?
> 
> I don't think so for two reasons, firstly I'm not aware of anyone actually
> doing SCEP using a standard web server, it's always a standalone SCEP
> application that isn't a web server (if anyone is implementing SCEP as a CGI
> for a conventional web server, please speak up, I've never heard of one), and
> secondly I don't know if anyone actually looks at the MIME types.  I wouldn't
> want to put money on that, no doubt some client or other will break if you
> change the strings, but I'd say that a lot of clients won't care what the
> value is.
>
>> I think either ABNF (which is pretty universally used in IETF RFCs) or in
>> free text form which sort of looks like HTTP request line, but isn't. Please
>> pick one and I can suggest some small specific edits to reflect that.
> 
> That would be really useful, thanks.  I think ABNF is best.

Below are all ABNF related changes that I suggest. (Examples in your
document are not affected):

Add a new sentence to the end of:

1.1.  Conventions Used in This Document

  This document uses the Augmented Backus-Naur Form (ABNF) notation as
specified
  in [ABNF] for defining formal syntax of commands.
  Non terminals not defined in this document (for example "HTTP-version")
  are defined in either [ABNF] or [RFC7230].

2.1.1.  Client

Replace:
OLD:
   2.  The CA HTTP CGI script path (this usually has a default value,
       see Section 4.1).

NEW:
   2.  The CA HTTP SCEP path (this usually has a default value,
       see Section 4.1).

3.5.1.  GetCACaps HTTP Message Format

Replace:
OLD:
   This message requests capabilities from a CA, with the format:

   "GET" CGI-PATH CGI-PROG "?operation=GetCACaps"

NEW:
   This message requests capabilities from a CA, with the format:

   "GET" SP SCEPPATH "?operation=GetCACaps" SP HTTP-version CRLF

4.1.  HTTP POST and GET Message Formats

Replace:

OLD:
   SCEP uses the HTTP "POST" and "GET" messages to exchange information
   with the CA.  The following defines the syntax of HTTP POST and GET
   messages sent from a client to a CA:

   "POST" CGI-PATH CGI-PROG "?operation=" OPERATION
   "GET" CGI-PATH CGI-PROG "?operation=" OPERATION "&message=" MESSAGE

   where:

   o  CGI-PATH defines the path to invoke the CGI program that parses
      the request.
   o  CGI-PROG is set to be the string "pkiclient.exe".  This is
      intended to be the program that the CA will use to handle the SCEP
      transactions.
   o  OPERATION depends on the SCEP transaction and is defined in the
      following sections.

   The CA will typically ignore CGI-PATH and/or CGI-PROG since it's
   unlikely to be issuing certificates via a web server.  Clients SHOULD
   set CGI-PATH/CGI-PROG to the fixed string "/cgi-bin/pkiclient.exe"
   unless directed to do otherwise by the CA.  The CA SHOULD ignore the
   CGI-PATH and CGI-PROG unless its precise format is critical to the
   CA's operation.

NEW:
   SCEP uses the HTTP "POST" and "GET" HTTP methods [RFC7230] to
   exchange information with the CA.  The following defines the ABNF
   syntax of HTTP POST and GET methods sent from a client to a CA:

   POSTREQUEST = "POST" SP SCEPPATH "?operation=" OPERATION SP
                 HTTP-version CRLF

   GETREQUEST = "GET" SP SCEPPATH "?operation=" OPERATION
                "&message=" MESSAGE SP HTTP-version CRLF

    where:

    o  SCEPPATH is the HTTP URL path for accessing CA.
       Clients SHOULD set SCEPPATH to the fixed string
       "/cgi-bin/pkiclient.exe" unless directed to do otherwise by
       the CA.

    o  OPERATION depends on the SCEP transaction and is defined in the
       following sections.

    o  HTTP-version is the HTTP version string, which is "HTTP/1.1" for
[RFC7230].

    o  SP and CRLF are defined in [ABNF].

And finally you add ABNF RFC (RFC 5234) and RFC 7230 (HTTP/1.1) to the
Normative References section.

> 
>> I would like to use ABNF terminal for this and only explain that the path is
>> typically as you describe only in one place in the document. 
> 
> OK, will that be part of the text above?  If you've got some appropriate
> wording to put in that'd be helpful.
> 
>> As above: pick between ABNF and free form text and I can suggest some
>> specific edits.
> 
> ABNF, thanks.
> 
>> So AES and SHA-2 are absolutely Normative references.
> 
> OK, I've added AES and SHA-2 refs.
> 
>> I am actually Ok with no mentioning ACME, but the text in the introduction
>> reads like it is arguing that SCEP is the best thing since bread and butter
>> and I don't believe what it is trying to say is accurate.
> 
> Hmm, it's just saying that it's widely used, which is why it's being
> documented, it doesn't try and claim it's particularly good... the comparisons
> to CMP and CMC didn't appear until draft 17, with more changes in wording
> around draft 22.  As far as I know this wording was purely political, PKIX
> wanted everyone to use their CMP or CMC protocols and so the references were
> added to appease PKIX.  Since the market appears to have made their choice
> between { CMP, CMC, SCEP }, it's probably easiest to just remove any mention
> of them, so that I don't have to engage in a comparative analysis of who knows
> how many different management protocols (there's a lot more than CMC and CMP
> out there now).  So I can just remove that entire paragraph apart from the
> first sentence and merge that with the previous paragraph:
> 
> -- Snip --
> 
> X.509 certificates serve as the basis for several standards-based security
> protocols such as <xref target="TLS">TLS</xref>, <xref target="SMIME">
> S/MIME</xref>, and <xref target="IKEv2">IKE/IPsec</xref>.  When an X.509
> certificate is issued there typically is a need for a certificate management
> protocol to enable a PKI client to request or renew a certificate from a
> Certificate Authority (CA).  This specification defines a protocol, Simple
> Certificate Enrolment Protocol (SCEP), for certificate management and
> certificate and CRL queries.
> 
> -- Snip --
> 
> That's a pretty basic statement of functionality without trying to get into a
> comparative analysis of a load of different protocols and mechanisms, and one
> which will hopefully upset the least number of people.

This text looks much better to me.

>>> I have no idea... I mean I literally have no idea, I don't know what
>>> implementations do in practice.  I know that in some cases with manual
>>> approval it can take hours, but I'm not sure if that's typical.  It could be
>>> seconds, minutes, hours...
>>
>> I suspect you will get a blocking DISCUSS comment on this in IESG review. But
>> if you want to take your chances, I am Ok with no change.
> 
> I've added the following, which formalises what's in the above sentence:
> 
>   The frequency of the polling operation is a CA/client configuration issue,
>   and may range from seconds or minutes when the issue process is automatic
>   but not instantaneous, through to hours or days if the certificate issue
>   operation requires manual approval.

This is better, thank you.

Best Regards,
Alexey

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 23 Jan 2019 01:36:24 +0000

>My apologies of dropping the ball on this. My replies below:

Thanks, working on the update now.  Should I send a copy back to you to check
it's OK, or just post the new draft?

Peter.

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 23 Jan 2019 10:28:25 +0000

Hi Peter,

> On 23 Jan 2019, at 01:36, Peter Gutmann <[email-masked]> wrote:
> 

Just post a new draft.

Thank you,
Alexey

---

From: Peter Gutmann <[email-masked]>
Date: Sun, 27 Jan 2019 12:45:26 +0000

OK, just posted it with (hopefully) all changes as requested, one small
difference is that I've put the HTTP note in section 4 which talks about HTTP
use:

   This section describes the SCEP Transactions and their HTTP [6] transport
   mechanism.

where it's more likely to be noticed than if it's tacked onto the
introduction.  I've also extended it a bit to point to the upcoming BCP-56,
which contains a lot of good advice on use of HTTP as a substrate:

-- Snip --

Note that SCEP doesn't follow best current practices on usage of HTTP.  In
particular, it uses unregistered Media Types, it recommends ignoring Media
Types and hardcoding specific URI paths.  Guidance on the appropriate
application of HTTP in these circumstances may be found in

REF: "Building Protocols with HTTP", draft-ietf-httpbis-bcp56bis-08, Mark
Nottingham, November 2018,
https://tools.ietf.org/html/draft-ietf-httpbis-bcp56bis-08.

-- Snip --

Before the final version is published I'll go through it one more time to
align it with draft-BCP-56bis as much as possible, mostly a reference to
section 4.5.1 on the use of GET vs POST.

Peter.

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 28 Jan 2019 12:11:48 +0000

Hi Peter,

> https://tools.ietf.org/html/draft-ietf-httpbis-bcp56bis-08.
That would be fine. Please post a new revision that includes this text.
> section 4.5.1 on the use of GET vs POST.

Ok.

Best Regards,

Alexey

---

From: Peter Gutmann <[email-masked]>
Date: Mon, 28 Jan 2019 23:02:22 +0000

>That would be fine. Please post a new revision that includes this text.

Argh, sorry, that should have already been in there but I didn't copy the text
across after writing it up in the email message.  Fixed now in -13:

4.  SCEP Transactions

   This section describes the SCEP Transactions and their HTTP [7]
   transport mechanism.

   Note that SCEP doesn't follow best current practices on usage of
   HTTP.  In particular, it uses unregistered Media Types, it recommends
   ignoring Media Types, and hardcodes specific URI paths.  Guidance on
   the appropriate application of HTTP in these circumstances may be
   found in [12].

Peter.