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

[Alexey Melnikov <[e-mail]>]

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

On 13/07/2018 09:49, Peter Gutmann wrote:
> Alexey Melnikov <[e-mail]> 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