Simple Certificate Enrolment Protocol
draft-gutmann-scep-16

[Ballot comment]
Thank you for addressing earlier comments, including comments from Adam.

Most of Ekr's comments were addressed, in particular all DISCUSS level seem to be addressed.

IANA registrations for the grandfathered media types:

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

are included as RFC Editor notes.

These still need registration templates, even if they are grandfathered.

[Ballot comment]
Given the purpose of this document is to describe a deployed protocol that however is not recommended by the IETF for new deployments anymore, I personally still think that this document should be published as Historic. However, this has been discussed at length by the community that came to the conclusion that informational status is most appropriate and of course I won't block this community consensus. Thanks to other IESG members for providing me some more background and sorry for me taking so long to release my discuss.

[Ballot discuss]
Thank you for addressing earlier comments, including comments from Adam.

The media type registration:

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

These still need registration templates, even if they are grandfathered.

[Ballot comment]
Removing DISCUSS since the fix is in the editor's copy.  Original COMMENT preserved below.

[updated COMMENT not emailed: I also agree with Alissa that there should be
some Introduction text explaining the choice of document status]

Given the previous discussion of the intended status for this document, I
think it is appropriate to publish it as Informational, as currently
indicated.

Some of these comments are fairly important, reflecting potential errors in
examples or minor internal inconsistencies, but may not rise to the level
of a DISCUSS for an Informational document.  Please consider them
carefully.

Section 1.1

RFC 8174 has updated BCP 14 boilerplate.

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

"not defined in this document ... defined in ... Section 4.1" seems a bit
inconsistent.

Section 2.2

                                  Clients SHOULD verify intermediate-
  level CA certificate signatures using the issuing CA's certificate
  before use during protocol exchanges.

Is this only SHOULD because you'll have to verify the signatures in order
to complete any protocol exchange using them?

Section 2.4

I guess given the history on this document I should not actually complain
about authentication by transmitting a cleartext secret to the peer (even
over an encrypted tunnel) vs. proof-of-possession.  But I still can note it
while reading.

  Inclusion of the challengePassword by the SCEP client is OPTIONAL and
  allows for unauthenticated authorization of enrolment requests

From the later text, I guess it is the omission of the challengePassword
that allows for unauthenticated authorization?  The wording here should
probably be tightened up.

Section 2.5

Do we want any text about continuing to reuse the same keypair indefinitely
becoming an increasingly bad idea as the time the keypair has been in use
increases?

Section 2.6

  store their certificates locally to obtain a copy when needed.  This
  functionality is not intended to provide a general purpose
  certificate access service, which may be achieved via HTTP
  certificate-store access [13] or LDAP.

nit(?): I might consinder adding "instead" or similar before "achieved".

Section 2.7

  1.  If the CA supports CRL Distribution Points (CRLDPs) [10], then
      the CRL MAY be retrieved via the mechanism specified in the

Do you want to say something about "extension in issued certificates"?

Section 2.9

I might reference (the table in) Section 3.5.2 to clarify that "AES" should
be AES128-CBC but can be any variant supported by CMS.  (Interestingly,
this text's use of SHA-256 instead of SHA-2 means that there is not a need
for clarification on that algorithm.)

Section 3.

Is there a good reference for the description language used in Figure 2?

Section 3.1

  is omitted".  This alternative processing mechanism SHOULD NOT be
  used since it exposes the challengePassword used to authorise the
  certificate issue.

nit: perhaps "exposes in cleartext" or "compromises" or similar.

Section 3.2.1.1

                                                        The client MUST
  use a unique string as the transaction identifier, encoded as a
  PrintableString, which MUST be used for all PKI messages exchanged
  for a given operation such as a certificate issue.

  Note that the transactionID must be unique, but not necessarily
  randomly generated.  For example it may be a value assigned by the CA
  (alongside the challengePassword) as an equivalent to the traditional
  user name + password, so that the client is identified by their
  transactionID.  [...]

Are these statements actually consistent?  The first seems to imply that
a transactionID is only usable for a single transaction and cannot be
reused (or the "unique" property is lost).  But having it assigned by the
CA with no further sequence number/uniquifier would seem to imply that it
would be reused (e.g., for renewal operations) and thus no longer be
unique.

Section 3.2.1.2

No need for a registry of message types?  (Implied by unrecognized values
being errors, of course, but implies a "finished" protocol that can never
be updated.)

Section 3.2.1.5

This nonce workflow seems to only prevent the server-side side effects of
replay if the server stores all previously seen nonces and rejects reuse.
That is, it ensures that the client gets a fresh response, but does not
prevent the server from reprocessing requests to issue, etc.

Section 3.3.2

  its presence.  Current versions of the specification no longer
  require the chaining of nonces across polling operations.

nit: can there really be more than one concurrent "current version" of this
specification?

Section 3.3.3

Is that SEQUENCE really valid ASN.1?

                      For this reason implementations SHOULD assume that
  the polling operation will be controlled by the recipientInfo and
  transactionID rather than the contents of the messageData.

That seems to be a "license to misbehave" (when generating CertPoll
messages).  Is that really what we want to encourage?

Section 3.4

  disseminate certificates and CRLs.  For SCEP the content field of the
  ContentInfo value of a degenerate certificates-only Signed-Data MUST
  be omitted.

Is this the encapsulatedContentInfo?

Section 3.5.2

Do we need to say that there is no requirement on the order in which
capabilities are returned?

Is it an error for "SCEPStandard" to appear without all of "AES",
"POSTPKIOperation", and "SHA-256"?  (The "it may be useful" later seems to
imply "no", which in turn implies that the CA is allowed to return a subset
of its actual capabilities in the response.  Which should perhaps be
documented.)

Should there be an IANA registry for capabilities?

                                                          A client that
  receives an empty message or an HTTP error SHOULD interpret the
  response as if none of the requested capabilities are supported by
  the CA.

nit: the syntax does not allow for querying ("request"ing) specific
capabilities, so I think this should be "none of the listed" or "no"
capabilities.

  Example:


  GET /cgi-bin/pkiclient.exe?operation=GetCACaps

Where is the  field?

Section 4.1

  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.

I no longer see CGI-PATH and/or CGI-PROG in the ABNF; is this text OBE?

                                The client can verify that the CA
  supports SCEP messages via POST by looking for the "POSTPKIOperation"
  capability (See Section 3.5.2).

I think it can also look for the "SCEPStandard" capability.

                                            In addition when using GET
  it's recommended to test your implementation over the public internet
  from as many locations as possible to determine whether the use of
  GET will cause problems with communications.

[My understanding is that it's uncommon in RFC style to use "your" in this
fashion.]

Section 4.2.1.2

Does the CMS format really admit the possibility of "leaf certificate(s)"
plural?

Section 4.3

It might be nice to throw in some URL-encoding for the GET example to
really drive home that this is not base64url, but I can fully understand a
desire to not change the example at this stage.

Section 4.3.1

  If the request is rejected, a CertRep message (Section 3.3.2) with
  pkiStatus set to FAILURE is returned.  The reply MUST also contain a
  failInfo attribute and MAY contain a failInfoText attribute.

This seems to be duplicating normative requirements already stated
elsewhere; is this really necessary?

Section 4.7.1

  current CA signing key.  Clients MUST validate the signature on the
  message before accepting any of its contents.  The response will have
  a Content-Type of "application/x-x509-next-ca-cert".

"accept" could be misinterpreted as "receive from the network into a local
buffer" or similar (as nonsensical as that is); do we want to use a
different verb like "processing" or "trusting"?

Section 5.2

In "Resync Case 3", why does the final PKCSReq continue to use
transactionId 7 instead of moving on to 8?  Shouldn't the FAILURE bring
closure to the transaction exchange?

Section 8.3

I could perhaps see mentioning a memory-hard hash function here, but it's
not clear that it's really necessary to do so.

[Ballot discuss]
As per IANA: The IANA Considerations section needs to mention the registration procedure for the new registry.

I also agree (at least) with comments raised by Adam, they are similar to what I raised in my own review. Some of them need fixes (e.g. to text or examples).

[Ballot discuss]
Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D3890


I have not had time to give this as thorough a read as I would like,
and would feel necessary were we advancing it at PS, so I am not
confident in its security properties. I have nevertheless noted a
number of issues that I think merit a DISCUSS.



DETAIL
S 2.3.
>          then a locally generated self-signed certificate MUST be used.
>          The keyUsage extension in the certificate MUST indicate that it
>          is valid for digitalSignature and keyEncipherment (if available).
>          The self-signed certificate SHOULD use the same subject name as
>          in the PKCS #10 request.  In this case the messageType is PKCSReq
>          (see Section 3.2.1.2).

Should it use the same *key* as the PKCS#10 request?


S 2.3.
> 
>      Note that although the above text describes several different types
>      of operations, in practice most implementations always apply the
>      first one even if an existing certificate already exists.  For this
>      reason support for the first case is mandatory while support for the
>      latter ones are optional (see Section 2.9).

we probably shouldn't have a SHOULD for something we know people don't
do, especially in an Info document.


S 2.5.
>      using CMS (Section 3).
> 
>      If the CA supports certificate renewal and if the CA policy permits
>      then a new certificate with new validity dates can be issued even
>      though the old one is still valid.  The CA MAY automatically revoke
>      the old client certificate.  To renew an existing certificate, the

Is this sentence about automatically revoking related to the previous
one? I.e., can I revoke the old certificate if the new one is not yet
valid? That would seem unwise.


S 3.
>      confidentiality use two layers of CMS, as shown in Figure 2.  By
>      applying both enveloping and signing transformations, the SCEP
>      message is protected both for the integrity of its end-to-end
>      transaction information and the confidentiality of its information
>      portion.  Some messages do not require enveloping, in which case the
>      EnvelopedData in Figure 2 is omitted.

I want to make sure I understand which messages *do* require
enveloping. I would assume PKSReq, at least if it includes the
challenge password, right? Maybe I'm missing it, but i don't see a
clear statement anywhere.


S 3.1.
>      the recipient's public key.  If the key is encryption-capable (for
>      example RSA) then the messageData is encrypted using the recipient's
>      public key with the CMS KeyTransRecipientInfo mechanism.  If the key
>      is not encryption-capable (for example DSA or ECDSA) then the
>      messageData is encrypted using the challengePassword with the CMS
>      PasswordRecipientInfo mechanism.

This requires a very strong ChallengePassword, which I don't see you
saying anywhere.


S 3.1.
>      Note that some earlier implementations of this specification dealt
>      with non-encryption-capable keys by omitting the encryption stage,
>      based on the text in Section 3 that indicated that "the EnvelopedData
>      is omitted".  This alternative processing mechanism SHOULD NOT be
>      used since it exposes the challengePassword used to authorise the
>      certificate issue.

Why is this not a MUST?


S 8.3.
> 
>      The challengePassword sent in the PKCS #10 enrolment request is
>      signed and encrypted by way of being encapsulated in a pkiMessage.
>      When saved by the CA, care should be taken to protect this password,
>      for example by storing a salted iterated hash of the password rather
>      than the password itself.

this won't work if you are using it for encryption.


S 8.7.
>      is public and thus encrypting the requests is of questionable value.
>      In addition CRLs and certificates sent in responses are already
>      signed by the CA and can be verified by the recipient without
>      requiring additional signing and encryption.  More lightweight means
>      of retrieving certificates and CRLs such as HTTP certificate-store
>      access [13] and LDAP are recommended for this reason.

This statement appears to directly cut against RFC 7258, which
establishes the IETF consensus that we should be considering
disclosure of metadata and its impact on pervasive monitoring. A
protocol which claims to have IETF consensus should not take the
opposite position. In addition to this, the claim that certificates
are inherently public is in fact not universally true, as discussions
about redaction in CT demonstrate. Moreover, the fact that a given
endpoint has given certificate is not public.


S 8.8.
>      default to SHA-1, with many supporting only that hash algorithm with
>      no ability to upgrade to a newer one.  SHA-1 is no longer regarded as
>      secure in all situations, but as used in SCEP it's still safe.  There
>      are three reasons for this.  The first is that attacking SCEP would
>      require creating a SHA-1 collision in close to real time, which won't
>      be feasible for a very long time.

I don't believe that this statement reflects the consensus of the
cryptographic community and it's also not clear to me that the
requirement for real-time is correct without quite a bit more
analysis.

[Ballot comment]
S 1.
>      Appendix A.  Background Notes . . . . . . . . . . . . . . . . . .  38
>      Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  41
> 
>  1.  Introduction
> 
>      X.509 certificates serve as the basis for several standards-based

Well, not just standards-based, standardized.


S 1.
>      Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  41
> 
>  1.  Introduction
> 
>      X.509 certificates serve as the basis for several standards-based
>      security protocols such as TLS [19], S/MIME [16], and IKE/IPsec [15].

You're going to want to update the TLS reference to point to TLS 1.3


S 1.
> 
>      X.509 certificates serve as the basis for several standards-based
>      security protocols such as TLS [19], S/MIME [16], and IKE/IPsec [15].
>      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

Is this actually true? It seems like a many certificates are manually
issued based on PKCS#10 CSRc.


S 2.2.
>      If the CA certificate(s) have not previously been acquired by the
>      client through some other means, the client MUST retrieve them before
>      any PKI operation (Section 3) can be started.  Since no public key
>      has yet been exchanged between the client and the CA, the messages
>      cannot be secured using CMS, and the CA certificate request and
>      response data is instead transferred in the clear.

It would be useful here to distinguish between a number of
certificates. For instance, a CA might have a certificate which it
used for communications security (in ACME, this would be its TLS
server cert) and a certificate which it uses to sign other certs. A
client might have (or be able to obtain) the former but then expect
the latter to be delivered in early communications. Thus, it would
still be possible to use comsec on this first communication.


S 2.2.
>      Alternatively, the CA certificate fingerprint MAY be used to
>      authenticate a CA Certificate distributed by the GetCACert response
>      (Section 4.2) or via HTTP certificate-store access [13].  The
>      fingerprint is created by calculating a SHA-256 hash over the whole
>      CA certificate (for legacy reasons, a SHA-1 hash may be used by some
>      implementations).

Yet alternately, there might be a cross-sign.


S 2.3.
>  2.3.  Client authentication
> 
>      As with every protocol that uses public-key cryptography, the
>      association between the public keys used in the protocol and the
>      identities with which they are associated must be authenticated in a
>      cryptographically secure manner.  The communications between the

This isn't actually true, at least in the literal sense, for all the
one-way authenticated DH protocols like TLS or SSH w/ passwords.


S 2.4.
>      Inclusion of the challengePassword by the SCEP client is OPTIONAL and
>      allows for unauthenticated authorization of enrolment requests
>      (which, however, requires manual approval of each certificate issue,
>      see below), or for renewal requests that are authenticated by being
>      signed with an existing certificate.  The CMS envelope protects the
>      privacy of the challengePassword.

I don't understand how manual operation works in practice. How is the
CA intended to determine that a given CSR corresponds to a valid
subscriber. It seems like *some* text is required here.


S 2.6.
> 
>      GetCert: PKI certificate query message
>      -------------------------------> CertRep: pkiStatus = SUCCESS
>                                      Certificate attached
>                                      <-----------------------------
>      Receive the certificate.

You should note in the security considerations that unless
unpredictable serial numbers are used, this allows for enumeration of
all the certificates in the system.


S 3.3.1.
>      message, the pkiMessage MUST include the following attributes:
> 
>      o  A transactionID attribute (Section 3.2.1.1).
>      o  A messageType attribute (Section 3.2.1.2) set to PKCSReq or
>        RenewalReq as appropriate.
>      o  A fresh senderNonce attribute (Section 3.2.1.5).

How do I carry the kind of information you would use for a WebPKI
cert, like my list of SANs?


S 3.3.4.
> 
>      These message types, while included here for completeness, apply
>      unnecessary cryptography and messaging overhead to the simple task of
>      transferring a certificate or CRL (see Section 8.7).  Implementations
>      SHOULD prefer HTTP certificate-store access [13] or LDAP over the use
>      of these messages.

This text here seems to generally run against the guidance in 7258,
which biases towards more encryption.


S 4.1.
>      via a web browser) work, then this is a symptom of the problematic
>      use of HTTP GET.  The solution to this problem is to update the
>      implementation to use HTTP POST instead.  In addition when using GET
>      it's recommended to test your implementation over the public internet
>      from as many locations as possible to determine whether the use of
>      GET will cause problems with communications.

Why would multiple locations be relevant here?


S 8.8.
>      require creating a SHA-1 collision in close to real time, which won't
>      be feasible for a very long time.
> 
>      The second reason is that the signature over the message doesn't
>      serve any critical cryptographic purpose: The PKCS #10 data itself is
>      authenticated through its own signature, protected by encryption, and

Isn't this signature via SHA-1?

[Ballot comment]
[updated COMMENT not emailed: I also agree with Alissa that there should be
some Introduction text explaining the choice of document status]

Given the previous discussion of the intended status for this document, I
think it is appropriate to publish it as Informational, as currently
indicated.

Some of these comments are fairly important, reflecting potential errors in
examples or minor internal inconsistencies, but may not rise to the level
of a DISCUSS for an Informational document.  Please consider them
carefully.

Section 1.1

RFC 8174 has updated BCP 14 boilerplate.

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

"not defined in this document ... defined in ... Section 4.1" seems a bit
inconsistent.

Section 2.2

                                  Clients SHOULD verify intermediate-
  level CA certificate signatures using the issuing CA's certificate
  before use during protocol exchanges.

Is this only SHOULD because you'll have to verify the signatures in order
to complete any protocol exchange using them?

Section 2.4

I guess given the history on this document I should not actually complain
about authentication by transmitting a cleartext secret to the peer (even
over an encrypted tunnel) vs. proof-of-possession.  But I still can note it
while reading.

  Inclusion of the challengePassword by the SCEP client is OPTIONAL and
  allows for unauthenticated authorization of enrolment requests

From the later text, I guess it is the omission of the challengePassword
that allows for unauthenticated authorization?  The wording here should
probably be tightened up.

Section 2.5

Do we want any text about continuing to reuse the same keypair indefinitely
becoming an increasingly bad idea as the time the keypair has been in use
increases?

Section 2.6

  store their certificates locally to obtain a copy when needed.  This
  functionality is not intended to provide a general purpose
  certificate access service, which may be achieved via HTTP
  certificate-store access [13] or LDAP.

nit(?): I might consinder adding "instead" or similar before "achieved".

Section 2.7

  1.  If the CA supports CRL Distribution Points (CRLDPs) [10], then
      the CRL MAY be retrieved via the mechanism specified in the

Do you want to say something about "extension in issued certificates"?

Section 2.9

I might reference (the table in) Section 3.5.2 to clarify that "AES" should
be AES128-CBC but can be any variant supported by CMS.  (Interestingly,
this text's use of SHA-256 instead of SHA-2 means that there is not a need
for clarification on that algorithm.)

Section 3.

Is there a good reference for the description language used in Figure 2?

Section 3.1

  is omitted".  This alternative processing mechanism SHOULD NOT be
  used since it exposes the challengePassword used to authorise the
  certificate issue.

nit: perhaps "exposes in cleartext" or "compromises" or similar.

Section 3.2.1.1

                                                        The client MUST
  use a unique string as the transaction identifier, encoded as a
  PrintableString, which MUST be used for all PKI messages exchanged
  for a given operation such as a certificate issue.

  Note that the transactionID must be unique, but not necessarily
  randomly generated.  For example it may be a value assigned by the CA
  (alongside the challengePassword) as an equivalent to the traditional
  user name + password, so that the client is identified by their
  transactionID.  [...]

Are these statements actually consistent?  The first seems to imply that
a transactionID is only usable for a single transaction and cannot be
reused (or the "unique" property is lost).  But having it assigned by the
CA with no further sequence number/uniquifier would seem to imply that it
would be reused (e.g., for renewal operations) and thus no longer be
unique.

Section 3.2.1.2

No need for a registry of message types?  (Implied by unrecognized values
being errors, of course, but implies a "finished" protocol that can never
be updated.)

Section 3.2.1.5

This nonce workflow seems to only prevent the server-side side effects of
replay if the server stores all previously seen nonces and rejects reuse.
That is, it ensures that the client gets a fresh response, but does not
prevent the server from reprocessing requests to issue, etc.

Section 3.3.2

  its presence.  Current versions of the specification no longer
  require the chaining of nonces across polling operations.

nit: can there really be more than one concurrent "current version" of this
specification?

Section 3.3.3

Is that SEQUENCE really valid ASN.1?

                      For this reason implementations SHOULD assume that
  the polling operation will be controlled by the recipientInfo and
  transactionID rather than the contents of the messageData.

That seems to be a "license to misbehave" (when generating CertPoll
messages).  Is that really what we want to encourage?

Section 3.4

  disseminate certificates and CRLs.  For SCEP the content field of the
  ContentInfo value of a degenerate certificates-only Signed-Data MUST
  be omitted.

Is this the encapsulatedContentInfo?

Section 3.5.2

Do we need to say that there is no requirement on the order in which
capabilities are returned?

Is it an error for "SCEPStandard" to appear without all of "AES",
"POSTPKIOperation", and "SHA-256"?  (The "it may be useful" later seems to
imply "no", which in turn implies that the CA is allowed to return a subset
of its actual capabilities in the response.  Which should perhaps be
documented.)

Should there be an IANA registry for capabilities?

                                                          A client that
  receives an empty message or an HTTP error SHOULD interpret the
  response as if none of the requested capabilities are supported by
  the CA.

nit: the syntax does not allow for querying ("request"ing) specific
capabilities, so I think this should be "none of the listed" or "no"
capabilities.

  Example:


  GET /cgi-bin/pkiclient.exe?operation=GetCACaps

Where is the  field?

Section 4.1

  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.

I no longer see CGI-PATH and/or CGI-PROG in the ABNF; is this text OBE?

                                The client can verify that the CA
  supports SCEP messages via POST by looking for the "POSTPKIOperation"
  capability (See Section 3.5.2).

I think it can also look for the "SCEPStandard" capability.

                                            In addition when using GET
  it's recommended to test your implementation over the public internet
  from as many locations as possible to determine whether the use of
  GET will cause problems with communications.

[My understanding is that it's uncommon in RFC style to use "your" in this
fashion.]

Section 4.2.1.2

Does the CMS format really admit the possibility of "leaf certificate(s)"
plural?

Section 4.3

It might be nice to throw in some URL-encoding for the GET example to
really drive home that this is not base64url, but I can fully understand a
desire to not change the example at this stage.

Section 4.3.1

  If the request is rejected, a CertRep message (Section 3.3.2) with
  pkiStatus set to FAILURE is returned.  The reply MUST also contain a
  failInfo attribute and MAY contain a failInfoText attribute.

This seems to be duplicating normative requirements already stated
elsewhere; is this really necessary?

Section 4.7.1

  current CA signing key.  Clients MUST validate the signature on the
  message before accepting any of its contents.  The response will have
  a Content-Type of "application/x-x509-next-ca-cert".

"accept" could be misinterpreted as "receive from the network into a local
buffer" or similar (as nonsensical as that is); do we want to use a
different verb like "processing" or "trusting"?

Section 5.2

In "Resync Case 3", why does the final PKCSReq continue to use
transactionId 7 instead of moving on to 8?  Shouldn't the FAILURE bring
closure to the transaction exchange?

Section 8.3

I could perhaps see mentioning a memory-hard hash function here, but it's
not clear that it's really necessary to do so.

[Ballot discuss]
Thanks for this easy-to-read document!

I have a fairly silly point, where the behavior seems to still be
underspecified:

Section 4.4 says that an error-handling path should "ignore this request";
does that mean that it should terminate the underlying connection over
which HTTP is running?  Return an HTTP error?  Keep the connection open
until the peer times out?

[Ballot comment]
Given the previous discussion of the intended status for this document, I
think it is appropriate to publish it as Informational, as currently
indicated.

Some of these comments are fairly important, reflecting potential errors in
examples or minor internal inconsistencies, but may not rise to the level
of a DISCUSS for an Informational document.  Please consider them
carefully.

Section 1.1

RFC 8174 has updated BCP 14 boilerplate.

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

"not defined in this document ... defined in ... Section 4.1" seems a bit
inconsistent.

Section 2.2

                                  Clients SHOULD verify intermediate-
  level CA certificate signatures using the issuing CA's certificate
  before use during protocol exchanges.

Is this only SHOULD because you'll have to verify the signatures in order
to complete any protocol exchange using them?

Section 2.4

I guess given the history on this document I should not actually complain
about authentication by transmitting a cleartext secret to the peer (even
over an encrypted tunnel) vs. proof-of-possession.  But I still can note it
while reading.

  Inclusion of the challengePassword by the SCEP client is OPTIONAL and
  allows for unauthenticated authorization of enrolment requests

From the later text, I guess it is the omission of the challengePassword
that allows for unauthenticated authorization?  The wording here should
probably be tightened up.

Section 2.5

Do we want any text about continuing to reuse the same keypair indefinitely
becoming an increasingly bad idea as the time the keypair has been in use
increases?

Section 2.6

  store their certificates locally to obtain a copy when needed.  This
  functionality is not intended to provide a general purpose
  certificate access service, which may be achieved via HTTP
  certificate-store access [13] or LDAP.

nit(?): I might consinder adding "instead" or similar before "achieved".

Section 2.7

  1.  If the CA supports CRL Distribution Points (CRLDPs) [10], then
      the CRL MAY be retrieved via the mechanism specified in the

Do you want to say something about "extension in issued certificates"?

Section 2.9

I might reference (the table in) Section 3.5.2 to clarify that "AES" should
be AES128-CBC but can be any variant supported by CMS.  (Interestingly,
this text's use of SHA-256 instead of SHA-2 means that there is not a need
for clarification on that algorithm.)

Section 3.

Is there a good reference for the description language used in Figure 2?

Section 3.1

  is omitted".  This alternative processing mechanism SHOULD NOT be
  used since it exposes the challengePassword used to authorise the
  certificate issue.

nit: perhaps "exposes in cleartext" or "compromises" or similar.

Section 3.2.1.1

                                                        The client MUST
  use a unique string as the transaction identifier, encoded as a
  PrintableString, which MUST be used for all PKI messages exchanged
  for a given operation such as a certificate issue.

  Note that the transactionID must be unique, but not necessarily
  randomly generated.  For example it may be a value assigned by the CA
  (alongside the challengePassword) as an equivalent to the traditional
  user name + password, so that the client is identified by their
  transactionID.  [...]

Are these statements actually consistent?  The first seems to imply that
a transactionID is only usable for a single transaction and cannot be
reused (or the "unique" property is lost).  But having it assigned by the
CA with no further sequence number/uniquifier would seem to imply that it
would be reused (e.g., for renewal operations) and thus no longer be
unique.

Section 3.2.1.2

No need for a registry of message types?  (Implied by unrecognized values
being errors, of course, but implies a "finished" protocol that can never
be updated.)

Section 3.2.1.5

This nonce workflow seems to only prevent the server-side side effects of
replay if the server stores all previously seen nonces and rejects reuse.
That is, it ensures that the client gets a fresh response, but does not
prevent the server from reprocessing requests to issue, etc.

Section 3.3.2

  its presence.  Current versions of the specification no longer
  require the chaining of nonces across polling operations.

nit: can there really be more than one concurrent "current version" of this
specification?

Section 3.3.3

Is that SEQUENCE really valid ASN.1?

                      For this reason implementations SHOULD assume that
  the polling operation will be controlled by the recipientInfo and
  transactionID rather than the contents of the messageData.

That seems to be a "license to misbehave" (when generating CertPoll
messages).  Is that really what we want to encourage?

Section 3.4

  disseminate certificates and CRLs.  For SCEP the content field of the
  ContentInfo value of a degenerate certificates-only Signed-Data MUST
  be omitted.

Is this the encapsulatedContentInfo?

Section 3.5.2

Do we need to say that there is no requirement on the order in which
capabilities are returned?

Is it an error for "SCEPStandard" to appear without all of "AES",
"POSTPKIOperation", and "SHA-256"?  (The "it may be useful" later seems to
imply "no", which in turn implies that the CA is allowed to return a subset
of its actual capabilities in the response.  Which should perhaps be
documented.)

Should there be an IANA registry for capabilities?

                                                          A client that
  receives an empty message or an HTTP error SHOULD interpret the
  response as if none of the requested capabilities are supported by
  the CA.

nit: the syntax does not allow for querying ("request"ing) specific
capabilities, so I think this should be "none of the listed" or "no"
capabilities.

  Example:


  GET /cgi-bin/pkiclient.exe?operation=GetCACaps

Where is the  field?

Section 4.1

  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.

I no longer see CGI-PATH and/or CGI-PROG in the ABNF; is this text OBE?

                                The client can verify that the CA
  supports SCEP messages via POST by looking for the "POSTPKIOperation"
  capability (See Section 3.5.2).

I think it can also look for the "SCEPStandard" capability.

                                            In addition when using GET
  it's recommended to test your implementation over the public internet
  from as many locations as possible to determine whether the use of
  GET will cause problems with communications.

[My understanding is that it's uncommon in RFC style to use "your" in this
fashion.]

Section 4.2.1.2

Does the CMS format really admit the possibility of "leaf certificate(s)"
plural?

Section 4.3

It might be nice to throw in some URL-encoding for the GET example to
really drive home that this is not base64url, but I can fully understand a
desire to not change the example at this stage.

Section 4.3.1

  If the request is rejected, a CertRep message (Section 3.3.2) with
  pkiStatus set to FAILURE is returned.  The reply MUST also contain a
  failInfo attribute and MAY contain a failInfoText attribute.

This seems to be duplicating normative requirements already stated
elsewhere; is this really necessary?

Section 4.7.1

  current CA signing key.  Clients MUST validate the signature on the
  message before accepting any of its contents.  The response will have
  a Content-Type of "application/x-x509-next-ca-cert".

"accept" could be misinterpreted as "receive from the network into a local
buffer" or similar (as nonsensical as that is); do we want to use a
different verb like "processing" or "trusting"?

Section 5.2

In "Resync Case 3", why does the final PKCSReq continue to use
transactionId 7 instead of moving on to 8?  Shouldn't the FAILURE bring
closure to the transaction exchange?

Section 8.3

I could perhaps see mentioning a memory-hard hash function here, but it's
not clear that it's really necessary to do so.

[Ballot comment]
Much thanks to the author/editor for taking the effort to put this document over
the finish line. Thanks also to everyone who worked on this and previous
versions of the document. It's a good thing that we're getting a widely-deployed
protocol published, even if it isn't entirely the design that we would come up
with today. I have a handful of comments, most of which are substantive (but
which should be fairly easy to address).


---------------------------------------------------------------------------

This nit was called out in the shepherd's review, written several versions ago,
and yet remains an issue. Please address it prior to publication.

-- Obsolete informational reference (is this intentional?): RFC 5246 (ref.
    '19') (Obsoleted by RFC 8446)

---------------------------------------------------------------------------

§4:

> In particular, it uses unregistered Media Types...

This seems a bit surprising. I see that the types in question are of the form
"application/x-*", which is not generally registrable today. However, given that
the purpose of this document is primarily documentation of existing practice, it
seems that the media types it uses are exactly what are contemplated by the
Media Type grandfathering procedures.

From RFC 6838 Appendix A:

  From time to time there may also be cases where a media type with an
  unfaceted subtype name has been widely deployed without being
  registered.  (Note that this includes subtype names beginning with
  the "x-" prefix.)  If possible, such a media type SHOULD be
  reregistered with a proper faceted subtype name, possibly using a
  deprecated alias to identify the original name (see Section 4.2.9).
  However, if this is not possible, the type can, subject to approval
  by both the media types reviewer and the IESG, be registered in the
  proper tree with its unfaceted name.

For an example of where this kind of registration exists, see
application/x-www-form-urlencoded.

I think this is a case where the registration of the various media types
described by this document would do significantly more good than damage, and
would strongly support registration of such names with IANA.

---------------------------------------------------------------------------

§4:

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

This is confusing, since neither "CGI-PATH" not "CGI-PROG" appear anywhere in
the document other than this paragraph. I suspect that these should have been
replaced with "SCEPPATH".

---------------------------------------------------------------------------

§4.3:

>  POST /cgi-bin/pkiclient.exe?operation=PKIOperation HTTP/1.1
>  Content-Length:
>
> 

Is this meant to indicate that Content-Type is not used on the POST requests? If
so, please say so explicitly, and indicate that this is another way in which
SCEP behavior varies from commonly-accepted HTTP behavior.

---------------------------------------------------------------------------

§4.4:

>  A
>  CA receiving a CertPoll for which it does not have a matching
>  PKCSReq/RenewalReq MUST ignore this request.

What does this mean? On its face, this implies that the HTTP request never sees
a response code at all. Is that what's meant? Or is the intention that an error
code of some description should be sent back?

If it's the former, this is another place where non-HTTP-like behavior needs
to be clearly called out, and I think we would need to have some description
about client timeout behavior.

[Ballot comment]
Much thanks to the author/editor for taking the effort to put this document over
the finish line. Thanks also to everyone who worked on this and previous
versions of the document. It's a good thing that we're getting a widely-deployed
protocol published, even if it isn't entirely the design that we would come up
with today. I have a handful of comments, most of which are substantive (but
which should be fairly easy to address).


---------------------------------------------------------------------------

-- Obsolete informational reference (is this intentional?): RFC 5246 (ref.
    '19') (Obsoleted by RFC 8446)

---------------------------------------------------------------------------

§4:

> In particular, it uses unregistered Media Types...

This seems a bit surprising. I see that the types in question are of the form
"application/x-*", which is not generally registrable today. However, given that
the purpose of this document is primarily documentation of existing practice, it
seem that the media types it uses are exactly what are contemplated by the Media
Type grandfathering procedures.

From RFC 6838 Appendix A:

  From time to time there may also be cases where a media type with an
  unfaceted subtype name has been widely deployed without being
  registered.  (Note that this includes subtype names beginning with
  the "x-" prefix.)  If possible, such a media type SHOULD be
  reregistered with a proper faceted subtype name, possibly using a
  deprecated alias to identify the original name (see Section 4.2.9).
  However, if this is not possible, the type can, subject to approval
  by both the media types reviewer and the IESG, be registered in the
  proper tree with its unfaceted name.

For an example of where this kind of registration exists, see
application/x-www-form-urlencoded.

I think this is a case where the registration of the various media types
described by this document would do significantly more good than damage, and
would strongly support registration of such names with IANA.

---------------------------------------------------------------------------

§4:

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

This is confusing, since neither "CGI-PATH" not "CGI-PROG" appear anywhere in
the document other than this paragraph. I suspect that these should have been
replaced with "SCEPPATH".

---------------------------------------------------------------------------

§4.3:

>  POST /cgi-bin/pkiclient.exe?operation=PKIOperation HTTP/1.1
>  Content-Length:
>
> 

Is this meant to indicate that Content-Type is not used on the POST requests? If
so, please say so explicitly, and indicate that this is another way in which
SCEP behavior varies from commonly-accepted HTTP behavior.

---------------------------------------------------------------------------

§4.4:

>  A
>  CA receiving a CertPoll for which it does not have a matching
>  PKCSReq/RenewalReq MUST ignore this request.

What does this mean? On its face, this implies that the HTTP request never sees
a response code at all. Is that what's meant? Or is the intention that an error
code of some description should be sent back?

If it's the former, this is another place where non-HTTP-like behavior needs
to be clearly called out, and I think we would need to have some description
about client timeout behavior.

[Ballot comment]
I have reviewed this document, but don't have sufficient knowledge to be able to add much.
Thanks to Christer Holmberg for the OpsDir review, and for addressing it.

[Ballot discuss]
Given the purpose of this document is to describe a deployed protocol that however is not recommended by the IETF community for new deployments anymore, the IESG should discuss if this document should be published as Historic.

[Ballot comment]
*** Substantive Comments ***

I agree with Alissa's comment that the document needs some up-front text saying why it is being published as informational and describing its limitations, whether that goes in custom boilerplate or body text. (I lean towards body text, since, in my experience, a lot of readers skip the boilerplate.) The appendix helps in this matter, but I think it could be made more prominent.

§2.1.2:

- "certificates. A CA MAY
enforce any arbitrary policies and apply them to certificate
requests, and MAY reject a request for any reason."

That seems more of a statement of fact than permission. (And even if it is intended as permission, normative keywords probably aren't appropriate for describing CA policy options, at least outside of a BCP.

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

Why not MUST? Can you offer guidance on when it might make sense to violate this?

- "CA key rollover provides a
mechanism by which the CA MAY distribute a new CA certificate"

Statement of fact?

2.3:

- "The keyUsage extension in the certificate MUST indicate that it
is valid for digitalSignature and keyEncipherment (if available)."

Can you elaborate on the "if available" part? Given that it is an exception to a MUST, some degree of precision would be helpful.

§2.5:
- "The client SHOULD use a new
keypair when requesting a new certificate, but MAY request a new
certificate using the old keypair."

Can you offer more guidance here? It effectively takes the form "SHOULD do X but MAY not do X", which is not very helpful.


§2.7: "SCEP clients MAY request a CRL via one of three methods."

That seems to make requesting a CRL completely optional. Is that the intent?

§3.2.1.4: "The failInfo attribute MUST contain one of the following failure
reasons:"

That's only in the case of an actual failure, right?

§7: "This assignment created the new SMI Security for SCEP Attribute
Identifiers ((1.3.6.1.5.5.7.TBD1) registry with the following entries
with references to this document:"

What is the registration policy?


*** Editorial Comments ***

§2 claims to offer a high-level overview. That does not seem to be the case; rather, it offers a number of protocol details. I think that a real overview that shows how this all works together would be very helpful for implementors.

§2.3: "Note that this means that, in the case of renewal operations, the
request is signed with, and the returned response may be encrypted
with, the key in the previously-issued certificate used to
authenticate the request, not the key in the PKCS #10 request."

Convoluted sentence.

§2.6:
- "To query a certificate..."
s/query/request. (unless the intent is to ask the certificate).

[Ballot comment]
General:

I can see there has been a lot of discussion about the status of this document in SAAG and as part of the IETF LC. I agree with the conclusion that informational is the most appropriate status. However, I wonder if this document could use some bespoke "Status of this Memo" text to be clear about the nature of the consensus behind the document. My read of the list traffic is that there is consensus that this protocol should be documented because it is in wide use. There is not consensus that the protocol design is sound; the IETF consensus protocol that serves this same function is EST. I think it would be useful to say some version of both of those things in the "Status of this Memo" text, and to do whatever needs to be done to the Consensus Boilerplate option in the datatracker to make that happen.

Would it make more sense for the author to be listed as an editor, given, e.g., https://mailarchive.ietf.org/arch/msg/saag/Llym2en1RnMzMUZoZ4zIQn6V-pI? I don't care one way or the other but just wanted to check.

Section 1:

Please use the RFC 8174 boilerplate.

Section 2.9:

"For historical reasons implementations MAY support communications of
  binary data via HTTP GET (Section 4.1), and the triple DES and SHA-1
  algorithms to secure pkiMessages (Section 3.2)."

I wonder if the bit about triple DES and SHA-1 is meant to have the normative MAY applied, rather than non-normative "may" as in Section 2.2. In any event it seems like they should either both be normative or non-normative.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has completed its review of draft-gutmann-scep-09. If any part of this review is inaccurate, please let us know.

The IANA Services Operator understands that, upon approval of this document, there are three actions which we must complete. We have a question about one of the actions.

First, in the SMI Security for PKIX Module Identifier (1.3.6.1.5.5.7.0) subregistry of the SMI Security Codes registry on the Structure of Management Information (SMI) Numbers (MIB Module Registrations) located at:

https://www.iana.org/assignments/smi-numbers/

a single new registration will be made as follows:

Decimal: [ TBD-at-Registration ]
Description: id-mod-scep-attr-2017
Reference: [ RFC-to-be ]

As this document requests registrations in a Specification Required (see RFC 8126) registry, we've initiated the expert review via a separate request. This review should be completed before your document is be approved for publication as an RFC.

Second, in the SMI Security for PKIX (1.3.6.1.5.5.7.0) subregistry also in the SMI Security Codes registry on the Structure of Management Information (SMI) Numbers (MIB Module Registrations) located at:

https://www.iana.org/assignments/smi-numbers/

a single new registration will be made as follows:

Decimal: [ TBD-at-Registration ]
Description: id-scep
Reference: [ RFC-to-be ]

As this document requests registrations in a Specification Required (see RFC 8126) registry, we've initiated the expert review via a separate request. This review should be completed before your document is be approved for publication as an RFC.

Third, a new subregistry called "SMI Security for SCEP Attribute Identifiers" (1.3.6.1.5.5.7.XXXX) will be created. XXXX will be the value to be determined in step two above. The registry will be managed via Specification Required as defined in RFC8126.

The new subregistry will be located in the SMI Security for PKIX subregistry also in the SMI Security Codes registry on the Structure of Management Information (SMI) Numbers (MIB Module Registrations) located at:

https://www.iana.org/assignments/smi-numbers/

IANA Question --> Will the registration procedure be "Specification Required," as it is for the RFC 7299 registries?

A single initial registration will populate the new subregistry:

Decimal: [ TBD-at-Registration ]
Description: id-scep-failInfoText
Reference: [ RFC-to-be ]

IANA Question --> Is the first value in this registry "1"?

The IANA Services Operator understands that these are the only actions required upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Amanda Baber
Lead IANA Services Specialist

The following Last Call announcement was sent out (ends 2018-03-19):

From: The IESG
To: IETF-Announce
CC: alexey.melnikov@isode.com, draft-gutmann-scep@ietf.org, carl@redhoundsoftware.com, Carl Wallace , pgut001@cs.auckland.ac.nz
Reply-To: ietf@ietf.org
Sender:
Subject: EXTENDED Last Call:  (Simple Certificate Enrolment Protocol) to Informational RFC


The IESG has received a request from an individual submitter to consider the
following document: - 'Simple Certificate Enrolment Protocol'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2018-03-19. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  This document specifies the Simple Certificate Enrolment Protocol
  (SCEP), a PKI protocol that leverages existing technology by using
  CMS (formerly known as PKCS #7) and PKCS #10 over HTTP.  SCEP is the
  evolution of the enrolment protocol sponsored by Cisco Systems, which
  enjoys wide support in both client and server implementations, as
  well as being relied upon by numerous other industry standards that
  work with certificates.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-gutmann-scep/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-gutmann-scep/ballot/

The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/553/
  https://datatracker.ietf.org/ipr/500/

The following Last Call announcement was sent out (ends 2018-03-05):

From: The IESG
To: IETF-Announce
CC: Kathleen.Moriarty.ietf@gmail.com, draft-gutmann-scep@ietf.org, carl@redhoundsoftware.com, Carl Wallace , pgut001@cs.auckland.ac.nz
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Simple Certificate Enrolment Protocol) to Informational RFC


The IESG has received a request from an individual submitter to consider the
following document: - 'Simple Certificate Enrolment Protocol'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2018-03-05. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  This document specifies the Simple Certificate Enrolment Protocol
  (SCEP), a PKI protocol that leverages existing technology by using
  CMS (formerly known as PKCS #7) and PKCS #10 over HTTP.  SCEP is the
  evolution of the enrolment protocol sponsored by Cisco Systems, which
  enjoys wide support in both client and server implementations, as
  well as being relied upon by numerous other industry standards that
  work with certificates.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-gutmann-scep/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-gutmann-scep/ballot/

The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/553/
  https://datatracker.ietf.org/ipr/500/