[saag] Another AD review of draft-gutmann-scep-10

[Alexey Melnikov <[e-mail]>]

Hi,

Kathleen passed AD-sponsorship of this document to me. So here is 
another review of the document:

In general the document is quite readable and contains enough details to 
implement a SCEP client/server. However it is rather light on 
references. I don't think readers need to fallback to google in order to 
find them. (I identified some of the most important ones below). The 
document also violates several HTTP related conventions. I am glad that 
this document is Informational, as the bar for Standards Track is higher.

Major issues:

1) In general, the document is using several unregistered MIME types 
with "x-" prefix:

application/x-x509-ca-cert
application/x-x509-ca-ra-cert
application/x-pki-message
application/x-x509-next-ca-cert

  These should be registered in the IANA Considerations as per Appendix 
A of RFC 6838.

application/x-x509-ca-cert

  How is this different from application/pkix-cert registered in RFC 2585?

2) Use of CGI-PROG/CGI-PROG and hardcoded paths in general are 
problematic. More on this below:

3.5.1.  GetCACaps HTTP Message Format

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

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

This is not a correct ABNF (in case you intended to define a formal 
syntax here) and this is not a correct HTTP request line. Please make it 
one or another, or clarify somewhere syntax that you use.

Also, I don't think CGI-PATH and CGI-PROG are significant for the request


4.1.  HTTP POST and GET Message Formats

    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

Again, this is neither correct formal syntax nor correct HTTP requests.


    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.


Firstly, clients don't care about HTTP server using CGI, they just care 
about knowing where to send SCEP requests.

Secondly, hardcoded URI paths are in violation of RFC 7320. You can read 
more on this in Section 4.4 of

  <https://datatracker.ietf.org/doc/draft-ietf-httpbis-bcp56bis/?include_text=1>


I understand that this is a deployed protocol and the default path used 
is unlikely to change. However, I don't think the document should pay so 
much attention to use of CGI-PATH/CGI-PROG. My suggestion is:
a) Remove any reference to CGI-PROG/CGI-PATH from the document
b) Replace the above section with something like this:

    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 " SCEP-PATH "?operation=" OPERATION " HTTP/1.1"

    "GET " SCEP-PATH "?operation=" OPERATION "&message=" MESSAGE " 
HTTP/1.1"

    where:

    o  SCEP-PATH is the HTTP URL path for accessing CA

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

    Clients SHOULD set SCEP-PATH to the fixed string 
"/cgi-bin/pkiclient.exe"
    unless directed to do otherwise by the CA.


Minor:

1) Missing references:

The first mention of X.509 certificate needs a Normative Reference to 
RFC 5280.

The first mentions of SHA-256, AES and AES128-CBC need Normative 
References, as these are mandatory to implement.

The first mention of LDAP needs an Informative Reference to RFC 4510.

In Section 3.3.3: ASN.1 syntax needs to be a Normative Reference, as you 
define a new structure using ASN.1 syntax.

2) Should ACME work be mentioned in the Introduction?

3)

2.1.1.  Client

    A client MUST have the following information locally configured:

    1.  The CA fully qualified domain name or IP address.
    2.  The CA HTTP CGI script path (this usually has a default value,
        see Section 4.1).

Clients shouldn't care whether or not SCEP is provided by a CGI program. 
Please change this to "CA HTTP URL path" or "CA HTTP URI path".

4)

2.5.  Certificate Enrolment/Renewal


    If the CA returns a CertRep message (Section 3.3.2) with status set
    to PENDING, the client enters into polling mode by periodically
    sending a CertPoll message (Section 3.3.3) to the CA until the CA
    operator completes the manual authentication (approving or denying
    the request).

How often and for how long should a client poll? Recommending some 
defaults would be useful to set expectations.

5)

3.2.1.4.  failInfo and failInfoText

    The failInfoText is a free-form UTF-8 text string that provides
    further information in the case of pkiStatus = FAILURE.  In
    particular it may be used to provide details on why a certificate
    request was not granted that go beyond what's provided by the near-
    universal failInfo = badRequest status.  Since this is a free-form
    text string intended for interpretation by humans, implementations
    SHOULD NOT assume that it has any type of machine-processable
    content.

Why not "MUST NOT" and what are possible implications of violating the 
SHOULD NOT?

6)

3.3.2.1.  CertRep SUCCESS

In the table for "PKCSReq" (and similar text for GetCert):

   The reply MUST contain at least the issued
   certificate in the certificates field of the
   Signed-Data.  The reply MAY contain additional
   certificates, but the issued certificate MUST be
   the leaf certificate.

What does the last requirement actually mean? Is this describing order 
of certificates or just saying that it is not an intermediate certificate?

7)
3.3.4.  GetCert and GetCRL

    A self-signed certificate MAY be used in the signed envelope. This
    enables the client to request their own certificate if they were
    unable to store it previously.

So just to double check that I understood this correctly: the client is 
generating a self-signed certificate B in order to retrieve its 
certificate A signed by CA?

8)

3.5.2.  CA Capabilities Response Format

Near the bottom of page 24:

    The Content-type of the reply SHOULD be "text/plain".  Clients SHOULD
    ignore the Content-type, as older implementations of SCEP may send
    various Content-types.

The last requirement is quite problematic for extensibility. I 
understand why this sentence is there though. Are future extensions to 
SCEP likely?


Nits:

1)

2.1.2.  Certificate Authority

    A SCEP CA is the entity that signs client certificates.  A CA MAY
    enforce any arbitrary policies and apply them to certificate
    requests, and MAY reject a request for any reason.

I think this is pretty much granted and doesn't need to be said, 
especially the latter part.

2) In Section 3.3.3: s/od/of

3) In Section 4.1, last paragraph:

    When using GET messages to communicate binary data, base64 encoding
    as specified in [2] MUST be used.

When referncing RFC 4648 you should specify the section number to avoid 
all confusion. I assume you meant Section 4?

    The base64 encoded data is
    distinct from "base64url" and may contain URI reserved characters,
    thus it MUST be escaped as specified in [8] in addition to being
    base64 encoded.  Finally, the encoded data is inserted into the
    MESSAGE portion of the HTTP GET request.

Best Regards,
Alexey