Ballot for draft-gutmann-scep
Discuss
Yes
No Objection
Note: This ballot was opened for revision 13 and is now closed.
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.
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.
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.
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.
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.
*** 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).
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.
SCEP is widely deployed and used, documenting it even for historic reference purposes is the right thing to do.
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.