Skip to main content

Simple Certificate Enrolment Protocol
draft-gutmann-scep-16

Discuss


Yes


No Objection

(Alvaro Retana)
(Deborah Brungard)
(Martin Vigoureux)
(Spencer Dawkins)
(Suresh Krishnan)
(Terry Manderson)

Note: This ballot was opened for revision 13 and is now closed.

Warren Kumari
No Objection
Comment (2019-02-06 for -13) Not sent
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.
Eric Rescorla Former IESG member
Discuss
Discuss [Treat as non-blocking comment] (2019-02-07 for -13) Sent
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.
Alexey Melnikov Former IESG member
(was Discuss, Yes) Yes
Yes (2020-01-29 for -14) Not sent
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.
Adam Roach Former IESG member
No Objection
No Objection (2019-02-06 for -13) Sent
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: <length of data>
>
>  <binary CMS data>

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.
Alissa Cooper Former IESG member
No Objection
No Objection (2019-02-05 for -13) Sent
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.
Alvaro Retana Former IESG member
No Objection
No Objection (for -13) Not sent

                            
Ben Campbell Former IESG member
No Objection
No Objection (2019-02-05 for -13) Sent
*** 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).
Benjamin Kaduk Former IESG member
(was Discuss) No Objection
No Objection (2019-02-08 for -13) Sent for earlier
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 <HTTP-version> 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.
Deborah Brungard Former IESG member
No Objection
No Objection (for -13) Not sent

                            
Ignas Bagdonas Former IESG member
No Objection
No Objection (2019-02-07 for -13) Not sent
SCEP is widely deployed and used, documenting it even for historic reference purposes is the right thing to do.
Martin Vigoureux Former IESG member
No Objection
No Objection (for -13) Not sent

                            
Mirja Kühlewind Former IESG member
(was Discuss) No Objection
No Objection (2019-10-08 for -14) Sent
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.
Spencer Dawkins Former IESG member
No Objection
No Objection (for -13) Not sent

                            
Suresh Krishnan Former IESG member
No Objection
No Objection (for -13) Not sent

                            
Terry Manderson Former IESG member
No Objection
No Objection (for -13) Not sent