From 56690068c795a1c8a4616c98814cf3244ad6cb91 Mon Sep 17 00:00:00 2001 From: javex Date: Mon, 4 Jun 2012 10:24:10 +0100 Subject: [PATCH] Initial commit of the default sources --- COPYRIGHT | 184 ++ HISTORY | 28 + Imakefile | 12 + Makefile | 24 + README | 449 ++++ TODO | 15 + cmd.h | 105 + conf.h | 29 + draft-nourse-scep-06.txt | 2283 ++++++++++++++++++ draft-nourse-scep-11.txt | 4734 ++++++++++++++++++++++++++++++++++++++ fileutils.c | 405 ++++ ias.c | 60 + ias.h | 23 + init.c | 234 ++ mkrequest | 171 ++ net.c | 191 ++ pkcs7.c | 734 ++++++ sceputils.c | 255 ++ sscep.c | 785 +++++++ sscep.conf | 106 + sscep.h | 308 +++ 21 files changed, 11135 insertions(+) create mode 100644 COPYRIGHT create mode 100644 HISTORY create mode 100644 Imakefile create mode 100644 Makefile create mode 100644 README create mode 100644 TODO create mode 100644 cmd.h create mode 100644 conf.h create mode 100644 draft-nourse-scep-06.txt create mode 100644 draft-nourse-scep-11.txt create mode 100644 fileutils.c create mode 100644 ias.c create mode 100644 ias.h create mode 100644 init.c create mode 100644 mkrequest create mode 100644 net.c create mode 100644 pkcs7.c create mode 100644 sceputils.c create mode 100644 sscep.c create mode 100644 sscep.conf create mode 100644 sscep.h diff --git a/COPYRIGHT b/COPYRIGHT new file mode 100644 index 0000000..357c2f6 --- /dev/null +++ b/COPYRIGHT @@ -0,0 +1,184 @@ + +Copyright (c) 2003 Jarkko Turkulainen. All rights reserved. + +Redistribution and use in source and binary forms, with or without +modification, are permitted provided that the following conditions +are met: + +1. Redistributions of source code must retain the above copyright + notice, this list of conditions and the following disclaimer. + +2. Redistributions in binary form must reproduce the above copyright + notice, this list of conditions and the following disclaimer in the + documentation and/or other materials provided with the distribution. + +THIS SOFTWARE IS PROVIDED BY JARKKO TURKULAINEN ``AS IS'' AND +ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE +IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE +ARE DISCLAIMED. IN NO EVENT SHALL JARKKO TURKULAINEN BE LIABLE +FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL +DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS +OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) +HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT +LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY +OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF +SUCH DAMAGE. + + +OpenSSL License +--------------- + +/* ==================================================================== + * Copyright (c) 1998-2001 The OpenSSL Project. All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in + * the documentation and/or other materials provided with the + * distribution. + * + * 3. All advertising materials mentioning features or use of this + * software must display the following acknowledgment: + * "This product includes software developed by the OpenSSL Project + * for use in the OpenSSL Toolkit. (http://www.openssl.org/)" + * + * 4. The names "OpenSSL Toolkit" and "OpenSSL Project" must not be used to + * endorse or promote products derived from this software without + * prior written permission. For written permission, please contact + * openssl-core@openssl.org. + * + * 5. Products derived from this software may not be called "OpenSSL" + * nor may "OpenSSL" appear in their names without prior written + * permission of the OpenSSL Project. + * + * 6. Redistributions of any form whatsoever must retain the following + * acknowledgment: + * "This product includes software developed by the OpenSSL Project + * for use in the OpenSSL Toolkit (http://www.openssl.org/)" + * + * THIS SOFTWARE IS PROVIDED BY THE OpenSSL PROJECT ``AS IS'' AND ANY + * EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR + * PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE OpenSSL PROJECT OR + * ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, + * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT + * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; + * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, + * STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) + * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED + * OF THE POSSIBILITY OF SUCH DAMAGE. + * ==================================================================== + * + * This product includes cryptographic software written by Eric Young + * (eay@cryptsoft.com). This product includes software written by Tim + * Hudson (tjh@cryptsoft.com). + * + */ + +Original SSLeay License +----------------------- + +/* Copyright (C) 1995-1998 Eric Young (eay@cryptsoft.com) + * All rights reserved. + * + * This package is an SSL implementation written + * by Eric Young (eay@cryptsoft.com). + * The implementation was written so as to conform with Netscapes SSL. + * + * This library is free for commercial and non-commercial use as long as + * the following conditions are aheared to. The following conditions + * apply to all code found in this distribution, be it the RC4, RSA, + * lhash, DES, etc., code; not just the SSL code. The SSL documentation + * included with this distribution is covered by the same copyright terms + * except that the holder is Tim Hudson (tjh@cryptsoft.com). + * + * Copyright remains Eric Young's, and as such any Copyright notices in + * the code are not to be removed. + * If this package is used in a product, Eric Young should be given attribution + * as the author of the parts of the library used. + * This can be in the form of a textual message at program startup or + * in documentation (online or textual) provided with the package. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * 3. All advertising materials mentioning features or use of this software + * must display the following acknowledgement: + * "This product includes cryptographic software written by + * Eric Young (eay@cryptsoft.com)" + * The word 'cryptographic' can be left out if the rouines from the library + * being used are not cryptographic related :-). + * 4. If you include any Windows specific code (or a derivative thereof) from + * the apps directory (application code) you must include an acknowledgement: + * "This product includes software written by Tim Hudson (tjh@cryptsoft.com)" + * + * THIS SOFTWARE IS PROVIDED BY ERIC YOUNG ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + * + * The licence and distribution terms for any publically available version or + * derivative of this code cannot be changed. i.e. this code cannot simply be + * copied and put under another distribution licence + * [including the GNU Public Licence.] + */ + +OpenOSP License +--------------- + +The Vovida Software License, Version 1.0 +Copyright (c) 2000 Vovida Networks, Inc. All rights reserved. + +Redistribution and use in source and binary forms, with or without +modification, are permitted provided that the following conditions +are met: + +1. Redistributions of source code must retain the above copyright + notice, this list of conditions and the following disclaimer. + +2. Redistributions in binary form must reproduce the above copyright + notice, this list of conditions and the following disclaimer in + the documentation and/or other materials provided with the + distribution. + +3. The names "OpenOSP", "OpenOSP server" and "Cisco" must not be used + to endorse or promote products derived from this software without + prior written permission. For written permission, please contact + openosp@vovida.org. + +4. Products derived from this software may not be called "CISCO" or + "OpenOSP", nor may "CISCO" or "OpenOSP" appear in their name, without + prior written permission. + +THIS SOFTWARE IS PROVIDED "AS IS" AND ANY EXPRESSED OR IMPLIED +WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES +OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE AND +NON-INFRINGEMENT ARE DISCLAIMED. IN NO EVENT SHALL VOVIDA +NETWORKS, INC. OR ITS CONTRIBUTORS BE LIABLE FOR ANY DAMAGES +IN EXCESS OF $1,000, NOR FOR ANY INDIRECT, INCIDENTAL, SPECIAL, +EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, +PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR +PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY +OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT +(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE +USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH +DAMAGE. diff --git a/HISTORY b/HISTORY new file mode 100644 index 0000000..5b130fa --- /dev/null +++ b/HISTORY @@ -0,0 +1,28 @@ + +SSCEP Release history +======================================== + +Release 20081211 +* Patch from Leo Koutikas: set signerkey correctly in pkcs7.c + + +Release 20071227 +* Patch from Bas ten Berge: OpenSSL-related fix + ability to use cert + serial number as hex + +Release 20040325 +* Fixed a bug in mkrequest. Thanks for Scott Moynes pointing it out. + +Release 20030417 +* Modifications from Fiel Cabral ensure that the URL encoded Base64 + PKCS7 is NUL-terminated. +* Manuel Gil Perez pointed out that not all CA's define the + certificate usage. Do not exit if such a thing happens, just warn. +* Changed the misleading error message for missing CA cert (-c) if + method "getca" is used. + + +First public release was around Jan 25 2003, I guess that would make it +a release 20030125. + + diff --git a/Imakefile b/Imakefile new file mode 100644 index 0000000..557bf17 --- /dev/null +++ b/Imakefile @@ -0,0 +1,12 @@ +# From: Fiel Cabral +# Run xmkmf then run make. + +PROGRAM = sscep +OBJS = sscep.o init.o net.o sceputils.o pkcs7.o ias.o +fileutils.o + +LOCAL_LIBS = -lcrypto + +SingleProgramTarget($(PROGRAM),$(OBJS),$(LOCAL_LIBS),NullParameter) +AllTarget($(PROGRAM)) + diff --git a/Makefile b/Makefile new file mode 100644 index 0000000..56518ca --- /dev/null +++ b/Makefile @@ -0,0 +1,24 @@ +# +# $Id: Makefile,v 1.0 2003/01/12 13:17:37 jt Exp $ +# + +BINDIR = /usr/local/bin +MANDIR = /usr/local/man/man8 + +CC = gcc +#WITH_DEBUG = -g +CFLAGS = -Wall -O $(WITH_DEBUG) + +MAN = sscep.8 +PROG = sscep +OBJS = sscep.o init.o net.o sceputils.o pkcs7.o ias.o fileutils.o + +$(PROG): $(OBJS) + $(CC) $(CFLAGS) -lcrypto -o $(PROG) $(OBJS) + +clean: + rm -f $(PROG) $(OBJS) $(MAN) core + +install: + ./install-sh $(PROG) $(BINDIR) + ./install-sh $(MAN) $(MANDIR) diff --git a/README b/README new file mode 100644 index 0000000..73ae170 --- /dev/null +++ b/README @@ -0,0 +1,449 @@ + +SSCEP - Simple SCEP client for Unix +Copyright (c) Jarkko Turkulainen 2003. All rights reserved. +See the file COPYRIGHT for licensing information. +=========================================================== + + +WHAT IS SSCEP? +============== + +SSCEP is a client-only implementation of the SCEP (Cisco System's Simple +Certificate Enrollment Protocol). SSCEP is designed for OpenBSD's isakmpd, +but it will propably work with any Unix system with a recent compiler and +OpenSSL toolkit libraries installed. + + +WHAT SCEP? +========== + +(From the Cisco Systems White Paper): + +SCEP is a PKI communication protocol which leverages existing +technology by using PKCS#7 and PKCS#10. SCEP is the evolution of the +enrollment protocol developed by Verisign, Inc. for Cisco Systems, Inc. +It now enjoys wide support in both client and CA implementations. + +The goal of SCEP is to support the secure issuance of certificates to +network devices in a scalable manner, using existing technology whenever +possible. The protocol supports the following operations: + + CA and RA public key distribution + Certificate enrollment + Certificate and CRL query + +Certificate and CRL access can be achieved by using the LDAP protocol, +or by using the query messages defined in SCEP. + + +SSCEP FEATURES +============== + +Currently, SSCEP implements all of the SCEP operations using SCEP query +messages. There's no LDAP support, and probably there will never be +(that's why it is simple). + +SSCEP has been tested successfully against the following CA products: + +o OpenSCEP server (getca, enroll and getcrl works)* +o Windows2000 server CA + Microsoft SCEP module (works) +o SSH Certifier (getca and enroll works) +o iPlanet CMS (getca and enroll works)* +o VeriSign Onsite (getca and enroll works)** +o Entrust VPN Connect (getca and enroll works)*** +o OpenCA (getca, enroll, getcrl and automatic approval works)**** + +(*) by default, subjectAltName extensions are dropped from certificate +(**) only DNS subjectAltName allowed (demo mode) +(***) demo requires to use /C=US/O=Entrust +(****) automatic approval according to newer SCEP drafts requires + OpenCA 0.9.2.4 or higher + +HOW TO COMPILE +============== + +The program should compile on OpenBSD system without problems. Uncompress +the package and run command + +$ make + +Copy binary file sscep and configuration file sscep.conf to somewhere. + + +HOW TO USE +========== + +Running the command "sscep" without any arguments should give you a list +of arguments and command line options. + +$ ./sscep + +sscep version 2005XXXX + +Usage: ./sscep OPERATION [OPTIONS] + +Available OPERATIONs are + getca Get CA/RA certificate(s) + enroll Enroll certificate + getcert Query certificate + getcrl Query CRL + +General OPTIONS + -u SCEP server URL + -p Use proxy server at host:port + -f Use configuration file + -c CA certificate file (write if OPERATION is getca) + -E PKCS#7 encryption algorithm (des|3des|blowfish) + -S PKCS#7 signature algorithm (md5|sha1) + -v Verbose operation + -d Debug (even more verbose operation) + +OPTIONS for OPERATION getca are + -i CA identifier string + -F Fingerprint algorithm (md5|sha1) + +OPTIONS for OPERATION enroll are + -k Private key file + -r Certificate request file + -K Signature private key file + -O Signature certificate (used instead of self-signed) + -l Write enrolled certificate in file + -e Use different CA cert for encryption + -L Write selfsigned certificate in file + -t Polling interval in seconds + -T Max polling time in seconds + -n Max number of GetCertInitial requests + -R Resume interrupted enrollment + +OPTIONS for OPERATION getcert are + -k Private key file + -l Local certificate file + -s Certificate serial number (decimal) + -w Write certificate in file + +OPTIONS for OPERATION getcrl are + -k Private key file + -l Local certificate file + -w Write CRL in file + + +SSCEP also supports configuration via a configuration file (-f). +This is the recommended way to configure SSCEP and all the examples +in below assume that you have done so. + +All configuration options are key-value pairs separated with one +or more space characters: + +"Key" [spaces] "Value" + +Quotation marks are optional - they are needed only if the value contains +space characters (space or tab). Quotation marks inside the value string +must be escaped using a backslash: + +"Key" [spaces] "Value \"containing quotation marks\"" + +Comment lines (lines starting with '#') and empty lines are discarded. + +Here are the available configuration file keys and example values: + +Key Explanation +===================================================================== + +CACertFile This is one is needed with all operations. + Example: ./ca.crt + Command line option: -c + +CAIdentifier Some CAs require you to define this. Example: mydomain.com + Command line option: -i + +CertReqFile Certificate request file created with mkrequest. + Example: ./local.csr + Command line option: -r + +Debug Debug? Answer "yes" or "no". + Command line option: -d + +EncAlgorithm PKCS#7 encryption algorithm. Available algorithms are des, + 3des and blowfish. NOTE: this could be very misleading, + current SCEP draft provides no mechanism to "negotiate" + the algorithm - even if you send 3des, reply might be des + (same thing applies to SigAlgorithm). + Command line option: -E + +EncCertFile If your CA/RA uses a different certificate for encyption + and signing, define this. CACertFile is used for verifying + the signature. Example: ./enc.crt + Command line option: -e + +SignCertFile Instead of creating a self-signed certificate from the + new key pair use an already existing certficate/key to + sign the SCEP request. If the "old" certificate and + key is used, the CA can verify that the holder of the + private key for an existing certificate re-enrolls for + a renewal certificate, allowing for automatic approval + of the request. Requires specification of the corresponding + signature private key file (-K, SignKeyFile). + Example: ./sig.crt + Command line option: -O + +SignKeyFile See SignCertFile. Specifies the corresponding private key. + Example: ./sig.key + Command line option: -K + +FingerPrint Display fingerprint algorithm. Available algorithms are md5 + and sha1. Default is md5. + Command line option: -F + +GetCertFile Write certificate asquired via getcert operation. + Example: ./cert.crt + Command line option: -w + +GetCertSerial Certificate serial number. Define this for getcert. The value + is defined as a decimal number. Example: 12 + Command line option: -s + +GetCrlFile Write CRL to file. Example: ./crl.crl + Command line option: -w + +LocalCertFile Write successfully enrolled certificate. Example: ./local.crt + Command line option: -l + +MaxPollCount Max number of GetCertInitial requests. Example: 50 + Command line option: -n + +MaxPollTime Max polling time in seconds. Example: 28800 + Command line option: -T + +PollInterval Poll periodically for pending certificate. Example: 60 + Command line option: -t + +PrivateKeyFile Private key created with mkrequest. Example: ./local.key + Command line option: -k + +Proxy Use HTTP proxy at host:port. Example: localhost:8080 + Command line option: -p + +SelfSignedFile Write optionally the selfsigned certificate in file (needed + in SCEP transaction). Example: ./selfsigned.crt + Command line option: -L + +SigAlgorithm PKCS#7 signature algorithm. Available algorithms are md5 + and sha1. Default is md5. + Command line option: -E + +URL URL of the SCEP server. Example: + http://localhost/cgi-bin/pkiclient.exe + Command line option: -u + +Verbose Verbose? Answer "yes" or "no" + Command line option: -v + + + +The actual enrollment is done with the following procedure: + +STEP 1 - Gather information +=========================== + +- CA server identification string +If your SCEP server requires you to use a specific identification string +in the initial CA certificate access (step 3), write it down. + +- CA server http URL +You must know the *complete* url, with http:// and cgi-program path and +everything. Example: + +http://pkiserver.company.com/cgi-bin/pkiclient.exe + +- CA naming policy +You need to know what kind of DN you request. Some may require you to use +unstructuredName naming, some may require a CN with localityName, etc. + + +STEP 2 - Make certificate request and key +========================================= + +Before the enrollment can take place, sscep needs a private key file +and the corresponding X.509 certificate request in PKCS#10 format. Edit +the DN variables in the file mkrequest (it's a shell script) if you need. +When ready, make the request: + +$ mkrequest -ip 172.30.0.1 +Generating RSA private key, 1024 bit long modulus +..............++++++ +...++++++ +e is 65537 (0x10001) +Using configuration from .4018client.cnf + +This writes key and request named local.key and local.csr (you can change +the "local" with variable PREFIX in mkrequest). + +If the CA supports automatic enrollment, you may supply the password in +cert request: + +$ mkrequest -ip 172.30.0.1 password + + +STEP 3 - Get CA certificate +=========================== + +Configure the URL and CACertFile in configuration file (sscep.conf) and +run the command + +$ ./sscep getca -f sscep.conf +./sscep: requesting CA certificate +./sscep: valid response from server +./sscep: MD5 fingerprint: 1D:3C:4C:DF:99:73:B8:FB:B4:EE:C4:56:A9:7C:37:A3 +./sscep: CA certificate written as ca.crt + +NOTE: it is very important to make sure that the CA certificate is really +what you think it is. The security of the whole protocol depends on that!! +This is why the fingerprint is printed on terminal - you should check that +from your CA. You can check the fingerprint any time with command + +$ openssl x509 -in ca.crt -noout -fingerprint + +If the CA sends a certificate chain, sscep writes all certificates in the +order it founds them in reply and names them with an integer prefix +(-number) appended to CACertFile. + +$ ./sscep getca -f sscep.conf +./sscep: requesting CA certificate +./sscep: valid response from server + +./sscep: found certificate with + subject: /C=FI/O=klake.org/CN=klake.org VPN RA + issuer: /C=FI/O=klake.org/CN=klake.org VPN CA + usage: Digital Signature, Non Repudiation + MD5 fingerprint: 7A:92:84:2A:6F:EE:28:14:F9:69:D8:9D:61:34:B5:67 +./sscep: certificate written as ca.crt-0 + +./sscep: found certificate with + subject: /C=FI/O=klake.org/CN=klake.org VPN CA + issuer: /C=FI/O=klake.org/CN=klake.org VPN CA + usage: Digital Signature, Non Repudiation, Certificate Sign, CRL Sign + MD5 fingerprint: A5:CE:94:5C:96:77:94:E8:F5:31:AB:D5:31:18:1D:E1 +./sscep: certificate written as ca.crt-1 + +SSCEP prints out issuer, subject, key usage and md5/sha1 fingerprint for +each certificate it founds. This information might help you to decide what +certificate to use. Some CAs may give you a three (or more) certificates, +the root CA(s) plus different RA certificates for encryption and signing. +If that's your case, you have to define encryption certificate with command +line option (-e) or with conf file keyword EncCertFile. Probably it is the +certificate with key usage "Key Encipherment". + +Currently, SSCEP doesn't verify the CA/RA certificate chain. You can +do it manually with OpenSSL: + +$ openssl verify -CAfile ca.crt-1 ca.crt-0 +ca.crt-0: OK + +NOTE: In case of multiple CA/RA certificates, the actual CA (the one who +signs your certificate) might not be the same as the CA/RA you are dealing +with. Keep this in mind when installing the CA cert in /etc/isakmpd/ca. + + +STEP 4 - Make enrollment +======================== + +You need to supply configuration file keys URL, CACertFile, PrivateKeyFile, +LocalCertFile and CertReqFile. PrivateKeyFile is the key generated in step 2 +(local.key), CertReqFile is the request (local.csr) and LocalCertFile is +where the enrolled certificate will be written once ready. + +If your CA/RA have different certificates for encryption and signing, you +must also provide the encryption certificate (EncCertFile). + +Normally, the enrollment looks like this: + +$ ./sscep enroll -f sscep.conf +./sscep: sending certificate request +./sscep: valid response from server +./sscep: pkistatus: PENDING +./sscep: requesting certificate (#1) +./sscep: valid response from server +./sscep: pkistatus: PENDING +./sscep: requesting certificate (#2) +./sscep: valid response from server +./sscep: pkistatus: PENDING +.... +./sscep: requesting certificate (#NNN) +./sscep: valid response from server +./sscep: pkistatus: SUCCESS +./sscep: certificate written as ./local.crt + +First message sent is PKCSReq, that's where your request goes. Then the CA +writes request down and sends reply PENDING, indicating that the certificate +is not signed yet. SSCEP polls periodically for the certificate by sending +GetCertInitial messages until the CA returns SUCCESS. The polling interval +can be adjusted with PollInterval, or command line option (-t). You can +interrupt the process any time and start again using "sscep enroll ..". +You should use the command line option (-R) when you continue the interrupted +enrollment. + +If the CA is configured for automatic enrollment (and your request includes +the challenge password), it returns SUCCESS as a first reply. Otherwise, the +enrollment requires manual signing and authentication (perhaps a phone call). + +Newer SCEP draft versions allow to use the existing certificate (issued +by the CA) to authenticate a renewal request. In this context, the SCEP +request with the new public key is signed with the old certificate and +key (instead of using a self-signed certificate created from the new +key pair). +To use this feature, use the command line options -O and -K to specify +the old certificate and private key (SignCertFile and SignCertKey +in the configuration file). +The actual behaviour of the SCEP server depends on the CA policy and +on the capabilities of the SCEP server (not all servers implement +this feature, using the existing certificate with an older SCEP server +may or may not work, depending on implementation). + +Note: Newer versions of OpenCA (http://www.openca.info/) support +an SCEP server that is capable of automatically approving SCEP requests +signed with the already existing key pair. + + +STEP 5 - Use certificate +======================== + +Install local.key, local.crt and ca.crt in the isakmpd default locations and +you are ready to go! Default locations are + +Private key /etc/isakmpd/private/local.key +Certificate /etc/isakmpd/certs/local.crt +CA certificate /etc/isakmpd/ca/ca.crt + +And pay attention to CA certificate if your enrollment was done via RA +server. "openssl verify -CAfile ca.crt local.crt" is your friend here. + + + +STEP 6 - Check out revocation list (optional) +============================================= + +You need your enrolled certificate for this step. + +$ ./sscep getcrl -f sscep.conf +./sscep: requesting crl +./sscep: valid response from server +./sscep: pkistatus: SUCCESS +./sscep: CRL written as ./crl.crl + + + +CREDITS +======= + +I'd like to thank the following people for providing me feedback: + +Fiel Cabral +Manuel Gil Perez + + +OpenSSL toolkit made this possible. + +I would also like to thank OpenSCEP project for it's great software, +reading the source code helped me understand the protocol. Unfortunately, +it's license is too restrictive for my use. + diff --git a/TODO b/TODO new file mode 100644 index 0000000..fae8b3f --- /dev/null +++ b/TODO @@ -0,0 +1,15 @@ + +TODO list for SSCEP +=================== + +o Automatic verify for CA/RA cert bundle (write_ca_re(), fileutils.c) + * Identify self-signed cert and verify against it + +o Automatic verify for issued certificate + +o Add meaningful exit status instead of SCEP_PKISTATUS_ERROR in some places + +o Fetch CRL via CA cert HTTP distribution point (not really a SCEP thing, + but nice feature anyway..) + + diff --git a/cmd.h b/cmd.h new file mode 100644 index 0000000..9a83d5d --- /dev/null +++ b/cmd.h @@ -0,0 +1,105 @@ + +/* + * sscep -- Simple SCEP client implementation + * Copyright (c) Jarkko Turkulainen 2003. All rights reserved. + * See the file COPYRIGHT for licensing information. + */ + +/* + * Command line options + * These are defined globally for easy access from all functions. + * For each command line option 'x', there is int x_flag and + * char *x_char or int x_num if the option requires parameter. + */ + +/* CA certificate */ +int c_flag; +char *c_char; + +/* Debug? */ +int d_flag; + +/* CA encryption certificate */ +int e_flag; +char *e_char; + +/* Encryption algorithm */ +char *E_char; +int E_flag; + +/* Configuration file */ +int f_flag; +char *f_char; + +/* Fingerprint algorithm */ +char *F_char; +int F_flag; + +/* Local certificate */ +char *l_char; +int l_flag; + +/* Local selfsigned certificate (generated automaticatally) */ +char *L_char; +int L_flag; + +/* CA identifier */ +char *i_char; +int i_flag; + +/* Private key */ +char *k_char; +int k_flag; + +/* Private key of already existing certificate */ +char *K_char; +int K_flag; + +/* Request count */ +int n_flag; +int n_num; + +/* Already existing certificate (to be renewed) */ +char *O_char; +int O_flag; + +/* Proxy */ +char *p_char; +int p_flag; + +/* GetCrl CRL file */ +char *r_char; +int r_flag; + +/* Resume */ +int R_flag; + +/* Certificate serial number */ +char *s_char; +int s_flag; + +/* Signature algorithm */ +char *S_char; +int S_flag; + +/* Polling interval */ +int t_num; +int t_flag; + +/* Max polling time */ +int T_num; +int T_flag; + +/* URL */ +int u_flag; +char *url_char; + +/* Verbose? boolean */ +int v_flag; + +/* GetCert certificate */ +int w_flag; +char *w_char; + +/* End of command line options */ + diff --git a/conf.h b/conf.h new file mode 100644 index 0000000..f4a5988 --- /dev/null +++ b/conf.h @@ -0,0 +1,29 @@ + +/* + * sscep -- Simple SCEP client implementation + * Copyright (c) Jarkko Turkulainen 2003. All rights reserved. + * See the file COPYRIGHT for licensing information. + */ + + +/* Network timeout */ +#define TIMEOUT 120 + +/* Polling interval seconds */ +#define POLL_TIME 300 + +/* Max polling seconds */ +#define MAX_POLL_TIME 28800 + +/* Max polling count */ +#define MAX_POLL_COUNT 256 + +/* CA identifier */ +#define CA_IDENTIFIER "CAIdentifier" + +/* Self signed certificate expiration */ +#define SELFSIGNED_EXPIRE_DAYS 365 + +/* Transaction id for GetCert and GetCrl methods */ +#define TRANS_ID_GETCERT "SSCEP transactionId" + diff --git a/draft-nourse-scep-06.txt b/draft-nourse-scep-06.txt new file mode 100644 index 0000000..0cb3e07 --- /dev/null +++ b/draft-nourse-scep-06.txt @@ -0,0 +1,2283 @@ +INTERNET DRAFT Xiaoyi Liu +draft-nourse-scep-06.txt Cheryl Madson +expires 15-November 2002 David McGrew + Andrew Nourse + Cisco Systems + +Category: Informational 15 May 2002 + + +Cisco Systems' Simple Certificate Enrollment Protocol(SCEP): + +Status of this Memo + +This document is an Internet-Draft and is NOT offered in +accordance with Section 10 of RFC2026, and the author does not +provide the IETF with any rights other than to publish as an +Internet-Draft + +Internet-Drafts are working documents of the Internet Engineering +Task Force (IETF), its areas, and its working groups. Note that +other groups may also distribute working documents as +Internet-Drafts. + +Internet-Drafts are draft documents valid for a maximum of six +months and may be updated, replaced, or obsoleted by other +documents at any time. It is inappropriate to use Internet- +Drafts as reference material or to cite them other than as +"work in progress." + +The list of current Internet-Drafts can be accessed at +http://www.ietf.org/ietf/1id-abstracts.txt + +The list of Internet-Draft Shadow Directories can be accessed at +http://www.ietf.org/shadow.html. + +This memo provides information for the Internet community. This memo +does not specify an Internet standard of any kind. Distribution of +this memo is unlimited. + + +Abstract + +This document specifies the Cisco Simple Certificate Enrollment +Protocol, a PKI communication protocol which leverages existing +technology by using PKCS#7 and PKCS#10. SCEP is the evolution of the +enrollment protocol developed by Verisign, Inc. for Cisco Systems, Inc. +It now enjoys wide support in both client and CA implementations. + + +Table of Contents + + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 2 + 2. The Goal of SCEP . . . . . . . . . . . . . . . . . . . . . 3 + 2.1 SCEP Entity types . . . . . . . . . . . . . . . . . . . . 3 + 2.2 SCEP Operations Overview . . . . . . . . . . . . . . . . . 7 + + +Liu/Madson/McGrew/Nourse [Page 2] + +Cisco Systems' Simple Certificate Enrollment Protocol May 2002 + + 2.3 PKI Operation Transactional Behavior . . . . . . . . . . . 10 + 2.4 Security . . . . . . . . . . . . . . . . . . . . . . . . . 12 + 3. Transport Protocol . . . . . . . . . . . . . . . . . . . . 13 + 4. Secure Transportation: PKCS #7 . . . . . . . . . . . . . . 14 + 4.1 SCEP Message Format . . . . . . . . . . . . . . . . . . . 14 + 4.2 Signed Transaction Attributes . . . . . . . . . . . . . . 15 + 5. SCEP Transaction Specification . . . . . . . . . . . . . . 16 + 6. Security Considerations . . . . . . . . . . . . . . . . . 33 + 7. Intellectual Propoerty . . . . . . . . . . . . . . . . . . 33 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . 33 + Appendix A. Cisco End Entity Subject Name Definition . . . . . 34 + Appendix B. IPSEC Client Enrollment Certificate Request . . . . 35 + Appendix C. Private OID Definitions . . . . . . . . . . . . . 36 + Appendix D. Obtaining CRL by LDAP Query . . . . . . . . . . . . 36 + Appendix E. SCEP State Transitions . . . . . . . . . . . . . . 37 + Appendix F. Author Contact Information. . . . . . . . . . . . . 40 + Appendix G. Copyright Section . . . . . . . . . . . . . . . . . 40 + + +Section 1. Introduction + +Public key technology is becoming more widely deployed and is becoming +the basis for standards based security, such as the Internet Engineering +Task Force's IPSEC and IKE protocols. With the use of public key +certificates in network security protocols comes the need for a +certificate management protocol that Public Key Infrastructure (PKI) +clients and Certificate Authority servers can use to support certificate +life cycle operations such as certificate enrollment and revocation, and +certificate and CRL access. + +In the following, Section 2 gives an overview of the PKI operations, and +Section 2.4 describes the security goals of the protocol and the +mechanisms used to achieve them. The transport protocol and the +security protocol PKCS#7 are described at Section 3 and Section 4, +respectively. The last section, Section 5, specifies each PKI operation +in terms of the message formats and the data structures of each +operation. + +The appendices provide detailed specifications and examples. End entity +subject names are specified in Appendix A, attribute OIDs are specified +in Appendix C , and the SCEP state transitions are described in Appendix +E. An example of a certificate enrollment request is provided in +Appendix B, and an example LDAP query URL encoding is provided in +Appendix D. + +The authors would like to thank Peter William of ValiCert, Inc. +(formerly of Verisign, Inc) and Alex Deacon of Verisign, Inc. and +Christopher Welles of IRE, Inc. for their contributions to this protocol +and to this document. + + + + +Liu/Madson/McGrew/Nourse [Page 3] + +Cisco Systems' Simple Certificate Enrollment Protocol May 2002 + +2.0 The Goal of SCEP +The goal of SCEP is to support the secure issuance of certificates to +network devices in a scalable manner, using existing technology whenever +possible. The protocol supports the following operations: + + CA and RA public key distribution + Certificate enrollment + Certificate revocation + Certificate query + CRL query + +Certificate and CRL access can be achieved by using the LDAP protocol +(as specified in Appendix D), or by using the query messages defined in +SCEP. The use of HTTP certificate and CRL access, and the support of +CDP as specified in RFC2459, will be specified in a future version of +this document. In Section 2.1, we first define PKI entity types as well +as the properties of each entity type. In Section 2.2, the PKI +operations are described at functional level. Section 2.3 describes the +transaction behavior of each PKI operations. The complete PKI messages +are covered in Section 5. + +2.1 SCEP Entity types + +The entity types defined in SCEP are the end entity type (i.e., IPSEC +clients), the Certificate Authority (CA) entity type, and the +Registration Authority entity type (RA). An end entity is sometimes +called a "SCEP client" in the following. + +2.1.1 End Entities + +An end entity is an entity whose name is defined in a certificate +subject name field and optionally, in SubjectAltName, a X.509 +certificate V3 extension. As an end entity, a SCEP client is identified +by a subject name consisting of the following naming attributes: + + Fully qualified domain name, for example, router.cisco.com + IP address, or + Serial number. + +In the paragraph above , the fully qualified domain name is required for +each SCEP client, the IP address and the serial number are optional name +attributes. In the certificate enrollment request, the PKCS#10 subject +field contains the required and optional name attributes. Based on the +PKCS#10 subject name information, the certificate issued to the SCEP +client must have the same name attributes set both in the subjectName +field and in the SubjectAltName extension. + +It is important to note that a client named as Alice.cisco.com is +different than a client named as Alice.cisco.com plus the IP address +name attribute 171.69.1.129. From CA point of view, the Distinguished +names assigned in these two cases are distinct names. + + +Liu/Madson/McGrew/Nourse [Page 4] + +Cisco Systems' Simple Certificate Enrollment Protocol May 2002 + +Entity names which are specified as in the IPSEC profile (i.e., FQDN, IP +address and User FQDN) must be presented in certificate's SubjectAltName +extension. Multiple IPSEC entity names, (if any) are encoded as multiple +values of a single SubjectAltName extension. The CA has the authority +to assign a distinguished name to an end entity. The assigned DN should +contain the SCEP client names as the relative DN. + +The attribute identifiers and an example of SCEP client subject name are +specified in Appendix A. Appendix B has an example from Cisco VPN Client +enrollment request. + +2.1.1.1 Local Key/Certificate/CRL Storage and Certificate-name uniqueness + +An end entity is required to generate asymmetric key pairs and to +provide storage to store its private keys. If the end entity does not +have enough permanent memory to save its certificate, the end entity +should be able to query its own certificate from the CA, once the +certificate has been issued. The public key pairs can be generated with +a specific key usage. The key usage are conveyed to the CA through the +certificate enrollment request. All current SCEP client implementations +expect that there will be only one pair of keys for a given subject name +and key usage combination and CA, at any time. This property is called +the certificate-name uniqueness property, and it implies that a CA that +implements SCEP will enforce the unique mapping between a SCEP client +subject name and its key pairs with a given key usage. At any time, if +the subject name is changed, or if the key is updated, the existing +certificate would have to be revoked before a new one could be issued. + +It is desirable that the CA enforce certificate-name uniqueness, but +it is not mandatory. However a CA that does not enforce uniqueness +must provide some other mechanism to prevent the re-transmission of an +enrollment request by a SCEP client from creating a second certificate +or certificate request, nor can the second request merely be rejected. +If a client times out from polling for a pending request it can +resynchronize by reissuing the original request with the original +subject name and transaction ID. This must return the status of the +original transaction, including the certificate if it was granted. +It must not create a new transaction unless the original cert has been +revoked, or the transaction arrives more than halfway through the +validity time of the original certificate. + +An enrollment request that occurs more than halfway through the validity +time of an existing certificate for the same subject name and key usage +MAY be interpreted as a renewal request and accepted regardless of the +duplication of subject name. Certificate renewal can be done this way. + + +2.1.1.2 End entity 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 + + +Liu/Madson/McGrew/Nourse [Page 5] + +Cisco Systems' Simple Certificate Enrollment Protocol May 2002 + +cryptographically secure manner. This requirement is needed to +prevent a "man in the middle" attack, in which an adversary that can +manipulate the data as it travels between the protocol participants +can subvert the security of the protocol. To satisfy this +requirement, SCEP provides two authentication methods: manual +authentication, and authentication based on pre-shared secret. In the +manual mode, the end entity submitting the request is required to wait +until its identity can be verified by the CA operator using any +reliable out-of-band method. To prevent a "man-in-the-middle" attack, +an MD5 `fingerprint' generated on the PKCS#10 (before PKCS #7 +enveloping and signing) must be compared out-of-band between the server +and the end entity. SCEP clients and CAs (or RAs, if appropriate) +must display this fingerprint to a user to enable this verification, +if manual mode is used. Failing to provide this information leaves +the protocol vulnerable to attack by sophisticated adversaries. When +utilizing a pre-shared secret scheme, the server should distribute a +shared secret to the end entity which can uniquely associate the +enrollment request with the given end entity. The distribution of the +secret must be private: only the end entity should know this +secret. The actual binding mechanism between the end entity and the +secret is subject to the server policy and implementation. When +creating enrollment request, the end entity is asked to provide a +challenge password. When using the pre-shared secret scheme, the end +entity must type in the re-distributed secret as the password. In the +manual authentication case, the challenge password is also required +since the server may challenge an end entity with the password before +any certificate can be revoked. Later on, this challenge password +will be included as a PKCS#10 attribute, and is sent to the server as +encrypted data. The PKCS#7 envelope protects the privacy of the +challenge password with DES encryption. + +2.1.1.3 Self-Signed Certificates + +In this protocol, the communication between the end entity and the +certificate authority is secured by using PKCS#7 as the messaging +protocol. PKCS#7, however, is a protocol which assumes the communicating +entities already possess the peer's certificates and requires both +parties use the issuer names and issuer assigned certificate serial +numbers to identify the certificate in order to verify the signature and +decrypt the message. When using PKCS#7 as a secure protocol for SCEP +transactions this assumption may not be valid. To solve this problem, +an end entity generates a self-signed certificate for its own public +key. In this self-signed certificate, the issuer name is the end entity +subject name (the same name later used in the PKCS#10). During the +certificate enrollment, the end entity will first post itself as the +signing authority by attaching the self-signed certificate to the signed +certificate request. When the Certificate Authority makes the envelope +on the issued certificate using the public key included in the +self-signed certificate, it should use the same issuer name and serial +number as conveyed in the self-signed certificate to inform the end +entity on which private key should be used to open the envelope. + +Note that when a client enrolls for Mayarate encryption and signature + +Liu/Madson/McGrew/Nourse [Page 6] + +Cisco Systems' Simple Certificate Enrollment Protocol May 2002 + +certificates, it may use the signature certificate to sign both +requests, and then expect its signature key to be used to encrypt +both responses. In any case, the recipientinfo on the envelope should +reflect the key used to encrypt the request. + +2.1.2 Certificate Authority + +A Certificate Authority(CA) is an entity whose name is defined in the +certificate issuer name field. Before any PKI operations can begin, +the CA generates its own public key pair and creates a self-signed CA +certificate, or causes another CA to issue a certificate to it. +Associated with the CA certificate is a fingerprint which will be used +by the end entity to authenticate the received CA certificate if it +is self-signed. The fingerprint is created by calculating a MD5 hash +on the whole CA certificate. Before any end entity can start its +enrollment, this root certificate has to be configured at the entity +side securely. For IPSEC clients, the client certificates must have +SubjectAltName extension. To utilize LDAP as a CRL query protocol, +the certificates must have CRL Distribution Point. Key usage is +optional. Without key usage, the public key is assumed as a general +purpose public key and it can be used for all the purposes. + +A Certificate Authority may enforce certain name policy. When using +X.500 directory name as the subject name, all the name attributes +specified in the PKCS#10 request should be included as Relative DN. All +the name attributes as defined in RFC2459 should be specified in the +SubjectAltName. An example is provided in Appendix A. + + If there is no LDAP query protocol support, the Certificate Authority +should answer certificate and CRL queries, and to this end it should be +online all the time. + +The updating of the CA's public key is not addressed within the SCEP +protocol. An SCEP client can remove its copy of a CA's public key and +re-enroll under the CA's new public key. + +2.1.3 Registration Authorities + +In the environment where a RA is present, an end entity performs +enrollment through the RA. In order to setup a secure channel with RA +using PKCS#7, the RA certificate(s) have to be obtained by the client +in addition to the CA certificate(s). + +In the following, the CA and RA are specified as one entity in the +context of PKI operation definitions. + +2.1.4 Trusted Root Store + +To support interoperability between IPSEC peers whose certificates are +issued by different CA, SCEP allows the users to configure multiple +trusted roots. A root is a trusted root when its certificate has been + + +Liu/Madson/McGrew/Nourse [Page 7] + +Cisco Systems' Simple Certificate Enrollment Protocol May 2002 + +configured as such in the client. An SCEP client that supports multiple +roots must associate with each root the information needed to query a +CRL from each root. + +Once a trusted root is configured in the client, the client can verify +the signatures of the certificates issued by the given root. + +2.2 SCEP Operations Overview + +In this section, we give a high level overview of the PKI operations as +defined in SCEP. + +2.2.1 End Entity Initialization + +The end entity initialization includes the key pair generation and the +configuring of the required information to communicate with the +certificate authority. + +2.2.1.1 Key Pair Generation + +Before an end entity can start PKI transaction, it first generates +asymmetric key pairs, using the selected algorithm (the RSA algorithm is +required in SCEP, and is the only algorithm in current implementations). + +An end entity can create one or more asymmetric key pairs, for different +key usage. The key pairs can be created for encryption only, signing +only, or for all purposes. For the same key usage, there can be only +one key pair at any time. + +The key pairs are saved by the client in NVRAM or other non-volatile +media. The identification of a key pair is based on the FQDN assigned to +the client and the selected key usage. Every time a new key pair is +generated to replace the old key pair, the existing certificates have to +be revoked from the CA and a new enrollment has to be completed. + +2.2.1.2 Required Information + +An end entity is required to have the following information configured +before starting any PKI operations: + + 1. the certificate authority IP address or fully qualified domain name, + 2. the certificate authority HTTP CGI script path, and + the HTTP proxy information in case there is no direct Internet + connection to the server, + 3. the CRL query URL, if the CRL is to be obtained by from a directory + server by means of LDAP. + + +2.2.2 CA/RA Certificate Distribution + +Before any PKI operation can be started, the end entity needs to get +the CA/RA certificates. At this time, since no public key has been + + +Liu/Madson/McGrew/Nourse [Page 8] + +Cisco Systems' Simple Certificate Enrollment Protocol May 2002 + +exchanged between the end entity and the CA/RA, the message to get the +CA/RA certificate can not be secured using PKCS#7 protocol. Instead, the +CA/RA certificate distribution is implemented as a clear HTTP Get +operation. After the end entity gets the CA certificate, it has to +authenticate the CA certificate by comparing the finger print with the +CA/RA operator. Since the RA certificates are signed by the CA, there is +no need to authenticate the RA certificates. + +This operation is defined as a transaction consisting of one HTTP Get +message and one HTTP Response message: + + END ENTITY CA SERVER + Get CA/RA Cert: HTTP Get message + -----------------------------> + CA/RA Cert download: HTTP Response message + <--------------------------------------- + Compute finger print and + call CA operator. + Receive call and check finger print + +If an RA is in use, a degenerated PKCS#7 with a certificate chain +consisting of both RA and CA certificates is sent back to the end +entity. Otherwise the CA certificate is directly sent back as the +HTTP response payload. + + +2.2.3 Certificate Enrollment + +An end entity starts an enrollment transaction by creating a +certificate request using PKCS#10 and send it to the CA/RA enveloped +using the PKCS#7. After the CA/RA receives the request, it will either +automatically approve the request and send the certificate back, or it +will require the end entity to wait until the operator can manually +authenticate the identity of the requesting end entity. Two +attributes are included in the PKCS#10 certificate request - a +Challenge Password attribute and an optional ExtensionReq attribute +which will be a sequence of extensions the end entity would like to be +included in its V3 certificate extensions. The Challenge Password is +used for revocation and may be used (at the option of the CA/RA) +additionally as a one-time password for automatic enrollment. + +In the automatic mode, the transaction consists of one PKCSReq PKI +Message, and one CertRep PKI message. In the manual mode, the end entity +enters into polling mode by periodically sending GetCertInitial PKI +message to the server, until the server operator completes the manual +authentication, after which the CA will respond to GetCertInitial by +returning the issued certificate. + +The transaction in automatic mode: + + END ENTITY CA SERVER + + +Liu/Madson/McGrew/Nourse [Page 9] + +Cisco Systems' Simple Certificate Enrollment Protocol May 2002 +PKCSReq: PKI cert. enrollment msg + --------------------------------> CertRep: pkiStatus = SUCCESS + certificate +attached + <------------------------------ + Receive issued certificate. + +The transaction in manual mode: + + END ENTITY CA SERVER + PKCSReq: PKI cert. enrollment msg + --------------------------------> CertRep: pkiStatus = PENDING + <------------------------------ + GetCertInitial: polling msg + --------------------------------> CertRep: pkiStatus = PENDING + <------------------------------ + ................. CertRep: pkiStatus = SUCCESS + certificate +attached + <------------------------------ + Receive issued certificate. + + +2.2.4 End Entity Certificate Revocation + +An end entity should be able to revoke its own certificate. Currently +the revocation is implemented as a manual process. In order to revoke a +certificate, the end entity make a phone call to the CA server +operator. The operator will come back asking the ChallangePassword +(which has been send to the server as an attribute of the PKCS#10 +certificate request). If the ChallangePassword matches, the certificate +is revoked. The reason of the revocation is documented by CA/RA. + + +2.2.5 Certificate Access + +There are two methods to query certificates. The first method is to use +LDAP as a query protocol. Using LDAP to query assumes the client +understand the LDAP scheme supported by the CA. The SCEP client assumes +that the subject DN name in the certificate is used as URL to query the +certificate. The standard attributes (userCertificate and caCertificate) +are used as filter. + +For the environment where LDAP is not available, a certificate query +message is defined to retrieve the certificates from CA. + +To query a certificate from the certificate authority, an end entity +sends a request consisting of the certificate's issuer name and the +serial number. This assumes that the end entity has saved the issuer + + +Liu/Madson/McGrew/Nourse [Page 10] + +Cisco Systems' Simple Certificate Enrollment Protocol May 2002 + +name and the serial number of the issued certificate from the previous +enrollment transaction. The transaction to query a certificate consists +of one GetCert PKI message and one CertRep PKI message: + + END ENTITY CA SERVER + GetCert: PKI cert query msg + -------------------------------> CertRep: pkiStatus = SUCCESS + certificate +attached + <----------------------------- + Receive the certificate. + +2.2.6 CRL Distribution + +The CA/RA will not "push" the CRL to the end entities. The query of the +CRL can only be initialized by the end entity. + +There are three methods to query CRL. + +The CRL may be retrieved by a simple HTTP GET. If the CA supports this +method, it should encode the URL into a CRL Distribution Point extension +in the certificates it issues. Support for this method should be +incorporated in new and updated clients, but may not be in older +versions. + +The second method is to query CRL using LDAP. This assumes the CA server +supports CRL LDAP publishing and issues the CRL Distribution Point in +the certificate. The CRL Distribution Point is encoded as a DN. Please +refer to Appendix D for the examples of CRL Distribution Point. + +The third method is implemented for the CA which does not support LDAP +CRL publishing or does not implement the CRL Distribution Point. In this +case, a CRL query is composed by creating a message consists of the CA +issuer name and the CA's certificate serial number. This method is +deprecated because it does not scale well and requires the CA to be a +high-availability service. + +The message is send to the CA in the same way as the other SCEP +requests: The transaction to query CRL consists of one GetCRL PKI +message and one CertRep PKI message which have no certificates but CRL. + + END ENTITY CA SERVER + GetCRL: PKI CRL query msg + ----------------------------------> CertRep: CRL attached + <-------------------------------- + +2.3 PKI Operation Transactional Behavior + +As described before, a PKI operation is a transaction consisting of the +messages exchanged between an end entity and the CA/RA. This section +will specify the transaction behavior on both the end entity and the + + +Liu/Madson/McGrew/Nourse [Page 11] + +Cisco Systems' Simple Certificate Enrollment Protocol May 2002 + +certificate authority server. Because the protocol is basically a two +way communication protocol without a confirmation message from the +initiating side, state and state resynchronization rules have to be +defined, in case any error happens at either side. Before the state +transition can be defined, the notion of transaction identifier has to +be defined first. + +2.3.1 Transaction Identifier + +A transaction identifier is a string generated by the entity when +starting a transaction. Since all the PKI operations defined in this +protocol are initiated by the end entity, it is the responsibility of +the end entity to generate a unique string as the transaction +identifier. All the PKI messages exchanged for a given PKI operations +must carry the same transaction identifier. The transaction identifier +is generated as a MD5 hash on the public key value for which the +enrollment request is made. This allows the SCEP client to reuse the +same transaction identifier if it is reissuing a request for the same +certificate (i.e. a certificate with the same subject, issuer, and key). +The SCEP protocol requires that transaction identifiers be unique, so +that queries can be matched up with transactions. For this reason, in +those cases in which Mayarate signing and encryption certificates are +issued to the same end entity, the keys must be different. + +2.3.2 State Transitions in Certificate Enrollment + +The end entity state transitions during enrollment operation is +indicated in the diagram below: + +-<------+ + | | + GetCertInitial triggered by timeout or + | | manual authentication + | | + [CERT-NONEXISTANT] ------> [CERT-REQ-PENDING] ---> [CERT-ISSUED] + | PKCSReq | CertRep with SUCCESS + | | + | | + +--------<-------------------+ + request rejected, timeout, or error + +As described in the section 2.2.3, certificate enrollment starts at the +state CERT-NONEXISTANT. Sending PKCSReq changes the state to +CERT-REQ-PENDING. Receiving CertRep with SUCCESS status changes the +state to CERT-ISSUED. In the case the server sending back the response +with pending status, the end entity will keep polling certificate +response by sending GetCertInitial to the server, until either a CertRep +with SUCCESS status is received, or the maximum polling number has been +exceeded. + +If an error or timeout occurs in the CERT-REQ-PENDING state, the end +entity will transition to the CERT-NONEXISTANT state. + + +Liu/Madson/McGrew/Nourse [Page 12] + +Cisco Systems' Simple Certificate Enrollment Protocol May 2002 + + +The client administrator will, eventually, start up another enrollment +request. It is important to note that, as long as the end entity does +not change its subject name or keys, the same transaction id will be +used in the "new" transaction. This is important because based on this +transaction id, the certificate authority server can recognize this as +an existing transaction instead of a new one. + + +2.3.3 Transaction Behavior of Certificate/CRL Access + +There is no state maintained during certificate access and CRL access +transaction. When using the certificate query and CRL query messages +defined in this protocol, the transaction identifier is still required +so that the end entity can match the response message with the +upstanding request message. When using LDAP to query the certificate and +the CRL, the behavior is specified by the LDAP protocol. + +2.4 Security + +The security goals of SCEP are that no adversary can: + +o subvert the public key/identity binding from that intended, +o discover the identity information in the enrollment requests and + issued certificates, +o cause the revocation of certificates with any non-negligible + probability. + +Here an adversary is any entity other than the end entity and the CA +(and optionally the RA) participating in the protocol that is +computationally limited, but that can manipulate data during +transmission (that is, a man-in-the-middle). The precise meaning of +'computationally limited' depends on the implementer's choice of +cryptographic hash functions and ciphers. The required algorithms are +RSA, DES, and MD5. + +The first and second goals are met through the use of PKCS#7 and PKCS#10 +encryption and digital signatures using authenticated public keys. The +CA's public key is authenticated via the checking of the CA fingerprint, +as specified in Section 2.1.2, and the SCEP client's public key is +authenticated through the manual authentication or pre-shared secret +authentication, as specified in Section 2.1.1.2. The third goal is met +through the use of a Challenge Password for revocation, that is chosen +by the SCEP client and communicated to the CA protected by the PKCS#7 +encryption, as specified in Section 2.2.4. + +The motivation of the first security goal is straightforward. The +motivation for the second security goal is to protect the identity +information in the enrollment requests and certificates. For example, +two IPSEC hosts behind a firewall may need to exchange certificates, and +may need to enroll certificates with a CA that is outside of a firewall. +Most networks with firewalls seek to prevent IP addresses and DNS + + +Liu/Madson/McGrew/Nourse [Page 13] + +Cisco Systems' Simple Certificate Enrollment Protocol May 2002 + +information from the trusted network leaving that network. The second +goal enables the hosts in this example to enroll with a CA outside the +firewall without revealing this information. The motivation for the +third security goal is to protect the SCEP clients from denial of +service attacks. + + +Section 3 Transport Protocol + +In the SCEP protocol, HTTP is used as the transport protocol for the PKI +messages. + +3.1 HTTP "GET" Message Format + +In the PKI protocol, CA/RA certificates are send to the end entity in +clear, whereas the end entity certificates are send out using the PKCS#7 +secure protocol. This results in two types of GET operations. The type +of GET operation is specified by augmenting the GET message with +OPERATION and MESSAGE parameters in the Request-URL. OPERATION +identifies the type of GET operation, and MESSAGE is actually the PKI +message encoded as a text string. + +The following is the syntax definition of a HTTP GET message send from +an end entity to a certificate authority server: + +Request = "GET " CGI-PATH CGI-PROG "?operation=" OPERATION "&message=" +MESSAGE +where: + CGI-PATH defines the actual CGI path to invoke the CGI program which + parses the request. +| CGI-PROG is set to be the string "pkiclient.exe". This is intended +| to be the program that the CA will use to handle the SCEP transactions, +| though the CA may ignore CGI-PROG and use only the CGI-PATH. + OPERATION is set to be the string "PKIOperation" when the GET message + carries a PKI message to request certificates or CRL; OPERATION is set +| to be the string "GetCACert" or "GetCACertChain" when the GET operation +| is used to get CA/RA certificate or the CA Cert chain (respectively). + When OPERATION is "PKIOperation", MESSAGE is a base64-encoded PKI + message +| when OPERATION is "GetCACert" or "GetCACertChain", MESSAGE is a string +| which represents the certificate authority issuer identifier. + +For example. An end entity may submit a message via HTTP to the server +as follows: + +GET /cgi-bin/pkiclient.exe?operation=PKIOperation&message=MIAGCSqGSIb3D +QEHA6CAMIACAQAxgDCBzAIBADB2MGIxETAPBgNVBAcTCE ......AAAAAA== + +3.2 Response Message Format + +For each GET operation, the CA/RA server will return a MIME object via +HTTP. For a GET operation with PKIOperation as its type, the response is +tagged as having a Content Type of application/x-pki-message. The body +of this message is a BER encoded binary PKI message. The following is an +example of the response: + + + +Liu/Madson/McGrew/Nourse [Page 14] + +Cisco Systems' Simple Certificate Enrollment Protocol May 2002 + +"Content-Type:application/x-pki-message\n\n" + +In the case of GET operation with a type of GetCACert, the MIME content +type returned will depend on whether or not an RA is in use. If there +is no RA, only the CA certificate is send back in the response, and the +response has the content type tagged as application/x-x509-ca-cert. the +body of the response is a DER encoded binary X.509 certificate. For +example: + + "Content-Type:application/x-x509-ca-cert\n\n" + +If there is an RA, the RA certificates are send back together with the +CA certificates, a certificate-only PKCS#7 SignedData is send back in +the response where the SignerInfo is empty. Section 5 has the detailed +definition of the message format in this case. The content type is +application/x-x509-ca-ra-cert. + +Section 4 Secure Transportation: PKCS#7 + +PKCS#7 is a general enveloping mechanism that enables both signed and +encrypted transmission of arbitrary data. It is widely implemented and +included in the RSA tool kit. + +In this section, the general PKCS#7 enveloped PKI message format is +specified. The complete PKCS#7 message format for each PKI transaction +will be covered in Section 5. + +4.1 SCEP Message Format + +As a transaction message, a SCEP message has a set of transaction +specific attributes and an information portion. Employing PKCS#7 +protocol, the transaction specific attributes are encoded as a set of +authenticated attributes of the SignedData. The information portion will +first be encrypted to become Enveloped Data, and then the digest of the +enveloped information portion is included as one of the message digest +attributes and being signed together with the other transaction specific +attributes. + +By applying both enveloping and signing transformations, a SCEP message +is protected both for the integrity of its end-end-transition +information and the confidentiality of its information portion. The +advantage of this technique over the conventional transaction message +format is that, the signed transaction type information and the status +of the transaction can be determined prior to invoke security handling +procedures specific to the information portion being processed. + +The following is an example of a SCEP message with its enveloped and +signed data portion represented by pkcsPKISigned and +pkcsPKIEnveloped. The out-most of any PKI message is a blob of +ContentInfo, with its content type set to SignedData and the actual +signed data as the content. + + +Liu/Madson/McGrew/Nourse [Page 15] + +Cisco Systems' Simple Certificate Enrollment Protocol May 2002 + + pkiMessage ContentInfo ::= { + contentType {pkcs-7 signedData(2)} + content pkcsPKISigned + } + pkcsPKISigned SignedData ::= { + version 1 + digestAlgorithm { iso(1) member-body(2) US(840) rsadsi(113549) + digestAlgorithm(2) 5} + contentInfo { + contentType {pkcs-7 1} -- data content identifier + content pkcsPKIEnvelope -- enveloped information portion + } + certificates -- signer certificate chain + signerInfo -- including signed transaction info and the digest + -- of the enveloped information portion as the + -- authenticated attributes + } + pkcsPKIEnveloped EnvelopedData ::= { + version 0 + recipientInfos -- information required to open the envelop + encryptedContentInfo { + contentType {pkcs-7 1} -- data content identifier + contentEncryptionAlgorithm + encryptedContent -- encrypted information portion + } + } + +4.2 Signed Transaction Attributes + +The following transaction attributes are encoded as authenticated +attributes. Please refer to Appendix B for the OID definitions. + +transactionID PrintableString -- Decimal value as a string + messageType PrintableString -- Decimal value as a string + pkiStatus PrintableString -- Decimal value as a string + failinfo PrintableString -- Decimal value as a string + senderNonce Octet String + recipientNonce Octet String + +where: + + The transactionID is an attribute which uniquely identify a + transaction. This attribute is required in all PKI messages. + + The messageType attribute specify the type of operation performed by the + transaction. This attribute is required in all PKI + messages. Currently, the following message types are defined: + + PKCSReq (19) -- Permits use of PKCS#10 certificate request + CertRep (3) -- Response to certificate or CRL request + GetCertInitial (20) -- Certificate polling in manual enrollment + GetCert (21) -- Retrieve a certificate + + +Liu/Madson/McGrew/Nourse [Page 16] + +Cisco Systems' Simple Certificate Enrollment Protocol May 2002 + + GetCRL (22) -- Retrieve a CRL + + All response message will include transaction status information which + is defined as pkiStatus attribute: + + SUCCESS (0) -- request granted + FAILURE (2) -- request rejected + PENDING (3) -- request pending for manual approval. + + If the status in the response is FAILURE, the failinfo attribute will + contain one of the following failure reasons: + + badAlg (0) -- Unrecognized or unsupported algorithm ident + badMessageCheck (1) -- integrity check failed + badRequest (2) -- transaction not permitted or supported + badTime (3) -- Message time field was not sufficiently close + to the system time + badCertId (4) -- No certificate could be identified matching + the provided criteria + + The attributes of senderNonce and recipientNonce are the 16 byte + random numbers generated for each transaction to prevent the replay + attack. + +When an end entity sends a PKI message to the server, a senderNonce is +included in the message. After the server processes the request, it will +send back the end entity senderNonce as the recipientNonce and generates +another nonce as the senderNonce in the response message. Because the +proposed pki protocol is a two-way communication protocol, it is clear +that the nonce can only be used by the end entity to prevent the +replay. The server has to employ extra state related information to +prevent a replay attack. + +Section 5. SCEP Transaction Specification + +In this section each SCEP transaction is specified in terms of the +complete messages exchanged during the transaction. + +5.1 Certificate Enrollment + +The certificate enrollment transaction consists of one PKCSReq message +send to the certificate authority from an end entity, and one CertRep +message send back from the server. The pkiStatus returned in the +response message is either SUCCESS, or FAILURE, or PENDING. The +information portion of a PKCSReq message is a PKCS#10 certificate +request, which contains the subject Distinguished Name, the subject +public key, and two attributes, a ChallangePassword attribute to be used +for revocation, and an optional ExtensionReq attribute which will be a +sequence of extensions the end entity expects to be included in its V3 +certificate extensions. One of the extension attribute specifies the key +usage. The pkiStatus is set to SUCCESS when the certificate is send +back in CertRep; the pkiStatus is set to FAILURE when the certificate + + +Liu/Madson/McGrew/Nourse [Page 17] + +Cisco Systems' Simple Certificate Enrollment Protocol May 2002 + +request is rejected; the pkiStatus is set to PENDING when the server has +decided to manually authenticate the end entity. The messages exchanged +in the manual authentication mode is further specified in Section 5.2. + +Precondition: + Both the end entity and the certificate authority have completed their + initialization process. The end entity has already been configured + with the CA/RA certificate. + +Postcondition: + Either the certificate is received by the end entity, or the end + entity is notified to do the manual authentication, or the request + is rejected. + +5.1.1 PKCSReq Message Format + +A PKCSReq message is created by following the steps defined below: + +1. Create a PKCS#10 certificate request which is signed by the end + entity's private key, corresponding to the public key included in + the PKCS#10 certificate request. This constitutes the information + portion of PKCSReq. + +2. Encrypt the PKCS#10 certificate request using a randomly generated + content-encryption key. This content-encryption key is then + encrypted by the CA's* public key and included in the recipientInfo. + This step completes the "envelope" for the PKCS#10 certificate + request. + +3. Generate a unique string as the transaction id. + +4. Generate a 16 byte random number as senderNonce. + +5. Generate message digest on the enveloped PKCS#10 certificate request + using the selected digest algorithm. + +6. Create SignedData by adding the end entity's self-signed certificate + as the signer's public key certificate. Include the message type, + transaction id, the senderNonce and the message digest as the + authenticated attributes and sign the attributes using the end + entity's private key. This completes the SignedData. + +7. The SignedData is prepended with the ContenInfo blob which indicates + a SignedData object. This final step completes the create of a + complete PKCSReq PKI message. + +In the following, the PKCSReq message is defined following the ASN.1 +notation. + +For readability, the values of a field is either represented by a quoted +string which specifies the intended value, or a constant when the value +is known. + + +Liu/Madson/McGrew/Nourse [Page 18] + +Cisco Systems' Simple Certificate Enrollment Protocol May 2002 + + -- PKCSReq information portion + pkcsCertReq CertificationRequest ::= { -- PKCS#10 + version 0 + subject "the end entity's subject name" + subjectPublicKeyInfo { + algorithm {pkcs-1 1} -- rsa encryption + subjectPublicKey "DER encoding of the end entity's public key" + } + attributes { + challengePassword {{pkcs-9 7} "password string" } + extensions + } + signatureAlgorithm {pkcs-1 4} -- MD5WithRSAEncryption + signature "bit string which is created by signing inner content + of the defined pkcsCertReq using end entity's private + key, corresponding to the public key included in + subjectPublicKeyInfo." + } + -- Enveloped information portion + pkcsCertReqEnvelope EnvelopeData ::= { -- PKCS#7 + version 0 + recipientInfo { + version 0 + issuerAndSerialNumber { + issuer "the CA issuer name" + serialNumber "the CA certificate serial number" + } + keyEncryptionAlgorithm {pkcs-1 1} -- rsa encryption + encryptedKey "content-encryption key + encrypted by CA public key" + } + encryptedContentInfo { + contentType {pkcs-7 1} -- data content + contentEncryptionAlgorithm "object identifier + for DES encryption" + encryptedContent "encrypted pkcsCertReq using the content- + encryption key" + } + } + -- Signed PKCSReq + pkcsCertReqSigned SignedData ::= { -- PKCS#7 + version 1 + digestAlgorithm {iso(1) member-body(2) US(840) rsadsi(113549) + digestAlgorithm(2) 5} + contentInfo { + contentType {pkcs-7 1} -- data content identifier + content pkcsCertReqEnvelope + } + certificate { -- the end entity's self-signed certificate + version 3 + serialNumber "the transaction id associated with enrollment" + signature {pkcs-1 4} -- md5WithRSAEncryption + + +Liu/Madson/McGrew/Nourse [Page 19] + +Cisco Systems' Simple Certificate Enrollment Protocol May 2002 + + issuer " the end entity's subject name" + validity { + notBefore "a UTC time" + notAfter "a UTC time" + } + subject "the end entity's subject name" + subjectPublicKeyInfo { + algorithm {pkcs-1 1} + subjectPublicKey "DER encoding of end entity's public key" + } + signatureAlgorithm {pkcs-1 4} + signature "the signature generated by using the end entity's + private key corresponding to the public key in + this certificate." + } + signerInfo { + version 1 + issuerAndSerialNumber { + issuer "the end entity's subject name" + serialNumber "the transaction id associated + with the enrollment" + } + digestAlgorithm {iso(0) member-body(2) US(840) rsadsi(113549) + digestAlgorithm(2) 5} + authenticateAttributes { + contentType {{pkcs-9 3} {pkcs-7 1}} + messageDigest {{pkcs-9 4} "an octet string"} + transaction-id {{id-attributes transId(7)} "printable + string"} + -- this transaction id will be used + -- together with the subject name as + -- the identifier of the end entity's key + -- pair during enrollment + messageType {{id-attributes messageType(2)} "PKCSReq"} + senderNonce {{id-attributes senderNonce(5)} + "a random number encoded as a string"} + } + digestEncryptionAlgorithm {pkcs-1 1} -- rsa encryption + encryptedDigest "encrypted digest of the authenticated + attributes using end entity's private key" + } + } + pkcsReq PKIMessage ::= { + contentType {pkcs-7 2} + content pkcsCertRepSigned + } + + + + + + + + +Liu/Madson/McGrew/Nourse [Page 20] + +Cisco Systems' Simple Certificate Enrollment Protocol May 2002 + +5.1.2 CertRep Message Format + +The response to an SCEP enrollment request is a CertRep message. + +5.1.2.1 PENDING Response + +When the CA is configured to manually authenticate the end entity, +the CertRep is returned with the attribute pkiStatus set to PENDING. +The data portion for this message is null. Only the transaction +required attributes are sent back. + +CertRepSigned SignedData ::= { -- PKCS#7 + version 1 + digestAlgorithm {iso(1) member-body(2) US(840) rsadsi(113549) + digestAlgorithm(2) 5} + contentInfo {contentType {pkcs-7 1} -- empty content + } + signerInfo { + version 1 + issuerAndSerialNumber { +| issuer "name of CA that issued the CA [RA] cert" +| serialNumber "the serial number of the CA [RA] cert" + } + digestAlgorithm (iso(1) member-body(2) US(840) rsadsi(113549) + digestAlgorithm(2) 5} + authenticateAttributes { + contentType {{pkcs-9 3} {pkcs-7 1}} + messageDigest {{pkcs-9 4} NULL} + messageType {{id-attribute messageType(0)} "CertRep"} + transaction-id {{id-attributes transid(7)} "printablestring"} + --- same transaction id used in PKCSReq + pkiStatus {{id-attributes pkiStatus(3)} "PENDING"} + recipientNonce {{id-attributes recipientNonce(6)}<16 bytes>} + senderNonce {{id-attributes senderNonce(5)} <16 bytes>} + } + digestEncrytionAlgorithm {pkcs-1 1} + encryptedDigest "encrypted message digest of the authenticated +| attributes using the CA's [RA's] private key" + } +} +CertRep PKIMessage ::= { + contentType {pkcs-7 2} + content CertRepSigned +} + +5.1.2.2 Failure Response + +In this case, the CertRep sent back to the end entity is same as in +the PENDING case, except that the pkiStatus attribute is set to FAILURE, +and the failInfo attribute should be included: + + pkistatus {{id-attributes pkiStatus(3)} "FAILURE"} + failInfo {{id-attributes failInfo(4)} "the reason to reject"} + +Liu/Madson/McGrew/Nourse [Page 21] + +Cisco Systems' Simple Certificate Enrollment Protocol May 2002 + +5.1.2.3 SUCCESS response + +In this case, the information portion of CertRep will be a degenerated +PKCS#7 which contains the end entity's certificate. It is then enveloped +and signed as below: + +pkcsCertRep SignedData ::= { -- PKCS#7 + version 1 + digestAlgorithm {iso(1) member-body(2) US(840) rsadsi(113549) + digestAlgorithm(2) 5} + contentInfo { -- empty content since this is degenerated PKCS#7 + contentType {pkcs-7 1} + } + certificates { + certificate { -- issued end entity's certificate + version 3 + serialNumber "issued end entity's certificate serial number" + signature {pkcs-1 4} -- md5WithRSAEncryption + issuer "the certificate authority issuer name" + validity { + notBefore "UTC time" + notAfter "UTC time" + } + subject "the end entity subject name as given in PKCS#10" + subjectPublicKeyInfo { + algorithm {pkcs-1 1} + subjectPublicKey "a DER encoding of end entity public + key as given in PKCS#10" + } + extensions " the extensions as given in PKCS#10" + signatureAlgorithm {pkcs-1 4} + signature " the certificate authority signature" + } + certificate "the certificate authority certificate" +| certificate "the registration authority certificate (if +applicable)" + } +} +pkcsCertRepEnvelope EnvelopedData ::= { -- PKCS#7 + version 0 + recipientInfo { + version 0 + issuerAndSerialNumber { -- use issuer name and serial number as + -- conveyed in end entity's self-signed + -- certificate, included in the PKCSReq + issuer "the end entity's subject name" + serialNumber "the serial number defined by the end entity in + its self-signed certificate" + } + keyEncryptionAlgorithm {pkcs-1 1} + encryptedKey "content-encrypt key encrypted by the end entity's + public key which is same key as authenticated in + the end entity's certificate" + } + +Liu/Madson/McGrew/Nourse [Page 22] + +Cisco Systems' Simple Certificate Enrollment Protocol May 2002 + + encryptedContentInfo { + contentType {pkcs-7 1} -- data content identifier + contentEncryptionAlgorithm "OID for DES encryption" + encryptedContent "encrypted pkcsCertRep using content encryption + key" + } +} +pkcsCertRepSigned SignedData ::= { -- PKCS#7 + version 1 + digestAlgorithm {iso(1) member-body(2) US(840) rsadsi(113549) + digestAlgorithm(2) 5} + contentInfo { + contentType {pkcs-7 1} + content pkcsCertRepEnvelope + } + signerInfo { + version 1 + issuerAndSerialNumber { + issuer "the certificate authority issuer name" + serialNumber "the CA certificate's serial number" + } + digestAlgorithm {iso(1), member-body(2) US(840) rsadsi(113549) + digestAlgorithm(2) 5} + authenticateAttributes { + contentType {{pkcs-9 3} {pkcs-7 1}} + messageDigest {{pkcs-9 4} "a octet string"} + messageType {{id-attribute messageType(2)} "CertRep"} + transaction-id {{id-attributes transId(7)} "printable + string"} + -- same transaction id as given in PKCSReq + pkiStatus {{id-attributes pkiStatus(3) "SUCCESS"} + recipientNonce {{id-attribute recipientNonce(6)}<16 bytes>} + senderNonce {{ id-attributes senderNonce(5) <16 bytes>} + } + digestEncryptionAlgorithm {pkcs-1 1} + encryptedDigest "encrypted digest of authenticate attributes + using CA's private key " + } +} +CertRep PKIMessage ::= { + contentType {pkcs-7 2} + content pkcsCertRepSigned +} + +5.2 Poll for End Entity Initial Certificate + +Either triggered by the PENDING status received from the CertRep, or by +the non-response timeout for the previous PKCSReq, an end entity will +enter the polling state by periodically sending GetCertInitial to the +server, until either the request is granted and the certificate is sent +back, or the request is rejected, or the the configured time limit for +polling is exceeded. + + +Liu/Madson/McGrew/Nourse [Page 23] + +Cisco Systems' Simple Certificate Enrollment Protocol May 2002 + + +Since GetCertInitial is part of the enrollment, the messages exchanged +during the polling period should carries the same transaction identifier +as the previous PKCSReq. + +PreCondition + Either the end entity has received a CertRep with pkiStatus set to be + PENDING, or the previous PKCSReq has timed out. + +PostContition + The end entity has either received the certificate, or be rejected of + its request, or the polling period ended as a failure. + +5.2.1 GetCertInitial Message Format + +|Since at this time the certificate has not been issued, the end entity +|can only use the end entity's subject name, combined with the +|transaction identifier, to identify the polled certificate request. + +|The certificate authority server must be able to uniquely identify the +|polled certificate request. A subject name can have more than one +|outstanding certificate request (with different key usage attributes). + +-- Information portion + +pkcsGetCertInitial issuerAndSubject ::= { + issuer "the certificate authority issuer name" + subject "the end entity subject name as given in PKCS#10" +} +pkcsGetCertInitialEnvelope EnvelopedData ::= { + version 0 + recipientInfo { + version 0 + issuerAndSerialNumber { + issuer "the CA issuer name" + serialNumber "the CA certificate serial number" + } + keyEncryptionAlgorithm {pkcs-1 1} + encryptedKey "content-encrypt key encrypted by CA's public key" + } + encryptedContentInfo { + contentType {pkcs-7 1} -- data content + contentEncryptionAlgorithm "OID for DES encryption" + encryptedContent "encrypted getCertInital" + } +} +pkcsGetCertInitialSigned SignedData ::= { -- PKCS#7 + version 1 + digestAlgorithm {iso(1) member-body(2) US(840) rsadsi(113549) + digestAlgorithm(2) 5} + contentInfo { + contentType {pkcs-7 1} + + +Liu/Madson/McGrew/Nourse [Page 24] + +Cisco Systems' Simple Certificate Enrollment Protocol May 2002 + + content pkcsGetCertIntialEnvelope + } + certificate { -- the end entity's self-signed certificate + version 3 + serialNumber "the transaction id associated with enrollment" + signature {pkcs-1 4} -- md5WithRSAEncryption + issuer " the end entity's subject name" + validity { + notBefore "a UTC time" + notAfter "a UTC time" + } + subject "the end entity's subject name" + subjectPublicKeyInfo { + algorithm {pkcs-1 1} + subjectPublicKey "DER encoding of end entity's public key" + } + signatureAlgorithm {pkcs-1 4} + signature "the signature generated by using the end entity's + private key corresponding to the public key in + this certificate." + } + signerInfo { + version 1 + issuerAndSerialNumber { + issuer "end entity's subject name" + serialNumber "the transaction id used in previous PKCSReq" + } + digestAlgorithm {iso(1), member-body(2) US(840) rsadsi(113549) + digestAlgorithm(2) 5} + authenticateAttributes { + contentType {{pkcs-9 3} {pkcs-7 1}} + messageDigest {{pkcs-9 4} "an octet string"} + -- digest of getCertInitial + messageType {{id-attribute messageType(2)} "GetCertInitial"} + transaction-id {{id-attributes transId(7)} "printable + string"} + -- same transaction idused in previous PKCSReq + senderNonce {{id-attribute senderNonce(3)} 0x<16 bytes>} + } + digestEncryptionAlgorithm {pkcs-1 1} + encryptedDigest "encrypted digest of authenticateAttributes" + } +} +GetCertInitial PKIMessage ::= { + contentType {pkcs-7 2} + content pkcsGetCertInitialSigned +} + + + +5.2.2 GetCertInitial Response Message Format + +The response messages for GetCertInitial are the same as for PKCSReq. + +Liu/Madson/McGrew/Nourse [Page 25] + +Cisco Systems' Simple Certificate Enrollment Protocol May 2002 + +5.3 Certificate Access + +The certificate query message defined in this section is an option when +the LDAP server is not available to provide the certificate query. An +end entity should be able to query an issued certificate from the +certificate authority, as long as the issuer name and the issuer +assigned certificate serial number is known to the requesting end +entity. This transaction is not intended to provide the service as a +certificate directory service. A more complicated query mechanism would +have to be defined in order to allow an end entity to query a certificate +using various different fields. + +This transaction consists of one GetCert message send to the server by +an end entity, and one CertRep message send back from the server. + +PreCondition + The queried certificate have been issued by the certificate authority + and the issuer assigned serial number is known. + +PostContition + Either the certificate is send back or the request is rejected. + + +5.3.1 GetCert Message Format + +The queried certificate is identified by its issuer name and the issuer +assigned serial number. If this is a query for an arbitrary end entity's +certificate, the requesting end entity should includes its own CA issued +certificate in the signed envelope. If this is a query for its own +certificate (assume the end entity lost the issued certificate, or does +not have enough non-volatile memory to save the certificate), then the +self-signed certificate has to be included in the signed envelope. + + pkcsGetCert issuerAndSerialNumber ::= { + issuer "the certificate issuer name" + serialNumber "the certificate serial number" + } + pkcsGetCertEnvelope EnvelopedData ::= { + version 0 + recipientInfo { + version 0 + issuerAndSerialNumber { + issuer "the CA [RA] issuer name" + serialNumber "the CA [RA] certificate serial number" + } + keyEncryptionAlgorithm {pkcs-1 1} + encryptedKey "content-encrypt key encrypted + by CA [RA] public key" + } + + + + + +Liu/Madson/McGrew/Nourse [Page 26] + +Cisco Systems' Simple Certificate Enrollment Protocol May 2002 + + + encryptedContentInfo { + contentType {pkcs-7 1} -- data content + contentEncryptionAlgorithm "OID for DES encryption" + encryptedContent "encrypted pkcsGetCert using the content + encryption key" + } + } + pkcsGetCertSigned SignedData ::= { + version 1 + digestAlgorithm {iso(1) member-body(2) US(840) rsadsi(113549) + digestAlgorithm(2) 5} + contentInfo { + contentType {pkcs-7 1} + content pkcsGetCertEnvelope + } + certificates { + certificate "CA issued certificate" + or "self-signed certificate" + } + signerInfo { + version 1 + issuerAndSerialNumber { + issuer "the end entity's subject name" + serialNumber "end entity's certificate serial number" + } + digestAlgorithm {iso(1), member-body(2) US(840) rsadsi(113549) + digestAlgorithm(2) 5} + authenticateAttributes { + contentType {{pkcs-9 3} {pkcs-7 1}} + messageDigest {{pkcs-9 4} "an octet string"} + -- digest of pkcsGetCertEnvelope + messageType {{id-attribute messageType(2)} "GetCert"} + transaction-id {{id-attributes transId(7)} "printable + string"} + senderNonce {{id-attribute senderNonce(3)} <16 bytes>} + } + digestEncryptionAlgorithm {pkcs-1 1} + encryptedDigest "encrypted digest of authenticateAttributes" + } + } + GetCert PKIMessage ::= { + contentType {pkcs-7 2} + content pkcsGetCertSigned + } + + + + + + + + + +Liu/Madson/McGrew/Nourse [Page 27] + +Cisco Systems' Simple Certificate Enrollment Protocol May 2002 + + +5.3.2 CertRep Message Format + +In this case, the CertRep from the server is same as the CertRep for the +PKCSReq, except that the server will only either grant the request or +reject the request. Also, the recipientInfo should use the CA issuer +name and CA assigned serial number to identify the end entity's key pair +since at this time, the end entity has received its own certificate. + +5.4 CRL Access + +The CRL query message defined in this section is an option when the LDAP +server is not available to provide the CRL query. In the PKI protocol +proposed here, only the end entity can initiate the transaction to +download CRL. An end entity send GetCRL request to the server and the +server send back CertRep whose information portion is a degenerated +PKCS#7 which contains only the most recent CRL. The size of CRL included +in the CertRep should be determined by the implementation. + +PreCondition + The certificate authority certificate has been downloaded to the end + entity. + +PostCondition + CRL send back to the end entity. + +5.4.1 GetCRL Message format + +The CRL is identified by using both CA's issuer name and the CA +certificate's serial number: + + pkcsGetCRL issuerAndSerialNumber { + issuer "the certificate authority issuer name" + serialNumber "certificate authority certificate's serial number" + } + +When the CRLDistributionPoint is supported, the pkcsGetCRL is defined as +the following: + + pkcsGetCRL SEQUENCE { + crlIssuer issuerAndSerialNumber + distributionPoint CE-CRLDistPoints + } + +where CE-CRLDisPoints is defined in X.509, but must contain only one +CRL distribution point. + + + + + + + + + + +Liu/Madson/McGrew/Nourse [Page 28] + +Cisco Systems' Simple Certificate Enrollment Protocol May 2002 + + pkcsGetCRLEnvelope EnvelopedData ::= { + version 0 + recipientInfo { + version 0 + issuerAndSerialNumber { + issuer "the certificate authority (or RA) issuer name" + serialNumber "the CA (RA) certificate's serial number" + } + keyEncryptionAlgorithm {pkcs-1 1} + encryptedKey "content-encrypt key encrypted by CA (RA) public key" + } + encryptedContentInfo { + contentType {pkcs-7 1} -- data content + contentEncryptionAlgorithm "OID for DES encryption" + encryptedContent "encrypted pkcsGetCRL" + } + } + pkcsGetCRLSigned SignedData ::= { + version 1 + digestAlgorithm {iso(1) member-body(2) US(840) rsadsi(113549) + digestAlgorithm(2) 5} + contentInfo { + contentType {pkcs-7 1} + content pkcsGetCRLEnvelope + } + certificates { + certificate "CA-issued or self-signed end entity's certificate" + } + signerInfo { + version 1 + issuerAndSerialNumber { + issuer "the end entity's issuer name" + serialNumber "the end entity's certificate serial number" + } + digestAlgorithm {iso(1), member-body(2) US(840) rsadsi(113549) + digestAlgorithm(2) 5} + authenticateAttributes { + contentType {{pkcs-9 3} {pkcs-7 1}} + messageDigest {{pkcs-9 4} 0x<16/20 bytes>} + -- digest of pkcsGetCRLEnvelope + messageType {{id-attribute messageType(2)} "CertCRL"} + transaction-id {{id-attributes transId(7)} "printable + string"} + senderNonce {{id-attribute senderNonce(3)} <16 bytes>} + } + digestEncryptionAlgorithm {pkcs-1 1} + encryptedDigest "encrypted digest of authenticateAttributes" + } + } + GetCRL PKIMessage ::= { + contentType {pkcs-7 2} + content pkcsGetCRLSigned + } + +Liu/Madson/McGrew/Nourse [Page 29] + +Cisco Systems' Simple Certificate Enrollment Protocol May 2002 + + +5.4.2 CertRep Message Format + +The CRL is send back to the end entity through CertRep message. The +information portion of this message is a degenerated PKCS#7 SignedData +which contains only a CRL. + + pkcsCertRep SignedData ::= { + version 1 + digestAlgorithm {iso(1) member-body(2) US(840) rsadsi(113549) + digestAlgorithm(2) 5} + contentInfo { + contentType {pkcs-7 1} + } + crl { + signature {pkcs-1 4} + issuer "the certificate authority issuer name" + lastUpdate "UTC time" + nextUpdate "UTC time" + revokedCertificate { + -- the first entry + userCertificate "certificate serial number" + revocationData "UTC time" + .... + -- last entry + userCertificate "certificate serial number" + revocationData "UTC time" + } + } + pkcsCertRepEnvelope EnvelopedData ::= { + version 0 + recipientInfo { + version 0 + issuerAndSerialNumber { + issuer "the end entity's issuer name" + serialNumber "the end entity certificate serial number" + } + keyEncryptionAlgorithm {pkcs-1 1} + encryptedKey "content-encrypt key encrypted by end entity's + public key " + } + encryptedContentInfo { + contentType {pkcs-7 1} -- data content + contentEncryptionAlgorithm "OID for DES encryption" + encryptedContent "encrypted pkcsCertRep using end entity's + public key" + } + } + + + + + + +Liu/Madson/McGrew/Nourse [Page 30] + +Cisco Systems' Simple Certificate Enrollment Protocol May 2002 + + + pkcsCertRepSigned SignedData ::= { -- PKCS#7 + version 1 + digestAlgorithm {iso(1) member-body(2) US(840) rsadsi(113549) + digestAlgorithm(2) 5} + contentInfo { + contentType {pkcs-7 1} + content pkcsCertRepEnvelope + } + signerInfo { + version 1 + issuerAndSerialNumber { + issuer "the certificate authority issuer name" + serialNumber "the CA certificate's serial number" + } + digestAlgorithm {iso(1), member-body(2) US(840) rsadsi(113549) + digestAlgorithm(2) 5} + authenticateAttributes { + contentType {{pkcs-9 3} {pkcs-7 1}} + messageDigest {{pkcs-9 4} "an octet string"} + -- digest of pkcsCertRepEnvelope + messageType {{id-attribute messageType(2)} "CertRep"} + transaction-id {{id-attributes transId(7)} "printable + string"} + -- same transaction id as given in PKCSReq + pkiStatus {{id-attributes pkiStatus(3) "SUCCESS"} + recipientNonce{{id-attribute recipientNonce(6)}<16 bytes>} + senderNonce {{id-attribute senderNonce (5) 0x<16 bytes>} + } + digestEncryptionAlgorithm {pkcs-1 1} + encryptedDigest "encrypted digest of authenticatedAttributes + using CA private key" + } + } + + +NOTE:The PKCS#7 EncryptedContent is specified as an octet string, but +SCEP entities must also accept a sequence of octet strings as a valid +alternate encoding. + +This alternate encoding must be accepted wherever PKCS #7 Enveloped +Data is specified in this document. + + + + + + + + + + + +Liu/Madson/McGrew/Nourse [Page 31] + +Cisco Systems' Simple Certificate Enrollment Protocol May 2002 + +5.5 Get Certificate Authority Certificate + +Before any transaction begins, end entities have to get the CA (and +possibly RA) certificate(s) first. Since no public keys have been +exchanged, the message can not be encrypted and the response must be +authenticated by out-of-band means. These certs are obtained by means +of an HTTP GET message. To get the CA certificate, the end entity does a +"HTTP GET" and receives a plain X.509 certificate in response. In the +request, the URL identifies a CGI script on the server and passes the CA +issuer identifier as the parameter to the CGI script. Once the CA +certificate is received by the end entity, a fingerprint is generated +using MD5 hash algorithm on the whole CA certificate. This fingerprint +is verified by some positive out-of-band means, such as a phone call. + + +5.5.1 GetCACert HTTP Message Format + "GET" CGI-PATH CGI-PROG "?operation=GetCACert" "&message=" CA-IDENT + where: + CGI-PATH defines the actual CGI path to invoke the CGI program + which parses the request. + CGI-PROG is set to be the string "pkiclient.exe" and this is + expected to be the program that the CA will use to handle the + SCEP transactions. + CA-IDENT is any string which is understood by the CA. + For example, it could be a domain name like ietf.org. + If a certificate authority has multiple root certificates + this field can be used to distinguish which is required. + Otherwise it may be ignored. + +5.5.2 Response + +The response for GetCACert is different between the case where the CA +directly communicated with the end entity during the enrollment, and the +case where a RA exists and the end entity communicates with the RA +during the enrollment. + +5.5.2.1 CA Certificate Only Response + +A binary X.509 CA certificate is send back as a MIME object with a +Content-Type of application/x-x509-ca-cert. + +5.5.2.2 CA and RA Certificates Response + +When an RA exists, both CA and RA certificates must be sent back in +the response to the GetCACert request. The RA certificate(s) must be +signed by the CA. A certificates-only PKCS#7 SignedData is used to +carry the certificates to the end entity, with a Content-Type of +application/x-x509-ca-ra-cert. + + + + + + + + +Liu/Madson/McGrew/Nourse [Page 32] + +|5.6 Get Certificate Authority Certificate Chain +| +|In order to support Certificate Authority hierarchies, it is necessary +|to have a way to get the entire certificate chain. The following message +|has been added to SCEP for this purpose. +| +|5.6.1 GetCACertChain HTTP Message Format +| +| "GET" CGI-SCRIPT "?" "operation=GetCACertChain" "&" "message" CA-IDENT +| where CGI-SCRIPT and CA-IDENT are as described for GetCACert. +| +|5.6.2 Response +| +|The response for GetCACertChain is a certificates-only PKCS#7 SignedData +|to carry the certificates to the end entity, with a Content-Type of +|application/x-x509-ca-ra-cert-chain. +| +|5.6.3 Backwards Compatability +| +|Versions of SCEP prior to revision 3 do not support GetCACertChain. +|Certificate Authorities written to these prior versions will not be +|able to process the message and may return an HTML error. +| +|To avoid this, clients should send the GetCACert message first. If the +|returned certificate is self-signed or is signed by a Certificate +|Authority that is trusted by the client, then it is not necessary to +|send the GetCACertChain message and it should not be sent. +| +|If a Certificate Authority is configured with a certificate that is +|not either self-signed or has a self-signed issuer, then it should +|support this message. In other words, it should be supported if the +|CA hierarchy is more than two-deep. +| +|An old CA in a two-deep hierarchy might still get this message from +|a client if the client did not trust either that CA or its issuer. +|In that event, the certificate cannot be trusted anyway. In any case +|the CA must not crash or hang upon the receipt of the message and the +|client must be able to handle whatever error is returned by the CA, +|including an HTML error or an ungraceful disconnect. + + + + + + + + + + + + + + + + + +Liu/Madson/McGrew/Nourse [Page 33] + +Cisco Systems' Simple Certificate Enrollment Protocol May 2002 + +The following is the ASN.1 definition of Cert-Only PKCS#7: + + certOnly SignedData ::= { + version 1 + digestAlgorithm {iso(1) member-body(2) US(840) rsadsi(113549) + digestAlgorithm(2) 5} + +contentInfo { + contentType {pkcs-7 1} -- data content identifier + content -- NULL + } + certificates -- the RA and CA certificates. + } + + CARACerts PKIMessage ::= { -- special pki message sent in the clear + contentType {pkcs-7 2} + content certOnly + } + + +6.0 Security Considerations + +This entire document is about security. Common security considerations +such as keeping private keys truly private and using adequate lengths +for symmetric and asymmetric keys must be followed in order to maintain +the security of this protocol. + + +7.0 Intellectual Property + +This protcol includes the optional use of Certificate Revocation List +Distribution Point (CRLDP) technology, which is a patented technology +of Entrust Technologies, Inc. (Method for Efficient Management of +Certificate Revocation Lists and Update Information (U.S. Patent +5,699,431)). Please contact Entrust Technologies, Inc. +(www.entrust.com) for more information on licensing CRLDP technology. + + +8.0 References + +[PKCS7] Kaliski, B., "PKCS #7: Cryptographic Message Syntax Version +1.5", RFC 2315, March 1998. + +[PKCS10] Kaliski, B., "PKCS #10: Certification Request Syntax Version +1.5", RFC 2314, March 1998. + +[RFC2459] Housley, R., ec. al., "Internet X.509 Public Key +Infrastructure Certificate and CRL Profile", RFC 2459, January 1999. + + + + + + +Liu/Madson/McGrew/Nourse [Page 34] + +Cisco Systems' Simple Certificate Enrollment Protocol May 2002 + +Appendix A: Cisco End Entity Subject Name Definition + +The ip address and the FQDN of a SCEP client should be included in the +V3 extension subjectAltName. When the subjectAltName extension attribute +is present, both the subjectAltName fields and the subjectName field could +have the IP address and the FQDN information. + +When the X.500 directory is used by the CA to define the name space, the +subject name defined above become a RDN which is part of DN binded to +the end entity's public key in the certificate. + + +A sample of DN assigned by Entrust CA is given below (assume the same +ciscoRouterAlice is used as the end entity defined subject name): + + OU = InteropTesting, O = Entrust Technologies, C = CA + RDN = {"alice.cisco.com", "172.21.114.67", "22334455"} + + +Liu/Madson/McGrew/Nourse [Page 35] + +Cisco Systems' Simple Certificate Enrollment Protocol May 2002 + +Appendix B: IPSEC Client Enrollment Certificate Request + +The following is the certificate enrollment request (PKCS#10) as created +by Cisco VPN Client: + +-----END NEW CERTIFICATE REQUEST----- + 0 30 439: SEQUENCE { + 4 30 288: SEQUENCE { + 8 02 1: INTEGER 0 + 11 30 57: SEQUENCE { + 13 31 55: SET { + 15 30 53: SEQUENCE { + 17 06 3: OBJECT IDENTIFIER commonName (2 5 4 3) + 22 13 46: PrintableString + : 'For Xiaoyi, IPSEC attrs in alternate name + extn' + : } + : } + : } + 70 30 158: SEQUENCE { + 73 30 13: SEQUENCE { + 75 06 9: OBJECT IDENTIFIER rsaEncryption (1 2 840 113549 1 + 1 1) + 86 05 0: NULL + : } + 88 03 140: BIT STRING 0 unused bits + : 30 81 88 02 81 80 73 DB 1D D5 65 AA EF C7 D4 8E + : AA 6E EB 46 AC 91 2A 0F 50 51 17 AD 50 A2 2A F2 + : CE BE F1 E4 22 8C D7 61 A1 6C 87 61 62 92 CB A6 + : 80 EA B4 0F 09 9D 18 5F 39 A3 02 0E DB 38 4C E4 + : 8A 63 2E 72 8B DC BE 9E ED 6C 1A 47 DE 13 1B 0F + : 83 29 4D 3E 08 86 FF 08 2B 43 09 EF 67 A7 6B EA + : 77 62 30 35 4D A9 0F 0F DF CC 44 F5 4D 2C 2E 19 + : E8 63 94 AC 84 A4 D0 01 E1 E3 97 16 CD 86 64 18 + : [ Another 11 bytes skipped ] + : } + 231 A0 63: [0] { + 233 30 61: SEQUENCE { + 235 06 9: OBJECT IDENTIFIER extensionReq (1 2 840 113549 1 9 + 14) + 246 31 48: SET { + 248 30 46: SEQUENCE { + 250 30 44: SEQUENCE { + 252 06 3: OBJECT IDENTIFIER subjectAltName (2 5 29 17) + 257 04 37: OCTET STRING + 30 23 87 04 01 02 03 04 81 0D 65 6D 61 69 + + +Liu/Madson/McGrew/Nourse [Page 36] + +Cisco Systems' Simple Certificate Enrollment Protocol May 2002 + + 6C 40 69 72 65 2E 63 6F 6D 82 0C 66 71 64 + 6E 2E 69 72 65 2E 63 6F 6D + : } + : } + : } + : } + : } + : } + + 296 30 13: SEQUENCE { + 298 06 9: OBJECT IDENTIFIER md5withRSAEncryption (1 2 840 113549 + 1 1 4) + 309 05 0: NULL + : } + 311 03 129: BIT STRING 0 unused bits + : 19 60 55 45 7F 72 FD 4E E5 3F D2 66 B0 77 13 9A + : 87 86 75 6A E1 36 C6 B6 21 71 68 BD 96 F0 B4 60 + : 95 8F 12 F1 65 33 16 FD 46 8A 63 19 90 40 B4 B7 + : 2C B5 AC 63 17 50 28 F0 CD A4 F0 00 4E D2 DE 6D + : C3 4F F5 CB 03 4D C8 D8 31 5A 7C 01 47 D2 2B 91 + : B5 48 55 C8 A7 0B DD 45 D3 4A 8D 94 04 3A 6C B0 + : A7 1D 64 74 AB 8A F7 FF 82 C7 22 0A 2A 95 FB 24 + : 88 AA B6 27 83 C1 EC 5E A0 BA 0C BA 2E 6D 50 C7 + : } + + +Appendix C: Private OID Definitions + +The OIDs used in defining pkiStatus are VeriSign self-maintained +OIDs. Please note, work is in progress to replace the VeriSign owned +object identifiers with the standard object identifiers. Once the +standarlization is completed, this documentation will be updated. + +id-VeriSign OBJECT_IDENTIFIER ::= {2 16 US(840) 1 VeriSign(113733)} +id-pki OBJECT_IDENTIFIER ::= {id-VeriSign pki(1)} +id-attributes OBJECT_IDENTIFIER ::= {id-pki attributes(9)} +id-messageType OBJECT_IDENTIFIER ::= {id-attributes messageType(2)} +id-pkiStatus OBJECT_IDENTIFIER ::= {id-attributes pkiStatus(3)} +id-failInfo OBJECT_IDENTIFIER ::= {id-attributes failInfo(4)} +id-senderNonce OBJECT_IDENTIFIER ::= {id-attributes senderNonce(5)} +id-recipientNonce OBJECT_IDENTIFIER ::= {id-attributes recipientNonce(6)} +id-transId OBJECT_IDENTIFIER ::= {id-attributes transId(7)} +id-extensionReq OBJECT_IDENTIFIER ::= {id-attributes extensionReq(8)} + + +Liu/Madson/McGrew/Nourse [Page 37] + +Cisco Systems' Simple Certificate Enrollment Protocol May 2002 + + Appendix D: CRL Query by means of LDAP + + In order to retrieve the CRL by means of LDAP, the client needs to know + where in the directory it is stored. The certificate must contain a + CRL Distribution Point extension encoded as a DN or as an LDAP URI. + +For example, the certificate issued by Entrust VPN contains +the following DN as the CRL distribution point: + + + +CN = CRL1, O = cisco, C = US. + + The asn.1 encoding of this distribution point is: + + 30 2C 31 0B 30 09 06 03 55 04 06 13 02 55 53 31 0E 30 0C 06 + 03 55 04 0A 13 05 63 69 73 63 6F 31 0D 30 0B 06 03 55 04 03 + 13 04 43 52 4C 31 + + +The ldap form would be: + +ldap://servername/CN=CRL1,O=cisco,C=US + + + +Appendix E: SCEP State Transitions + +SCEP state transitions are based on transaction identifier. The design +goal is to ensure the synchronization between the CA and the end entity +under various error situations. + + +An identity is defined by the combination of FQDN, the IP address and +the client serial number. FQDN is the required name attribute. It is +important to notice that, a client named as Alice.cisco.com is different +from the client named as Alice.cisco.com plus IPAddress 171.69.1.129. + +Each enrollment transaction is uniquely associated with a transaction +identifier. Because the enrollment transaction could be interrupted by +various errors, including network connection errors or client reboot, +the SCEP client generates a transaction identifier by calculating MD5 +hash on the public key value for which the enrollment is requested. This +retains the same transaction identifier throughout the enrollment +transaction, even if the client has rebooted or timed out, and issues a +new enrollment request for the same key pair. It also provides the way +for the CA to uniquely identify a transaction in its database. At the +end entity side, it generates a transaction identifier which is included +in PKCSReq. If the CA returns a response of PENDING, the end entity +will poll by periodically sending out GetCertInitial with the same +transaction identifier until either a response other than PENDING is +obtained, or the configured maximum time has elapsed. + +If the client times out or the client reboots, the client administrator +will start another enrollment transaction with the same key pair. The +second enrollment will have the transaction idenifier. At the server +side, instead of accepting the PKCSReq as a new enrollment request, it +should respond as if another GetCertInitial message had been sent with +that transaction ID. In another word, the second PKCSReq should be +taken as a resynchronization message to allow the enrollment resume as +the same transaction. + +It is important to keep the transaction id unique since CEP requires the +same policy and same identity be applied to the same subject name and + + +Liu/Madson/McGrew/Nourse [Page 38] + +Cisco Systems' Simple Certificate Enrollment Protocol May 2002 + +key pair binding. In the current implementation, an SCEP client can +only assume one identity. At any time, only one key pair, with a given +key usage, can be associated with the same identity. + +The following gives several example of client to CA transactions. + +Client actions are indicated in the left column, CA actions are +indicated in the right column. A blank action signifies that no message +was received. Note that these examples assume that the CA enforces the +certificate-name uniqueness property defined in Section 2.1.1.1. + +The first transaction, for example, would read like this: + "Client Sends PKCSReq message with transaction ID 1 to the + CA. The CA signs the certificate and constructs a CertRep Message + containing the signed certificate with a transaction ID 1. The client + receives the message and installs the cert locally." + +Successful Enrollment Case: no manual authentication +PKCSReq (1) ----------> CA Signs Cert +Client Installs Cert <---------- CertRep (1) SIGNED CERT + + + +Successful Enrollment Case: manual authentication required +PKCSReq (10) ----------> Cert Request goes into Queue +Client Polls <---------- CertRep (10) PENDING +GetCertInitial (10) ----------> Still pending +Client Polls <---------- CertRep (10) PENDING +GetCertInitial (10) ----------> Still pending +Client Polls <---------- CertRep (10) PENDING +GetCertInitial (10) ----------> Still pending +Client Polls <---------- CertRep (10) PENDING +GetCertInitial (10) ----------> Cert has been signed +Client Installs Cert <---------- CertRep (10) SIGNED CERT + + + +Resync Case - CA Receive and Signs PKCSReq, Client Did not receive +CertRep: + +PKCSReq (3) ----------> Cert Request goes into queue + <---------- CertRep (3) PENDING +GetCertInitial (3) ----------> + <---------- CertRep (3) PENDING +GetCertInitial (3) -----------> + <----------- CA signed Cert and send back + CertRep(3) +(Time Out) +PKCSReq (3) ----------> Cert already signed, send back to + client +Client Installs Cert <---------- CertRep (3) SIGNED CERT + + + +Liu/Madson/McGrew/Nourse [Page 39] + +Cisco Systems' Simple Certificate Enrollment Protocol May 2002 + + +Case when NVRAM is lost and client has to generate a new key pair, there +is no change of name information: + +PKCSReq (4) ----------> CA Signs Cert +Client Installs Cert <---------- CertRep (4) SIGNED CERT +(Client looses Cert) +PKCSReq (5) ----------> There is already a valid cert with + this DN. +Client Admin Revokes <---------- CertRep (5) OVERLAPPING CERT ERROR +PKCSReq (5) ----------> CA Signs Cert +Client Installs Cert <---------- CertRep (5) SIGNED CERT + + +Case when client admin resync the enrollment using a different PKCS#10: +PKCSReq (6) ----------> CA Signs Cert + <---------- CertRep (6) SIGNED CERT +(Client timeout and admin starts another enrollment with a different + PKCS#10, but the same transaction id) +PKCSReq (6) with different PKCS#10 + ----------> There is already a valid cert with + this entity (by checking FQDN). + <---------- CertRep (6) INVALID PKCS#10 CERT + ERROR +Client admin either revokes the existing cert +or corrects the error by enrolling with +the same PKCS#10 as the first PKCSReq(6) +PKCSReq (6) ----------> CA find the existing Cert +Client Installs Cert <---------- CertRep (6) SIGNED CERT + + +Resync case when server is slow in response: +PKCSReq (13) ----------> Cert Request goes into Queue + <---------- CertRep (13) PENDING +GetCertInitial ----------> Still pending + <---------- CertRep (13) PENDING +GetCertInitial ----------> Still pending + <---------- CertRep (13) PENDING +GetCertInitial ----------> Still pending + <---------- CertRep (13) PENDING +GetCertInitial ----------> Still pending +(TimeOut) <---------- CertRep (13) PENDING +* Case 1 +PKCSReq (13) ----------> Still pending +Client polls <---------- CertRep (13) PENDING +CertCertInitial ----------> Cert has been signed +Client Installs Cert <---------- CertRep (13) SIGNED CERT +* Case 2 +PKCSReq (13) ----------> Cert has been signed +Client Installs Cert <---------- CertRep (13) SIGNED CERT + + + + +Liu/Madson/McGrew/Nourse [Page 40] + +Cisco Systems' Simple Certificate Enrollment Protocol May 2002 + +Appendix F. Author Contact Information + +Xiaoyi Liu Cheryl Madson +Cisco Cisco +170 West Tasman Drive 170 West Tasman Drive +San Jose, CA 94134 San Jose, CA 94134 +xliu@cisco.com cmadson@cisco.com + + +David McGrew Andrew Nourse +Cisco Cisco +170 West Tasman Drive 101 Cooper Street +San Jose, CA 94134 Santa Cruz, CA 95060 +mcgrew@cisco.com nourse@cisco.com + + + + +Appendix G. Copyright Section + +Copyright (C) The Internet Society (2000). All Rights Reserved. + +This document and translations of it may be copied and furnished +to others, and derivative works that comment on or otherwise +explain it or assist in its implmentation may be prepared, copied, +published and distributed, in whole or in part, without +restriction of any kind, provided that the above copyright notice +and this paragraph are included on all such copies and derivative +works. However, this document itself may not be modified in any +way, such as by removing the copyright notice or references to the +Internet Society or other Internet organizations, except as needed +for the purpose of developing Internet standards in which case the +procedures for copyrights defined in the Internet Standards +process must be followed, or as required to translate it into +languages other than English. + +The limited permissions granted above are perpetual and will not +be revoked by the Internet Society or its successors or assigns. + +This document and the information contained herein is provided on +an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET +ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR +IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF +THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED +WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + + + + +This draft expires 15-November 2002 + +[End of draft-nourse-scep-07.txt] + + diff --git a/draft-nourse-scep-11.txt b/draft-nourse-scep-11.txt new file mode 100644 index 0000000..48a5cbb --- /dev/null +++ b/draft-nourse-scep-11.txt @@ -0,0 +1,4734 @@ + +INTERNET DRAFT Xiaoyi Liu +draft-nourse-scep-11.txt Cheryl Madson +expires 11 Aug 2005 David McGrew +(revised 11 Feb 2005) Andrew Nourse + Cisco Systems + +Category: Informational 11 Feb 2005 + + +Cisco Systems' Simple Certificate Enrollment Protocol(SCEP): + +Status of this Memo + +This document is an Internet-Draft and is NOT offered in accordance +with Section 10 of RFC2026, and the author does not provide the IETF +with any rights other than to publish as an Internet-Draft + +Internet-Drafts are working documents of the Internet Engineering Task +Force (IETF), its areas, and its working groups. Note that other +groups may also distribute working documents as Internet-Drafts. + +Internet-Drafts are draft documents valid for a maximum of six months +and may be updated, replaced, or obsoleted by other documents at any +time. It is inappropriate to use Internet- Drafts as reference +material or to cite them other than as "work in progress." + +The list of current Internet-Drafts can be accessed at +http://www.ietf.org/ietf/1id-abstracts.txt + +The list of Internet-Draft Shadow Directories can be accessed at +http://www.ietf.org/shadow.html. + +This memo provides information for the Internet community. This memo +does not specify an Internet standard of any kind. Distribution of +this memo is unlimited. + +By submitting this Internet-Draft, I certify that any applicable patent +or other IPR claims of which I am aware have been disclosed, or will be +disclosed, and any of which I become aware will be disclosed, in accordance +with RFC 3668. + +Abstract + +This document specifies the Simple Certificate Enrollment Protocol, +a PKI communication protocol which leverages existing technology by +using PKCS#7 and PKCS#10. SCEP is the evolution of the enrollment +protocol developed by Verisign, Inc. for Cisco Systems, Inc. +It now enjoys wide support in both client and CA implementations. + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 2 + 2. The Goal of SCEP . . . . . . . . . . . . . . . . . . . . . 3 + 2.1 SCEP Entity types . . . . . . . . . . . . . . . . . . . . 3 + 2.2 SCEP Operations Overview . . . . . . . . . . . . . . . . . 7 + 2.3 PKI Operation Transactional Behavior . . . . . . . . . . . 10 + 2.4 Security . . . . . . . . . . . . . . . . . . . . . . . . . 12 + 3. Transport Protocol . . . . . . . . . . . . . . . . . . . . 13 + 4. Secure Transportation: PKCS #7 . . . . . . . . . . . . . . 14 + 4.1 SCEP Message Format . . . . . . . . . . . . . . . . . . . 14 + + Liu/Madson/McGrew/Nourse [Page 2] + +Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005 + + 4.2 Signed Transaction Attributes . . . . . . . . . . . . . . 15 + 5. SCEP Transaction Specification . . . . . . . . . . . . . . 16 + 5.1 Certificate Enrollment . . . . . . . . . . . . . . . . . . 16 + 5.2 Poll for Requester Initial Certificate . . . . . . . . . . 22 + 5.3 Certificate Access . . . . . . . . . . . . . . . . . . . . 26 + 5.4 CRL Access . . . . . . . . . . . . . . . . . . . . . . . 27 + 5.5 Get Certificate Authority Certificate . . . . . . . . . . 31 + 5.6 Get Certificate Authority Certificate Chain . . . . . . . 33 + 6. Security Considerations . . . . . . . . . . . . . . . . . 33 + 7. Intellectual Propoerty . . . . . . . . . . . . . . . . . . 33 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . 33 + Appendix A. Cisco Requester Subject Name Definition . . . . . . 34 + Appendix B. IPSEC Client Enrollment Certificate Request . . . . 35 + Appendix C. Private OID Definitions . . . . . . . . . . . . . 36 + Appendix D. Obtaining CRL by LDAP Query . . . . . . . . . . . . 36 + Appendix E. SCEP State Transitions . . . . . . . . . . . . . . 37 + Appendix F. CA Capabilities . . . . . . . . . . . . . . . . . . 40 + Appendix G. Certificate Renewal and CA Key Rollover . . . . . . 41 + Appendix H. PKIOperation via HTTP POST Message. . . . . . . . . 42 + Appendix Y. Author Contact Information. . . . . . . . . . . . . 43 + Appendix Z. Copyright Section . . . . . . . . . . . . . . . . . 43 + +Section 1. Introduction + +Public key technology is becoming more widely deployed and is becoming +the basis for standards based security, such as the Internet Engineering +Task Force's IPSEC and IKE protocols. With the use of public key +certificates in network security protocols comes the need for a +certificate management protocol that Public Key Infrastructure (PKI) +clients and Certificate Authority servers can use to support certificate +life cycle operations such as certificate enrollment and revocation, and +certificate and CRL access. + +In the following, Section 2 gives an overview of the PKI operations, +and Section 2.4 describes the security goals of the protocol and the +mechanisms used to achieve them. The transport protocol and the +security protocol PKCS#7 are described at Section 3 and Section 4, +respectively. The last section, Section 5, specifies each PKI +operation in terms of the message formats and the data structures of +each operation. + +The appendices provide detailed specifications and examples. Requester +subject names are specified in Appendix A, attribute OIDs are +specified in Appendix C , and the SCEP state transitions are described +in Appendix E. An example of a certificate enrollment request is +provided in Appendix B, and an example LDAP query URL encoding is +provided in Appendix D. + +The authors would like to thank Peter William of ValiCert, Inc. +(formerly of Verisign, Inc) and Alex Deacon of Verisign, Inc. and +Christopher Welles of IRE, Inc. for their contributions to this protocol +and to this document. + + Liu/Madson/McGrew/Nourse [Page 3] + +Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005 + +2.0 The Goal of SCEP +The goal of SCEP is to support the secure issuance of certificates to +network devices in a scalable manner, using existing technology whenever +possible. The protocol supports the following operations: + + CA and RA public key distribution + Certificate enrollment + Certificate revocation + Certificate query + CRL query + +Certificate and CRL access can be achieved by using the LDAP protocol +(as specified in Appendix D), or by using the query messages defined in +SCEP. The use of HTTP certificate and CRL access, and the support of +CDP as specified in RFC2459, will be specified in a future version of +this document. In Section 2.1, we first define PKI entity types as well +as the properties of each entity type. In Section 2.2, the PKI +operations are described at functional level. Section 2.3 describes the +transaction behavior of each PKI operations. The complete PKI messages +are covered in Section 5. + +2.1 SCEP Entity types + +The entity types defined in SCEP are the "requester" type (i.e., IPSEC +clients), the Certificate Authority (CA) entity type, and the +Registration Authority entity type (RA). A requester is sometimes +called a "SCEP client" in the following. + +2.1.1 Requesters + +A requester is an entity whose name is defined in a certificate +subject name field and optionally, in SubjectAltName, a X.509 +certificate V3 extension. As a requester, a SCEP client is identified +by a subject name consisting of the following naming attributes: + + Fully qualified domain name, for example, router.cisco.com + IP address, Serial number, and/or x.500 distinguished name + +The fully qualified domain name is required for a requester that intends +to use the certificate for ISAKMP. The IP address, serial number, and +x.500 distinguished name are optional name attributes. In the +certificate enrollment request, the PKCS#10 subject field contains the +required and optional name attributes. The distinguished name, if any, +should be the subject name field, while any domain name, serial number, +or IP address supplied should be in the subjectAltName field. The +subject name field may be empty (if there is no distinguished name) +or the subjectAltName may be omitted, but not both. + +It is important to note that a client named as Alice.cisco.com is +different than a client named as Alice.cisco.com plus the IP address +name attribute 117.96.1.219. From CA point of view, the Distinguished +names assigned in these two cases are distinct names. + + + Liu/Madson/McGrew/Nourse [Page 4] + +Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005 + +Entity names which are specified as in the IPSEC profile (i.e., FQDN, IP +address and User FQDN) must be presented in certificate's SubjectAltName +extension. Multiple IPSEC entity names, (if any) are encoded as multiple +values of a single SubjectAltName extension. The CA has the authority +to assign a distinguished name to a requester, whether or not one was +included in the request. The assigned DN should contain the SCEP client +names as the relative DN. + +The attribute identifiers and an example of SCEP client subject name are +specified in Appendix A. Appendix B has an example from Cisco VPN Client +enrollment request. + +2.1.1.1 Local Key/Certificate/CRL Storage and Certificate-name uniqueness + +A requester is required to generate asymmetric key pairs and to provide +storage to store its private keys. If the requester does not have enough +permanent memory to save its certificate, then it should be able to query +its own certificate from the CA or an LDAP server, once the certificate +has been issued. The public key pairs can be generated with a specific +key usage. The key usage is conveyed to the CA through the certificate +enrollment request. All current SCEP client implementations expect that +there will be only one pair of keys for a given subject name +and key usage combination and CA, at any time. This property is called +the certificate-name uniqueness property, and it implies that a CA that +implements SCEP will enforce the unique mapping between a SCEP client +subject name and its key pairs with a given key usage. At any time, if +the subject name is changed, or if the key is updated, the existing +certificate would have to be revoked before a new one could be issued. + +It is desirable that the CA enforce certificate-name uniqueness, but +it is not mandatory. However a CA that does not enforce uniqueness +must provide some other mechanism to prevent the re-transmission of an +enrollment request by a SCEP client from creating a second certificate +or certificate request, nor can the second request merely be rejected. +If a client times out from polling for a pending request it can +resynchronize by reissuing the original request with the original +subject name, key, and transaction ID. This should return the status of +the original transaction, including the certificate if it was granted. +It should not create a new transaction unless the original cert has been +revoked, or the transaction arrives more than halfway through the +validity time of the original certificate. + +An enrollment request that occurs more than halfway through the validity +time of an existing certificate for the same subject name and key usage +MAY be interpreted as a re-enrollment or renewal request and accepted. +A new certificate with new validity dates may be issued, even though +the old one is still valid, if the CA policy permits, as described in +2.1.1.3. See also appendix G. + +2.1.1.2 Requester 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 + Liu/Madson/McGrew/Nourse [Page 5] + +Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005 + +cryptographically secure manner. This requirement is needed to +prevent a "man in the middle" attack, in which an adversary that can +manipulate the data as it travels between the protocol participants +can subvert the security of the protocol. To satisfy this +requirement, SCEP provides two authentication methods: manual +authentication, and authentication based on pre-shared secret. In the +manual mode, the requester is required to wait until its identity can +be verified by the CA operator using any reliable out-of-band +method. To prevent a "man-in-the-middle" attack, a SHA-1 or MD5 +`fingerprint' generated on the PKCS#10 (before PKCS #7 enveloping and +signing) must be compared out-of-band between the server and the +requester. SCEP clients and CAs (or RAs, if appropriate) must display +this fingerprint to the operator to enable this verification if manual +mode is used. Failing to provide this information leaves the protocol +vulnerable to attack by sophisticated adversaries. When utilizing a +pre-shared secret scheme, the server should distribute a shared secret +to the requester which can uniquely associate the enrollment request +with the given end entity. The distribution of the secret must be +private: only the end entity should know this secret. The actual +binding mechanism between the requester and the secret is subject to +the server policy and implementation. When creating the enrollment +request, the requester is asked to provide a challenge password. When +using the pre-shared secret scheme, the requester must enter the +re-distributed secret as the password. In the manual authentication +case, the challenge password only used to authenticate a request for +the certificate's revokation. This challenge password is included as +a PKCS#10 attribute, and is sent to the server as encrypted data. The +PKCS#7 envelope protects the privacy of the challenge password with +DES encryption. + +2.1.1.3 Requester Uses Existing CA-Issued or Self-Signed Certificates + +In this protocol, the communication between the requester and the +certificate authority is secured by using PKCS#7 as the messaging +protocol. PKCS#7, however, is a protocol which assumes the +communicating entities already possess the peer's certificates and +requires both parties use the issuer names and issuer assigned +certificate serial numbers to identify the certificate in order to +verify the signature and decrypt the message. If the requesting +system already has a certificate issued by the CA, that certificate +may be presented as credentials for the renewal of that certificate if +the CA supports the "Renewal" capability and the CA policy permits the +certificate to be renewed. If the requester has no certificate issued +by the CA, or if the CA does not support and permit renewal, the +requestor must generate a self-signed certificate with the requester +subject name (the same name later used in the PKCS#10) as both issuer +and subject name. During the certificate enrollment, the requester +will first post itself as the signing authority by attaching the +self-signed certificate to the signed certificate request. When the +Certificate Authority makes the envelope on the issued certificate +using the public key included in the self-signed certificate, it +should use the same issuer name and serial number as conveyed in the +self-signed certificate to inform the end entity on which private key +should be used to open the envelope. + Liu/Madson/McGrew/Nourse [Page 6] + +Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005 + +Note that when a client enrolls for separate encryption and signature +certificates, it may use the signature certificate to sign both +requests, and then expect its signature key to be used to encrypt +both responses. In any case, the recipientinfo on the envelope should +reflect the key used to encrypt the request. + +2.1.1.4 Trusted CA Store + +To support interoperability between IPSEC peers whose certificates are +issued by different CA, SCEP allows the users to configure multiple +trusted certificates. Trusted certificates are have been configured as +such in the client, based on some out-of-band means such as a "fingerprint". +These trusted certificates are used to verify certificate chains that end +in those certificates. + +2.1.2 Certificate Authority + +A Certificate Authority(CA) is an entity whose name is defined in the +certificate issuer name field. Before any PKI operations can begin, +the CA generates its own public key pair and creates a self-signed CA +certificate, or causes another CA to issue a certificate to it. +Associated with the CA certificate is a fingerprint which will be used +by the requester to authenticate the received CA certificate if it is +self-signed. The fingerprint is created by calculating a SHA-1 or MD5 +hash on the whole CA certificate. Before any requester can start its +enrollment, this CA certificate has to be configured at the entity +side securely. For IPSEC clients, the client certificates must have +SubjectAltName extension. To utilize LDAP as a CRL query protocol, +the certificates must have a CRL Distribution Point. Key usage is +optional. Without key usage, the public key is assumed as a general +purpose public key and it can be used for all the purposes. + +A Certificate Authority may enforce certain name policy. When using +X.500 directory name as the subject name, all the name attributes +specified in the PKCS#10 request should be included as Relative DN. All +the name attributes as defined in RFC2459 should be specified in the +SubjectAltName. An example is provided in Appendix A. + + If there is no LDAP query protocol support, the Certificate Authority +should answer certificate and CRL queries, and to this end it should be +online all the time. + +The updating of the CA's public key is addressed in Appendix G. + +2.1.3 Registration Authorities + +In an environment where an RA is present, a requester performs +enrollment through the RA. In order to setup a secure channel with an RA +using PKCS#7, the RA certificate(s) have to be obtained by the client +in addition to the CA certificate(s). + +In the following, the CA and RA are specified as one entity in the +context of PKI operation definitions. + Liu/Madson/McGrew/Nourse [Page 7] +Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005 +2.2 SCEP Operations Overview + +In this section, we give a high level overview of the PKI operations as +defined in SCEP. + +2.2.1 Requester Initialization + +The requester initialization includes the key pair generation and the +configuring of the required information to communicate with the +certificate authority. + +2.2.1.1 Key Pairs + +Before a requester can start PKI transaction, it must have at least one +asymmetric key pair, using the selected algorithm (the RSA algorithm is +required in SCEP, and is the only algorithm in current implementations). + +Key pairs may be intended for particular purposes, such as encryption only, +or signing only. The usage of any associated certificate can be restricted +by adding key usage and extended key usage attributes to the PKCS#10. + +2.2.1.2 Required Information + +A requester is required to have the following information configured +before starting any PKI operations: + +1. the certificate authority IP address or fully-qualified domain name, +2. the certificate authority HTTP CGI script path, and + the HTTP proxy information in case there is no direct Internet + connection to the server, +3. If CRLs are being published by the CA to an LDAP directory server, + and there is a CRL Distribution Point containing only an X.500 directory + name, then the client will need to know the LDAP server fully-qualified + domain name or IP address. CRL Distribution Points are discussed in + more detail in RFC 2459. + + +2.2.2 CA/RA Certificate Distribution + +Before any PKI operation can be started, the requester needs to get +the CA/RA certificates. At this time, since no public key has been + + Liu/Madson/McGrew/Nourse [Page 8] + +Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005 + +exchanged between the requester and the CA/RA, the message to get the +CA/RA certificate can not be secured using PKCS#7 protocol. Instead, the +CA/RA certificate distribution is implemented as a clear HTTP Get +operation. After the requester gets the CA certificate, it has to +authenticate the CA certificate by comparing the finger print with the +CA/RA operator. Since the RA certificates are signed by the CA, there is +no need to authenticate the RA certificates. + +This operation is defined as a transaction consisting of one HTTP Get +message and one HTTP Response message: + + REQUESTER CA SERVER + Get CA/RA Cert: HTTP Get message + -----------------------------> + CA/RA Cert download: HTTP Response message + <--------------------------------------- + Compute finger print and + call CA operator. + Receive call and check finger print + +If an RA is in use, a degenerated PKCS#7 with a certificate chain +consisting of both RA and CA certificates is sent back to the end +entity. Otherwise the CA certificate is directly sent back as the +HTTP response payload. + + +2.2.3 Certificate Enrollment + +A requester starts an enrollment transaction by creating a certificate +request using PKCS#10 and sends it to the CA/RA enveloped using the +PKCS#7. After the CA/RA receives the request, it will either +automatically approve the request and send the certificate back, or it +will require the requester to wait until the operator can manually +authenticate the identity of the requester. Two attributes are +included in the PKCS#10 certificate request - a Challenge Password +attribute and an optional ExtensionReq attribute which will be a +sequence of extensions the requester would like to be included in its +V3 certificate extensions. The Challenge Password may be used to +authenticate either the enrollment request itself, or a verbal +revocation request for the issued certificate in the event of key +compromise or other reason. + +In the automatic mode, the transaction consists of one PKCSReq PKI +Message, and one CertRep PKI message. In the manual mode, the requester +enters into polling mode by periodically sending a GetCertInitial PKI +message to the server, until the server operator completes the manual +authentication, after which the CA will respond to GetCertInitial by +returning the issued certificate. A CA MAY run in automatic mode for +preapproved requests, and manual mode for the rest. A request with a +non-null password is not necessarily a pre-approved request. It is up +to the CA server to decide. Polling mode is entered whenever the +server returns a PENDING response. + + Liu/Madson/McGrew/Nourse [Page 9] +Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005 + + +The transaction in automatic mode: + + REQUESTER CA SERVER + +PKCSReq: PKI cert. enrollment msg + --------------------------------> CertRep: pkiStatus = SUCCESS + certificate attached + <------------------------------ + Receive issued certificate. + +The transaction in manual mode: + + REQUESTER CA SERVER + PKCSReq: PKI cert. enrollment msg + --------------------------------> CertRep: pkiStatus = PENDING + <------------------------------ + GetCertInitial: polling msg + --------------------------------> CertRep: pkiStatus = PENDING + <------------------------------ + ................. CertRep: pkiStatus = SUCCESS + certificate attached + <------------------------------ + Receive issued certificate. + +2.2.4 Requester Certificate Revocation + +A requester should be able to revoke its own certificate. Currently +the revocation is implemented as a manual process. In order to revoke a +certificate, the requester makes a phone call to the CA server +operator. The operator will come back asking the ChallengePassword +(which has been sent to the server as an attribute of the PKCS#10 +certificate request). If the ChallengePassword matches, the certificate +is revoked. The reason of the revocation is documented by CA/RA. + +2.2.5 Certificate Access + +There are two methods to query certificates. The first method is to use +LDAP as a query protocol. Using LDAP to query assumes the client +understand the LDAP scheme supported by the CA. The SCEP client assumes +that the subject DN name in the certificate is used as the URL to query the +certificate. The standard attributes (userCertificate and caCertificate) +are used as filter. + +For the environment where LDAP is not available, a certificate query +message is defined to retrieve the certificates from the CA. + +To query a certificate from the certificate authority, a requester +sends a request consisting of the certificate's issuer name and the +serial number. This assumes that the requester has saved the issuer + + Liu/Madson/McGrew/Nourse [Page 10] + +Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005 + +name and the serial number of the issued certificate from the previous +enrollment transaction. The transaction to query a certificate consists +of one GetCert PKI message and one CertRep PKI message: + + REQUESTER CA SERVER + GetCert: PKI cert query msg + -------------------------------> CertRep: pkiStatus = SUCCESS + certificate +attached + <----------------------------- + Receive the certificate. + +2.2.6 CRL Distribution + +The CA/RA will not "push" the CRL to the end entities. The query of the +CRL can only be initialized by the requester. + +There are three methods to query CRL. + +The CRL may be retrieved by a simple HTTP GET. If the CA supports this +method, it should encode the URL into a CRL Distribution Point extension +in the certificates it issues. Support for this method should be +incorporated in new and updated clients, but may not be in older +versions. + +The second method is to query CRL using LDAP. This assumes the CA server +supports CRL LDAP publishing and issues the CRL Distribution Point in +the certificate. The CRL Distribution Point is encoded as a DN. Please +refer to Appendix D for the examples of CRL Distribution Point. + +The third method is implemented for the CA which does not support LDAP +CRL publishing or does not implement the CRL Distribution Point. In this +case, a CRL query is composed by creating a message consists of the CA +issuer name and the CA's certificate serial number. This method is +deprecated because it does not scale well and requires the CA to be a +high-availability service. + +The message is sent to the CA in the same way as the other SCEP +requests: The transaction to query CRL consists of one GetCRL PKI +message and one CertRep PKI message which have no certificates but CRL. + + REQUESTER CA SERVER + GetCRL: PKI CRL query msg + ----------------------------------> CertRep: CRL attached + <-------------------------------- + +2.3 PKI Operation Transactional Behavior + +As described before, a PKI operation is a transaction consisting of the +messages exchanged between a requester and the CA/RA. This section +will specify the transaction behavior on both the requester and the + + + Liu/Madson/McGrew/Nourse [Page 11] + +Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005 + +certificate authority server. Because the protocol is basically a two +way communication protocol without a confirmation message from the +initiating side, state and state resynchronization rules have to be +defined, in case any error happens at either side. Before the state +transition can be defined, the notion of transaction identifier has to +be defined first. + +2.3.1 Transaction Identifier + +A transaction identifier is a string generated by the entity when +starting a transaction. Since all the PKI operations defined in this +protocol are initiated by the requester, it is the responsibility of +the requester to generate a unique string as the transaction +identifier. All the PKI messages exchanged for a given PKI transaction +must carry the same transaction identifier. The transaction identifier +is generated as a SHA-1 or MD5 hash on the public key value for which the +enrollment request is made. This allows the SCEP client to reuse the +same transaction identifier if it is reissuing a request for the same +certificate (i.e. a certificate with the same subject, issuer, and key). +The SCEP protocol requires that transaction identifiers be unique, so +that queries can be matched up with transactions. For this reason, in +those cases in which separate signing and encryption certificates are +issued to the same requester, the keys must be different. + +2.3.2 State Transitions in Certificate Enrollment + +The requester state transitions during enrollment operation are +indicated in the diagram below: + +-<------+ + | | + GetCertInitial triggered by timeout or + | | manual authentication + | | + [CERT-NONEXISTANT] ------> [CERT-REQ-PENDING] ---> [CERT-ISSUED] + | PKCSReq | CertRep with SUCCESS + | | + | | + +--------<-------------------+ + request rejected, timeout, or error + +As described in the section 2.2.3, certificate enrollment starts at the +state CERT-NONEXISTANT. Sending PKCSReq changes the state to +CERT-REQ-PENDING. Receiving CertRep with SUCCESS status changes the +state to CERT-ISSUED. In the case the server sending back the response +with pending status, the requester will keep polling certificate +response by sending GetCertInitial to the server, until either a CertRep +with SUCCESS status is received, or the maximum polling number has been +exceeded. + +If an error or timeout occurs in the CERT-REQ-PENDING state, the end +entity will transition to the CERT-NONEXISTANT state. + + + Liu/Madson/McGrew/Nourse [Page 12] + +Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005 + + +The client administrator will, eventually, start up another enrollment +request. It is important to note that, as long as the requester does +not change its subject name or keys, the same transaction id will be +used in the "new" transaction. This is important because based on this +transaction id, the certificate authority server can recognize this as +an existing transaction instead of a new one. + + +2.3.3 Transaction Behavior of Certificate/CRL Access + +There is no state maintained during certificate access and CRL access +transaction. When using the certificate query and CRL query messages +defined in this protocol, the transaction identifier is still required +so that the requester can match the response message with the +upstanding request message. When using LDAP to query the certificate and +the CRL, the behavior is specified by the LDAP protocol. + +2.4 Security + +The security goals of SCEP are that no adversary can: + +o subvert the public key/identity binding from that intended, +o discover the identity information in the enrollment requests and + issued certificates, +o cause the revocation of certificates with any non-negligible + probability. + +Here an adversary is any entity other than the requester and the CA +(and optionally the RA) participating in the protocol that is +computationally limited, but that can manipulate data during +transmission (that is, a man-in-the-middle). The precise meaning of +'computationally limited' depends on the implementer's choice of +cryptographic hash functions and ciphers. The required algorithms are +RSA, DES, and either SHA-1 or MD5, depending on the "SHA-1" CA Capability. +[See Appendix F]. + +The first and second goals are met through the use of PKCS#7 and PKCS#10 +encryption and digital signatures using authenticated public keys. The +CA's public key is authenticated via the checking of the CA fingerprint, +as specified in Section 2.1.2, and the SCEP client's public key is +authenticated through the manual authentication or pre-shared secret +authentication, as specified in Section 2.1.1.2. The third goal is met +through the use of a Challenge Password for revocation, that is chosen +by the SCEP client and communicated to the CA protected by the PKCS#7 +encryption, as specified in Section 2.2.4. + +The motivation of the first security goal is straightforward. The +motivation for the second security goal is to protect the identity +information in the enrollment requests and certificates. For example, +two IPSEC hosts behind a firewall may need to exchange certificates, and +may need to enroll certificates with a CA that is outside of a firewall. +Most networks with firewalls seek to prevent IP addresses and DNS + + Liu/Madson/McGrew/Nourse [Page 13] + +Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005 + +information from the trusted network leaving that network. The second +goal enables the hosts in this example to enroll with a CA outside the +firewall without revealing this information. The motivation for the +third security goal is to protect the SCEP clients from denial of +service attacks. + +Section 3 Transport Protocol + +In the SCEP protocol, HTTP is used as the transport protocol for the PKI +messages. + +3.1 HTTP "GET" and "POST" Message Format + +The following is the syntax definition of a HTTP GET message sent from +a requester to a certificate authority server: + +Request = "GET " CGI-PATH CGI-PROG "?operation=" OPERATION "&message=" MESSAGE +where: + CGI-PATH defines the actual CGI path to invoke the CGI program which + parses the request. + CGI-PROG is set to be the string "pkiclient.exe". This is intended + to be the program that the CA will use to handle the SCEP transactions, + though the CA may ignore CGI-PROG and use only the CGI-PATH. + OPERATION is set to be the string "PKIOperation" when the GET message + carries a PKI message to request certificates or CRL; OPERATION is set + to be the string "GetCACaps", "GetCACert", "GetNextCACert" or + "GetCACertChain" when the GET operation is used to get CA capabilities, + CA/RA certificate, the replacement CA/RA certificates for when the + current ones expire, or the CA Cert chain (respectively). + + When OPERATION is "PKIOperation", MESSAGE is a base64-encoded PKI message, + When OPERATION is GetCACert, MESSAGE is a CRL distribution + point in URI format, otherwise, MESSAGE is a string which represents + the certificate authority issuer identifier. + +SCEP uses the HTTP "GET" and "POST" messages to request information from the CA. +Requests for CA certificates or capabilities are sent in the clear, using "GET", +with the OPERATION and MESSAGE fields identifying the requested data. +CRLs may also be requested in the clear if the CA supports it. + +Other types of requests are sent using the PKCS#7 secure protocol. +These may be issued by means of a GET operation with +OPERATION and MESSAGE parameters in the Request-URL. OPERATION +identifies the type of GET operation, and MESSAGE is actually the PKCS#7 +message Base64-Encoded. + +For example. a requester may submit a message via HTTP to the server +as follows: + +GET /cgi-bin/pkiclient.exe?operation=PKIOperation&message=MIAGCSqGSIb3D +QEHA6CAMIACAQAxgDCBzAIBADB2MGIxETAPBgNVBAcTCE ......AAAAAA== + Liu/Madson/McGrew/Nourse [Page 13a] + +If supported by the CA, the message may also be sent via HTTP POST: + +POST /cgi-bin/pkiclient.exe?operation=PKIOperation + +This is further described in Appendix H. +To determine if the CA supports POST, use the GetCACaps message described +in Appendix F. + + +3.2 Response Message Format + +For each GET operation, the CA/RA server will return a MIME object via +HTTP. For a GET operation with PKIOperation as its type, the response is +tagged as having a Content Type of application/x-pki-message. The body +of this message is a BER encoded binary PKI message. The following is an +example of the response: + +"Content-Type:application/x-pki-message\n\n" + +In the case of GET operation with a type of GetCACert the MIME content +type returned will depend on whether or not an RA is in use. If there +is no RA, only the CA certificate is sent back in the response, and +the response has the content type tagged as +application/x-x509-ca-cert. the body of the response is a DER encoded +binary X.509 certificate. For example: + +"Content-Type:application/x-x509-ca-cert\n\n" + +If there is an RA, the RA certificates are sent back together with the +CA certificates, a certificate-only PKCS#7 SignedData is sent back in +the response where the SignerInfo is empty. Section 5 has the detailed +definition of the message format in this case. The content type is +application/x-x509-ca-ra-cert. + +The response to GetNextCACert is always a certificates-only PKCS#7 +SignedData with a content type of application/x-x509-ca-ra-cert. +If there is an RA, The signer is the current RA certificate. Otherwise, +the signer is the current CA certificate. + +If the CA supports it, PKIOperation may also be done via an HTTP POST. +This is described in Appendix H. + + Liu/Madson/McGrew/Nourse [Page 14] + +Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005 + +Section 4 Secure Transportation: PKCS#7 + +PKCS#7 is a general enveloping mechanism that enables both signed and +encrypted transmission of arbitrary data. It is widely implemented and +included in the RSA tool kit. In this section, the general PKCS#7 +enveloped PKI message format is specified. The complete PKCS#7 message +format for each PKI transaction will be covered in Section 5. + +4.1 SCEP Message Format + +As a transaction message, a SCEP message has a set of transaction +specific attributes and an information portion. Employing PKCS#7 +protocol, the transaction specific attributes are encoded as a set of +authenticated attributes of the SignedData. The information portion will +first be encrypted to become Enveloped Data, and then the digest of the +enveloped information portion is included as one of the message digest +attributes and being signed together with the other transaction specific +attributes. + +By applying both enveloping and signing transformations, a SCEP message +is protected both for the integrity of its end-end-transition +information and the confidentiality of its information portion. The +advantage of this technique over the conventional transaction message +format is that, the signed transaction type information and the status +of the transaction can be determined prior to invoke security handling +procedures specific to the information portion being processed. + +The following is an example of a SCEP message with its enveloped and +signed data portion represented by pkcsPKISigned and +pkcsPKIEnveloped. The out-most of any PKI message is a blob of +ContentInfo, with its content type set to SignedData and the actual +signed data as the content. + + Liu/Madson/McGrew/Nourse [Page 15] + +Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005 + + pkiMessage ContentInfo ::= { + contentType {pkcs-7 signedData(2)} + content pkcsPKISigned + } + pkcsPKISigned SignedData ::= { + version 1 + digestAlgorithm { iso(1) member-body(2) US(840) rsadsi(113549) + digestAlgorithm(2) 5} + contentInfo { + contentType {pkcs-7 1} -- data content identifier + content pkcsPKIEnvelope -- enveloped information portion + } + certificates -- signer certificate chain + signerInfo -- including signed transaction info and the digest + -- of the enveloped information portion as the + -- authenticated attributes + } + pkcsPKIEnveloped EnvelopedData ::= { + version 0 + recipientInfos -- information required to open the envelop + encryptedContentInfo { + contentType {pkcs-7 1} -- data content identifier + contentEncryptionAlgorithm + encryptedContent -- encrypted information portion + } + } + +4.2 Signed Transaction Attributes + +The following transaction attributes are encoded as authenticated +attributes. Please refer to Appendix B for the OID definitions. + +transactionID PrintableString -- Decimal value as a string + messageType PrintableString -- Decimal value as a string + pkiStatus PrintableString -- Decimal value as a string + failinfo PrintableString -- Decimal value as a string + senderNonce Octet String + recipientNonce Octet String + +where: + + The transactionID is an attribute which uniquely identify a + transaction. This attribute is required in all PKI messages. + + The messageType attribute specify the type of operation performed by the + transaction. This attribute is required in all PKI + messages. Currently, the following message types are defined: + + PKCSReq (19) -- Permits use of PKCS#10 certificate request + CertRep (3) -- Response to certificate or CRL request + GetCertInitial (20) -- Certificate polling in manual enrollment + GetCert (21) -- Retrieve a certificate + GetCRL (22) -- Retrieve a CRL + + Liu/Madson/McGrew/Nourse [Page 16] + +Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005 + + + All response message will include transaction status information which + is defined as pkiStatus attribute: + + SUCCESS (0) -- request granted + FAILURE (2) -- request rejected + PENDING (3) -- request pending for manual approval. + + If the status in the response is FAILURE, the failinfo attribute will + contain one of the following failure reasons: + + badAlg (0) -- Unrecognized or unsupported algorithm ident + badMessageCheck (1) -- integrity check failed + badRequest (2) -- transaction not permitted or supported + badTime (3) -- Message time field was not sufficiently close + to the system time + badCertId (4) -- No certificate could be identified matching + the provided criteria + + The attributes of senderNonce and recipientNonce are the 16 byte + random numbers generated for each transaction to prevent the replay + attack. + +When a requester sends a PKI message to the server, a senderNonce is +included in the message. After the server processes the request, it will +send back the requester senderNonce as the recipientNonce and generates +another nonce as the senderNonce in the response message. Because the +proposed pki protocol is a two-way communication protocol, it is clear +that the nonce can only be used by the requester to prevent the +replay. The server has to employ extra state related information to +prevent a replay attack. + +Section 5. SCEP Transaction Specification + +In this section each SCEP transaction is specified in terms of the +complete messages exchanged during the transaction. + +5.1 Certificate Enrollment + +The certificate enrollment transaction consists of one PKCSReq message +sent to the certificate authority from a requester, and one CertRep +message sent back from the server. The pkiStatus returned in the +response message is either SUCCESS, or FAILURE, or PENDING. The +information portion of a PKCSReq message is a PKCS#10 certificate +request, which contains the subject Distinguished Name, the subject +public key, and two attributes, a ChallengePassword attribute to be used +for revocation, and an optional ExtensionReq attribute which will be a +sequence of extensions the requester expects to be included in its V3 +certificate extensions. One of the extension attribute specifies the key +usage. If the request is granted, the pkiStatus is set to SUCCESS, and +the certificate is returned in CertRep; if the request is rejected, the + + + Liu/Madson/McGrew/Nourse [Page 17] + +Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005 + +pkiStatus is set to FAILURE; if the server requires manual approval of +the request, the pkiStatus is set to PENDING. The messages exchanged +in the manual authentication mode is further specified in Section 5.2. + +Precondition: + Both the requester and the certificate authority have completed their + initialization process. The requester has already been configured + with the CA/RA certificate. + +Postcondition: + Either the certificate is received by the requester, or the end + entity is notified to do the manual authentication, or the request + is rejected. + +5.1.1 PKCSReq Message Format + +A PKCSReq message is created by following the steps defined below: + +1. Create a PKCS#10 certificate request which is signed by the end + entity's private key, corresponding to the public key included in + the PKCS#10 certificate request. This constitutes the information + portion of PKCSReq. + +2. Encrypt the PKCS#10 certificate request using a randomly generated + content-encryption key. This content-encryption key is then + encrypted by the CA's* public key and included in the recipientInfo. + This step completes the "envelope" for the PKCS#10 certificate + request. + +3. Generate a unique string as the transaction id. + +4. Generate a 16 byte random number as senderNonce. + +5. Generate message digest on the enveloped PKCS#10 certificate request + using the selected digest algorithm. + +6. Create SignedData by adding the requester's self- or CA-certificate + as the signer's public key certificate. Include the message type, + transaction id, the senderNonce and the message digest as the + authenticated attributes and sign the attributes using the end + entity's private key. This completes the SignedData. + +7. The SignedData is prepended with the ContenInfo blob which indicates + a SignedData object. This final step completes the create of a + complete PKCSReq PKI message. + +In the following, the PKCSReq message is defined following the ASN.1 +notation. + +For readability, the values of a field is either represented by a quoted +string which specifies the intended value, or a constant when the value +is known. + + + Liu/Madson/McGrew/Nourse [Page 18] + +Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005 + + -- PKCSReq information portion + pkcsCertReq CertificationRequest ::= { -- PKCS#10 + version 0 + subject "the requester's subject name" + subjectPublicKeyInfo { + algorithm {pkcs-1 1} -- rsa encryption + subjectPublicKey "DER encoding of the requester's public key" + } + attributes { + challengePassword {{pkcs-9 7} "password string" } + extensions + } + signatureAlgorithm {pkcs-1 4} -- MD5WithRSAEncryption + signature "bit string which is created by signing inner content + of the defined pkcsCertReq using requester's private + key, corresponding to the public key included in + subjectPublicKeyInfo." + } + -- Enveloped information portion + pkcsCertReqEnvelope EnvelopeData ::= { -- PKCS#7 + version 0 + recipientInfo { + version 0 + issuerAndSerialNumber { + issuer "the CA issuer name" + serialNumber "the CA certificate serial number" + } + keyEncryptionAlgorithm {pkcs-1 1} -- rsa encryption + encryptedKey "content-encryption key + encrypted by CA public key" + } + encryptedContentInfo { + contentType {pkcs-7 1} -- data content + contentEncryptionAlgorithm "object identifier + for DES encryption" + encryptedContent "encrypted pkcsCertReq using the content- + encryption key" + } + } + -- Signed PKCSReq + pkcsCertReqSigned SignedData ::= { -- PKCS#7 + version 1 + digestAlgorithm {iso(1) member-body(2) US(840) rsadsi(113549) + digestAlgorithm(2) 5} + contentInfo { + contentType {pkcs-7 1} -- data content identifier + content pkcsCertReqEnvelope + } + certificate { -- requester self-signed or CA-issued certificate + version 3 + serialNumber "the transaction id associated with enrollment" + signature {pkcs-1 4} -- md5WithRSAEncryption + + + Liu/Madson/McGrew/Nourse [Page 19] + +Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005 + + issuer " the requester's subject name" + validity { + notBefore "a UTC time" + notAfter "a UTC time" + } + subject "the requester's subject name" + subjectPublicKeyInfo { + algorithm {pkcs-1 1} + subjectPublicKey "DER encoding of requester's public key" + } + signatureAlgorithm {pkcs-1 4} + signature "the signature generated by using the requester's + private key corresponding to the public key in + this certificate." + } + signerInfo { + version 1 + issuerAndSerialNumber { + issuer "the requester's subject name" + serialNumber "the transaction id associated + with the enrollment" + } + digestAlgorithm {iso(0) member-body(2) US(840) rsadsi(113549) + digestAlgorithm(2) 5} + authenticateAttributes { + contentType {{pkcs-9 3} {pkcs-7 1}} + messageDigest {{pkcs-9 4} "an octet string"} + transaction-id {{id-attributes transId(7)} "printable + string"} + -- this transaction id will be used + -- together with the subject name as + -- the identifier of the requester's key + -- pair during enrollment + messageType {{id-attributes messageType(2)} "PKCSReq"} + senderNonce {{id-attributes senderNonce(5)} + "a random number encoded as a string"} + } + digestEncryptionAlgorithm {pkcs-1 1} -- rsa encryption + encryptedDigest "encrypted digest of the authenticated + attributes using requester's private key" + } + } + pkcsReq PKIMessage ::= { + contentType {pkcs-7 2} + content pkcsCertRepSigned + } + + + + + + + + + Liu/Madson/McGrew/Nourse [Page 20] + +Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005 + +5.1.2 CertRep Message Format + +The response to an SCEP enrollment request is a CertRep message. + +5.1.2.1 PENDING Response + +When the CA is configured to manually authenticate the requester, +the CertRep is returned with the attribute pkiStatus set to PENDING. +The data portion for this message is null. Only the transaction +required attributes are sent back. + +CertRepSigned SignedData ::= { -- PKCS#7 + version 1 + digestAlgorithm {iso(1) member-body(2) US(840) rsadsi(113549) + digestAlgorithm(2) 5} + contentInfo {contentType {pkcs-7 1} -- empty content + } + signerInfo { + version 1 + issuerAndSerialNumber { + issuer "name of CA that issued the CA [RA] cert" + serialNumber "the serial number of the CA [RA] cert" + } + digestAlgorithm (iso(1) member-body(2) US(840) rsadsi(113549) + digestAlgorithm(2) 5} + authenticateAttributes { + contentType {{pkcs-9 3} {pkcs-7 1}} + messageDigest {{pkcs-9 4} NULL} + messageType {{id-attribute messageType(0)} "CertRep"} + transaction-id {{id-attributes transid(7)} "printablestring"} + --- same transaction id used in PKCSReq + pkiStatus {{id-attributes pkiStatus(3)} "PENDING"} + recipientNonce {{id-attributes recipientNonce(6)}<16 bytes>} + senderNonce {{id-attributes senderNonce(5)} <16 bytes>} + } + digestEncrytionAlgorithm {pkcs-1 1} + encryptedDigest "encrypted message digest of the authenticated + attributes using the CA's [RA's] private key" + } +} +CertRep PKIMessage ::= { + contentType {pkcs-7 2} + content CertRepSigned +} + +5.1.2.2 Failure Response + +In this case, the CertRep sent back to the requester is same as in +the PENDING case, except that the pkiStatus attribute is set to FAILURE, +and the failInfo attribute should be included: + + pkistatus {{id-attributes pkiStatus(3)} "FAILURE"} + failInfo {{id-attributes failInfo(4)} "the reason to reject"} + + Liu/Madson/McGrew/Nourse [Page 21] + +Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005 + +5.1.2.3 SUCCESS response + +In this case, the information portion of CertRep will be a degenerated +PKCS#7 which contains the requester's certificate. It is then enveloped +and signed as below: + +pkcsCertRep SignedData ::= { -- PKCS#7 + version 1 + digestAlgorithm {iso(1) member-body(2) US(840) rsadsi(113549) + digestAlgorithm(2) 5} + contentInfo { -- empty content since this is degenerated PKCS#7 + contentType {pkcs-7 1} + } + certificates { + certificate { -- issued requester's certificate // must be first + version 3 + serialNumber "issued requester's certificate serial number" + signature {pkcs-1 4} -- md5WithRSAEncryption + issuer "the certificate authority issuer name" + validity { + notBefore "UTC time" + notAfter "UTC time" + } + subject "the requester subject name as given in PKCS#10" + subjectPublicKeyInfo { + algorithm {pkcs-1 1} + subjectPublicKey "a DER encoding of requester public + key as given in PKCS#10" + } + extensions " the extensions as given in PKCS#10" + signatureAlgorithm {pkcs-1 4} + signature " the certificate authority signature" + } + certificate "the certificate authority certificate" (optional) + certificate "the registration authority certificate(s)" (optional) + } +} +pkcsCertRepEnvelope EnvelopedData ::= { -- PKCS#7 + version 0 + recipientInfo { + version 0 + issuerAndSerialNumber { -- use issuer name and serial number as + -- conveyed in requester's self-signed + -- certificate, included in the PKCSReq + issuer "the requester's subject name" + serialNumber "the serial number defined by the requester in + its self-signed certificate" + } + keyEncryptionAlgorithm {pkcs-1 1} + encryptedKey "content-encrypt key encrypted by the requester's + public key which is same key as authenticated in + the requester's certificate" + } + + + Liu/Madson/McGrew/Nourse [Page 22] + +Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005 + + encryptedContentInfo { + contentType {pkcs-7 1} -- data content identifier + contentEncryptionAlgorithm "OID for DES encryption" + encryptedContent "encrypted pkcsCertRep using content encryption + key" + } +} +pkcsCertRepSigned SignedData ::= { -- PKCS#7 + version 1 + digestAlgorithm {iso(1) member-body(2) US(840) rsadsi(113549) + digestAlgorithm(2) 5} + contentInfo { + contentType {pkcs-7 1} + content pkcsCertRepEnvelope + } + signerInfo { + version 1 + issuerAndSerialNumber { + issuer "the certificate authority issuer name" + serialNumber "the CA certificate's serial number" + } + digestAlgorithm {iso(1), member-body(2) US(840) rsadsi(113549) + digestAlgorithm(2) 5} + authenticateAttributes { + contentType {{pkcs-9 3} {pkcs-7 1}} + messageDigest {{pkcs-9 4} "a octet string"} + messageType {{id-attribute messageType(2)} "CertRep"} + transaction-id {{id-attributes transId(7)} "printable + string"} + -- same transaction id as given in PKCSReq + pkiStatus {{id-attributes pkiStatus(3) "SUCCESS"} + recipientNonce {{id-attribute recipientNonce(6)}<16 bytes>} + senderNonce {{ id-attributes senderNonce(5) <16 bytes>} + } + digestEncryptionAlgorithm {pkcs-1 1} + encryptedDigest "encrypted digest of authenticate attributes + using CA's private key " + } +} +CertRep PKIMessage ::= { + contentType {pkcs-7 2} + content pkcsCertRepSigned +} + +5.2 Poll for Requester Initial Certificate + +Either triggered by the PENDING status received from the CertRep, or by +the non-response timeout for the previous PKCSReq, a requester will +enter the polling state by periodically sending GetCertInitial to the +server, until either the request is granted and the certificate is sent +back, or the request is rejected, or the configured time limit for +polling is exceeded. + + + Liu/Madson/McGrew/Nourse [Page 23] + +Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005 + + +Since GetCertInitial is part of the enrollment, the messages exchanged +during the polling period should carry the same transaction identifier +as the previous PKCSReq. + +PreCondition + Either the requester has received a CertRep with pkiStatus set to be + PENDING, or the previous PKCSReq has timed out. + +PostContition + The requester has either received the certificate, or be rejected of + its request, or the polling period ended as a failure. + +5.2.1 GetCertInitial Message Format + +Since at this time the certificate has not been issued, the requester +can only use the requester's subject name, combined with the +transaction identifier, to identify the polled certificate request. + +The certificate authority server must be able to uniquely identify the +polled certificate request. A subject name can have more than one +outstanding certificate request (with different key usage attributes). + +-- Information portion + +pkcsGetCertInitial issuerAndSubject ::= { + issuer "the certificate authority issuer name" + subject "the requester subject name as given in PKCS#10" +} +pkcsGetCertInitialEnvelope EnvelopedData ::= { + version 0 + recipientInfo { + version 0 + issuerAndSerialNumber { + issuer "the CA issuer name" + serialNumber "the CA certificate serial number" + } + keyEncryptionAlgorithm {pkcs-1 1} + encryptedKey "content-encrypt key encrypted by CA's public key" + } + encryptedContentInfo { + contentType {pkcs-7 1} -- data content + contentEncryptionAlgorithm "OID for DES encryption" + encryptedContent "encrypted getCertInital" + } +} +pkcsGetCertInitialSigned SignedData ::= { -- PKCS#7 + version 1 + digestAlgorithm {iso(1) member-body(2) US(840) rsadsi(113549) + digestAlgorithm(2) 5} + contentInfo { + contentType {pkcs-7 1} + + + Liu/Madson/McGrew/Nourse [Page 24] + +Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005 + + content pkcsGetCertIntialEnvelope + } + certificate { -- the requester's self-signed certificate + version 3 + serialNumber "the transaction id associated with enrollment" + signature {pkcs-1 4} -- md5WithRSAEncryption + issuer " the requester's subject name" + validity { + notBefore "a UTC time" + notAfter "a UTC time" + } + subject "the requester's subject name" + subjectPublicKeyInfo { + algorithm {pkcs-1 1} + subjectPublicKey "DER encoding of requester's public key" + } + signatureAlgorithm {pkcs-1 4} + signature "the signature generated by using the requester's + private key corresponding to the public key in + this certificate." + } + signerInfo { + version 1 + issuerAndSerialNumber { + issuer "requester's subject name" + serialNumber "the transaction id used in previous PKCSReq" + } + digestAlgorithm {iso(1), member-body(2) US(840) rsadsi(113549) + digestAlgorithm(2) 5} + authenticateAttributes { + contentType {{pkcs-9 3} {pkcs-7 1}} + messageDigest {{pkcs-9 4} "an octet string"} + -- digest of getCertInitial + messageType {{id-attribute messageType(2)} "GetCertInitial"} + transaction-id {{id-attributes transId(7)} "printable + string"} + -- same transaction idused in previous PKCSReq + senderNonce {{id-attribute senderNonce(3)} 0x<16 bytes>} + } + digestEncryptionAlgorithm {pkcs-1 1} + encryptedDigest "encrypted digest of authenticateAttributes" + } +} +GetCertInitial PKIMessage ::= { + contentType {pkcs-7 2} + content pkcsGetCertInitialSigned +} + + + +5.2.2 GetCertInitial Response Message Format + +The response messages for GetCertInitial are the same as for PKCSReq. + + Liu/Madson/McGrew/Nourse [Page 25] + +Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005 + +5.3 Certificate Access + +The certificate query message defined in this section is an option when +the LDAP server is not available to provide the certificate query. A +requester should be able to query an issued certificate from the +certificate authority, as long as the issuer name and the issuer +assigned certificate serial number is known to the requesting end +entity. This transaction is not intended to provide the service as a +certificate directory service. A more complicated query mechanism would +have to be defined in order to allow a requester to query a certificate +using various different fields. + +This transaction consists of one GetCert message sent to the server by +a requester, and one CertRep message sent back from the server. + +PreCondition + The queried certificate have been issued by the certificate authority + and the issuer assigned serial number is known. + +PostCondition + Either the certificate is sent back or the request is rejected. + + +5.3.1 GetCert Message Format + +The queried certificate is identified by its issuer name and the issuer +assigned serial number. If this is a query for an arbitrary requester's +certificate, the requesting requester should includes its own CA issued +certificate in the signed envelope. If this is a query for its own +certificate (assume the requester lost the issued certificate, or does +not have enough non-volatile memory to save the certificate), then the +self-signed certificate has to be included in the signed envelope. + + pkcsGetCert issuerAndSerialNumber ::= { + issuer "the certificate issuer name" + serialNumber "the certificate serial number" + } + pkcsGetCertEnvelope EnvelopedData ::= { + version 0 + recipientInfo { + version 0 + issuerAndSerialNumber { + issuer "the CA [RA] issuer name" + serialNumber "the CA [RA] certificate serial number" + } + keyEncryptionAlgorithm {pkcs-1 1} + encryptedKey "content-encrypt key encrypted + by CA [RA] public key" + } + + + + + + Liu/Madson/McGrew/Nourse [Page 26] + +Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005 + + + encryptedContentInfo { + contentType {pkcs-7 1} -- data content + contentEncryptionAlgorithm "OID for DES encryption" + encryptedContent "encrypted pkcsGetCert using the content + encryption key" + } + } + pkcsGetCertSigned SignedData ::= { + version 1 + digestAlgorithm {iso(1) member-body(2) US(840) rsadsi(113549) + digestAlgorithm(2) 5} + contentInfo { + contentType {pkcs-7 1} + content pkcsGetCertEnvelope + } + certificates { + certificate "CA issued certificate" + or "self-signed certificate" + } + signerInfo { + version 1 + issuerAndSerialNumber { + issuer "the requester's subject name" + serialNumber "requester's certificate serial number" + } + digestAlgorithm {iso(1), member-body(2) US(840) rsadsi(113549) + digestAlgorithm(2) 5} + authenticateAttributes { + contentType {{pkcs-9 3} {pkcs-7 1}} + messageDigest {{pkcs-9 4} "an octet string"} + -- digest of pkcsGetCertEnvelope + messageType {{id-attribute messageType(2)} "GetCert"} + transaction-id {{id-attributes transId(7)} "printable + string"} + senderNonce {{id-attribute senderNonce(3)} <16 bytes>} + } + digestEncryptionAlgorithm {pkcs-1 1} + encryptedDigest "encrypted digest of authenticateAttributes" + } + } + GetCert PKIMessage ::= { + contentType {pkcs-7 2} + content pkcsGetCertSigned + } + + + + + + + + + + Liu/Madson/McGrew/Nourse [Page 27] + +Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005 + + +5.3.2 CertRep Message Format + +In this case, the CertRep from the server is same as the CertRep for the +PKCSReq, except that the server will only either grant the request or +reject the request. Also, the recipientInfo should use the CA issuer +name and CA assigned serial number to identify the requester's key pair +since at this time, the requester has received its own certificate. + +5.4 CRL Access + +The CRL query message defined in this section is an option when the LDAP +server is not available to provide the CRL query. In the PKI protocol +proposed here, only the requester can initiate the transaction to +download CRL. A requester sends GetCRL request to the server and the +server sends back CertRep whose information portion is a degenerated +PKCS#7 which contains only the most recent CRL. The size of CRL included +in the CertRep should be determined by the implementation. + +PreCondition + The certificate authority certificate has been downloaded to the end + entity. + +PostCondition + CRL sent back to the requester. + +5.4.1 GetCRL Message format + +The CRL is identified by using both CA's issuer name and the CA +certificate's serial number: + + pkcsGetCRL issuerAndSerialNumber { + issuer "the certificate authority issuer name" + serialNumber "certificate authority certificate's serial number" + } + +When the CRLDistributionPoint is supported, the pkcsGetCRL is defined as +the following: + + pkcsGetCRL SEQUENCE { + crlIssuer issuerAndSerialNumber + distributionPoint CE-CRLDistPoints + } + +where CE-CRLDisPoints is defined in X.509, but must contain only one +CRL distribution point. + + + + + + + + + + + Liu/Madson/McGrew/Nourse [Page 28] + +Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005 + + pkcsGetCRLEnvelope EnvelopedData ::= { + version 0 + recipientInfo { + version 0 + issuerAndSerialNumber { + issuer "the certificate authority (or RA) issuer name" + serialNumber "the CA (RA) certificate's serial number" + } + keyEncryptionAlgorithm {pkcs-1 1} + encryptedKey "content-encrypt key encrypted by CA (RA) public key" + } + encryptedContentInfo { + contentType {pkcs-7 1} -- data content + contentEncryptionAlgorithm "OID for DES encryption" + encryptedContent "encrypted pkcsGetCRL" + } + } + pkcsGetCRLSigned SignedData ::= { + version 1 + digestAlgorithm {iso(1) member-body(2) US(840) rsadsi(113549) + digestAlgorithm(2) 5} + contentInfo { + contentType {pkcs-7 1} + content pkcsGetCRLEnvelope + } + certificates { + certificate "CA-issued or self-signed requester's certificate" + } + signerInfo { + version 1 + issuerAndSerialNumber { + issuer "the requester's issuer name" + serialNumber "the requester's certificate serial number" + } + digestAlgorithm {iso(1), member-body(2) US(840) rsadsi(113549) + digestAlgorithm(2) 5} + authenticateAttributes { + contentType {{pkcs-9 3} {pkcs-7 1}} + messageDigest {{pkcs-9 4} 0x<16/20 bytes>} + -- digest of pkcsGetCRLEnvelope + messageType {{id-attribute messageType(2)} "CertCRL"} + transaction-id {{id-attributes transId(7)} "printable + string"} + senderNonce {{id-attribute senderNonce(3)} <16 bytes>} + } + digestEncryptionAlgorithm {pkcs-1 1} + encryptedDigest "encrypted digest of authenticateAttributes" + } + } + GetCRL PKIMessage ::= { + contentType {pkcs-7 2} + content pkcsGetCRLSigned + } + + Liu/Madson/McGrew/Nourse [Page 29] + +Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005 + + +5.4.2 CertRep Message Format + +The CRL is sent back to the requester through CertRep message. The +information portion of this message is a degenerated PKCS#7 SignedData +which contains only a CRL. + + pkcsCertRep SignedData ::= { + version 1 + digestAlgorithm {iso(1) member-body(2) US(840) rsadsi(113549) + digestAlgorithm(2) 5} + contentInfo { + contentType {pkcs-7 1} + } + crl { + signature {pkcs-1 4} + issuer "the certificate authority issuer name" + lastUpdate "UTC time" + nextUpdate "UTC time" + revokedCertificate { + -- the first entry + userCertificate "certificate serial number" + revocationData "UTC time" + .... + -- last entry + userCertificate "certificate serial number" + revocationData "UTC time" + } + } + pkcsCertRepEnvelope EnvelopedData ::= { + version 0 + recipientInfo { + version 0 + issuerAndSerialNumber { + issuer "the requester's issuer name" + serialNumber "the requester certificate serial number" + } + keyEncryptionAlgorithm {pkcs-1 1} + encryptedKey "content-encrypt key encrypted by requester's + public key " + } + encryptedContentInfo { + contentType {pkcs-7 1} -- data content + contentEncryptionAlgorithm "OID for DES encryption" + encryptedContent "encrypted pkcsCertRep using requester's + public key" + } + } + + + + + + + Liu/Madson/McGrew/Nourse [Page 30] + +Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005 + + + pkcsCertRepSigned SignedData ::= { -- PKCS#7 + version 1 + digestAlgorithm {iso(1) member-body(2) US(840) rsadsi(113549) + digestAlgorithm(2) 5} + contentInfo { + contentType {pkcs-7 1} + content pkcsCertRepEnvelope + } + signerInfo { + version 1 + issuerAndSerialNumber { + issuer "the certificate authority issuer name" + serialNumber "the CA certificate's serial number" + } + digestAlgorithm {iso(1), member-body(2) US(840) rsadsi(113549) + digestAlgorithm(2) 5} + authenticateAttributes { + contentType {{pkcs-9 3} {pkcs-7 1}} + messageDigest {{pkcs-9 4} "an octet string"} + -- digest of pkcsCertRepEnvelope + messageType {{id-attribute messageType(2)} "CertRep"} + transaction-id {{id-attributes transId(7)} "printable + string"} + -- same transaction id as given in PKCSReq + pkiStatus {{id-attributes pkiStatus(3) "SUCCESS"} + recipientNonce{{id-attribute recipientNonce(6)}<16 bytes>} + senderNonce {{id-attribute senderNonce (5) 0x<16 bytes>} + } + digestEncryptionAlgorithm {pkcs-1 1} + encryptedDigest "encrypted digest of authenticatedAttributes + using CA private key" + } + } + + +NOTE:The PKCS#7 EncryptedContent is specified as an octet string, but +SCEP entities must also accept a sequence of octet strings as a valid +alternate encoding. + +This alternate encoding must be accepted wherever PKCS #7 Enveloped +Data is specified in this document. + + + + + + + + + + + + Liu/Madson/McGrew/Nourse [Page 31] + +Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005 + +5.5 Get Certificate Authority Certificate + +Before any transaction begins, end entities have to get the CA (and +possibly RA) certificate(s) first. Since the requester may have no CA +certificates or CA public keys at all, this message can not be +encrypted and the response must be authenticated by out-of-band means. +These certs are obtained by means of an HTTP GET message. To get the +CA certificate, the requester does a "HTTP GET" with a URL that +identifies a CGI script on the server and an optional CA issuer +identifier as the parameter to the CGI script. The response is either +a single X.509 CA certificate ("CA mode"), or a PKCS7 message +containing the CA certificate and RA certificates ("RA mode"). The +client can determine which mode the CA operates in by which response +it gets. Once the CA certificate is received by the requester, a +fingerprint is generated using either the SHA-1 or the MD5 hash +algorithm on the whole CA certificate. If the requester does not have +a certificate path to a trusted CA certificate, this fingerprint may +be used to verify the certificate, by some positive out-of-band means, +such as a phone call. + +5.5.1 GetCACert HTTP Message Format + "GET" CGI-PATH CGI-PROG "?operation=GetCACert" "&message=" CA-IDENT + where: + CGI-PATH defines the actual CGI path to invoke the CGI program + which parses the request. + CGI-PROG is set to be the string "pkiclient.exe" and this is + expected to be the program that the CA will use to handle the + SCEP transactions. + CA-IDENT is any string which is understood by the CA. + For example, it could be a domain name like ietf.org. + If a certificate authority has multiple CA certificates + this field can be used to distinguish which is required. + Otherwise it may be ignored. + +5.5.2 Response + +The response for GetCACert is different between the case where the CA +directly communicated with the requester during the enrollment, and the +case where a RA exists and the requester communicates with the RA +during the enrollment. + +5.5.2.1 CA Certificate Only Response + +A binary X.509 CA certificate is sent back as a MIME object with a +Content-Type of application/x-x509-ca-cert. + +5.5.2.2 CA and RA Certificates Response + +When an RA exists, both CA and RA certificates must be sent back in +the response to the GetCACert request. The RA certificate(s) must be +signed by the CA. A certificates-only PKCS#7 SignedData is used to +carry the certificates to the requester, with a Content-Type of +application/x-x509-ca-ra-cert. + + Liu/Madson/McGrew/Nourse [Page 32] + +5.5.3 Get Next Certificate Authority Certificate + +5.5.3.1 GetNextCACert HTTP Message Format + "GET" CGI-PATH CGI-PROG "?operation=GetNextCACert" "&message=" CA-IDENT + +The response to this message is a PKCS#7 certificates-only message containing +a CA certificate (and possibly RA certificates) to be used when the current CA +certificate expires, signed with the current CA cert (or RA certificate, if +the CA is in RA mode. Note that a PKCS#7 is returned even in CA mode. + +5.5.3.2 GetCACaps HTTP Message Format + "GET" CGI-PATH CGI-PROG "?operation=GetCACaps" "&message=" CA-IDENT + +This message requests capabilities from CA. The response is a list of +text capabilities, as defined in Appendix F. Support for this message +is optional, but if it is not supported, the client should assume that +none of the capabilities in Appendix F are supported. + +5.6 Get Certificate Authority Certificate Chain + +GetCACertChain provides a way to get the entire certificate chain. + +5.6.1 GetCACertChain HTTP Message Format + + "GET" CGI-SCRIPT "?" "operation=GetCACertChain" "&" "message" CA-IDENT + where CGI-SCRIPT and CA-IDENT are as described for GetCACert. + +5.6.2 Response + +The response for GetCACertChain is a certificates-only PKCS#7 SignedData +to carry the certificates to the requester, with a Content-Type of +application/x-x509-ca-ra-cert-chain. + +5.6.3 Backwards Compatability + +Versions of SCEP prior to revision 3 do not support GetCACertChain. +Certificate Authorities written to these prior versions will not be +able to process the message and may return an HTML error. + +To avoid this, clients should send the GetCACert message first. If the +returned certificate is self-signed or is signed by a Certificate +Authority that is trusted by the client, then it is not necessary to +send the GetCACertChain message and it should not be sent. + +If a Certificate Authority is configured with a certificate that is +not either self-signed or has a self-signed issuer, then it should +support this message. In other words, it should be supported if the +CA hierarchy is more than two-deep. + +An old CA in a two-deep hierarchy might still get this message from +a client if the client did not trust either that CA or its issuer. +In that event, the certificate cannot be trusted anyway. In any case +the CA must not crash or hang upon the receipt of the message and the +client must be able to handle whatever error is returned by the CA, +including an HTML error or an ungraceful disconnect. + + Liu/Madson/McGrew/Nourse [Page 33] + +Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005 + +The following is the ASN.1 definition of Cert-Only PKCS#7: + + certOnly SignedData ::= { + version 1 + digestAlgorithm {iso(1) member-body(2) US(840) rsadsi(113549) + digestAlgorithm(2) 5} + +contentInfo { + contentType {pkcs-7 1} -- data content identifier + content -- NULL + } + certificates -- the RA and CA certificates. + } + + CARACerts PKIMessage ::= { -- special pki message sent in the clear + contentType {pkcs-7 2} + content certOnly + } + + +6.0 Security Considerations + +This entire document is about security. Common security considerations +such as keeping private keys truly private and using adequate lengths +for symmetric and asymmetric keys must be followed in order to maintain +the security of this protocol. + + +7.0 Intellectual Property + +This protcol includes the optional use of Certificate Revocation List +Distribution Point (CRLDP) technology, which is a patented technology +of Entrust Technologies, Inc. (Method for Efficient Management of +Certificate Revocation Lists and Update Information (U.S. Patent +5,699,431)). Please contact Entrust Technologies, Inc. +(www.entrust.com) for more information on licensing CRLDP technology. + + +8.0 References + +[PKCS7] Kaliski, B., "PKCS #7: Cryptographic Message Syntax Version +1.5", RFC 2315, March 1998. + +[PKCS10] Kaliski, B., "PKCS #10: Certification Request Syntax Version +1.5", RFC 2314, March 1998. + +[RFC2459] Housley, R., ec. al., "Internet X.509 Public Key +Infrastructure Certificate and CRL Profile", RFC 2459, January 1999. + + + + + + + Liu/Madson/McGrew/Nourse [Page 34] + +Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005 + +Appendix A: Cisco Requester Subject Name Definition + +The ip address and the FQDN of a SCEP client should be included in the +V3 extension subjectAltName. When the subjectAltName extension attribute +is present, both the subjectAltName fields and the subjectName field could +have the IP address and the FQDN information. + +When the X.500 directory is used by the CA to define the name space, the +subject name defined above become a RDN which is part of DN binded to +the requester's public key in the certificate. + + +A sample of DN assigned by Entrust CA is given below (assume the same +ciscoRouterAlice is used as the requester defined subject name): + + OU = InteropTesting, O = Entrust Technologies, C = CA + RDN = {"alice.cisco.com", "172.21.114.67", "22334455"} + + + Liu/Madson/McGrew/Nourse [Page 35] + +Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005 + +Appendix B: IPSEC Client Enrollment Certificate Request + +The following is the certificate enrollment request (PKCS#10) as created +by Cisco VPN Client: + +-----END NEW CERTIFICATE REQUEST----- + 0 30 439: SEQUENCE { + 4 30 288: SEQUENCE { + 8 02 1: INTEGER 0 + 11 30 57: SEQUENCE { + 13 31 55: SET { + 15 30 53: SEQUENCE { + 17 06 3: OBJECT IDENTIFIER commonName (2 5 4 3) + 22 13 46: PrintableString + : 'For Xiaoyi, IPSEC attrs in alternate name + extn' + : } + : } + : } + 70 30 158: SEQUENCE { + 73 30 13: SEQUENCE { + 75 06 9: OBJECT IDENTIFIER rsaEncryption (1 2 840 113549 1 + 1 1) + 86 05 0: NULL + : } + 88 03 140: BIT STRING 0 unused bits + : 30 81 88 02 81 80 73 DB 1D D5 65 AA EF C7 D4 8E + : AA 6E EB 46 AC 91 2A 0F 50 51 17 AD 50 A2 2A F2 + : CE BE F1 E4 22 8C D7 61 A1 6C 87 61 62 92 CB A6 + : 80 EA B4 0F 09 9D 18 5F 39 A3 02 0E DB 38 4C E4 + : 8A 63 2E 72 8B DC BE 9E ED 6C 1A 47 DE 13 1B 0F + : 83 29 4D 3E 08 86 FF 08 2B 43 09 EF 67 A7 6B EA + : 77 62 30 35 4D A9 0F 0F DF CC 44 F5 4D 2C 2E 19 + : E8 63 94 AC 84 A4 D0 01 E1 E3 97 16 CD 86 64 18 + : [ Another 11 bytes skipped ] + : } + 231 A0 63: [0] { + 233 30 61: SEQUENCE { + 235 06 9: OBJECT IDENTIFIER extensionReq (1 2 840 113549 1 9 + 14) + 246 31 48: SET { + 248 30 46: SEQUENCE { + 250 30 44: SEQUENCE { + 252 06 3: OBJECT IDENTIFIER subjectAltName (2 5 29 17) + 257 04 37: OCTET STRING + 30 23 87 04 01 02 03 04 81 0D 65 6D 61 69 + + + Liu/Madson/McGrew/Nourse [Page 36] + +Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005 + + 6C 40 69 72 65 2E 63 6F 6D 82 0C 66 71 64 + 6E 2E 69 72 65 2E 63 6F 6D + : } + : } + : } + : } + : } + : } + + 296 30 13: SEQUENCE { + 298 06 9: OBJECT IDENTIFIER md5withRSAEncryption (1 2 840 113549 + 1 1 4) + 309 05 0: NULL + : } + 311 03 129: BIT STRING 0 unused bits + : 19 60 55 45 7F 72 FD 4E E5 3F D2 66 B0 77 13 9A + : 87 86 75 6A E1 36 C6 B6 21 71 68 BD 96 F0 B4 60 + : 95 8F 12 F1 65 33 16 FD 46 8A 63 19 90 40 B4 B7 + : 2C B5 AC 63 17 50 28 F0 CD A4 F0 00 4E D2 DE 6D + : C3 4F F5 CB 03 4D C8 D8 31 5A 7C 01 47 D2 2B 91 + : B5 48 55 C8 A7 0B DD 45 D3 4A 8D 94 04 3A 6C B0 + : A7 1D 64 74 AB 8A F7 FF 82 C7 22 0A 2A 95 FB 24 + : 88 AA B6 27 83 C1 EC 5E A0 BA 0C BA 2E 6D 50 C7 + : } + + +Appendix C: Private OID Definitions + +The OIDs used in defining pkiStatus are VeriSign self-maintained +OIDs. Please note, work is in progress to replace the VeriSign owned +object identifiers with the standard object identifiers. Once the +standarlization is completed, this documentation will be updated. + +id-VeriSign OBJECT_IDENTIFIER ::= {2 16 US(840) 1 VeriSign(113733)} +id-pki OBJECT_IDENTIFIER ::= {id-VeriSign pki(1)} +id-attributes OBJECT_IDENTIFIER ::= {id-pki attributes(9)} +id-messageType OBJECT_IDENTIFIER ::= {id-attributes messageType(2)} +id-pkiStatus OBJECT_IDENTIFIER ::= {id-attributes pkiStatus(3)} +id-failInfo OBJECT_IDENTIFIER ::= {id-attributes failInfo(4)} +id-senderNonce OBJECT_IDENTIFIER ::= {id-attributes senderNonce(5)} +id-recipientNonce OBJECT_IDENTIFIER ::= {id-attributes recipientNonce(6)} +id-transId OBJECT_IDENTIFIER ::= {id-attributes transId(7)} +id-extensionReq OBJECT_IDENTIFIER ::= {id-attributes extensionReq(8)} + + + Liu/Madson/McGrew/Nourse [Page 37] + +Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005 + + Appendix D: CRL Query by means of LDAP + + In order to retrieve the CRL by means of LDAP, the client needs to know + where in the directory it is stored. The certificate must contain a + CRL Distribution Point extension encoded as a DN or as an LDAP URI. + +For example, the certificate issued by Entrust VPN contains +the following DN as the CRL distribution point: + + + +CN = CRL1, O = cisco, C = US. + + The asn.1 encoding of this distribution point is: + + 30 2C 31 0B 30 09 06 03 55 04 06 13 02 55 53 31 0E 30 0C 06 + 03 55 04 0A 13 05 63 69 73 63 6F 31 0D 30 0B 06 03 55 04 03 + 13 04 43 52 4C 31 + + +The ldap form would be: + +ldap://servername/CN=CRL1,O=cisco,C=US + + + +Appendix E: SCEP State Transitions + +SCEP state transitions are based on transaction identifier. The design +goal is to ensure the synchronization between the CA and the requester +under various error situations. + + +An identity is defined by the combination of FQDN, the IP address and +the client serial number. FQDN is the required name attribute. It is +important to notice that, a client named as Alice.cisco.com is different +from the client named as Alice.cisco.com plus IPAddress 117.96.1.219. + +Each enrollment transaction is uniquely associated with a transaction +identifier. Because the enrollment transaction could be interrupted by +various errors, including network connection errors or client reboot, +the SCEP client generates a transaction identifier by calculating a +hash on the public key value for which the enrollment is requested. This +retains the same transaction identifier throughout the enrollment +transaction, even if the client has rebooted or timed out, and issues a +new enrollment request for the same key pair. It also provides the way +for the CA to uniquely identify a transaction in its database. At the +requester side, it generates a transaction identifier which is included +in PKCSReq. If the CA returns a response of PENDING, the requester +will poll by periodically sending out GetCertInitial with the same +transaction identifier until either a response other than PENDING is +obtained, or the configured maximum time has elapsed. + +If the client times out or the client reboots, the client administrator +will start another enrollment transaction with the same key pair. The +second enrollment will have the transaction idenifier. At the server +side, instead of accepting the PKCSReq as a new enrollment request, it +should respond as if another GetCertInitial message had been sent with +that transaction ID. In another word, the second PKCSReq should be +taken as a resynchronization message to allow the enrollment resume as +the same transaction. + +It is important to keep the transaction id unique since SCEP requires the +same policy and same identity be applied to the same subject name and + + + Liu/Madson/McGrew/Nourse [Page 38] + +Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005 + +key pair binding. In the current implementation, an SCEP client can +only assume one identity. At any time, only one key pair, with a given +key usage, can be associated with the same identity. + +The following gives several examples of client to CA transactions. + +Client actions are indicated in the left column, CA actions are +indicated in the right column. A blank action signifies that no message +was received. Note that these examples assume that the CA enforces the +certificate-name uniqueness property defined in Section 2.1.1.1. + +The first transaction, for example, would read like this: + "Client Sends PKCSReq message with transaction ID 1 to the + CA. The CA signs the certificate and constructs a CertRep Message + containing the signed certificate with a transaction ID 1. The client + receives the message and installs the cert locally." + +Successful Enrollment Case: no manual authentication +PKCSReq (1) ----------> CA Signs Cert +Client Installs Cert <---------- CertRep (1) SIGNED CERT + + + +Successful Enrollment Case: manual authentication required +PKCSReq (10) ----------> Cert Request goes into Queue +Client Polls <---------- CertRep (10) PENDING +GetCertInitial (10) ----------> Still pending +Client Polls <---------- CertRep (10) PENDING +GetCertInitial (10) ----------> Still pending +Client Polls <---------- CertRep (10) PENDING +GetCertInitial (10) ----------> Still pending +Client Polls <---------- CertRep (10) PENDING +GetCertInitial (10) ----------> Cert has been signed +Client Installs Cert <---------- CertRep (10) SIGNED CERT + + + +Resync Case - CA Receive and Signs PKCSReq, Client Did not receive +CertRep: + +PKCSReq (3) ----------> Cert Request goes into queue + <---------- CertRep (3) PENDING +GetCertInitial (3) ----------> + <---------- CertRep (3) PENDING +GetCertInitial (3) -----------> + <----------- CA signed Cert and sent back + CertRep(3) +(Time Out) +PKCSReq (3) ----------> Cert already signed, sent back to + client +Client Installs Cert <---------- CertRep (3) SIGNED CERT + + + + Liu/Madson/McGrew/Nourse [Page 39] + +Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005 + + +Case when NVRAM is lost and client has to generate a new key pair, there +is no change of name information: + +PKCSReq (4) ----------> CA Signs Cert +Client Installs Cert <---------- CertRep (4) SIGNED CERT +(Client looses Cert) +PKCSReq (5) ----------> There is already a valid cert with + this DN. +Client Admin Revokes <---------- CertRep (5) OVERLAPPING CERT ERROR +PKCSReq (5) ----------> CA Signs Cert +Client Installs Cert <---------- CertRep (5) SIGNED CERT + + +Case when client admin resync the enrollment using a different PKCS#10: +PKCSReq (6) ----------> CA Signs Cert + <---------- CertRep (6) SIGNED CERT +(Client timeout and admin starts another enrollment with a different + PKCS#10, but the same transaction id) +PKCSReq (6) with different PKCS#10 + ----------> There is already a valid cert with + this entity (by checking FQDN). + <---------- CertRep (6) INVALID PKCS#10 CERT + ERROR +Client admin either revokes the existing cert +or corrects the error by enrolling with +the same PKCS#10 as the first PKCSReq(6) +PKCSReq (6) ----------> CA find the existing Cert +Client Installs Cert <---------- CertRep (6) SIGNED CERT + + +Resync case when server is slow in response: +PKCSReq (13) ----------> Cert Request goes into Queue + <---------- CertRep (13) PENDING +GetCertInitial ----------> Still pending + <---------- CertRep (13) PENDING +GetCertInitial ----------> Still pending + <---------- CertRep (13) PENDING +GetCertInitial ----------> Still pending + <---------- CertRep (13) PENDING +GetCertInitial ----------> Still pending +(TimeOut) <---------- CertRep (13) PENDING +* Case 1 +PKCSReq (13) ----------> Still pending +Client polls <---------- CertRep (13) PENDING +CertCertInitial ----------> Cert has been signed +Client Installs Cert <---------- CertRep (13) SIGNED CERT +* Case 2 +PKCSReq (13) ----------> Cert has been signed +Client Installs Cert <---------- CertRep (13) SIGNED CERT + + + + + Liu/Madson/McGrew/Nourse [Page 40] + +Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005 + +Appendix F. CA Capabilities + +The response for a GetCACaps message is a list of CA capabilities, in +plain text, separated by characters, as follows (quotation marks +are NOT sent): + +Keyword Description + +"GetNextCACert" CA Supports the GetNextCACert message. +"POSTPKIOperation" PKIOPeration messages may be sent via HTTP POST. +"SHA-1" CA Supports the SHA-1 hashing algorithm in + signatures and fingerprints. If present, the + client SHOULD use SHA-1. If absent, the client + MUST use MD5 to maintain backward compatability. +"Renewal" Clients may use current certificate and key to + authenticate an enrollment request for a new + certificate. + +A client must be able to accept and ignore any unknown keywords that +might be sent back by a CA that implements a future version of SCEP. + +Example: + +GET /cgi-bin/pkiclient.exe?operation=GetCACaps&message=myca + +returns: + +GetNextCACert +POSTPKIOperation + +This means that the CA supports the GetNextCACert message and allows +PKIOperation messages (PKCSreq, GetCert, GetCertInitial...) to be sent +using HTTP POST. + + + Liu/Madson/McGrew/Nourse [Page 41] + +Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005 + +Appendix G. Certificate Renewal and CA Key Rollover + +To renew a client certificate, use the PKCSreq message and sign it with +the existing client certificate instead of a self-signed certificate. + +To obtain the new CA certificate prior to the expiration of the current +one, use the GetNextCACert message if the CA supports it. + +To obtain a new client certificate signed by the new CA certificate, +use the new CA or RA certificate in the message envelope. + + +Example: + +GetNextCACert ----------> + <---------- CertRep (3) New CA certificate + +PKCSReq* (1) ----------> CA Signs certificate with NEW key +Client Stores Cert <---------- CertRep (3) Certificate issued +for installation when from NEW CA certificate and keypair. +existing cert expires. + + +*enveloped for new CA or RA cert and keypair. The CA will use the +envelope to determine which key and certificate to use to issue the +client certificate. + + + Liu/Madson/McGrew/Nourse [Page 42] + +Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005 + +Appendix H. PKIOperation via HTTP POST Message + +If the remote CA supports it, any of the PKCS#7-encoded SCEP messages +may be sent via HTTP POST instead of HTTP GET. This is allowed for +any SCEP message except GetCACert, GetCACertChain, GetNextCACert, +or GetCACaps. In this form of the message, Base 64 encoding is not +used. + +POST /cgi-bin/pkiclient.exe?operation=PKIOperation + + +The client can verify that the CA supports SCEP messages via POST by +looking for the "POSTPKIOperation" capability (See Appendix F). + + + + + + + Liu/Madson/McGrew/Nourse [Page 43] + +Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005 + +Appendix Y. Author Contact Information + +Xiaoyi Liu Cheryl Madson +Cisco Cisco +510 McCarthy Drive 510 McCarthy Drive +Milpitas, CA Milpitas, CA. +xliu@cisco.com cmadson@cisco.com + + +David McGrew Andrew Nourse +Cisco Cisco +170 West Tasman Drive 510 McCarthy Drive +San Jose, CA 94134 Milpitas, CA. +mcgrew@cisco.com nourse@cisco.com + + + + +Appendix Z. Copyright Section + +Copyright (C) The Internet Society (2005). This document is subject +to the rights, licenses and restrictions contained in BCP 78, and +except as set forth therein, the authors retain all their rights. + +This document and the information contained herein are provided on an +"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS +OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET +ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, +INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE +INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED +WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + + + +This draft expires 11 Aug 2005 + +[End of draft-nourse-scep-11.txt] + + +INTERNET DRAFT Xiaoyi Liu +draft-nourse-scep-11.txt Cheryl Madson +expires 11 Aug 2005 David McGrew +(revised 11 Feb 2005) Andrew Nourse + Cisco Systems + +Category: Informational 11 Feb 2005 + + +Cisco Systems' Simple Certificate Enrollment Protocol(SCEP): + +Status of this Memo + +This document is an Internet-Draft and is NOT offered in accordance +with Section 10 of RFC2026, and the author does not provide the IETF +with any rights other than to publish as an Internet-Draft + +Internet-Drafts are working documents of the Internet Engineering Task +Force (IETF), its areas, and its working groups. Note that other +groups may also distribute working documents as Internet-Drafts. + +Internet-Drafts are draft documents valid for a maximum of six months +and may be updated, replaced, or obsoleted by other documents at any +time. It is inappropriate to use Internet- Drafts as reference +material or to cite them other than as "work in progress." + +The list of current Internet-Drafts can be accessed at +http://www.ietf.org/ietf/1id-abstracts.txt + +The list of Internet-Draft Shadow Directories can be accessed at +http://www.ietf.org/shadow.html. + +This memo provides information for the Internet community. This memo +does not specify an Internet standard of any kind. Distribution of +this memo is unlimited. + +By submitting this Internet-Draft, I certify that any applicable patent +or other IPR claims of which I am aware have been disclosed, or will be +disclosed, and any of which I become aware will be disclosed, in accordance +with RFC 3668. + +Abstract + +This document specifies the Simple Certificate Enrollment Protocol, +a PKI communication protocol which leverages existing technology by +using PKCS#7 and PKCS#10. SCEP is the evolution of the enrollment +protocol developed by Verisign, Inc. for Cisco Systems, Inc. +It now enjoys wide support in both client and CA implementations. + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 2 + 2. The Goal of SCEP . . . . . . . . . . . . . . . . . . . . . 3 + 2.1 SCEP Entity types . . . . . . . . . . . . . . . . . . . . 3 + 2.2 SCEP Operations Overview . . . . . . . . . . . . . . . . . 7 + 2.3 PKI Operation Transactional Behavior . . . . . . . . . . . 10 + 2.4 Security . . . . . . . . . . . . . . . . . . . . . . . . . 12 + 3. Transport Protocol . . . . . . . . . . . . . . . . . . . . 13 + 4. Secure Transportation: PKCS #7 . . . . . . . . . . . . . . 14 + 4.1 SCEP Message Format . . . . . . . . . . . . . . . . . . . 14 + + Liu/Madson/McGrew/Nourse [Page 2] + +Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005 + + 4.2 Signed Transaction Attributes . . . . . . . . . . . . . . 15 + 5. SCEP Transaction Specification . . . . . . . . . . . . . . 16 + 5.1 Certificate Enrollment . . . . . . . . . . . . . . . . . . 16 + 5.2 Poll for Requester Initial Certificate . . . . . . . . . . 22 + 5.3 Certificate Access . . . . . . . . . . . . . . . . . . . . 26 + 5.4 CRL Access . . . . . . . . . . . . . . . . . . . . . . . 27 + 5.5 Get Certificate Authority Certificate . . . . . . . . . . 31 + 5.6 Get Certificate Authority Certificate Chain . . . . . . . 33 + 6. Security Considerations . . . . . . . . . . . . . . . . . 33 + 7. Intellectual Propoerty . . . . . . . . . . . . . . . . . . 33 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . 33 + Appendix A. Cisco Requester Subject Name Definition . . . . . . 34 + Appendix B. IPSEC Client Enrollment Certificate Request . . . . 35 + Appendix C. Private OID Definitions . . . . . . . . . . . . . 36 + Appendix D. Obtaining CRL by LDAP Query . . . . . . . . . . . . 36 + Appendix E. SCEP State Transitions . . . . . . . . . . . . . . 37 + Appendix F. CA Capabilities . . . . . . . . . . . . . . . . . . 40 + Appendix G. Certificate Renewal and CA Key Rollover . . . . . . 41 + Appendix H. PKIOperation via HTTP POST Message. . . . . . . . . 42 + Appendix Y. Author Contact Information. . . . . . . . . . . . . 43 + Appendix Z. Copyright Section . . . . . . . . . . . . . . . . . 43 + +Section 1. Introduction + +Public key technology is becoming more widely deployed and is becoming +the basis for standards based security, such as the Internet Engineering +Task Force's IPSEC and IKE protocols. With the use of public key +certificates in network security protocols comes the need for a +certificate management protocol that Public Key Infrastructure (PKI) +clients and Certificate Authority servers can use to support certificate +life cycle operations such as certificate enrollment and revocation, and +certificate and CRL access. + +In the following, Section 2 gives an overview of the PKI operations, +and Section 2.4 describes the security goals of the protocol and the +mechanisms used to achieve them. The transport protocol and the +security protocol PKCS#7 are described at Section 3 and Section 4, +respectively. The last section, Section 5, specifies each PKI +operation in terms of the message formats and the data structures of +each operation. + +The appendices provide detailed specifications and examples. Requester +subject names are specified in Appendix A, attribute OIDs are +specified in Appendix C , and the SCEP state transitions are described +in Appendix E. An example of a certificate enrollment request is +provided in Appendix B, and an example LDAP query URL encoding is +provided in Appendix D. + +The authors would like to thank Peter William of ValiCert, Inc. +(formerly of Verisign, Inc) and Alex Deacon of Verisign, Inc. and +Christopher Welles of IRE, Inc. for their contributions to this protocol +and to this document. + + Liu/Madson/McGrew/Nourse [Page 3] + +Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005 + +2.0 The Goal of SCEP +The goal of SCEP is to support the secure issuance of certificates to +network devices in a scalable manner, using existing technology whenever +possible. The protocol supports the following operations: + + CA and RA public key distribution + Certificate enrollment + Certificate revocation + Certificate query + CRL query + +Certificate and CRL access can be achieved by using the LDAP protocol +(as specified in Appendix D), or by using the query messages defined in +SCEP. The use of HTTP certificate and CRL access, and the support of +CDP as specified in RFC2459, will be specified in a future version of +this document. In Section 2.1, we first define PKI entity types as well +as the properties of each entity type. In Section 2.2, the PKI +operations are described at functional level. Section 2.3 describes the +transaction behavior of each PKI operations. The complete PKI messages +are covered in Section 5. + +2.1 SCEP Entity types + +The entity types defined in SCEP are the "requester" type (i.e., IPSEC +clients), the Certificate Authority (CA) entity type, and the +Registration Authority entity type (RA). A requester is sometimes +called a "SCEP client" in the following. + +2.1.1 Requesters + +A requester is an entity whose name is defined in a certificate +subject name field and optionally, in SubjectAltName, a X.509 +certificate V3 extension. As a requester, a SCEP client is identified +by a subject name consisting of the following naming attributes: + + Fully qualified domain name, for example, router.cisco.com + IP address, Serial number, and/or x.500 distinguished name + +The fully qualified domain name is required for a requester that intends +to use the certificate for ISAKMP. The IP address, serial number, and +x.500 distinguished name are optional name attributes. In the +certificate enrollment request, the PKCS#10 subject field contains the +required and optional name attributes. The distinguished name, if any, +should be the subject name field, while any domain name, serial number, +or IP address supplied should be in the subjectAltName field. The +subject name field may be empty (if there is no distinguished name) +or the subjectAltName may be omitted, but not both. + +It is important to note that a client named as Alice.cisco.com is +different than a client named as Alice.cisco.com plus the IP address +name attribute 117.96.1.219. From CA point of view, the Distinguished +names assigned in these two cases are distinct names. + + + Liu/Madson/McGrew/Nourse [Page 4] + +Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005 + +Entity names which are specified as in the IPSEC profile (i.e., FQDN, IP +address and User FQDN) must be presented in certificate's SubjectAltName +extension. Multiple IPSEC entity names, (if any) are encoded as multiple +values of a single SubjectAltName extension. The CA has the authority +to assign a distinguished name to a requester, whether or not one was +included in the request. The assigned DN should contain the SCEP client +names as the relative DN. + +The attribute identifiers and an example of SCEP client subject name are +specified in Appendix A. Appendix B has an example from Cisco VPN Client +enrollment request. + +2.1.1.1 Local Key/Certificate/CRL Storage and Certificate-name uniqueness + +A requester is required to generate asymmetric key pairs and to provide +storage to store its private keys. If the requester does not have enough +permanent memory to save its certificate, then it should be able to query +its own certificate from the CA or an LDAP server, once the certificate +has been issued. The public key pairs can be generated with a specific +key usage. The key usage is conveyed to the CA through the certificate +enrollment request. All current SCEP client implementations expect that +there will be only one pair of keys for a given subject name +and key usage combination and CA, at any time. This property is called +the certificate-name uniqueness property, and it implies that a CA that +implements SCEP will enforce the unique mapping between a SCEP client +subject name and its key pairs with a given key usage. At any time, if +the subject name is changed, or if the key is updated, the existing +certificate would have to be revoked before a new one could be issued. + +It is desirable that the CA enforce certificate-name uniqueness, but +it is not mandatory. However a CA that does not enforce uniqueness +must provide some other mechanism to prevent the re-transmission of an +enrollment request by a SCEP client from creating a second certificate +or certificate request, nor can the second request merely be rejected. +If a client times out from polling for a pending request it can +resynchronize by reissuing the original request with the original +subject name, key, and transaction ID. This should return the status of +the original transaction, including the certificate if it was granted. +It should not create a new transaction unless the original cert has been +revoked, or the transaction arrives more than halfway through the +validity time of the original certificate. + +An enrollment request that occurs more than halfway through the validity +time of an existing certificate for the same subject name and key usage +MAY be interpreted as a re-enrollment or renewal request and accepted. +A new certificate with new validity dates may be issued, even though +the old one is still valid, if the CA policy permits, as described in +2.1.1.3. See also appendix G. + +2.1.1.2 Requester 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 + Liu/Madson/McGrew/Nourse [Page 5] + +Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005 + +cryptographically secure manner. This requirement is needed to +prevent a "man in the middle" attack, in which an adversary that can +manipulate the data as it travels between the protocol participants +can subvert the security of the protocol. To satisfy this +requirement, SCEP provides two authentication methods: manual +authentication, and authentication based on pre-shared secret. In the +manual mode, the requester is required to wait until its identity can +be verified by the CA operator using any reliable out-of-band +method. To prevent a "man-in-the-middle" attack, a SHA-1 or MD5 +`fingerprint' generated on the PKCS#10 (before PKCS #7 enveloping and +signing) must be compared out-of-band between the server and the +requester. SCEP clients and CAs (or RAs, if appropriate) must display +this fingerprint to the operator to enable this verification if manual +mode is used. Failing to provide this information leaves the protocol +vulnerable to attack by sophisticated adversaries. When utilizing a +pre-shared secret scheme, the server should distribute a shared secret +to the requester which can uniquely associate the enrollment request +with the given end entity. The distribution of the secret must be +private: only the end entity should know this secret. The actual +binding mechanism between the requester and the secret is subject to +the server policy and implementation. When creating the enrollment +request, the requester is asked to provide a challenge password. When +using the pre-shared secret scheme, the requester must enter the +re-distributed secret as the password. In the manual authentication +case, the challenge password only used to authenticate a request for +the certificate's revokation. This challenge password is included as +a PKCS#10 attribute, and is sent to the server as encrypted data. The +PKCS#7 envelope protects the privacy of the challenge password with +DES encryption. + +2.1.1.3 Requester Uses Existing CA-Issued or Self-Signed Certificates + +In this protocol, the communication between the requester and the +certificate authority is secured by using PKCS#7 as the messaging +protocol. PKCS#7, however, is a protocol which assumes the +communicating entities already possess the peer's certificates and +requires both parties use the issuer names and issuer assigned +certificate serial numbers to identify the certificate in order to +verify the signature and decrypt the message. If the requesting +system already has a certificate issued by the CA, that certificate +may be presented as credentials for the renewal of that certificate if +the CA supports the "Renewal" capability and the CA policy permits the +certificate to be renewed. If the requester has no certificate issued +by the CA, or if the CA does not support and permit renewal, the +requestor must generate a self-signed certificate with the requester +subject name (the same name later used in the PKCS#10) as both issuer +and subject name. During the certificate enrollment, the requester +will first post itself as the signing authority by attaching the +self-signed certificate to the signed certificate request. When the +Certificate Authority makes the envelope on the issued certificate +using the public key included in the self-signed certificate, it +should use the same issuer name and serial number as conveyed in the +self-signed certificate to inform the end entity on which private key +should be used to open the envelope. + Liu/Madson/McGrew/Nourse [Page 6] + +Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005 + +Note that when a client enrolls for separate encryption and signature +certificates, it may use the signature certificate to sign both +requests, and then expect its signature key to be used to encrypt +both responses. In any case, the recipientinfo on the envelope should +reflect the key used to encrypt the request. + +2.1.1.4 Trusted CA Store + +To support interoperability between IPSEC peers whose certificates are +issued by different CA, SCEP allows the users to configure multiple +trusted certificates. Trusted certificates are have been configured as +such in the client, based on some out-of-band means such as a "fingerprint". +These trusted certificates are used to verify certificate chains that end +in those certificates. + +2.1.2 Certificate Authority + +A Certificate Authority(CA) is an entity whose name is defined in the +certificate issuer name field. Before any PKI operations can begin, +the CA generates its own public key pair and creates a self-signed CA +certificate, or causes another CA to issue a certificate to it. +Associated with the CA certificate is a fingerprint which will be used +by the requester to authenticate the received CA certificate if it is +self-signed. The fingerprint is created by calculating a SHA-1 or MD5 +hash on the whole CA certificate. Before any requester can start its +enrollment, this CA certificate has to be configured at the entity +side securely. For IPSEC clients, the client certificates must have +SubjectAltName extension. To utilize LDAP as a CRL query protocol, +the certificates must have a CRL Distribution Point. Key usage is +optional. Without key usage, the public key is assumed as a general +purpose public key and it can be used for all the purposes. + +A Certificate Authority may enforce certain name policy. When using +X.500 directory name as the subject name, all the name attributes +specified in the PKCS#10 request should be included as Relative DN. All +the name attributes as defined in RFC2459 should be specified in the +SubjectAltName. An example is provided in Appendix A. + + If there is no LDAP query protocol support, the Certificate Authority +should answer certificate and CRL queries, and to this end it should be +online all the time. + +The updating of the CA's public key is addressed in Appendix G. + +2.1.3 Registration Authorities + +In an environment where an RA is present, a requester performs +enrollment through the RA. In order to setup a secure channel with an RA +using PKCS#7, the RA certificate(s) have to be obtained by the client +in addition to the CA certificate(s). + +In the following, the CA and RA are specified as one entity in the +context of PKI operation definitions. + Liu/Madson/McGrew/Nourse [Page 7] +Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005 +2.2 SCEP Operations Overview + +In this section, we give a high level overview of the PKI operations as +defined in SCEP. + +2.2.1 Requester Initialization + +The requester initialization includes the key pair generation and the +configuring of the required information to communicate with the +certificate authority. + +2.2.1.1 Key Pairs + +Before a requester can start PKI transaction, it must have at least one +asymmetric key pair, using the selected algorithm (the RSA algorithm is +required in SCEP, and is the only algorithm in current implementations). + +Key pairs may be intended for particular purposes, such as encryption only, +or signing only. The usage of any associated certificate can be restricted +by adding key usage and extended key usage attributes to the PKCS#10. + +2.2.1.2 Required Information + +A requester is required to have the following information configured +before starting any PKI operations: + +1. the certificate authority IP address or fully-qualified domain name, +2. the certificate authority HTTP CGI script path, and + the HTTP proxy information in case there is no direct Internet + connection to the server, +3. If CRLs are being published by the CA to an LDAP directory server, + and there is a CRL Distribution Point containing only an X.500 directory + name, then the client will need to know the LDAP server fully-qualified + domain name or IP address. CRL Distribution Points are discussed in + more detail in RFC 2459. + + +2.2.2 CA/RA Certificate Distribution + +Before any PKI operation can be started, the requester needs to get +the CA/RA certificates. At this time, since no public key has been + + Liu/Madson/McGrew/Nourse [Page 8] + +Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005 + +exchanged between the requester and the CA/RA, the message to get the +CA/RA certificate can not be secured using PKCS#7 protocol. Instead, the +CA/RA certificate distribution is implemented as a clear HTTP Get +operation. After the requester gets the CA certificate, it has to +authenticate the CA certificate by comparing the finger print with the +CA/RA operator. Since the RA certificates are signed by the CA, there is +no need to authenticate the RA certificates. + +This operation is defined as a transaction consisting of one HTTP Get +message and one HTTP Response message: + + REQUESTER CA SERVER + Get CA/RA Cert: HTTP Get message + -----------------------------> + CA/RA Cert download: HTTP Response message + <--------------------------------------- + Compute finger print and + call CA operator. + Receive call and check finger print + +If an RA is in use, a degenerated PKCS#7 with a certificate chain +consisting of both RA and CA certificates is sent back to the end +entity. Otherwise the CA certificate is directly sent back as the +HTTP response payload. + + +2.2.3 Certificate Enrollment + +A requester starts an enrollment transaction by creating a certificate +request using PKCS#10 and sends it to the CA/RA enveloped using the +PKCS#7. After the CA/RA receives the request, it will either +automatically approve the request and send the certificate back, or it +will require the requester to wait until the operator can manually +authenticate the identity of the requester. Two attributes are +included in the PKCS#10 certificate request - a Challenge Password +attribute and an optional ExtensionReq attribute which will be a +sequence of extensions the requester would like to be included in its +V3 certificate extensions. The Challenge Password may be used to +authenticate either the enrollment request itself, or a verbal +revocation request for the issued certificate in the event of key +compromise or other reason. + +In the automatic mode, the transaction consists of one PKCSReq PKI +Message, and one CertRep PKI message. In the manual mode, the requester +enters into polling mode by periodically sending a GetCertInitial PKI +message to the server, until the server operator completes the manual +authentication, after which the CA will respond to GetCertInitial by +returning the issued certificate. A CA MAY run in automatic mode for +preapproved requests, and manual mode for the rest. A request with a +non-null password is not necessarily a pre-approved request. It is up +to the CA server to decide. Polling mode is entered whenever the +server returns a PENDING response. + + Liu/Madson/McGrew/Nourse [Page 9] +Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005 + + +The transaction in automatic mode: + + REQUESTER CA SERVER + +PKCSReq: PKI cert. enrollment msg + --------------------------------> CertRep: pkiStatus = SUCCESS + certificate attached + <------------------------------ + Receive issued certificate. + +The transaction in manual mode: + + REQUESTER CA SERVER + PKCSReq: PKI cert. enrollment msg + --------------------------------> CertRep: pkiStatus = PENDING + <------------------------------ + GetCertInitial: polling msg + --------------------------------> CertRep: pkiStatus = PENDING + <------------------------------ + ................. CertRep: pkiStatus = SUCCESS + certificate attached + <------------------------------ + Receive issued certificate. + +2.2.4 Requester Certificate Revocation + +A requester should be able to revoke its own certificate. Currently +the revocation is implemented as a manual process. In order to revoke a +certificate, the requester makes a phone call to the CA server +operator. The operator will come back asking the ChallengePassword +(which has been sent to the server as an attribute of the PKCS#10 +certificate request). If the ChallengePassword matches, the certificate +is revoked. The reason of the revocation is documented by CA/RA. + +2.2.5 Certificate Access + +There are two methods to query certificates. The first method is to use +LDAP as a query protocol. Using LDAP to query assumes the client +understand the LDAP scheme supported by the CA. The SCEP client assumes +that the subject DN name in the certificate is used as the URL to query the +certificate. The standard attributes (userCertificate and caCertificate) +are used as filter. + +For the environment where LDAP is not available, a certificate query +message is defined to retrieve the certificates from the CA. + +To query a certificate from the certificate authority, a requester +sends a request consisting of the certificate's issuer name and the +serial number. This assumes that the requester has saved the issuer + + Liu/Madson/McGrew/Nourse [Page 10] + +Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005 + +name and the serial number of the issued certificate from the previous +enrollment transaction. The transaction to query a certificate consists +of one GetCert PKI message and one CertRep PKI message: + + REQUESTER CA SERVER + GetCert: PKI cert query msg + -------------------------------> CertRep: pkiStatus = SUCCESS + certificate +attached + <----------------------------- + Receive the certificate. + +2.2.6 CRL Distribution + +The CA/RA will not "push" the CRL to the end entities. The query of the +CRL can only be initialized by the requester. + +There are three methods to query CRL. + +The CRL may be retrieved by a simple HTTP GET. If the CA supports this +method, it should encode the URL into a CRL Distribution Point extension +in the certificates it issues. Support for this method should be +incorporated in new and updated clients, but may not be in older +versions. + +The second method is to query CRL using LDAP. This assumes the CA server +supports CRL LDAP publishing and issues the CRL Distribution Point in +the certificate. The CRL Distribution Point is encoded as a DN. Please +refer to Appendix D for the examples of CRL Distribution Point. + +The third method is implemented for the CA which does not support LDAP +CRL publishing or does not implement the CRL Distribution Point. In this +case, a CRL query is composed by creating a message consists of the CA +issuer name and the CA's certificate serial number. This method is +deprecated because it does not scale well and requires the CA to be a +high-availability service. + +The message is sent to the CA in the same way as the other SCEP +requests: The transaction to query CRL consists of one GetCRL PKI +message and one CertRep PKI message which have no certificates but CRL. + + REQUESTER CA SERVER + GetCRL: PKI CRL query msg + ----------------------------------> CertRep: CRL attached + <-------------------------------- + +2.3 PKI Operation Transactional Behavior + +As described before, a PKI operation is a transaction consisting of the +messages exchanged between a requester and the CA/RA. This section +will specify the transaction behavior on both the requester and the + + + Liu/Madson/McGrew/Nourse [Page 11] + +Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005 + +certificate authority server. Because the protocol is basically a two +way communication protocol without a confirmation message from the +initiating side, state and state resynchronization rules have to be +defined, in case any error happens at either side. Before the state +transition can be defined, the notion of transaction identifier has to +be defined first. + +2.3.1 Transaction Identifier + +A transaction identifier is a string generated by the entity when +starting a transaction. Since all the PKI operations defined in this +protocol are initiated by the requester, it is the responsibility of +the requester to generate a unique string as the transaction +identifier. All the PKI messages exchanged for a given PKI transaction +must carry the same transaction identifier. The transaction identifier +is generated as a SHA-1 or MD5 hash on the public key value for which the +enrollment request is made. This allows the SCEP client to reuse the +same transaction identifier if it is reissuing a request for the same +certificate (i.e. a certificate with the same subject, issuer, and key). +The SCEP protocol requires that transaction identifiers be unique, so +that queries can be matched up with transactions. For this reason, in +those cases in which separate signing and encryption certificates are +issued to the same requester, the keys must be different. + +2.3.2 State Transitions in Certificate Enrollment + +The requester state transitions during enrollment operation are +indicated in the diagram below: + +-<------+ + | | + GetCertInitial triggered by timeout or + | | manual authentication + | | + [CERT-NONEXISTANT] ------> [CERT-REQ-PENDING] ---> [CERT-ISSUED] + | PKCSReq | CertRep with SUCCESS + | | + | | + +--------<-------------------+ + request rejected, timeout, or error + +As described in the section 2.2.3, certificate enrollment starts at the +state CERT-NONEXISTANT. Sending PKCSReq changes the state to +CERT-REQ-PENDING. Receiving CertRep with SUCCESS status changes the +state to CERT-ISSUED. In the case the server sending back the response +with pending status, the requester will keep polling certificate +response by sending GetCertInitial to the server, until either a CertRep +with SUCCESS status is received, or the maximum polling number has been +exceeded. + +If an error or timeout occurs in the CERT-REQ-PENDING state, the end +entity will transition to the CERT-NONEXISTANT state. + + + Liu/Madson/McGrew/Nourse [Page 12] + +Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005 + + +The client administrator will, eventually, start up another enrollment +request. It is important to note that, as long as the requester does +not change its subject name or keys, the same transaction id will be +used in the "new" transaction. This is important because based on this +transaction id, the certificate authority server can recognize this as +an existing transaction instead of a new one. + + +2.3.3 Transaction Behavior of Certificate/CRL Access + +There is no state maintained during certificate access and CRL access +transaction. When using the certificate query and CRL query messages +defined in this protocol, the transaction identifier is still required +so that the requester can match the response message with the +upstanding request message. When using LDAP to query the certificate and +the CRL, the behavior is specified by the LDAP protocol. + +2.4 Security + +The security goals of SCEP are that no adversary can: + +o subvert the public key/identity binding from that intended, +o discover the identity information in the enrollment requests and + issued certificates, +o cause the revocation of certificates with any non-negligible + probability. + +Here an adversary is any entity other than the requester and the CA +(and optionally the RA) participating in the protocol that is +computationally limited, but that can manipulate data during +transmission (that is, a man-in-the-middle). The precise meaning of +'computationally limited' depends on the implementer's choice of +cryptographic hash functions and ciphers. The required algorithms are +RSA, DES, and either SHA-1 or MD5, depending on the "SHA-1" CA Capability. +[See Appendix F]. + +The first and second goals are met through the use of PKCS#7 and PKCS#10 +encryption and digital signatures using authenticated public keys. The +CA's public key is authenticated via the checking of the CA fingerprint, +as specified in Section 2.1.2, and the SCEP client's public key is +authenticated through the manual authentication or pre-shared secret +authentication, as specified in Section 2.1.1.2. The third goal is met +through the use of a Challenge Password for revocation, that is chosen +by the SCEP client and communicated to the CA protected by the PKCS#7 +encryption, as specified in Section 2.2.4. + +The motivation of the first security goal is straightforward. The +motivation for the second security goal is to protect the identity +information in the enrollment requests and certificates. For example, +two IPSEC hosts behind a firewall may need to exchange certificates, and +may need to enroll certificates with a CA that is outside of a firewall. +Most networks with firewalls seek to prevent IP addresses and DNS + + Liu/Madson/McGrew/Nourse [Page 13] + +Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005 + +information from the trusted network leaving that network. The second +goal enables the hosts in this example to enroll with a CA outside the +firewall without revealing this information. The motivation for the +third security goal is to protect the SCEP clients from denial of +service attacks. + +Section 3 Transport Protocol + +In the SCEP protocol, HTTP is used as the transport protocol for the PKI +messages. + +3.1 HTTP "GET" and "POST" Message Format + +The following is the syntax definition of a HTTP GET message sent from +a requester to a certificate authority server: + +Request = "GET " CGI-PATH CGI-PROG "?operation=" OPERATION "&message=" MESSAGE +where: + CGI-PATH defines the actual CGI path to invoke the CGI program which + parses the request. + CGI-PROG is set to be the string "pkiclient.exe". This is intended + to be the program that the CA will use to handle the SCEP transactions, + though the CA may ignore CGI-PROG and use only the CGI-PATH. + OPERATION is set to be the string "PKIOperation" when the GET message + carries a PKI message to request certificates or CRL; OPERATION is set + to be the string "GetCACaps", "GetCACert", "GetNextCACert" or + "GetCACertChain" when the GET operation is used to get CA capabilities, + CA/RA certificate, the replacement CA/RA certificates for when the + current ones expire, or the CA Cert chain (respectively). + + When OPERATION is "PKIOperation", MESSAGE is a base64-encoded PKI message, + When OPERATION is GetCACert, MESSAGE is a CRL distribution + point in URI format, otherwise, MESSAGE is a string which represents + the certificate authority issuer identifier. + +SCEP uses the HTTP "GET" and "POST" messages to request information from the CA. +Requests for CA certificates or capabilities are sent in the clear, using "GET", +with the OPERATION and MESSAGE fields identifying the requested data. +CRLs may also be requested in the clear if the CA supports it. + +Other types of requests are sent using the PKCS#7 secure protocol. +These may be issued by means of a GET operation with +OPERATION and MESSAGE parameters in the Request-URL. OPERATION +identifies the type of GET operation, and MESSAGE is actually the PKCS#7 +message Base64-Encoded. + +For example. a requester may submit a message via HTTP to the server +as follows: + +GET /cgi-bin/pkiclient.exe?operation=PKIOperation&message=MIAGCSqGSIb3D +QEHA6CAMIACAQAxgDCBzAIBADB2MGIxETAPBgNVBAcTCE ......AAAAAA== + Liu/Madson/McGrew/Nourse [Page 13a] + +If supported by the CA, the message may also be sent via HTTP POST: + +POST /cgi-bin/pkiclient.exe?operation=PKIOperation + +This is further described in Appendix H. +To determine if the CA supports POST, use the GetCACaps message described +in Appendix F. + + +3.2 Response Message Format + +For each GET operation, the CA/RA server will return a MIME object via +HTTP. For a GET operation with PKIOperation as its type, the response is +tagged as having a Content Type of application/x-pki-message. The body +of this message is a BER encoded binary PKI message. The following is an +example of the response: + +"Content-Type:application/x-pki-message\n\n" + +In the case of GET operation with a type of GetCACert the MIME content +type returned will depend on whether or not an RA is in use. If there +is no RA, only the CA certificate is sent back in the response, and +the response has the content type tagged as +application/x-x509-ca-cert. the body of the response is a DER encoded +binary X.509 certificate. For example: + +"Content-Type:application/x-x509-ca-cert\n\n" + +If there is an RA, the RA certificates are sent back together with the +CA certificates, a certificate-only PKCS#7 SignedData is sent back in +the response where the SignerInfo is empty. Section 5 has the detailed +definition of the message format in this case. The content type is +application/x-x509-ca-ra-cert. + +The response to GetNextCACert is always a certificates-only PKCS#7 +SignedData with a content type of application/x-x509-ca-ra-cert. +If there is an RA, The signer is the current RA certificate. Otherwise, +the signer is the current CA certificate. + +If the CA supports it, PKIOperation may also be done via an HTTP POST. +This is described in Appendix H. + + Liu/Madson/McGrew/Nourse [Page 14] + +Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005 + +Section 4 Secure Transportation: PKCS#7 + +PKCS#7 is a general enveloping mechanism that enables both signed and +encrypted transmission of arbitrary data. It is widely implemented and +included in the RSA tool kit. In this section, the general PKCS#7 +enveloped PKI message format is specified. The complete PKCS#7 message +format for each PKI transaction will be covered in Section 5. + +4.1 SCEP Message Format + +As a transaction message, a SCEP message has a set of transaction +specific attributes and an information portion. Employing PKCS#7 +protocol, the transaction specific attributes are encoded as a set of +authenticated attributes of the SignedData. The information portion will +first be encrypted to become Enveloped Data, and then the digest of the +enveloped information portion is included as one of the message digest +attributes and being signed together with the other transaction specific +attributes. + +By applying both enveloping and signing transformations, a SCEP message +is protected both for the integrity of its end-end-transition +information and the confidentiality of its information portion. The +advantage of this technique over the conventional transaction message +format is that, the signed transaction type information and the status +of the transaction can be determined prior to invoke security handling +procedures specific to the information portion being processed. + +The following is an example of a SCEP message with its enveloped and +signed data portion represented by pkcsPKISigned and +pkcsPKIEnveloped. The out-most of any PKI message is a blob of +ContentInfo, with its content type set to SignedData and the actual +signed data as the content. + + Liu/Madson/McGrew/Nourse [Page 15] + +Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005 + + pkiMessage ContentInfo ::= { + contentType {pkcs-7 signedData(2)} + content pkcsPKISigned + } + pkcsPKISigned SignedData ::= { + version 1 + digestAlgorithm { iso(1) member-body(2) US(840) rsadsi(113549) + digestAlgorithm(2) 5} + contentInfo { + contentType {pkcs-7 1} -- data content identifier + content pkcsPKIEnvelope -- enveloped information portion + } + certificates -- signer certificate chain + signerInfo -- including signed transaction info and the digest + -- of the enveloped information portion as the + -- authenticated attributes + } + pkcsPKIEnveloped EnvelopedData ::= { + version 0 + recipientInfos -- information required to open the envelop + encryptedContentInfo { + contentType {pkcs-7 1} -- data content identifier + contentEncryptionAlgorithm + encryptedContent -- encrypted information portion + } + } + +4.2 Signed Transaction Attributes + +The following transaction attributes are encoded as authenticated +attributes. Please refer to Appendix B for the OID definitions. + +transactionID PrintableString -- Decimal value as a string + messageType PrintableString -- Decimal value as a string + pkiStatus PrintableString -- Decimal value as a string + failinfo PrintableString -- Decimal value as a string + senderNonce Octet String + recipientNonce Octet String + +where: + + The transactionID is an attribute which uniquely identify a + transaction. This attribute is required in all PKI messages. + + The messageType attribute specify the type of operation performed by the + transaction. This attribute is required in all PKI + messages. Currently, the following message types are defined: + + PKCSReq (19) -- Permits use of PKCS#10 certificate request + CertRep (3) -- Response to certificate or CRL request + GetCertInitial (20) -- Certificate polling in manual enrollment + GetCert (21) -- Retrieve a certificate + GetCRL (22) -- Retrieve a CRL + + Liu/Madson/McGrew/Nourse [Page 16] + +Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005 + + + All response message will include transaction status information which + is defined as pkiStatus attribute: + + SUCCESS (0) -- request granted + FAILURE (2) -- request rejected + PENDING (3) -- request pending for manual approval. + + If the status in the response is FAILURE, the failinfo attribute will + contain one of the following failure reasons: + + badAlg (0) -- Unrecognized or unsupported algorithm ident + badMessageCheck (1) -- integrity check failed + badRequest (2) -- transaction not permitted or supported + badTime (3) -- Message time field was not sufficiently close + to the system time + badCertId (4) -- No certificate could be identified matching + the provided criteria + + The attributes of senderNonce and recipientNonce are the 16 byte + random numbers generated for each transaction to prevent the replay + attack. + +When a requester sends a PKI message to the server, a senderNonce is +included in the message. After the server processes the request, it will +send back the requester senderNonce as the recipientNonce and generates +another nonce as the senderNonce in the response message. Because the +proposed pki protocol is a two-way communication protocol, it is clear +that the nonce can only be used by the requester to prevent the +replay. The server has to employ extra state related information to +prevent a replay attack. + +Section 5. SCEP Transaction Specification + +In this section each SCEP transaction is specified in terms of the +complete messages exchanged during the transaction. + +5.1 Certificate Enrollment + +The certificate enrollment transaction consists of one PKCSReq message +sent to the certificate authority from a requester, and one CertRep +message sent back from the server. The pkiStatus returned in the +response message is either SUCCESS, or FAILURE, or PENDING. The +information portion of a PKCSReq message is a PKCS#10 certificate +request, which contains the subject Distinguished Name, the subject +public key, and two attributes, a ChallengePassword attribute to be used +for revocation, and an optional ExtensionReq attribute which will be a +sequence of extensions the requester expects to be included in its V3 +certificate extensions. One of the extension attribute specifies the key +usage. If the request is granted, the pkiStatus is set to SUCCESS, and +the certificate is returned in CertRep; if the request is rejected, the + + + Liu/Madson/McGrew/Nourse [Page 17] + +Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005 + +pkiStatus is set to FAILURE; if the server requires manual approval of +the request, the pkiStatus is set to PENDING. The messages exchanged +in the manual authentication mode is further specified in Section 5.2. + +Precondition: + Both the requester and the certificate authority have completed their + initialization process. The requester has already been configured + with the CA/RA certificate. + +Postcondition: + Either the certificate is received by the requester, or the end + entity is notified to do the manual authentication, or the request + is rejected. + +5.1.1 PKCSReq Message Format + +A PKCSReq message is created by following the steps defined below: + +1. Create a PKCS#10 certificate request which is signed by the end + entity's private key, corresponding to the public key included in + the PKCS#10 certificate request. This constitutes the information + portion of PKCSReq. + +2. Encrypt the PKCS#10 certificate request using a randomly generated + content-encryption key. This content-encryption key is then + encrypted by the CA's* public key and included in the recipientInfo. + This step completes the "envelope" for the PKCS#10 certificate + request. + +3. Generate a unique string as the transaction id. + +4. Generate a 16 byte random number as senderNonce. + +5. Generate message digest on the enveloped PKCS#10 certificate request + using the selected digest algorithm. + +6. Create SignedData by adding the requester's self- or CA-certificate + as the signer's public key certificate. Include the message type, + transaction id, the senderNonce and the message digest as the + authenticated attributes and sign the attributes using the end + entity's private key. This completes the SignedData. + +7. The SignedData is prepended with the ContenInfo blob which indicates + a SignedData object. This final step completes the create of a + complete PKCSReq PKI message. + +In the following, the PKCSReq message is defined following the ASN.1 +notation. + +For readability, the values of a field is either represented by a quoted +string which specifies the intended value, or a constant when the value +is known. + + + Liu/Madson/McGrew/Nourse [Page 18] + +Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005 + + -- PKCSReq information portion + pkcsCertReq CertificationRequest ::= { -- PKCS#10 + version 0 + subject "the requester's subject name" + subjectPublicKeyInfo { + algorithm {pkcs-1 1} -- rsa encryption + subjectPublicKey "DER encoding of the requester's public key" + } + attributes { + challengePassword {{pkcs-9 7} "password string" } + extensions + } + signatureAlgorithm {pkcs-1 4} -- MD5WithRSAEncryption + signature "bit string which is created by signing inner content + of the defined pkcsCertReq using requester's private + key, corresponding to the public key included in + subjectPublicKeyInfo." + } + -- Enveloped information portion + pkcsCertReqEnvelope EnvelopeData ::= { -- PKCS#7 + version 0 + recipientInfo { + version 0 + issuerAndSerialNumber { + issuer "the CA issuer name" + serialNumber "the CA certificate serial number" + } + keyEncryptionAlgorithm {pkcs-1 1} -- rsa encryption + encryptedKey "content-encryption key + encrypted by CA public key" + } + encryptedContentInfo { + contentType {pkcs-7 1} -- data content + contentEncryptionAlgorithm "object identifier + for DES encryption" + encryptedContent "encrypted pkcsCertReq using the content- + encryption key" + } + } + -- Signed PKCSReq + pkcsCertReqSigned SignedData ::= { -- PKCS#7 + version 1 + digestAlgorithm {iso(1) member-body(2) US(840) rsadsi(113549) + digestAlgorithm(2) 5} + contentInfo { + contentType {pkcs-7 1} -- data content identifier + content pkcsCertReqEnvelope + } + certificate { -- requester self-signed or CA-issued certificate + version 3 + serialNumber "the transaction id associated with enrollment" + signature {pkcs-1 4} -- md5WithRSAEncryption + + + Liu/Madson/McGrew/Nourse [Page 19] + +Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005 + + issuer " the requester's subject name" + validity { + notBefore "a UTC time" + notAfter "a UTC time" + } + subject "the requester's subject name" + subjectPublicKeyInfo { + algorithm {pkcs-1 1} + subjectPublicKey "DER encoding of requester's public key" + } + signatureAlgorithm {pkcs-1 4} + signature "the signature generated by using the requester's + private key corresponding to the public key in + this certificate." + } + signerInfo { + version 1 + issuerAndSerialNumber { + issuer "the requester's subject name" + serialNumber "the transaction id associated + with the enrollment" + } + digestAlgorithm {iso(0) member-body(2) US(840) rsadsi(113549) + digestAlgorithm(2) 5} + authenticateAttributes { + contentType {{pkcs-9 3} {pkcs-7 1}} + messageDigest {{pkcs-9 4} "an octet string"} + transaction-id {{id-attributes transId(7)} "printable + string"} + -- this transaction id will be used + -- together with the subject name as + -- the identifier of the requester's key + -- pair during enrollment + messageType {{id-attributes messageType(2)} "PKCSReq"} + senderNonce {{id-attributes senderNonce(5)} + "a random number encoded as a string"} + } + digestEncryptionAlgorithm {pkcs-1 1} -- rsa encryption + encryptedDigest "encrypted digest of the authenticated + attributes using requester's private key" + } + } + pkcsReq PKIMessage ::= { + contentType {pkcs-7 2} + content pkcsCertRepSigned + } + + + + + + + + + Liu/Madson/McGrew/Nourse [Page 20] + +Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005 + +5.1.2 CertRep Message Format + +The response to an SCEP enrollment request is a CertRep message. + +5.1.2.1 PENDING Response + +When the CA is configured to manually authenticate the requester, +the CertRep is returned with the attribute pkiStatus set to PENDING. +The data portion for this message is null. Only the transaction +required attributes are sent back. + +CertRepSigned SignedData ::= { -- PKCS#7 + version 1 + digestAlgorithm {iso(1) member-body(2) US(840) rsadsi(113549) + digestAlgorithm(2) 5} + contentInfo {contentType {pkcs-7 1} -- empty content + } + signerInfo { + version 1 + issuerAndSerialNumber { + issuer "name of CA that issued the CA [RA] cert" + serialNumber "the serial number of the CA [RA] cert" + } + digestAlgorithm (iso(1) member-body(2) US(840) rsadsi(113549) + digestAlgorithm(2) 5} + authenticateAttributes { + contentType {{pkcs-9 3} {pkcs-7 1}} + messageDigest {{pkcs-9 4} NULL} + messageType {{id-attribute messageType(0)} "CertRep"} + transaction-id {{id-attributes transid(7)} "printablestring"} + --- same transaction id used in PKCSReq + pkiStatus {{id-attributes pkiStatus(3)} "PENDING"} + recipientNonce {{id-attributes recipientNonce(6)}<16 bytes>} + senderNonce {{id-attributes senderNonce(5)} <16 bytes>} + } + digestEncrytionAlgorithm {pkcs-1 1} + encryptedDigest "encrypted message digest of the authenticated + attributes using the CA's [RA's] private key" + } +} +CertRep PKIMessage ::= { + contentType {pkcs-7 2} + content CertRepSigned +} + +5.1.2.2 Failure Response + +In this case, the CertRep sent back to the requester is same as in +the PENDING case, except that the pkiStatus attribute is set to FAILURE, +and the failInfo attribute should be included: + + pkistatus {{id-attributes pkiStatus(3)} "FAILURE"} + failInfo {{id-attributes failInfo(4)} "the reason to reject"} + + Liu/Madson/McGrew/Nourse [Page 21] + +Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005 + +5.1.2.3 SUCCESS response + +In this case, the information portion of CertRep will be a degenerated +PKCS#7 which contains the requester's certificate. It is then enveloped +and signed as below: + +pkcsCertRep SignedData ::= { -- PKCS#7 + version 1 + digestAlgorithm {iso(1) member-body(2) US(840) rsadsi(113549) + digestAlgorithm(2) 5} + contentInfo { -- empty content since this is degenerated PKCS#7 + contentType {pkcs-7 1} + } + certificates { + certificate { -- issued requester's certificate // must be first + version 3 + serialNumber "issued requester's certificate serial number" + signature {pkcs-1 4} -- md5WithRSAEncryption + issuer "the certificate authority issuer name" + validity { + notBefore "UTC time" + notAfter "UTC time" + } + subject "the requester subject name as given in PKCS#10" + subjectPublicKeyInfo { + algorithm {pkcs-1 1} + subjectPublicKey "a DER encoding of requester public + key as given in PKCS#10" + } + extensions " the extensions as given in PKCS#10" + signatureAlgorithm {pkcs-1 4} + signature " the certificate authority signature" + } + certificate "the certificate authority certificate" (optional) + certificate "the registration authority certificate(s)" (optional) + } +} +pkcsCertRepEnvelope EnvelopedData ::= { -- PKCS#7 + version 0 + recipientInfo { + version 0 + issuerAndSerialNumber { -- use issuer name and serial number as + -- conveyed in requester's self-signed + -- certificate, included in the PKCSReq + issuer "the requester's subject name" + serialNumber "the serial number defined by the requester in + its self-signed certificate" + } + keyEncryptionAlgorithm {pkcs-1 1} + encryptedKey "content-encrypt key encrypted by the requester's + public key which is same key as authenticated in + the requester's certificate" + } + + + Liu/Madson/McGrew/Nourse [Page 22] + +Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005 + + encryptedContentInfo { + contentType {pkcs-7 1} -- data content identifier + contentEncryptionAlgorithm "OID for DES encryption" + encryptedContent "encrypted pkcsCertRep using content encryption + key" + } +} +pkcsCertRepSigned SignedData ::= { -- PKCS#7 + version 1 + digestAlgorithm {iso(1) member-body(2) US(840) rsadsi(113549) + digestAlgorithm(2) 5} + contentInfo { + contentType {pkcs-7 1} + content pkcsCertRepEnvelope + } + signerInfo { + version 1 + issuerAndSerialNumber { + issuer "the certificate authority issuer name" + serialNumber "the CA certificate's serial number" + } + digestAlgorithm {iso(1), member-body(2) US(840) rsadsi(113549) + digestAlgorithm(2) 5} + authenticateAttributes { + contentType {{pkcs-9 3} {pkcs-7 1}} + messageDigest {{pkcs-9 4} "a octet string"} + messageType {{id-attribute messageType(2)} "CertRep"} + transaction-id {{id-attributes transId(7)} "printable + string"} + -- same transaction id as given in PKCSReq + pkiStatus {{id-attributes pkiStatus(3) "SUCCESS"} + recipientNonce {{id-attribute recipientNonce(6)}<16 bytes>} + senderNonce {{ id-attributes senderNonce(5) <16 bytes>} + } + digestEncryptionAlgorithm {pkcs-1 1} + encryptedDigest "encrypted digest of authenticate attributes + using CA's private key " + } +} +CertRep PKIMessage ::= { + contentType {pkcs-7 2} + content pkcsCertRepSigned +} + +5.2 Poll for Requester Initial Certificate + +Either triggered by the PENDING status received from the CertRep, or by +the non-response timeout for the previous PKCSReq, a requester will +enter the polling state by periodically sending GetCertInitial to the +server, until either the request is granted and the certificate is sent +back, or the request is rejected, or the configured time limit for +polling is exceeded. + + + Liu/Madson/McGrew/Nourse [Page 23] + +Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005 + + +Since GetCertInitial is part of the enrollment, the messages exchanged +during the polling period should carry the same transaction identifier +as the previous PKCSReq. + +PreCondition + Either the requester has received a CertRep with pkiStatus set to be + PENDING, or the previous PKCSReq has timed out. + +PostContition + The requester has either received the certificate, or be rejected of + its request, or the polling period ended as a failure. + +5.2.1 GetCertInitial Message Format + +Since at this time the certificate has not been issued, the requester +can only use the requester's subject name, combined with the +transaction identifier, to identify the polled certificate request. + +The certificate authority server must be able to uniquely identify the +polled certificate request. A subject name can have more than one +outstanding certificate request (with different key usage attributes). + +-- Information portion + +pkcsGetCertInitial issuerAndSubject ::= { + issuer "the certificate authority issuer name" + subject "the requester subject name as given in PKCS#10" +} +pkcsGetCertInitialEnvelope EnvelopedData ::= { + version 0 + recipientInfo { + version 0 + issuerAndSerialNumber { + issuer "the CA issuer name" + serialNumber "the CA certificate serial number" + } + keyEncryptionAlgorithm {pkcs-1 1} + encryptedKey "content-encrypt key encrypted by CA's public key" + } + encryptedContentInfo { + contentType {pkcs-7 1} -- data content + contentEncryptionAlgorithm "OID for DES encryption" + encryptedContent "encrypted getCertInital" + } +} +pkcsGetCertInitialSigned SignedData ::= { -- PKCS#7 + version 1 + digestAlgorithm {iso(1) member-body(2) US(840) rsadsi(113549) + digestAlgorithm(2) 5} + contentInfo { + contentType {pkcs-7 1} + + + Liu/Madson/McGrew/Nourse [Page 24] + +Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005 + + content pkcsGetCertIntialEnvelope + } + certificate { -- the requester's self-signed certificate + version 3 + serialNumber "the transaction id associated with enrollment" + signature {pkcs-1 4} -- md5WithRSAEncryption + issuer " the requester's subject name" + validity { + notBefore "a UTC time" + notAfter "a UTC time" + } + subject "the requester's subject name" + subjectPublicKeyInfo { + algorithm {pkcs-1 1} + subjectPublicKey "DER encoding of requester's public key" + } + signatureAlgorithm {pkcs-1 4} + signature "the signature generated by using the requester's + private key corresponding to the public key in + this certificate." + } + signerInfo { + version 1 + issuerAndSerialNumber { + issuer "requester's subject name" + serialNumber "the transaction id used in previous PKCSReq" + } + digestAlgorithm {iso(1), member-body(2) US(840) rsadsi(113549) + digestAlgorithm(2) 5} + authenticateAttributes { + contentType {{pkcs-9 3} {pkcs-7 1}} + messageDigest {{pkcs-9 4} "an octet string"} + -- digest of getCertInitial + messageType {{id-attribute messageType(2)} "GetCertInitial"} + transaction-id {{id-attributes transId(7)} "printable + string"} + -- same transaction idused in previous PKCSReq + senderNonce {{id-attribute senderNonce(3)} 0x<16 bytes>} + } + digestEncryptionAlgorithm {pkcs-1 1} + encryptedDigest "encrypted digest of authenticateAttributes" + } +} +GetCertInitial PKIMessage ::= { + contentType {pkcs-7 2} + content pkcsGetCertInitialSigned +} + + + +5.2.2 GetCertInitial Response Message Format + +The response messages for GetCertInitial are the same as for PKCSReq. + + Liu/Madson/McGrew/Nourse [Page 25] + +Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005 + +5.3 Certificate Access + +The certificate query message defined in this section is an option when +the LDAP server is not available to provide the certificate query. A +requester should be able to query an issued certificate from the +certificate authority, as long as the issuer name and the issuer +assigned certificate serial number is known to the requesting end +entity. This transaction is not intended to provide the service as a +certificate directory service. A more complicated query mechanism would +have to be defined in order to allow a requester to query a certificate +using various different fields. + +This transaction consists of one GetCert message sent to the server by +a requester, and one CertRep message sent back from the server. + +PreCondition + The queried certificate have been issued by the certificate authority + and the issuer assigned serial number is known. + +PostCondition + Either the certificate is sent back or the request is rejected. + + +5.3.1 GetCert Message Format + +The queried certificate is identified by its issuer name and the issuer +assigned serial number. If this is a query for an arbitrary requester's +certificate, the requesting requester should includes its own CA issued +certificate in the signed envelope. If this is a query for its own +certificate (assume the requester lost the issued certificate, or does +not have enough non-volatile memory to save the certificate), then the +self-signed certificate has to be included in the signed envelope. + + pkcsGetCert issuerAndSerialNumber ::= { + issuer "the certificate issuer name" + serialNumber "the certificate serial number" + } + pkcsGetCertEnvelope EnvelopedData ::= { + version 0 + recipientInfo { + version 0 + issuerAndSerialNumber { + issuer "the CA [RA] issuer name" + serialNumber "the CA [RA] certificate serial number" + } + keyEncryptionAlgorithm {pkcs-1 1} + encryptedKey "content-encrypt key encrypted + by CA [RA] public key" + } + + + + + + Liu/Madson/McGrew/Nourse [Page 26] + +Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005 + + + encryptedContentInfo { + contentType {pkcs-7 1} -- data content + contentEncryptionAlgorithm "OID for DES encryption" + encryptedContent "encrypted pkcsGetCert using the content + encryption key" + } + } + pkcsGetCertSigned SignedData ::= { + version 1 + digestAlgorithm {iso(1) member-body(2) US(840) rsadsi(113549) + digestAlgorithm(2) 5} + contentInfo { + contentType {pkcs-7 1} + content pkcsGetCertEnvelope + } + certificates { + certificate "CA issued certificate" + or "self-signed certificate" + } + signerInfo { + version 1 + issuerAndSerialNumber { + issuer "the requester's subject name" + serialNumber "requester's certificate serial number" + } + digestAlgorithm {iso(1), member-body(2) US(840) rsadsi(113549) + digestAlgorithm(2) 5} + authenticateAttributes { + contentType {{pkcs-9 3} {pkcs-7 1}} + messageDigest {{pkcs-9 4} "an octet string"} + -- digest of pkcsGetCertEnvelope + messageType {{id-attribute messageType(2)} "GetCert"} + transaction-id {{id-attributes transId(7)} "printable + string"} + senderNonce {{id-attribute senderNonce(3)} <16 bytes>} + } + digestEncryptionAlgorithm {pkcs-1 1} + encryptedDigest "encrypted digest of authenticateAttributes" + } + } + GetCert PKIMessage ::= { + contentType {pkcs-7 2} + content pkcsGetCertSigned + } + + + + + + + + + + Liu/Madson/McGrew/Nourse [Page 27] + +Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005 + + +5.3.2 CertRep Message Format + +In this case, the CertRep from the server is same as the CertRep for the +PKCSReq, except that the server will only either grant the request or +reject the request. Also, the recipientInfo should use the CA issuer +name and CA assigned serial number to identify the requester's key pair +since at this time, the requester has received its own certificate. + +5.4 CRL Access + +The CRL query message defined in this section is an option when the LDAP +server is not available to provide the CRL query. In the PKI protocol +proposed here, only the requester can initiate the transaction to +download CRL. A requester sends GetCRL request to the server and the +server sends back CertRep whose information portion is a degenerated +PKCS#7 which contains only the most recent CRL. The size of CRL included +in the CertRep should be determined by the implementation. + +PreCondition + The certificate authority certificate has been downloaded to the end + entity. + +PostCondition + CRL sent back to the requester. + +5.4.1 GetCRL Message format + +The CRL is identified by using both CA's issuer name and the CA +certificate's serial number: + + pkcsGetCRL issuerAndSerialNumber { + issuer "the certificate authority issuer name" + serialNumber "certificate authority certificate's serial number" + } + +When the CRLDistributionPoint is supported, the pkcsGetCRL is defined as +the following: + + pkcsGetCRL SEQUENCE { + crlIssuer issuerAndSerialNumber + distributionPoint CE-CRLDistPoints + } + +where CE-CRLDisPoints is defined in X.509, but must contain only one +CRL distribution point. + + + + + + + + + + + Liu/Madson/McGrew/Nourse [Page 28] + +Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005 + + pkcsGetCRLEnvelope EnvelopedData ::= { + version 0 + recipientInfo { + version 0 + issuerAndSerialNumber { + issuer "the certificate authority (or RA) issuer name" + serialNumber "the CA (RA) certificate's serial number" + } + keyEncryptionAlgorithm {pkcs-1 1} + encryptedKey "content-encrypt key encrypted by CA (RA) public key" + } + encryptedContentInfo { + contentType {pkcs-7 1} -- data content + contentEncryptionAlgorithm "OID for DES encryption" + encryptedContent "encrypted pkcsGetCRL" + } + } + pkcsGetCRLSigned SignedData ::= { + version 1 + digestAlgorithm {iso(1) member-body(2) US(840) rsadsi(113549) + digestAlgorithm(2) 5} + contentInfo { + contentType {pkcs-7 1} + content pkcsGetCRLEnvelope + } + certificates { + certificate "CA-issued or self-signed requester's certificate" + } + signerInfo { + version 1 + issuerAndSerialNumber { + issuer "the requester's issuer name" + serialNumber "the requester's certificate serial number" + } + digestAlgorithm {iso(1), member-body(2) US(840) rsadsi(113549) + digestAlgorithm(2) 5} + authenticateAttributes { + contentType {{pkcs-9 3} {pkcs-7 1}} + messageDigest {{pkcs-9 4} 0x<16/20 bytes>} + -- digest of pkcsGetCRLEnvelope + messageType {{id-attribute messageType(2)} "CertCRL"} + transaction-id {{id-attributes transId(7)} "printable + string"} + senderNonce {{id-attribute senderNonce(3)} <16 bytes>} + } + digestEncryptionAlgorithm {pkcs-1 1} + encryptedDigest "encrypted digest of authenticateAttributes" + } + } + GetCRL PKIMessage ::= { + contentType {pkcs-7 2} + content pkcsGetCRLSigned + } + + Liu/Madson/McGrew/Nourse [Page 29] + +Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005 + + +5.4.2 CertRep Message Format + +The CRL is sent back to the requester through CertRep message. The +information portion of this message is a degenerated PKCS#7 SignedData +which contains only a CRL. + + pkcsCertRep SignedData ::= { + version 1 + digestAlgorithm {iso(1) member-body(2) US(840) rsadsi(113549) + digestAlgorithm(2) 5} + contentInfo { + contentType {pkcs-7 1} + } + crl { + signature {pkcs-1 4} + issuer "the certificate authority issuer name" + lastUpdate "UTC time" + nextUpdate "UTC time" + revokedCertificate { + -- the first entry + userCertificate "certificate serial number" + revocationData "UTC time" + .... + -- last entry + userCertificate "certificate serial number" + revocationData "UTC time" + } + } + pkcsCertRepEnvelope EnvelopedData ::= { + version 0 + recipientInfo { + version 0 + issuerAndSerialNumber { + issuer "the requester's issuer name" + serialNumber "the requester certificate serial number" + } + keyEncryptionAlgorithm {pkcs-1 1} + encryptedKey "content-encrypt key encrypted by requester's + public key " + } + encryptedContentInfo { + contentType {pkcs-7 1} -- data content + contentEncryptionAlgorithm "OID for DES encryption" + encryptedContent "encrypted pkcsCertRep using requester's + public key" + } + } + + + + + + + Liu/Madson/McGrew/Nourse [Page 30] + +Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005 + + + pkcsCertRepSigned SignedData ::= { -- PKCS#7 + version 1 + digestAlgorithm {iso(1) member-body(2) US(840) rsadsi(113549) + digestAlgorithm(2) 5} + contentInfo { + contentType {pkcs-7 1} + content pkcsCertRepEnvelope + } + signerInfo { + version 1 + issuerAndSerialNumber { + issuer "the certificate authority issuer name" + serialNumber "the CA certificate's serial number" + } + digestAlgorithm {iso(1), member-body(2) US(840) rsadsi(113549) + digestAlgorithm(2) 5} + authenticateAttributes { + contentType {{pkcs-9 3} {pkcs-7 1}} + messageDigest {{pkcs-9 4} "an octet string"} + -- digest of pkcsCertRepEnvelope + messageType {{id-attribute messageType(2)} "CertRep"} + transaction-id {{id-attributes transId(7)} "printable + string"} + -- same transaction id as given in PKCSReq + pkiStatus {{id-attributes pkiStatus(3) "SUCCESS"} + recipientNonce{{id-attribute recipientNonce(6)}<16 bytes>} + senderNonce {{id-attribute senderNonce (5) 0x<16 bytes>} + } + digestEncryptionAlgorithm {pkcs-1 1} + encryptedDigest "encrypted digest of authenticatedAttributes + using CA private key" + } + } + + +NOTE:The PKCS#7 EncryptedContent is specified as an octet string, but +SCEP entities must also accept a sequence of octet strings as a valid +alternate encoding. + +This alternate encoding must be accepted wherever PKCS #7 Enveloped +Data is specified in this document. + + + + + + + + + + + + Liu/Madson/McGrew/Nourse [Page 31] + +Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005 + +5.5 Get Certificate Authority Certificate + +Before any transaction begins, end entities have to get the CA (and +possibly RA) certificate(s) first. Since the requester may have no CA +certificates or CA public keys at all, this message can not be +encrypted and the response must be authenticated by out-of-band means. +These certs are obtained by means of an HTTP GET message. To get the +CA certificate, the requester does a "HTTP GET" with a URL that +identifies a CGI script on the server and an optional CA issuer +identifier as the parameter to the CGI script. The response is either +a single X.509 CA certificate ("CA mode"), or a PKCS7 message +containing the CA certificate and RA certificates ("RA mode"). The +client can determine which mode the CA operates in by which response +it gets. Once the CA certificate is received by the requester, a +fingerprint is generated using either the SHA-1 or the MD5 hash +algorithm on the whole CA certificate. If the requester does not have +a certificate path to a trusted CA certificate, this fingerprint may +be used to verify the certificate, by some positive out-of-band means, +such as a phone call. + +5.5.1 GetCACert HTTP Message Format + "GET" CGI-PATH CGI-PROG "?operation=GetCACert" "&message=" CA-IDENT + where: + CGI-PATH defines the actual CGI path to invoke the CGI program + which parses the request. + CGI-PROG is set to be the string "pkiclient.exe" and this is + expected to be the program that the CA will use to handle the + SCEP transactions. + CA-IDENT is any string which is understood by the CA. + For example, it could be a domain name like ietf.org. + If a certificate authority has multiple CA certificates + this field can be used to distinguish which is required. + Otherwise it may be ignored. + +5.5.2 Response + +The response for GetCACert is different between the case where the CA +directly communicated with the requester during the enrollment, and the +case where a RA exists and the requester communicates with the RA +during the enrollment. + +5.5.2.1 CA Certificate Only Response + +A binary X.509 CA certificate is sent back as a MIME object with a +Content-Type of application/x-x509-ca-cert. + +5.5.2.2 CA and RA Certificates Response + +When an RA exists, both CA and RA certificates must be sent back in +the response to the GetCACert request. The RA certificate(s) must be +signed by the CA. A certificates-only PKCS#7 SignedData is used to +carry the certificates to the requester, with a Content-Type of +application/x-x509-ca-ra-cert. + + Liu/Madson/McGrew/Nourse [Page 32] + +5.5.3 Get Next Certificate Authority Certificate + +5.5.3.1 GetNextCACert HTTP Message Format + "GET" CGI-PATH CGI-PROG "?operation=GetNextCACert" "&message=" CA-IDENT + +The response to this message is a PKCS#7 certificates-only message containing +a CA certificate (and possibly RA certificates) to be used when the current CA +certificate expires, signed with the current CA cert (or RA certificate, if +the CA is in RA mode. Note that a PKCS#7 is returned even in CA mode. + +5.5.3.2 GetCACaps HTTP Message Format + "GET" CGI-PATH CGI-PROG "?operation=GetCACaps" "&message=" CA-IDENT + +This message requests capabilities from CA. The response is a list of +text capabilities, as defined in Appendix F. Support for this message +is optional, but if it is not supported, the client should assume that +none of the capabilities in Appendix F are supported. + +5.6 Get Certificate Authority Certificate Chain + +GetCACertChain provides a way to get the entire certificate chain. + +5.6.1 GetCACertChain HTTP Message Format + + "GET" CGI-SCRIPT "?" "operation=GetCACertChain" "&" "message" CA-IDENT + where CGI-SCRIPT and CA-IDENT are as described for GetCACert. + +5.6.2 Response + +The response for GetCACertChain is a certificates-only PKCS#7 SignedData +to carry the certificates to the requester, with a Content-Type of +application/x-x509-ca-ra-cert-chain. + +5.6.3 Backwards Compatability + +Versions of SCEP prior to revision 3 do not support GetCACertChain. +Certificate Authorities written to these prior versions will not be +able to process the message and may return an HTML error. + +To avoid this, clients should send the GetCACert message first. If the +returned certificate is self-signed or is signed by a Certificate +Authority that is trusted by the client, then it is not necessary to +send the GetCACertChain message and it should not be sent. + +If a Certificate Authority is configured with a certificate that is +not either self-signed or has a self-signed issuer, then it should +support this message. In other words, it should be supported if the +CA hierarchy is more than two-deep. + +An old CA in a two-deep hierarchy might still get this message from +a client if the client did not trust either that CA or its issuer. +In that event, the certificate cannot be trusted anyway. In any case +the CA must not crash or hang upon the receipt of the message and the +client must be able to handle whatever error is returned by the CA, +including an HTML error or an ungraceful disconnect. + + Liu/Madson/McGrew/Nourse [Page 33] + +Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005 + +The following is the ASN.1 definition of Cert-Only PKCS#7: + + certOnly SignedData ::= { + version 1 + digestAlgorithm {iso(1) member-body(2) US(840) rsadsi(113549) + digestAlgorithm(2) 5} + +contentInfo { + contentType {pkcs-7 1} -- data content identifier + content -- NULL + } + certificates -- the RA and CA certificates. + } + + CARACerts PKIMessage ::= { -- special pki message sent in the clear + contentType {pkcs-7 2} + content certOnly + } + + +6.0 Security Considerations + +This entire document is about security. Common security considerations +such as keeping private keys truly private and using adequate lengths +for symmetric and asymmetric keys must be followed in order to maintain +the security of this protocol. + + +7.0 Intellectual Property + +This protcol includes the optional use of Certificate Revocation List +Distribution Point (CRLDP) technology, which is a patented technology +of Entrust Technologies, Inc. (Method for Efficient Management of +Certificate Revocation Lists and Update Information (U.S. Patent +5,699,431)). Please contact Entrust Technologies, Inc. +(www.entrust.com) for more information on licensing CRLDP technology. + + +8.0 References + +[PKCS7] Kaliski, B., "PKCS #7: Cryptographic Message Syntax Version +1.5", RFC 2315, March 1998. + +[PKCS10] Kaliski, B., "PKCS #10: Certification Request Syntax Version +1.5", RFC 2314, March 1998. + +[RFC2459] Housley, R., ec. al., "Internet X.509 Public Key +Infrastructure Certificate and CRL Profile", RFC 2459, January 1999. + + + + + + + Liu/Madson/McGrew/Nourse [Page 34] + +Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005 + +Appendix A: Cisco Requester Subject Name Definition + +The ip address and the FQDN of a SCEP client should be included in the +V3 extension subjectAltName. When the subjectAltName extension attribute +is present, both the subjectAltName fields and the subjectName field could +have the IP address and the FQDN information. + +When the X.500 directory is used by the CA to define the name space, the +subject name defined above become a RDN which is part of DN binded to +the requester's public key in the certificate. + + +A sample of DN assigned by Entrust CA is given below (assume the same +ciscoRouterAlice is used as the requester defined subject name): + + OU = InteropTesting, O = Entrust Technologies, C = CA + RDN = {"alice.cisco.com", "172.21.114.67", "22334455"} + + + Liu/Madson/McGrew/Nourse [Page 35] + +Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005 + +Appendix B: IPSEC Client Enrollment Certificate Request + +The following is the certificate enrollment request (PKCS#10) as created +by Cisco VPN Client: + +-----END NEW CERTIFICATE REQUEST----- + 0 30 439: SEQUENCE { + 4 30 288: SEQUENCE { + 8 02 1: INTEGER 0 + 11 30 57: SEQUENCE { + 13 31 55: SET { + 15 30 53: SEQUENCE { + 17 06 3: OBJECT IDENTIFIER commonName (2 5 4 3) + 22 13 46: PrintableString + : 'For Xiaoyi, IPSEC attrs in alternate name + extn' + : } + : } + : } + 70 30 158: SEQUENCE { + 73 30 13: SEQUENCE { + 75 06 9: OBJECT IDENTIFIER rsaEncryption (1 2 840 113549 1 + 1 1) + 86 05 0: NULL + : } + 88 03 140: BIT STRING 0 unused bits + : 30 81 88 02 81 80 73 DB 1D D5 65 AA EF C7 D4 8E + : AA 6E EB 46 AC 91 2A 0F 50 51 17 AD 50 A2 2A F2 + : CE BE F1 E4 22 8C D7 61 A1 6C 87 61 62 92 CB A6 + : 80 EA B4 0F 09 9D 18 5F 39 A3 02 0E DB 38 4C E4 + : 8A 63 2E 72 8B DC BE 9E ED 6C 1A 47 DE 13 1B 0F + : 83 29 4D 3E 08 86 FF 08 2B 43 09 EF 67 A7 6B EA + : 77 62 30 35 4D A9 0F 0F DF CC 44 F5 4D 2C 2E 19 + : E8 63 94 AC 84 A4 D0 01 E1 E3 97 16 CD 86 64 18 + : [ Another 11 bytes skipped ] + : } + 231 A0 63: [0] { + 233 30 61: SEQUENCE { + 235 06 9: OBJECT IDENTIFIER extensionReq (1 2 840 113549 1 9 + 14) + 246 31 48: SET { + 248 30 46: SEQUENCE { + 250 30 44: SEQUENCE { + 252 06 3: OBJECT IDENTIFIER subjectAltName (2 5 29 17) + 257 04 37: OCTET STRING + 30 23 87 04 01 02 03 04 81 0D 65 6D 61 69 + + + Liu/Madson/McGrew/Nourse [Page 36] + +Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005 + + 6C 40 69 72 65 2E 63 6F 6D 82 0C 66 71 64 + 6E 2E 69 72 65 2E 63 6F 6D + : } + : } + : } + : } + : } + : } + + 296 30 13: SEQUENCE { + 298 06 9: OBJECT IDENTIFIER md5withRSAEncryption (1 2 840 113549 + 1 1 4) + 309 05 0: NULL + : } + 311 03 129: BIT STRING 0 unused bits + : 19 60 55 45 7F 72 FD 4E E5 3F D2 66 B0 77 13 9A + : 87 86 75 6A E1 36 C6 B6 21 71 68 BD 96 F0 B4 60 + : 95 8F 12 F1 65 33 16 FD 46 8A 63 19 90 40 B4 B7 + : 2C B5 AC 63 17 50 28 F0 CD A4 F0 00 4E D2 DE 6D + : C3 4F F5 CB 03 4D C8 D8 31 5A 7C 01 47 D2 2B 91 + : B5 48 55 C8 A7 0B DD 45 D3 4A 8D 94 04 3A 6C B0 + : A7 1D 64 74 AB 8A F7 FF 82 C7 22 0A 2A 95 FB 24 + : 88 AA B6 27 83 C1 EC 5E A0 BA 0C BA 2E 6D 50 C7 + : } + + +Appendix C: Private OID Definitions + +The OIDs used in defining pkiStatus are VeriSign self-maintained +OIDs. Please note, work is in progress to replace the VeriSign owned +object identifiers with the standard object identifiers. Once the +standarlization is completed, this documentation will be updated. + +id-VeriSign OBJECT_IDENTIFIER ::= {2 16 US(840) 1 VeriSign(113733)} +id-pki OBJECT_IDENTIFIER ::= {id-VeriSign pki(1)} +id-attributes OBJECT_IDENTIFIER ::= {id-pki attributes(9)} +id-messageType OBJECT_IDENTIFIER ::= {id-attributes messageType(2)} +id-pkiStatus OBJECT_IDENTIFIER ::= {id-attributes pkiStatus(3)} +id-failInfo OBJECT_IDENTIFIER ::= {id-attributes failInfo(4)} +id-senderNonce OBJECT_IDENTIFIER ::= {id-attributes senderNonce(5)} +id-recipientNonce OBJECT_IDENTIFIER ::= {id-attributes recipientNonce(6)} +id-transId OBJECT_IDENTIFIER ::= {id-attributes transId(7)} +id-extensionReq OBJECT_IDENTIFIER ::= {id-attributes extensionReq(8)} + + + Liu/Madson/McGrew/Nourse [Page 37] + +Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005 + + Appendix D: CRL Query by means of LDAP + + In order to retrieve the CRL by means of LDAP, the client needs to know + where in the directory it is stored. The certificate must contain a + CRL Distribution Point extension encoded as a DN or as an LDAP URI. + +For example, the certificate issued by Entrust VPN contains +the following DN as the CRL distribution point: + + + +CN = CRL1, O = cisco, C = US. + + The asn.1 encoding of this distribution point is: + + 30 2C 31 0B 30 09 06 03 55 04 06 13 02 55 53 31 0E 30 0C 06 + 03 55 04 0A 13 05 63 69 73 63 6F 31 0D 30 0B 06 03 55 04 03 + 13 04 43 52 4C 31 + + +The ldap form would be: + +ldap://servername/CN=CRL1,O=cisco,C=US + + + +Appendix E: SCEP State Transitions + +SCEP state transitions are based on transaction identifier. The design +goal is to ensure the synchronization between the CA and the requester +under various error situations. + + +An identity is defined by the combination of FQDN, the IP address and +the client serial number. FQDN is the required name attribute. It is +important to notice that, a client named as Alice.cisco.com is different +from the client named as Alice.cisco.com plus IPAddress 117.96.1.219. + +Each enrollment transaction is uniquely associated with a transaction +identifier. Because the enrollment transaction could be interrupted by +various errors, including network connection errors or client reboot, +the SCEP client generates a transaction identifier by calculating a +hash on the public key value for which the enrollment is requested. This +retains the same transaction identifier throughout the enrollment +transaction, even if the client has rebooted or timed out, and issues a +new enrollment request for the same key pair. It also provides the way +for the CA to uniquely identify a transaction in its database. At the +requester side, it generates a transaction identifier which is included +in PKCSReq. If the CA returns a response of PENDING, the requester +will poll by periodically sending out GetCertInitial with the same +transaction identifier until either a response other than PENDING is +obtained, or the configured maximum time has elapsed. + +If the client times out or the client reboots, the client administrator +will start another enrollment transaction with the same key pair. The +second enrollment will have the transaction idenifier. At the server +side, instead of accepting the PKCSReq as a new enrollment request, it +should respond as if another GetCertInitial message had been sent with +that transaction ID. In another word, the second PKCSReq should be +taken as a resynchronization message to allow the enrollment resume as +the same transaction. + +It is important to keep the transaction id unique since SCEP requires the +same policy and same identity be applied to the same subject name and + + + Liu/Madson/McGrew/Nourse [Page 38] + +Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005 + +key pair binding. In the current implementation, an SCEP client can +only assume one identity. At any time, only one key pair, with a given +key usage, can be associated with the same identity. + +The following gives several examples of client to CA transactions. + +Client actions are indicated in the left column, CA actions are +indicated in the right column. A blank action signifies that no message +was received. Note that these examples assume that the CA enforces the +certificate-name uniqueness property defined in Section 2.1.1.1. + +The first transaction, for example, would read like this: + "Client Sends PKCSReq message with transaction ID 1 to the + CA. The CA signs the certificate and constructs a CertRep Message + containing the signed certificate with a transaction ID 1. The client + receives the message and installs the cert locally." + +Successful Enrollment Case: no manual authentication +PKCSReq (1) ----------> CA Signs Cert +Client Installs Cert <---------- CertRep (1) SIGNED CERT + + + +Successful Enrollment Case: manual authentication required +PKCSReq (10) ----------> Cert Request goes into Queue +Client Polls <---------- CertRep (10) PENDING +GetCertInitial (10) ----------> Still pending +Client Polls <---------- CertRep (10) PENDING +GetCertInitial (10) ----------> Still pending +Client Polls <---------- CertRep (10) PENDING +GetCertInitial (10) ----------> Still pending +Client Polls <---------- CertRep (10) PENDING +GetCertInitial (10) ----------> Cert has been signed +Client Installs Cert <---------- CertRep (10) SIGNED CERT + + + +Resync Case - CA Receive and Signs PKCSReq, Client Did not receive +CertRep: + +PKCSReq (3) ----------> Cert Request goes into queue + <---------- CertRep (3) PENDING +GetCertInitial (3) ----------> + <---------- CertRep (3) PENDING +GetCertInitial (3) -----------> + <----------- CA signed Cert and sent back + CertRep(3) +(Time Out) +PKCSReq (3) ----------> Cert already signed, sent back to + client +Client Installs Cert <---------- CertRep (3) SIGNED CERT + + + + Liu/Madson/McGrew/Nourse [Page 39] + +Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005 + + +Case when NVRAM is lost and client has to generate a new key pair, there +is no change of name information: + +PKCSReq (4) ----------> CA Signs Cert +Client Installs Cert <---------- CertRep (4) SIGNED CERT +(Client looses Cert) +PKCSReq (5) ----------> There is already a valid cert with + this DN. +Client Admin Revokes <---------- CertRep (5) OVERLAPPING CERT ERROR +PKCSReq (5) ----------> CA Signs Cert +Client Installs Cert <---------- CertRep (5) SIGNED CERT + + +Case when client admin resync the enrollment using a different PKCS#10: +PKCSReq (6) ----------> CA Signs Cert + <---------- CertRep (6) SIGNED CERT +(Client timeout and admin starts another enrollment with a different + PKCS#10, but the same transaction id) +PKCSReq (6) with different PKCS#10 + ----------> There is already a valid cert with + this entity (by checking FQDN). + <---------- CertRep (6) INVALID PKCS#10 CERT + ERROR +Client admin either revokes the existing cert +or corrects the error by enrolling with +the same PKCS#10 as the first PKCSReq(6) +PKCSReq (6) ----------> CA find the existing Cert +Client Installs Cert <---------- CertRep (6) SIGNED CERT + + +Resync case when server is slow in response: +PKCSReq (13) ----------> Cert Request goes into Queue + <---------- CertRep (13) PENDING +GetCertInitial ----------> Still pending + <---------- CertRep (13) PENDING +GetCertInitial ----------> Still pending + <---------- CertRep (13) PENDING +GetCertInitial ----------> Still pending + <---------- CertRep (13) PENDING +GetCertInitial ----------> Still pending +(TimeOut) <---------- CertRep (13) PENDING +* Case 1 +PKCSReq (13) ----------> Still pending +Client polls <---------- CertRep (13) PENDING +CertCertInitial ----------> Cert has been signed +Client Installs Cert <---------- CertRep (13) SIGNED CERT +* Case 2 +PKCSReq (13) ----------> Cert has been signed +Client Installs Cert <---------- CertRep (13) SIGNED CERT + + + + + Liu/Madson/McGrew/Nourse [Page 40] + +Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005 + +Appendix F. CA Capabilities + +The response for a GetCACaps message is a list of CA capabilities, in +plain text, separated by characters, as follows (quotation marks +are NOT sent): + +Keyword Description + +"GetNextCACert" CA Supports the GetNextCACert message. +"POSTPKIOperation" PKIOPeration messages may be sent via HTTP POST. +"SHA-1" CA Supports the SHA-1 hashing algorithm in + signatures and fingerprints. If present, the + client SHOULD use SHA-1. If absent, the client + MUST use MD5 to maintain backward compatability. +"Renewal" Clients may use current certificate and key to + authenticate an enrollment request for a new + certificate. + +A client must be able to accept and ignore any unknown keywords that +might be sent back by a CA that implements a future version of SCEP. + +Example: + +GET /cgi-bin/pkiclient.exe?operation=GetCACaps&message=myca + +returns: + +GetNextCACert +POSTPKIOperation + +This means that the CA supports the GetNextCACert message and allows +PKIOperation messages (PKCSreq, GetCert, GetCertInitial...) to be sent +using HTTP POST. + + + Liu/Madson/McGrew/Nourse [Page 41] + +Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005 + +Appendix G. Certificate Renewal and CA Key Rollover + +To renew a client certificate, use the PKCSreq message and sign it with +the existing client certificate instead of a self-signed certificate. + +To obtain the new CA certificate prior to the expiration of the current +one, use the GetNextCACert message if the CA supports it. + +To obtain a new client certificate signed by the new CA certificate, +use the new CA or RA certificate in the message envelope. + + +Example: + +GetNextCACert ----------> + <---------- CertRep (3) New CA certificate + +PKCSReq* (1) ----------> CA Signs certificate with NEW key +Client Stores Cert <---------- CertRep (3) Certificate issued +for installation when from NEW CA certificate and keypair. +existing cert expires. + + +*enveloped for new CA or RA cert and keypair. The CA will use the +envelope to determine which key and certificate to use to issue the +client certificate. + + + Liu/Madson/McGrew/Nourse [Page 42] + +Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005 + +Appendix H. PKIOperation via HTTP POST Message + +If the remote CA supports it, any of the PKCS#7-encoded SCEP messages +may be sent via HTTP POST instead of HTTP GET. This is allowed for +any SCEP message except GetCACert, GetCACertChain, GetNextCACert, +or GetCACaps. In this form of the message, Base 64 encoding is not +used. + +POST /cgi-bin/pkiclient.exe?operation=PKIOperation + + +The client can verify that the CA supports SCEP messages via POST by +looking for the "POSTPKIOperation" capability (See Appendix F). + + + + + + + Liu/Madson/McGrew/Nourse [Page 43] + +Cisco Systems' Simple Certificate Enrollment Protocol Feb 2005 + +Appendix Y. Author Contact Information + +Xiaoyi Liu Cheryl Madson +Cisco Cisco +510 McCarthy Drive 510 McCarthy Drive +Milpitas, CA Milpitas, CA. +xliu@cisco.com cmadson@cisco.com + + +David McGrew Andrew Nourse +Cisco Cisco +170 West Tasman Drive 510 McCarthy Drive +San Jose, CA 94134 Milpitas, CA. +mcgrew@cisco.com nourse@cisco.com + + + + +Appendix Z. Copyright Section + +Copyright (C) The Internet Society (2005). This document is subject +to the rights, licenses and restrictions contained in BCP 78, and +except as set forth therein, the authors retain all their rights. + +This document and the information contained herein are provided on an +"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS +OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET +ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, +INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE +INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED +WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + + + +This draft expires 11 Aug 2005 + +[End of draft-nourse-scep-11.txt] + diff --git a/fileutils.c b/fileutils.c new file mode 100644 index 0000000..558550c --- /dev/null +++ b/fileutils.c @@ -0,0 +1,405 @@ + +/* + * sscep -- Simple SCEP client implementation + * Copyright (c) Jarkko Turkulainen 2003. All rights reserved. + * See the file COPYRIGHT for licensing information. + */ + + +/* Misc. cert/crl manipulation routines */ + +#include "sscep.h" + +/* Open the inner, decrypted PKCS7 and try to write CRL. */ +void +write_crl(struct scep *s) { + PKCS7 *p7; + STACK_OF(X509_CRL) *crls; + X509_CRL *crl; + FILE *fp; + + /* Get CRL */ + p7 = s->reply_p7; + crls = p7->d.sign->crl; + + /* We expect only one CRL: */ + crl = sk_X509_CRL_value(crls, 0); + if (crl == NULL) { + fprintf(stderr, "%s: cannot find CRL in reply\n", pname); + exit (SCEP_PKISTATUS_FILE); + } + + /* Write PEM-formatted file: */ + if (!(fp = fopen(w_char, "w"))) { + fprintf(stderr, "%s: cannot open CRL file for writing\n", + pname); + exit (SCEP_PKISTATUS_FILE); + } + if (v_flag) + printf("%s: writing CRL\n", pname); + if (d_flag) + PEM_write_X509_CRL(stdout, crl); + if (PEM_write_X509_CRL(fp, crl) != 1) { + fprintf(stderr, "%s: error while writing CRL " + "file\n", pname); + ERR_print_errors_fp(stderr); + exit (SCEP_PKISTATUS_FILE); + } + printf("%s: CRL written as %s\n", pname, w_char); + (void)fclose(fp); +} + +static int +compare_subject(X509 * cert) +{ + int rc = X509_NAME_cmp(X509_get_subject_name(cert), X509_REQ_get_subject_name(request)); + + if (rc) + { + /* X509_NAME_cmp should return 0 when X509_get_subject_name() + * and X509_REQ_get_subject_name() match. There is a bug + * report on that issue (1422). + * + * Assume we cannot trust X509_NAME_cmp() and perform a strcmp() + * when X509_NAME_cmp returns true (which is in fact false ;-)) + */ + char cert_buf[1024]; + char req_buf[1024]; + X509_NAME_oneline(X509_get_subject_name(cert), cert_buf, sizeof(cert_buf)); + X509_NAME_oneline(X509_REQ_get_subject_name(request), req_buf, sizeof(req_buf)); + if (v_flag) + printf (" X509_NAME_cmp() workaround: strcmp request subject (%s) to cert subject (%s)\n", req_buf, cert_buf); + rc = strcmp (cert_buf, req_buf); + } + + return rc; +} /* is_same_cn */ + +/* Open the inner, decrypted PKCS7 and try to write cert. */ +void +write_local_cert(struct scep *s) { + PKCS7 *p7; + STACK_OF(X509) *certs; + X509 *cert = NULL; + FILE *fp; + int i; + + localcert = NULL; + + /* Get certs */ + p7 = s->reply_p7; + certs = p7->d.sign->cert; + + if (v_flag) { + printf ("write_local_cert(): found %d cert(s)\n", sk_X509_num(certs)); + } + + /* Find cert */ + for (i = 0; i < sk_X509_num(certs); i++) { + char buffer[1024]; + cert = sk_X509_value(certs, i); + if (v_flag) { + printf("%s: found certificate with\n" + " subject: '%s'\n", pname, + X509_NAME_oneline(X509_get_subject_name(cert), + buffer, sizeof(buffer))); + printf(" issuer: %s\n", + X509_NAME_oneline(X509_get_issuer_name(cert), + buffer, sizeof(buffer))); + printf(" request_subject: '%s'\n", + X509_NAME_oneline(X509_REQ_get_subject_name(request), + buffer, sizeof(buffer))); + } + /* The subject has to match that of our request */ + if (!compare_subject(cert)) { + + if (v_flag) + printf ("CN's of request and certificate matched!\n"); + + /* The subject cannot be the issuer (selfsigned) */ + if (X509_NAME_cmp(X509_get_subject_name(cert), + X509_get_issuer_name(cert))) { + localcert = cert; + break; + } + } + } + if (localcert == NULL) { + fprintf(stderr, "%s: cannot find requested certificate\n", + pname); + exit (SCEP_PKISTATUS_FILE); + + } + /* Write PEM-formatted file: */ + if (!(fp = fopen(l_char, "w"))) { + fprintf(stderr, "%s: cannot open cert file for writing\n", + pname); + exit (SCEP_PKISTATUS_FILE); + } + if (v_flag) + printf("%s: writing cert\n", pname); + if (d_flag) + PEM_write_X509(stdout, localcert); + if (PEM_write_X509(fp, localcert) != 1) { + fprintf(stderr, "%s: error while writing certificate " + "file\n", pname); + ERR_print_errors_fp(stderr); + exit (SCEP_PKISTATUS_FILE); + } + printf("%s: certificate written as %s\n", pname, l_char); + (void)fclose(fp); +} + +/* Open the inner, decrypted PKCS7 and try to write cert. */ +void +write_other_cert(struct scep *s) { + PKCS7 *p7; + STACK_OF(X509) *certs; + X509 *cert = NULL; + FILE *fp; + int i; + + othercert = NULL; + + /* Get certs */ + p7 = s->reply_p7; + certs = p7->d.sign->cert; + + /* Find cert */ + for (i = 0; i < sk_X509_num(certs); i++) { + char buffer[1024]; + + cert = sk_X509_value(certs, i); + if (v_flag) { + printf("%s: found certificate with\n" + " subject: %s\n", pname, + X509_NAME_oneline(X509_get_subject_name(cert), + buffer, sizeof(buffer))); + printf(" issuer: %s\n", + X509_NAME_oneline(X509_get_issuer_name(cert), + buffer, sizeof(buffer))); + } + /* The serial has to match to requested one */ + if (!ASN1_INTEGER_cmp(X509_get_serialNumber(cert), + s->ias_getcert->serial)) { + othercert = cert; + break; + } + } + if (othercert == NULL) { + fprintf(stderr, "%s: cannot find certificate\n", pname); + exit (SCEP_PKISTATUS_FILE); + + } + /* Write PEM-formatted file: */ + if (!(fp = fopen(w_char, "w"))) { + fprintf(stderr, "%s: cannot open cert file for writing\n", + pname); + exit (SCEP_PKISTATUS_FILE); + } + if (v_flag) + printf("%s: writing cert\n", pname); + if (d_flag) + PEM_write_X509(stdout, othercert); + if (PEM_write_X509(fp, othercert) != 1) { + fprintf(stderr, "%s: error while writing certificate " + "file\n", pname); + ERR_print_errors_fp(stderr); + exit (SCEP_PKISTATUS_FILE); + } + printf("%s: certificate written as %s\n", pname, w_char); + (void)fclose(fp); +} + + +/* + * Open the inner, decrypted PKCS7 and try to write CA/RA certificates + */ +int +write_ca_ra(struct http_reply *s) { + BIO *bio; + PKCS7 *p7; + STACK_OF(X509) *certs = NULL; + X509 *cert = NULL; + FILE *fp = NULL; + int c, i, index; + unsigned int n; + unsigned char md[EVP_MAX_MD_SIZE]; + X509_EXTENSION *ext; + + /* Create read-only memory bio */ + bio = BIO_new_mem_buf(s->payload, s->bytes); + p7 = d2i_PKCS7_bio(bio, NULL); + if (p7 == NULL) { + fprintf(stderr, "%s: error reading PKCS#7 data\n", pname); + ERR_print_errors_fp(stderr); + exit (SCEP_PKISTATUS_FILE); + } + /* Get certs */ + i = OBJ_obj2nid(p7->type); + switch (i) { + case NID_pkcs7_signed: + certs = p7->d.sign->cert; + break; + default: + printf("%s: wrong PKCS#7 type\n", pname); + exit (SCEP_PKISTATUS_FILE); + } + /* Check */ + if (certs == NULL) { + fprintf(stderr, "%s: cannot find certificates\n", pname); + exit (SCEP_PKISTATUS_FILE); + } + + /* Verify the chain + * XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX + */ + /* Find cert */ + for (i = 0; i < sk_X509_num(certs); i++) { + char buffer[1024]; + char name[1024]; + + memset(buffer, 0, 1024); + memset(name, 0, 1024); + cert = sk_X509_value(certs, i); + + /* Create name */ + snprintf(name, 1024, "%s-%d", c_char, i); + + /* Read and print certificate information */ + printf("\n%s: found certificate with\n subject: %s\n", pname, + X509_NAME_oneline(X509_get_subject_name(cert), + buffer, sizeof(buffer))); + printf(" issuer: %s\n", + X509_NAME_oneline(X509_get_issuer_name(cert), + buffer, sizeof(buffer))); + if (!X509_digest(cert, fp_alg, md, &n)) { + ERR_print_errors_fp(stderr); + exit (SCEP_PKISTATUS_FILE); + } + /* Print key usage: */ + index = X509_get_ext_by_NID(cert, NID_key_usage, -1); + if (index < 0) { + if (v_flag) + fprintf(stderr, "%s: cannot find key usage\n", + pname); + /* exit (SCEP_PKISTATUS_FILE); */ + } else { + ext = X509_get_ext(cert, index); + printf(" usage: "); + X509V3_EXT_print_fp(stdout, ext, 0, 0); + printf("\n"); + } + + printf(" %s fingerprint: ", OBJ_nid2sn(EVP_MD_type(fp_alg))); + for (c = 0; c < (int)n; c++) { + printf("%02X%c",md[c], (c + 1 == (int)n) ?'\n':':'); + } + + /* Write PEM-formatted file: */ + if (!(fp = fopen(name, "w"))) { + fprintf(stderr, "%s: cannot open cert file for " + "writing\n", pname); + exit (SCEP_PKISTATUS_FILE); + } + if (v_flag) + printf("%s: writing cert\n", pname); + if (d_flag) + PEM_write_X509(stdout, cert); + if (PEM_write_X509(fp, cert) != 1) { + fprintf(stderr, "%s: error while writing certificate " + "file\n", pname); + ERR_print_errors_fp(stderr); + exit (SCEP_PKISTATUS_FILE); + } + printf("%s: certificate written as %s\n", pname, name); + } + (void)fclose(fp); + exit (SCEP_PKISTATUS_SUCCESS); +} + +/* Read CA cert and optionally, encyption CA cert */ + +void +read_ca_cert(void) { + /* Read CA cert file */ + if (!c_flag || !(cafile = fopen(c_char, "r"))) { + fprintf(stderr, "%s: cannot open CA cert file\n", pname); + exit (SCEP_PKISTATUS_FILE); + } + if (!PEM_read_X509(cafile, &cacert, NULL, NULL)) { + fprintf(stderr, "%s: error while reading CA cert\n", pname); + ERR_print_errors_fp(stderr); + exit (SCEP_PKISTATUS_FILE); + } + fclose(cafile); + + /* Read enc CA cert */ + if (e_flag) { + if (!(cafile = fopen(e_char, "r"))) { + fprintf(stderr, "%s: cannot open enc CA cert file\n", + pname); + exit (SCEP_PKISTATUS_FILE); + } + if (!PEM_read_X509(cafile, &encert, NULL, NULL)) { + fprintf(stderr,"%s: error while reading enc CA cert\n", + pname); + ERR_print_errors_fp(stderr); + exit (SCEP_PKISTATUS_FILE); + } + fclose(cafile); + } +} + +/* Read local certificate (GetCert and GetCrl) */ + +void +read_cert(X509** cert, char* filename) { + FILE *file; + if (!(file = fopen(filename, "r"))) { + fprintf(stderr, "%s: cannot open cert file %s\n", pname, filename); + exit (SCEP_PKISTATUS_FILE); + } + if (!PEM_read_X509(file, cert, NULL, NULL)) { + fprintf(stderr, "%s: error while reading cert %s\n", pname, filename); + ERR_print_errors_fp(stderr); + exit (SCEP_PKISTATUS_FILE); + } + fclose(file); +} + +/* Read private key */ + +void +read_key(EVP_PKEY** key, char* filename) { + FILE *file; + /* Read private key file */ + if (!(file = fopen(filename, "r"))) { + fprintf(stderr, "%s: cannot open private key file %s\n", pname, filename); + exit (SCEP_PKISTATUS_FILE); + } + if (!PEM_read_PrivateKey(file, key, NULL, NULL)) { + fprintf(stderr, "%s: error while reading private key %s\n", pname, filename); + ERR_print_errors_fp(stderr); + exit (SCEP_PKISTATUS_FILE); + } + fclose(file); +} + +/* Read PKCS#10 request */ + +void +read_request(void) { + /* Read certificate request file */ + if (!r_flag || !(reqfile = fopen(r_char, "r"))) { + fprintf(stderr, "%s: cannot open certificate request\n", pname); + exit (SCEP_PKISTATUS_FILE); + } + if (!PEM_read_X509_REQ(reqfile, &request, NULL, NULL)) { + fprintf(stderr, "%s: error while reading request file\n", pname); + ERR_print_errors_fp(stderr); + exit (SCEP_PKISTATUS_FILE); + } + fclose(reqfile); +} + diff --git a/ias.c b/ias.c new file mode 100644 index 0000000..bf1fb11 --- /dev/null +++ b/ias.c @@ -0,0 +1,60 @@ + +/* + * sscep -- Simple SCEP client implementation + * Copyright (c) Jarkko Turkulainen 2003. All rights reserved. + * See the file COPYRIGHT for licensing information. + */ + + +/* + * Routines for pkcs7_issuer_and_subject data type needed when + * sending GETCertInitial requests. + */ + +#include "sscep.h" +#include "ias.h" + +int i2d_pkcs7_issuer_and_subject(pkcs7_issuer_and_subject *a, + unsigned char **pp) { + + M_ASN1_I2D_vars(a); + M_ASN1_I2D_len(a->issuer,i2d_X509_NAME); + M_ASN1_I2D_len(a->subject,i2d_X509_NAME); + M_ASN1_I2D_seq_total(); + M_ASN1_I2D_put(a->issuer,i2d_X509_NAME); + M_ASN1_I2D_put(a->subject,i2d_X509_NAME); + M_ASN1_I2D_finish(); +} + +pkcs7_issuer_and_subject * +d2i_pkcs7_issuer_and_subject(pkcs7_issuer_and_subject **a, + unsigned char **pp, long length) { + + M_ASN1_D2I_vars(a, pkcs7_issuer_and_subject *, + pkcs7_issuer_and_subject_new); + M_ASN1_D2I_Init(); + M_ASN1_D2I_start_sequence(); + M_ASN1_D2I_get(ret->issuer,d2i_X509_NAME); + M_ASN1_D2I_get(ret->subject,d2i_X509_NAME); + M_ASN1_D2I_Finish(a,pkcs7_issuer_and_subject_free, 99); +} + +pkcs7_issuer_and_subject *pkcs7_issuer_and_subject_new(void) { + + pkcs7_issuer_and_subject *ret=NULL; + ASN1_CTX c; + M_ASN1_New_Malloc(ret,pkcs7_issuer_and_subject); + M_ASN1_New(ret->issuer,X509_NAME_new); + M_ASN1_New(ret->subject,X509_NAME_new); + return(ret); + M_ASN1_New_Error(199); +} + +void pkcs7_issuer_and_subject_free(pkcs7_issuer_and_subject *a) { + + if (a == NULL) return; + X509_NAME_free(a->issuer); + M_ASN1_INTEGER_free(a->subject); + OPENSSL_free(a); +} + diff --git a/ias.h b/ias.h new file mode 100644 index 0000000..470d908 --- /dev/null +++ b/ias.h @@ -0,0 +1,23 @@ + +/* + * sscep -- Simple SCEP client implementation + * Copyright (c) Jarkko Turkulainen 2003. All rights reserved. + * See the file COPYRIGHT for licensing information. + */ + +/* Macros */ + +#define i2d_pkcs7_issuer_and_subject_bio(bp, ias) \ + ASN1_i2d_bio(i2d_pkcs7_issuer_and_subject, bp, (unsigned char *)ias) +#define i2d_PKCS7_ISSUER_AND_SERIAL_bio(bp, ias) \ + ASN1_i2d_bio(i2d_PKCS7_ISSUER_AND_SERIAL, bp, (unsigned char *)ias) + +/* Routines */ +int i2d_pkcs7_issuer_and_subject(pkcs7_issuer_and_subject *, unsigned char **); +pkcs7_issuer_and_subject * +d2i_pkcs7_issuer_and_subject(pkcs7_issuer_and_subject **, unsigned char **, + long length); +pkcs7_issuer_and_subject *pkcs7_issuer_and_subject_new(void); +void pkcs7_issuer_and_subject_free(pkcs7_issuer_and_subject *); + + diff --git a/init.c b/init.c new file mode 100644 index 0000000..72ec427 --- /dev/null +++ b/init.c @@ -0,0 +1,234 @@ +/* + * sscep -- Simple SCEP client implementation + * Copyright (c) Jarkko Turkulainen 2003. All rights reserved. + * See the file COPYRIGHT for licensing information. + */ + +/* Configuration file initialization */ + +#include "sscep.h" + +void +init_config(FILE *conf) { + char buff[1024]; + char *str1, *str2; + int k, i, lines; + + lines = 0; + while (fgets(buff, 1024, conf)) { + lines++; + + /* null-terminate: */ + buff[strlen(buff)-1] = '\0'; + + /* skip leading white space: */ + for ( i = 0 ; isspace(buff[i]) ; i++) + ; + + /* empty line? */ + if (!strlen(&buff[i])) + continue; + + /* comment? */ + if (!strncmp("#", &buff[i], 1)) + continue; + + /* fetch key and value: */ + + k = 0; + str1 = get_string(&buff[i]); + i += strlen(&buff[i])+1; + for ( ; isspace(buff[i]) ; i++ ) + ; + k = 1; + str2 = get_string(&buff[i]); + + /* if not found... */ + if (!strlen(str2) && v_flag) { + fprintf(stderr, "%s: config file parse" + " error, line %d\n", pname, lines); + /* Parse configuration keys */ + } else { + if (!strncmp(str1, "CACertFile", 10)) { + if (!c_flag) { + c_flag = 1; + if (!(c_char = strdup(str2))) + error_memory(); + } + } else if (!strncmp(str1, "CAIdentifier", 12)) { + if (!i_flag) { + i_flag = 1; + if (!(i_char = strdup(str2))) + error_memory(); + } + } else if (!strncmp(str1, "CertReqFile", 11)) { + if (!r_flag) { + r_flag = 1; + if (!(r_char = strdup(str2))) + error_memory(); + } + } else if (!strncmp(str1, "Debug", 5)) { + if (!strncmp(str2, "yes", 3) && !d_flag) + d_flag = 1; + } else if (!strncmp(str1, "EncCertFile", 11)) { + if (!e_flag) { + e_flag = 1; + if (!(e_char = strdup(str2))) + error_memory(); + } + } else if (!strncmp(str1, "EncAlgorithm", 11)) { + if (!E_flag) { + E_flag = 1; + if (!(E_char = strdup(str2))) + error_memory(); + } + } else if (!strncmp(str1, "FingerPrint", 10)) { + if (!F_flag) { + F_flag = 1; + if (!(F_char = strdup(str2))) + error_memory(); + } + } else if (!strncmp(str1, "GetCertFile", 11) && + (operation_flag == SCEP_OPERATION_GETCERT)) { + if (!w_flag) { + w_flag = 1; + if (!(w_char = strdup(str2))) + error_memory(); + } + } else if (!strncmp(str1, "GetCrlFile", 10) && + (operation_flag == SCEP_OPERATION_GETCRL)) { + if (!w_flag) { + w_flag = 1; + if (!(w_char = strdup(str2))) + error_memory(); + } + } else if (!strncmp(str1, "GetCertSerial", 13)) { + if (!s_flag) { + s_flag = 1; + if (!(s_char = strdup(str2))) + error_memory(); + } + } else if (!strncmp(str1, "LocalCertFile", 13)) { + if (!l_flag) { + l_flag = 1; + if (!(l_char = strdup(str2))) + error_memory(); + } + } else if (!strncmp(str1, "SignCertFile", 12)) { + if (!O_flag) { + O_flag = 1; + if (!(O_char = strdup(str2))) + error_memory(); + } + } else if (!strncmp(str1, "MaxPollCount", 12)) { + if (!n_flag) { + n_flag = 1; + n_num = atoi(str2); + } + } else if (!strncmp(str1, "MaxPollTime", 11)) { + if (!T_flag) { + T_flag = 1; + T_num = atoi(str2); + } + } else if (!strncmp(str1, "PrivateKeyFile", 15)) { + if (!k_flag) { + k_flag = 1; + if (!(k_char = strdup(str2))) + error_memory(); + } + } else if (!strncmp(str1, "SignKeyFile", 11)) { + if (!K_flag) { + K_flag = 1; + if (!(K_char = strdup(str2))) + error_memory(); + } + } else if (!strncmp(str1, "SelfSignedFile", 15)) { + if (!L_flag) { + L_flag = 1; + if (!(L_char = strdup(str2))) + error_memory(); + } + } else if (!strncmp(str1, "SigAlgorithm", 11)) { + if (!S_flag) { + S_flag = 1; + if (!(S_char = strdup(str2))) + error_memory(); + } + } else if (!strncmp(str1, "Proxy", 5)) { + if (!p_flag) { + p_flag = 1; + if (!(p_char = strdup(str2))) + error_memory(); + } + } else if (!strncmp(str1, "PollInterval", 11)) { + if (!t_flag) { + t_flag = 1; + t_num = atoi(str2); + } + } else if (!strncmp(str1, "URL", 3)) { + if (!u_flag) { + u_flag = 1; + if (!(url_char = strdup(str2))) + error_memory(); + } + } else if (!strncmp(str1, "Verbose", 7)) { + if (!strncmp(str2, "yes", 3) && !v_flag) + v_flag = 1; + } + } + } +} + +/* + * Find string, strip off '"'s. + */ + +char * +get_string(char *str) { + char *tmpstr; + char *retstr; + int c; + + /* Malloc space for string: */ + if (!(tmpstr = malloc(strlen(str)))) + error_memory(); + + /* check for '"': */ + if (*str != '"') c = 0; + else c = 1; + + /* not '"': */ + if (!c) { + retstr = str; + free(tmpstr); + while (*str++ != '\0') { + if (isspace(*str)) { + break; + } + } + *str = '\0'; + + /* starts with '"': */ + } else { + retstr = tmpstr; + while (*str++ != '\0') { + if (*str == '\\' && *(str+1) && *(str+1) == '"') { + *tmpstr++ = *(str+1); + str++; + } else if (*str == '"') + break; + else + *tmpstr++ = *str; + } + *tmpstr = '\0'; + } + return retstr; +} + +void +error_memory() { + fprintf(stderr, "%s: memory allocation failure, errno: %d\n", + pname, errno); + exit(1); +} + diff --git a/mkrequest b/mkrequest new file mode 100644 index 0000000..1665a8b --- /dev/null +++ b/mkrequest @@ -0,0 +1,171 @@ +#!/bin/sh +# +# mkrequest -- make client certificate request and RSA key +# Copyright (c) Jarkko Turkulainen 2003. All rights reserved. +# See the file COPYRIGHT for licensing information. +# +# Usage: $0 -ip|-dns|-email name [challenge] +# +# Required parameters (one of these): +# -ip name Use subjectAltName IP Address (example: -ip 1.2.3.4) +# -dns name Use subjectAltName FQDN (-dns gw.nowhere.com) +# -email name Use subjectAltName UFQDN (-email noone@nowhere.com) +# +# Optional parameter is the request challenge password, used for +# self-revocation and if SCEP server supports it, for automatic enrolling. +# +####################################################################### +# +# EDIT THE PARAMETERS BELOW IF YOU NEED +# + +# Prefix - key will be named as PREFIX.key and request PREFIX.csr +PREFIX=local + +# +# Additional DN components. Add if your company policy requires them. +# commonName is assigned automatically from the subjectAltName, or if your +# CA requires the use of unstructuredName as a DN, you must fill in +# the relevant attributes below. +# +# countryName (example: FI) +COUNTRY= +# +# stateOrProvinceName (example: Uusimaa) +STATE= +# +# localityName (example: Helsinki) +LOCALITY= +# +# organizationName (example: klake.org) +ORGANIZATION= +# +# organizationalUnitName (example: Sales) +ORGANIZATIONAL_UNIT= +# +# Some CAs may require you to use Cisco-style subject. +# OpenBSD isakmpd don't care about the subject, only that matter is the +# subjectAltName extension. If the CA won't honor that, the certificate +# is useless for isakmpd. +# +UNSTRUCTURED_NAME= +UNSTRUCTURED_ADDRESS= +SERIAL_NUMBER= + + +# RSA key length, minimum of 1024 recommended. +KEYBITS=1024 + +# +# NO NEED FOR EDITING BELOW THIS LINE +# +####################################################################### + + +if [ ! "$2" ]; then + echo "Usage: $0 -ip|-dns|-email name [challenge]" + exit 1 +fi +case $1 in + -ip) + NAME=CERTIP + PARAMETER=$2 + EXT=x509v3_IPAddr + ;; + -dns) + NAME=CERTNAME + PARAMETER=$2 + EXT=x509v3_DNS + ;; + -email) + NAME=CERTEMAIL + PARAMETER=$2 + EXT=x509v3_Email + ;; + *) + echo "Illegal subjectAltName extension $1" + echo "Usage: $0 -ip|-dns|-email name [keybits]" + exit 1 + ;; +esac + +if [ ! "$PREFIX" ]; then + PREFIX=$PARAMETER +fi + +if [ "$3" ]; then + PASSWORD=$3 +fi + +if [ ! "$UNSTRUCTURED_NAME" ]; then + if [ "$UNSTRUCTURED_ADDRESS" -o "$SERIAL_NUMBER" ]; then + echo "unstructuredName is required" + exit 1; + fi +fi + +# Generate key and request +openssl genrsa -out $PREFIX.key $KEYBITS +chmod 600 $PREFIX.key + +CONFIG=.$$client.cnf +cat << _EOF_ > $CONFIG +[ req ] +prompt = no +distinguished_name = req_distinguished_name +_EOF_ +if [ "$PASSWORD" ]; then + cat << _EOF_ >> $CONFIG +attributes=req_attributes +[ req_attributes ] +challengePassword=$PASSWORD +_EOF_ +fi +echo "[ req_distinguished_name ]" >> $CONFIG +if [ "$COUNTRY" ]; then + echo "C=$COUNTRY" >> $CONFIG +fi +if [ "$STATE" ]; then + echo "ST=$STATE" >> $CONFIG +fi +if [ "$LOCALITY" ]; then + echo "L=$LOCALITY" >> $CONFIG +fi +if [ "$ORGANIZATION" ]; then + echo "O=$ORGANIZATION" >> $CONFIG +fi +if [ "$OUNIT" ]; then + echo "OU=$ORGANIZATIONAL_UNIT" >> $CONFIG +fi +if [ ! "$UNSTRUCTURED_NAME" ]; then + echo "CN=$PARAMETER" >> $CONFIG +else + echo "unstructuredName=$UNSTRUCTURED_NAME" >> $CONFIG + if [ "$UNSTRUCTURED_ADDRESS" ]; then + echo "unstructuredAddress=$UNSTRUCTURED_ADDRESS" >> $CONFIG + fi + if [ "$SERIAL_NUMBER" ]; then + echo "serialNumber=$SERIAL_NUMBER" >> $CONFIG + fi +fi +cat << _EOF_ >> $CONFIG +[x509v3_IPAddr] +subjectAltName=critical,IP:$PARAMETER +[x509v3_DNS] +subjectAltName=critical,DNS:$PARAMETER +[x509v3_Email] +subjectAltName=critical,email:$PARAMETER +_EOF_ + +# Make request +openssl req -new -key $PREFIX.key -out $PREFIX.csr -config $CONFIG \ + -reqexts $EXT + +# Make a self-signed certificate from request subject +# Normally, this is done from the sscep +# openssl req -x509 -new -key $PREFIX.key -out $PREFIX-selfsigned.crt \ +# -config $CONFIG -extensions $EXT >/dev/null 2>&1 + +# Remove config file +rm -rf $CONFIG + diff --git a/net.c b/net.c new file mode 100644 index 0000000..beaf26d --- /dev/null +++ b/net.c @@ -0,0 +1,191 @@ + +/* + * sscep -- Simple SCEP client implementation + * Copyright (c) Jarkko Turkulainen 2003. All rights reserved. + * See the file COPYRIGHT for licensing information. + */ + + +/* HTTP routine */ + + +#include "sscep.h" + +int +send_msg(struct http_reply *http,char *msg,char *host,int port,int operation) { + int sd, rc, used, bytes; + struct sockaddr_in localAddr, servAddr; + struct hostent *h; + char tmp[1024], *buf, *p; + + /* resolve name */ + h = gethostbyname(host); + if (h == NULL) { + printf("unknown host '%s'\n", host); + return (1); + } + + /* fill in server socket structure: */ + servAddr.sin_family = h->h_addrtype; + memcpy((char *) &servAddr.sin_addr.s_addr, + h->h_addr_list[0], h->h_length); + servAddr.sin_port = htons(port); + + /* create socket */ + sd = socket(AF_INET, SOCK_STREAM, 0); + if (sd < 0) { + perror("cannot open socket "); + return (1); + } + + /* bind any port number */ + localAddr.sin_family = AF_INET; + localAddr.sin_addr.s_addr = htonl(INADDR_ANY); + localAddr.sin_port = htons(0); + rc = bind(sd, (struct sockaddr *) &localAddr, sizeof(localAddr)); + if (rc < 0) { + printf("cannot bind port TCP %u\n", port); + perror("error "); + return (1); + } + + /* connect to server */ + alarm(timeout); + rc = connect(sd, (struct sockaddr *) &servAddr, sizeof(servAddr)); + alarm(0); + if (rc < 0) { + perror("cannot connect"); + return (1); + } + + /* send data */ + alarm(timeout); + rc = send(sd, msg, sizeof(char) * strlen(msg), 0); + alarm(0); + if (rc < 0) { + perror("cannot send data "); + close(sd); + return (1); + } + + /* Get response */ + alarm(timeout); + buf = (char *)malloc(1024); + used = 0; + while ((bytes = read(sd, &buf[used], 1024)) > 0) { + used += bytes; + buf = (char *)realloc(buf, used + 1024); + } + alarm(0); + buf[used] = '\0'; + + /* Fetch the status code: */ + sscanf(buf, "%s %d ", tmp, &http->status); + if (v_flag) + fprintf(stdout, "%s: server returned status code %d\n", + pname, http->status); + + /* Set SCEP reply type */ + switch (operation) { + case SCEP_OPERATION_GETCA: + if (strstr(buf, MIME_GETCA)) { + http->type = SCEP_MIME_GETCA; + if (v_flag) + printf("%s: MIME header: %s\n", + pname, MIME_GETCA); + } else if (strstr(buf, MIME_GETCA_RA) || + strstr(buf, MIME_GETCA_RA_ENTRUST)) { + http->type = SCEP_MIME_GETCA_RA; + if (v_flag) + printf("%s: MIME header: %s\n", + pname, MIME_GETCA_RA); + } else { + if (v_flag) + printf("%s: mime_err: %s\n", pname,buf); + + goto mime_err; + } + break; + default: + if (!strstr(buf, MIME_PKI)) { + if (v_flag) + printf("%s: mime_err: %s\n", pname,buf); + goto mime_err; + } + http->type = SCEP_MIME_PKI; + if (v_flag) + printf("%s: MIME header: %s\n",pname,MIME_PKI); + break; + } + + /* Find payload */ + for (p = buf; *buf; buf++) { + if (!strncmp(buf, "\n\n", 2) && *(buf + 2)) { + http->payload = buf + 2; + break; + } + if (!strncmp(buf, "\n\r\n\r", 4) && *(buf + 4)) { + http->payload = buf + 4; + break; + } + if (!strncmp(buf, "\r\n\r\n", 4) && *(buf + 4)) { + http->payload = buf + 4; + break; + } + } + http->bytes = used - (http->payload - p); + if (http->payload == NULL) { + /* This is not necessarily error... + * XXXXXXXXXXXXXXXX check */ + fprintf(stderr, "%s: cannot find data from http reply\n",pname); + } + + close(sd); + return (0); + +mime_err: + fprintf(stderr, "%s: wrong (or missing) MIME content type\n", pname); + return (1); + +} + +/* URL-encode the input and return back encoded string */ +char * url_encode(char *s, size_t n) { + char *r; + size_t len; + int i; + char ch[2]; + + /* Allocate 2 times bigger space than the original string */ + len = 2 * n; + r = (char *)malloc(len); + if (r == NULL) { + return NULL; + } + strcpy(r, ""); + + /* Copy data */ + for (i = 0; i < n; i++) { + switch (*(s+i)) { + case '+': + strncat(r, "%2B", len); + break; + case '-': + strncat(r, "%2D", len); + break; + case '=': + strncat(r, "%3D", len); + break; + case '\n': + strncat(r, "%0A", len); + break; + default: + ch[0] = *(s+i); + ch[1] = '\0'; + strncat(r, ch, len); + break; + } + } + r[len-1] = '\0'; + return r; +} diff --git a/pkcs7.c b/pkcs7.c new file mode 100644 index 0000000..7550a2e --- /dev/null +++ b/pkcs7.c @@ -0,0 +1,734 @@ +/* + * sscep -- Simple SCEP client implementation + * Copyright (c) Jarkko Turkulainen 2003. All rights reserved. + * See the file COPYRIGHT for licensing information. + */ + +/* PKCS#7 routines */ + +#include "sscep.h" +#include "ias.h" + +/* + * Wrap data in PKCS#7 envelopes and base64-encode the result. + * Data is PKCS#10 request in PKCSReq, or pkcs7_issuer_and_subject + * structure in GetCertInitial and PKCS7_ISSUER_AND_SERIAL in + * GetCert and GETCrl. + */ +int pkcs7_wrap(struct scep *s) { + BIO *databio = NULL; + BIO *encbio = NULL; + BIO *pkcs7bio = NULL; + BIO *memorybio = NULL; + BIO *outbio = NULL; + BIO *base64bio = NULL; + unsigned char *buffer = NULL; + int rc, len = 0; + STACK_OF(X509) *recipients; + PKCS7 *p7enc; + PKCS7_SIGNER_INFO *si; + STACK_OF(X509_ATTRIBUTE) *attributes; + X509 *signercert = NULL; + EVP_PKEY *signerkey = NULL; + + /* Create a new sender nonce for all messages + * XXXXXXXXXXXXXX should it be per transaction? */ + s->sender_nonce_len = 16; + s->sender_nonce = (unsigned char *)malloc(s->sender_nonce_len); + RAND_bytes(s->sender_nonce, s->sender_nonce_len); + + /* Prepare data payload */ + switch(s->request_type) { + case SCEP_REQUEST_PKCSREQ: + /* + * Set printable message type + * We set this later as an autheticated attribute + * "messageType". + */ + s->request_type_str = SCEP_REQUEST_PKCSREQ_STR; + + /* Signer cert */ + signercert = s->signercert; + signerkey = s->signerkey; + + /* Create inner PKCS#7 */ + if (v_flag) + printf("%s: creating inner PKCS#7\n", pname); + + /* Read request in memory bio */ + databio = BIO_new(BIO_s_mem()); + if ((rc = i2d_X509_REQ_bio(databio, request)) <= 0) { + fprintf(stderr, "%s: error writing " + "certificate request in bio\n", pname); + ERR_print_errors_fp(stderr); + exit (SCEP_PKISTATUS_P7); + } + BIO_flush(databio); + BIO_set_flags(databio, BIO_FLAGS_MEM_RDONLY); + break; + + case SCEP_REQUEST_GETCERTINIT: + + /* Set printable message type */ + s->request_type_str = SCEP_REQUEST_GETCERTINIT_STR; + + /* Signer cert */ + signercert = s->signercert; + signerkey = s->signerkey; + + /* Create inner PKCS#7 */ + if (v_flag) + printf("%s: creating inner PKCS#7\n", pname); + + /* Read data in memory bio */ + databio = BIO_new(BIO_s_mem()); + if ((rc = i2d_pkcs7_issuer_and_subject_bio(databio, + s->ias_getcertinit)) <= 0) { + fprintf(stderr, "%s: error writing " + "GetCertInitial data in bio\n", pname); + ERR_print_errors_fp(stderr); + exit (SCEP_PKISTATUS_P7); + } + BIO_flush(databio); + BIO_set_flags(databio, BIO_FLAGS_MEM_RDONLY); + break; + + case SCEP_REQUEST_GETCERT: + /* Set printable message type */ + s->request_type_str = SCEP_REQUEST_GETCERT_STR; + + /* Signer cert */ + signercert = localcert; + signerkey = rsa; + + /* Read data in memory bio */ + databio = BIO_new(BIO_s_mem()); + if ((rc = i2d_PKCS7_ISSUER_AND_SERIAL_bio(databio, + s->ias_getcert)) <= 0) { + fprintf(stderr, "%s: error writing " + "GetCert data in bio\n", pname); + ERR_print_errors_fp(stderr); + exit (SCEP_PKISTATUS_P7); + } + BIO_flush(databio); + BIO_set_flags(databio, BIO_FLAGS_MEM_RDONLY); + break; + + case SCEP_REQUEST_GETCRL: + /* Set printable message type */ + s->request_type_str = SCEP_REQUEST_GETCRL_STR; + + /* Signer cert */ + signercert = localcert; + signerkey = rsa; + + /* Read data in memory bio */ + databio = BIO_new(BIO_s_mem()); + if ((rc = i2d_PKCS7_ISSUER_AND_SERIAL_bio(databio, + s->ias_getcrl)) <= 0) { + fprintf(stderr, "%s: error writing " + "GetCert data in bio\n", pname); + ERR_print_errors_fp(stderr); + exit (SCEP_PKISTATUS_P7); + } + BIO_flush(databio); + BIO_set_flags(databio, BIO_FLAGS_MEM_RDONLY); + break; + } + /* Below this is the common code for all request_type */ + + /* Read in the payload */ + s->request_len = BIO_get_mem_data(databio, &s->request_payload); + if (v_flag) + printf("%s: data payload size: %d bytes\n", pname, + s->request_len); + BIO_free(databio); + + /* Create encryption certificate stack */ + if ((recipients = sk_X509_new(NULL)) == NULL) { + fprintf(stderr, "%s: error creating " + "certificate stack\n", pname); + ERR_print_errors_fp(stderr); + exit (SCEP_PKISTATUS_P7); + } + /* Use different CA cert for encryption if requested */ + if (e_flag) { + if (sk_X509_push(recipients, encert) <= 0) { + fprintf(stderr, "%s: error adding recipient encryption " + "certificate\n", pname); + ERR_print_errors_fp(stderr); + exit (SCEP_PKISTATUS_P7); + } + /* Use same CA cert also for encryption */ + } else { + if (sk_X509_push(recipients, cacert) <= 0) { + fprintf(stderr, "%s: error adding recipient encryption " + "certificate\n", pname); + ERR_print_errors_fp(stderr); + exit (SCEP_PKISTATUS_P7); + } + } + + /* Create BIO for encryption */ + if ((encbio = BIO_new_mem_buf(s->request_payload, + s->request_len)) == NULL) { + fprintf(stderr, "%s: error creating data " "bio\n", pname); + ERR_print_errors_fp(stderr); + exit (SCEP_PKISTATUS_P7); + } + + /* Encrypt */ + if (!(p7enc = PKCS7_encrypt(recipients, encbio, + enc_alg, PKCS7_BINARY))) { + fprintf(stderr, "%s: request payload encrypt failed\n", pname); + ERR_print_errors_fp(stderr); + exit (SCEP_PKISTATUS_P7); + } + if (v_flag) + printf("%s: successfully encrypted payload\n", pname); + + /* Write encrypted data */ + memorybio = BIO_new(BIO_s_mem()); + if (i2d_PKCS7_bio(memorybio, p7enc) <= 0) { + fprintf(stderr, "%s: error writing encrypted data\n", pname); + ERR_print_errors_fp(stderr); + exit (SCEP_PKISTATUS_P7); + } + BIO_flush(memorybio); + BIO_set_flags(memorybio, BIO_FLAGS_MEM_RDONLY); + len = BIO_get_mem_data(memorybio, &buffer); + if (v_flag) + printf("%s: envelope size: %d bytes\n", pname, len); + if (d_flag) { + printf("%s: printing PEM fomatted PKCS#7\n", pname); + PEM_write_PKCS7(stdout, p7enc); + } + BIO_free(memorybio); + + /* Create outer PKCS#7 */ + if (v_flag) + printf("%s: creating outer PKCS#7\n", pname); + s->request_p7 = PKCS7_new(); + if (s->request_p7 == NULL) { + fprintf(stderr, "%s: failed creating PKCS#7 for signing\n", + pname); + ERR_print_errors_fp(stderr); + exit (SCEP_PKISTATUS_P7); + } + if (!PKCS7_set_type(s->request_p7, NID_pkcs7_signed)) { + fprintf(stderr, "%s: failed setting PKCS#7 type\n", pname); + ERR_print_errors_fp(stderr); + exit (SCEP_PKISTATUS_P7); + } + + /* Add signer certificate and signature */ + PKCS7_add_certificate(s->request_p7, signercert); + if ((si = PKCS7_add_signature(s->request_p7, + signercert, signerkey, sig_alg)) == NULL) { + fprintf(stderr, "%s: error adding PKCS#7 signature\n", pname); + ERR_print_errors_fp(stderr); + exit (SCEP_PKISTATUS_P7); + } + if (v_flag) + printf("%s: signature added successfully\n", pname); + + /* Set signed attributes */ + if (v_flag) + printf("%s: adding signed attributes\n", pname); + attributes = sk_X509_ATTRIBUTE_new_null(); + add_attribute_string(attributes, nid_transId, s->transaction_id); + add_attribute_string(attributes, nid_messageType, s->request_type_str); + add_attribute_octet(attributes, nid_senderNonce, s->sender_nonce, + s->sender_nonce_len); + PKCS7_set_signed_attributes(si, attributes); + + /* Add contentType */ + if (!PKCS7_add_signed_attribute(si, NID_pkcs9_contentType, + V_ASN1_OBJECT, OBJ_nid2obj(NID_pkcs7_data))) { + fprintf(stderr, "%s: error adding NID_pkcs9_contentType\n", + pname); + ERR_print_errors_fp(stderr); + exit (SCEP_PKISTATUS_P7); + } + + /* Create new content */ + if (!PKCS7_content_new(s->request_p7, NID_pkcs7_data)) { + fprintf(stderr, "%s: failed setting PKCS#7 content type\n", + pname); + ERR_print_errors_fp(stderr); + exit (SCEP_PKISTATUS_P7); + } + + /* Write data */ + pkcs7bio = PKCS7_dataInit(s->request_p7, NULL); + if (pkcs7bio == NULL) { + fprintf(stderr, "%s: error opening bio for writing PKCS#7 " + "data\n", pname); + ERR_print_errors_fp(stderr); + exit (SCEP_PKISTATUS_P7); + } + if (len != BIO_write(pkcs7bio, buffer, len)) { + fprintf(stderr, "%s: error writing PKCS#7 data\n", pname); + ERR_print_errors_fp(stderr); + exit (SCEP_PKISTATUS_P7); + } + if (v_flag) + printf("%s: PKCS#7 data written successfully\n", pname); + + /* Finalize PKCS#7 */ + if (!PKCS7_dataFinal(s->request_p7, pkcs7bio)) { + fprintf(stderr, "%s: error finalizing outer PKCS#7\n", pname); + ERR_print_errors_fp(stderr); + exit (SCEP_PKISTATUS_P7); + } + if (d_flag) { + printf("%s: printing PEM fomatted PKCS#7\n", pname); + PEM_write_PKCS7(stdout, s->request_p7); + } + + /* base64-encode the data */ + if (v_flag) + printf("%s: applying base64 encoding\n",pname); + + /* Create base64 filtering bio */ + memorybio = BIO_new(BIO_s_mem()); + base64bio = BIO_new(BIO_f_base64()); + outbio = BIO_push(base64bio, memorybio); + + /* Copy PKCS#7 */ + i2d_PKCS7_bio(outbio, s->request_p7); + BIO_flush(outbio); + BIO_set_flags(memorybio, BIO_FLAGS_MEM_RDONLY); + s->request_len = BIO_get_mem_data(memorybio, &s->request_payload); + if (v_flag) + printf("%s: base64 encoded payload size: %d bytes\n", + pname, s->request_len); + BIO_free(outbio); + + return (0); +} + +/* + * Unwrap PKCS#7 data and decrypt if necessary + */ +int pkcs7_unwrap(struct scep *s) { + BIO *memorybio; + BIO *outbio; + BIO *pkcs7bio; + int i, len, bytes, used; + STACK_OF(PKCS7_SIGNER_INFO) *sk; + PKCS7 *p7enc; + PKCS7_SIGNER_INFO *si; + STACK_OF(X509_ATTRIBUTE) *attribs; + char *p; + unsigned char buffer[1024]; + X509 *recipientcert; + EVP_PKEY *recipientkey; + + /* Create new memory BIO for outer PKCS#7 */ + memorybio = BIO_new(BIO_s_mem()); + + /* Read in data */ + if (v_flag) + printf("%s: reading outer PKCS#7\n",pname); + if ((len = BIO_write(memorybio, s->reply_payload, s->reply_len)) <= 0) { + fprintf(stderr, "%s: error reading PKCS#7 data\n", pname); + ERR_print_errors_fp(stderr); + exit (SCEP_PKISTATUS_P7); + } + if (v_flag) + printf("%s: PKCS#7 payload size: %d bytes\n", pname, len); + BIO_set_flags(memorybio, BIO_FLAGS_MEM_RDONLY); + s->reply_p7 = d2i_PKCS7_bio(memorybio, NULL); + if (d_flag) { + printf("%s: printing PEM fomatted PKCS#7\n", pname); + PEM_write_PKCS7(stdout, s->reply_p7); + } + + /* Make sure this is a signed PKCS#7 */ + if (!PKCS7_type_is_signed(s->reply_p7)) { + fprintf(stderr, "%s: PKCS#7 is not signed!\n", pname); + ERR_print_errors_fp(stderr); + exit (SCEP_PKISTATUS_P7); + } + + /* Create BIO for content data */ + pkcs7bio = PKCS7_dataInit(s->reply_p7, NULL); + if (pkcs7bio == NULL) { + fprintf(stderr, "%s: cannot get PKCS#7 data\n", pname); + ERR_print_errors_fp(stderr); + exit (SCEP_PKISTATUS_P7); + } + + /* Copy enveloped data from PKCS#7 */ + outbio = BIO_new(BIO_s_mem()); + used = 0; + for (;;) { + bytes = BIO_read(pkcs7bio, buffer, sizeof(buffer)); + used += bytes; + if (bytes <= 0) break; + BIO_write(outbio, buffer, bytes); + } + BIO_flush(outbio); + if (v_flag) + printf("%s: PKCS#7 contains %d bytes of enveloped data\n", + pname, used); + + /* Get signer */ + sk = PKCS7_get_signer_info(s->reply_p7); + if (sk == NULL) { + fprintf(stderr, "%s: cannot get signer info!\n", pname); + ERR_print_errors_fp(stderr); + exit (SCEP_PKISTATUS_P7); + } + + /* Verify signature */ + if (v_flag) + printf("%s: verifying signature\n", pname); + si = sk_PKCS7_SIGNER_INFO_value(sk, 0); + if (PKCS7_signatureVerify(pkcs7bio, s->reply_p7, si, cacert) <= 0) { + fprintf(stderr, "%s: error verifying signature\n", pname); + ERR_print_errors_fp(stderr); + exit (SCEP_PKISTATUS_P7); + } + if (v_flag) + printf("%s: signature ok\n", pname); + + /* Get signed attributes */ + if (v_flag) + printf("%s: finding signed attributes\n", pname); + attribs = PKCS7_get_signed_attributes(si); + if (attribs == NULL) { + fprintf(stderr, "%s: no attributes found\n", pname); + ERR_print_errors_fp(stderr); + exit (SCEP_PKISTATUS_P7); + } + + /* Transaction id */ + if ((get_signed_attribute(attribs, nid_transId, + V_ASN1_PRINTABLESTRING, &p)) == 1) { + fprintf(stderr, "%s: cannot find transId\n", pname); + exit (SCEP_PKISTATUS_P7); + } + if (v_flag) + printf("%s: reply transaction id: %s\n", pname, p); + if (strncmp(s->transaction_id, p, strlen(p))) { + fprintf(stderr, "%s: transaction id mismatch\n", pname); + exit (SCEP_PKISTATUS_P7); + } + /* Message type, should be of type CertRep */ + if ((i = get_signed_attribute(attribs, nid_messageType, + V_ASN1_PRINTABLESTRING, &p)) == 1) { + fprintf(stderr, "%s: cannot find messageType\n", pname); + exit (SCEP_PKISTATUS_P7); + } + if (atoi(p) != 3) { + fprintf(stderr, "%s: wrong message type in reply\n", pname); + exit (SCEP_PKISTATUS_P7); + } + if (v_flag) + printf("%s: reply message type is good\n", pname); + + /* Sender and recipient nonces: */ + if ((i = get_signed_attribute(attribs, nid_senderNonce, + V_ASN1_OCTET_STRING, &p)) == 1) { + if (v_flag) + fprintf(stderr, "%s: cannot find senderNonce\n", pname); + /* Some implementations don't put in on reply */ + /* XXXXXXXXXXXXXXXXXXXXXXXXXXXXX + exit (SCEP_PKISTATUS_P7); */ + } + s->reply_sender_nonce = p; + if (v_flag) { + printf("%s: senderNonce in reply: ", pname); + for (i = 0; i < 16; i++) { + printf("%02X", s->reply_sender_nonce[i]); + } + printf("\n"); + } + if (( i = get_signed_attribute(attribs, nid_recipientNonce, + V_ASN1_OCTET_STRING, &p)) == 1) { + fprintf(stderr, "%s: cannot find recipientNonce\n", pname); + exit (SCEP_PKISTATUS_P7); + } + s->reply_recipient_nonce = p; + if (v_flag) { + printf("%s: recipientNonce in reply: ", pname); + for (i = 0; i < 16; i++) { + printf("%02X", s->reply_recipient_nonce[i]); + } + printf("\n"); + } + /* + * Compare recipient nonce to original sender nonce + * The draft says nothing about this, but it makes sense to me.. + * XXXXXXXXXXXXXX check + */ + for (i = 0; i < 16; i++) { + if (s->sender_nonce[i] != s->reply_recipient_nonce[i]) { + if (v_flag) + fprintf(stderr, "%s: corrupted nonce " + "received\n", pname); + /* Instead of exit, break out */ + break; + } + } + /* Get pkiStatus */ + if ((i = get_signed_attribute(attribs, nid_pkiStatus, + V_ASN1_PRINTABLESTRING, &p)) == 1) { + fprintf(stderr, "%s: cannot find pkiStatus\n", pname); + /* This is a mandatory attribute.. */ + exit (SCEP_PKISTATUS_P7); + } + switch (atoi(p)) { + case SCEP_PKISTATUS_SUCCESS: + printf("%s: pkistatus: SUCCESS\n",pname); + s->pki_status = SCEP_PKISTATUS_SUCCESS; + break; + case SCEP_PKISTATUS_FAILURE: + printf("%s: pkistatus: FAILURE\n",pname); + s->pki_status = SCEP_PKISTATUS_FAILURE; + break; + case SCEP_PKISTATUS_PENDING: + printf("%s: pkistatus: PENDING\n",pname); + s->pki_status = SCEP_PKISTATUS_PENDING; + break; + default: + fprintf(stderr, "%s: wrong pkistatus in reply\n",pname); + exit (SCEP_PKISTATUS_P7); + } + + /* Get failInfo */ + if (s->pki_status == SCEP_PKISTATUS_FAILURE) { + if ((i = get_signed_attribute(attribs, nid_failInfo, + V_ASN1_PRINTABLESTRING, &p)) == 1) { + fprintf(stderr, "%s: cannot find failInfo\n", + pname); + exit (SCEP_PKISTATUS_P7); + } + switch (atoi(p)) { + case SCEP_FAILINFO_BADALG: + s->fail_info = SCEP_FAILINFO_BADALG; + printf("%s: reason: %s\n", pname, + SCEP_FAILINFO_BADALG_STR); + break; + case SCEP_FAILINFO_BADMSGCHK: + s->fail_info = SCEP_FAILINFO_BADMSGCHK; + printf("%s: reason: %s\n", pname, + SCEP_FAILINFO_BADMSGCHK_STR); + break; + case SCEP_FAILINFO_BADREQ: + s->fail_info = SCEP_FAILINFO_BADREQ; + printf("%s: reason: %s\n", pname, + SCEP_FAILINFO_BADREQ_STR); + break; + case SCEP_FAILINFO_BADTIME: + s->fail_info = SCEP_FAILINFO_BADTIME; + printf("%s: reason: %s\n", pname, + SCEP_FAILINFO_BADTIME_STR); + break; + case SCEP_FAILINFO_BADCERTID: + s->fail_info = SCEP_FAILINFO_BADCERTID; + printf("%s: reason: %s\n", pname, + SCEP_FAILINFO_BADCERTID_STR); + break; + default: + fprintf(stderr, "%s: wrong failInfo in " "reply\n",pname); + exit (SCEP_PKISTATUS_P7); + } + } + /* If FAILURE or PENDING, we can return */ + if (s->pki_status != SCEP_PKISTATUS_SUCCESS) { + /* There shouldn't be any more data... */ + if (v_flag && (used != 0)) { + fprintf(stderr, "%s: illegal size of payload\n", pname); + } + return (0); + } + /* We got success and expect data */ + if (used == 0) { + fprintf(stderr, "%s: illegal size of payload\n", pname); + exit (SCEP_PKISTATUS_P7); + } + + /* Decrypt the inner PKCS#7 */ + if ((s->request_type == SCEP_REQUEST_PKCSREQ) || + (s->request_type == SCEP_REQUEST_GETCERTINIT)) { + recipientcert = s->signercert; + recipientkey = s->signerkey; + } + else { + recipientcert = localcert; + recipientkey = rsa; + } + if (v_flag) + printf("%s: reading inner PKCS#7\n",pname); + p7enc = d2i_PKCS7_bio(outbio, NULL); + if (p7enc == NULL) { + fprintf(stderr, "%s: cannot read inner PKCS#7\n", pname); + ERR_print_errors_fp(stderr); + exit (SCEP_PKISTATUS_P7); + } + if (d_flag) { + printf("%s: printing PEM fomatted PKCS#7\n", pname); + PEM_write_PKCS7(stdout, p7enc); + } + + /* Decrypt the data */ + outbio = BIO_new(BIO_s_mem()); + if (v_flag) + printf("%s: decrypting inner PKCS#7\n",pname); + if (PKCS7_decrypt(p7enc, recipientkey, recipientcert, outbio, 0) == 0) { + fprintf(stderr, "%s: error decrypting inner PKCS#7\n", pname); + ERR_print_errors_fp(stderr); + exit (SCEP_PKISTATUS_P7); + } + BIO_flush(outbio); + + /* Write decrypted data */ + s->reply_len = BIO_get_mem_data(outbio, &s->reply_payload); + if (v_flag) + printf("%s: PKCS#7 payload size: %d bytes\n", pname, + s->reply_len); + BIO_set_flags(outbio, BIO_FLAGS_MEM_RDONLY); + s->reply_p7 = d2i_PKCS7_bio(outbio, NULL); + + return (0); + +} + +/* Add signed attributes */ +int +add_attribute_string(STACK_OF(X509_ATTRIBUTE) *attrs, int nid, char *buffer) { + ASN1_STRING *asn1_string = NULL; + X509_ATTRIBUTE *x509_a; + int c; + + if (v_flag) + printf("%s: adding string attribute %s\n", pname, + OBJ_nid2sn(nid)); + + asn1_string = ASN1_STRING_new(); + if ((c = ASN1_STRING_set(asn1_string, buffer, strlen(buffer))) <= 0) { + fprintf(stderr, "%s: error adding data to ASN.1 string\n", + pname); + ERR_print_errors_fp(stderr); + exit (SCEP_PKISTATUS_P7); + } + x509_a = X509_ATTRIBUTE_create(nid, V_ASN1_PRINTABLESTRING, + asn1_string); + sk_X509_ATTRIBUTE_push(attrs, x509_a); + + return (0); + +} +int +add_attribute_octet(STACK_OF(X509_ATTRIBUTE) *attrs, int nid, char *buffer, + int len) { + ASN1_STRING *asn1_string = NULL; + X509_ATTRIBUTE *x509_a; + int c; + + if (v_flag) + printf("%s: adding octet attribute %s\n", pname, + OBJ_nid2sn(nid)); + + asn1_string = ASN1_STRING_new(); + if ((c = ASN1_STRING_set(asn1_string, buffer, len)) <= 0) { + fprintf(stderr, "%s: error adding data to ASN.1 string\n", + pname); + ERR_print_errors_fp(stderr); + exit (SCEP_PKISTATUS_P7); + } + x509_a = X509_ATTRIBUTE_create(nid, V_ASN1_OCTET_STRING, + asn1_string); + sk_X509_ATTRIBUTE_push(attrs, x509_a); + + return (0); + +} + +/* Find signed attributes */ +int +get_signed_attribute(STACK_OF(X509_ATTRIBUTE) *attribs, int nid, + int type, char **buffer) { + int rc; + ASN1_TYPE *asn1_type; + unsigned int len; + + /* Find attribute */ + rc = get_attribute(attribs, nid, &asn1_type); + if (rc == 1) { + if (v_flag) + fprintf(stderr, "%s: error finding attribute\n",pname); + return (1); + } + if (ASN1_TYPE_get(asn1_type) != type) { + fprintf(stderr, "%s: wrong ASN.1 type\n",pname); + exit (SCEP_PKISTATUS_P7); + } + + /* Copy data */ + len = ASN1_STRING_length(asn1_type->value.asn1_string); + if (len <= 0) { + return (1); + } else if (v_flag) + printf("%s: allocating %d bytes for attribute\n", pname, len); + if (type == V_ASN1_PRINTABLESTRING) { + *buffer = (unsigned char *)malloc(len + 1); + } else { + *buffer = (unsigned char *)malloc(len); + } + if (*buffer == NULL) { + fprintf(stderr, "%s: cannot malloc space for attribute\n", + pname); + exit (SCEP_PKISTATUS_P7); + } + memcpy(*buffer, ASN1_STRING_data(asn1_type->value.asn1_string), len); + + /* Add null terminator if it's a PrintableString */ + if (type == V_ASN1_PRINTABLESTRING) { + (*buffer)[len] = 0; + len++; + } + + return (0); +} +int +get_attribute(STACK_OF(X509_ATTRIBUTE) *attribs, int required_nid, + ASN1_TYPE **asn1_type) { + int i; + ASN1_OBJECT *asn1_obj = NULL; + X509_ATTRIBUTE *x509_attrib = NULL; + + if (v_flag) + printf("%s: finding attribute %s\n", pname, + OBJ_nid2sn(required_nid)); + *asn1_type = NULL; + asn1_obj = OBJ_nid2obj(required_nid); + if (asn1_obj == NULL) { + fprintf(stderr, "%s: error creating ASN.1 object\n", pname); + ERR_print_errors_fp(stderr); + exit (SCEP_PKISTATUS_P7); + } + /* Find attribute */ + for (i = 0; i < sk_X509_ATTRIBUTE_num(attribs); i++) { + x509_attrib = sk_X509_ATTRIBUTE_value(attribs, i); + if (OBJ_cmp(x509_attrib->object, asn1_obj) == 0) { + if ((x509_attrib->value.set) && + (sk_ASN1_TYPE_num(x509_attrib->value.set) != 0)) { + if (*asn1_type != NULL) { + fprintf(stderr, "%s: no value found", + pname); + exit (SCEP_PKISTATUS_P7); + } + *asn1_type = + sk_ASN1_TYPE_value(x509_attrib->value.set, 0); + } + } + } + + if (*asn1_type == NULL) + return (1); + return (0); +} diff --git a/sceputils.c b/sceputils.c new file mode 100644 index 0000000..4d3e2a7 --- /dev/null +++ b/sceputils.c @@ -0,0 +1,255 @@ +/* + * sscep -- Simple SCEP client implementation + * Copyright (c) Jarkko Turkulainen 2003. All rights reserved. + * See the file COPYRIGHT for licensing information. + */ + +/* Misc. SCEP routines */ + +#include "sscep.h" +#include "ias.h" + +/* + * Initialize a SCEP transaction + */ +int new_transaction(struct scep *s) { + + /* Set the whole struct as 0 */ + memset(s, 0, sizeof(*s)); + + /* Set request and reply type */ + s->request_type = SCEP_REQUEST_NONE; + s->request_type_str = NULL; + s->reply_type = SCEP_REPLY_NONE; + s->reply_type_str = NULL; + s->pki_status = SCEP_PKISTATUS_UNSET; + s->pki_status_str = NULL; + s->fail_info_str = NULL; + + /* Set other variables */ + s->ias_getcertinit = pkcs7_issuer_and_subject_new(); + s->ias_getcert = PKCS7_ISSUER_AND_SERIAL_new(); + s->ias_getcrl = PKCS7_ISSUER_AND_SERIAL_new(); + + /* Create transaction id */ + if (operation_flag == SCEP_OPERATION_ENROLL) + s->transaction_id = key_fingerprint(request); + else + s->transaction_id = TRANS_ID_GETCERT; + if (v_flag) { + printf("%s: transaction id: %s\n", pname, s->transaction_id); + } + return (0); +} + +/* + * Create self signed certificate based on request subject. + * Set also subjectAltName extension if found from request. + */ +int new_selfsigned(struct scep *s) { + unsigned char *ptr; + X509 *cert; + X509_NAME *subject; + ASN1_INTEGER *serial; +/* No extensions in selfsigned + X509_EXTENSION *subject_altname; + STACK_OF(X509_EXTENSION) *req_extensions; + int subject_altname_pos; +*/ + + /* Extract public value of the local key from request */ + if (!(s->pkey = X509_REQ_get_pubkey(request))) { + fprintf(stderr, "%s: error getting public key from request\n", + pname); + ERR_print_errors_fp(stderr); + exit (SCEP_PKISTATUS_SS); + } + + /* Get subject, issuer and extensions */ + if (!(subject = X509_REQ_get_subject_name(request))) { + fprintf(stderr, "%s: error getting subject\n", pname); + ERR_print_errors_fp(stderr); + exit (SCEP_PKISTATUS_SS); + } + +/* Don't generate v3 extensions in selfsigned.. */ +#if 0 + if (!(req_extensions = X509_REQ_get_extensions(request))) { + fprintf(stderr, "%s: error getting X509v3 extensions\n", pname); + ERR_print_errors_fp(stderr); + exit (SCEP_PKISTATUS_SS); + } + /* Only supported extension is subjectAltName */ + subject_altname_pos = X509v3_get_ext_by_NID(req_extensions, + OBJ_sn2nid("subjectAltName"), -1); + subject_altname = X509v3_get_ext(req_extensions, subject_altname_pos); +#endif + + /* Create new certificate */ + if (!(cert = X509_new())) { + fprintf(stderr, "%s: error creating X509 certificate\n", pname); + ERR_print_errors_fp(stderr); + exit (SCEP_PKISTATUS_SS); + } + /* Set version (X509v3) */ + if (X509_set_version(cert, 2L) != 1) { + fprintf(stderr, "%s: error setting cert version\n", pname); + ERR_print_errors_fp(stderr); + exit (SCEP_PKISTATUS_SS); + } + /* Get serial no from transaction id */ + ptr = (unsigned char *)s->transaction_id; + if (!(serial = c2i_ASN1_INTEGER(NULL, &ptr, 32))) { + fprintf(stderr, "%s: error converting serial\n", pname); + ERR_print_errors_fp(stderr); + exit (SCEP_PKISTATUS_SS); + } + if (X509_set_serialNumber(cert, serial) != 1) { + fprintf(stderr, "%s: error setting serial\n", pname); + ERR_print_errors_fp(stderr); + exit (SCEP_PKISTATUS_SS); + } + /* Set subject */ + if (X509_set_subject_name(cert, subject) != 1) { + fprintf(stderr, "%s: error setting subject\n", pname); + ERR_print_errors_fp(stderr); + exit (SCEP_PKISTATUS_SS); + } + /* Set issuer (it's really the same as subject */ + if (X509_set_issuer_name(cert, subject) != 1) { + fprintf(stderr, "%s: error setting issuer\n", pname); + ERR_print_errors_fp(stderr); + exit (SCEP_PKISTATUS_SS); + } + /* Set public key */ + if (X509_set_pubkey(cert, s->pkey) != 1) { + fprintf(stderr, "%s: error setting public key", pname); + ERR_print_errors_fp(stderr); + exit (SCEP_PKISTATUS_SS); + } + /* Set duration */ + if (!(X509_gmtime_adj(X509_get_notBefore(cert), 0))) { + fprintf(stderr, "%s: error setting begin time", pname); + ERR_print_errors_fp(stderr); + exit (SCEP_PKISTATUS_SS); + } + if (!(X509_gmtime_adj(X509_get_notAfter(cert), + SELFSIGNED_EXPIRE_DAYS * 24 * 60))) { + fprintf(stderr, "%s: error setting end time", pname); + ERR_print_errors_fp(stderr); + exit (SCEP_PKISTATUS_SS); + } +/* Don't generate v3 extensions in selfsigned.. */ +#if 0 + /* Add subjectAltName */ + if (subject_altname && !X509_add_ext(cert, subject_altname, -1)) { + fprintf(stderr, "%s: error setting subjectAltName", pname); + ERR_print_errors_fp(stderr); + exit (SCEP_PKISTATUS_SS); + } +#endif + /* Sign certificate */ + if (!(X509_sign(cert, rsa, sig_alg))) { + fprintf(stderr, "%s: error signing certificate", pname); + ERR_print_errors_fp(stderr); + exit (SCEP_PKISTATUS_SS); + } + + /* Copy the pointer and return */ + s->signercert = cert; + s->signerkey = rsa; + return (0); +} + +/* + * Initialize SCEP + */ +int init_scep() { + unsigned char randpool[1024]; + + /* Add algorithms and init random pool */ + OpenSSL_add_all_algorithms(); + ERR_load_crypto_strings(); + RAND_seed(randpool, sizeof(randpool)); + + /* Create OpenSSL NIDs */ + + nid_messageType = OBJ_create("2.16.840.1.113733.1.9.2", "messageType", + "messageType"); + if (nid_messageType == 0) { + goto err; + } + nid_pkiStatus = OBJ_create("2.16.840.1.113733.1.9.3", "pkiStatus", + "pkiStatus"); + if (nid_pkiStatus == 0) { + goto err; + } + nid_failInfo = OBJ_create("2.16.840.1.113733.1.9.4", "failInfo", + "failInfo"); + if (nid_failInfo == 0) { + goto err; + } + nid_senderNonce = OBJ_create("2.16.840.1.113733.1.9.5", "senderNonce", + "senderNonce"); + if (nid_senderNonce == 0) { + goto err; + } + nid_recipientNonce = OBJ_create("2.16.840.1.113733.1.9.6", + "recipientNonce", "recipientNonce"); + if (nid_recipientNonce == 0) { + goto err; + } + nid_transId = OBJ_create("2.16.840.1.113733.1.9.7", "transId", + "transId"); + if (nid_transId == 0) { + goto err; + } + nid_extensionReq = OBJ_create("2.16.840.1.113733.1.9.8", + "extensionReq", "extensionReq"); + if (nid_extensionReq == 0) { + goto err; + } + return (0); + +err: + fprintf(stderr, "%s: cannot create OID\n", pname); + return (1); + +} + +/* + * Calculate transaction id. + * Return pointer to ascii presentation of the hash. + */ +char * +key_fingerprint(X509_REQ *req) { + char *ret, *str; + unsigned char *data, md[MD5_DIGEST_LENGTH]; + int c, len; + BIO *bio; + MD5_CTX ctx; + + /* Assign space for ASCII presentation of the digest */ + str = (unsigned char *)malloc(2 * MD5_DIGEST_LENGTH + 1); + ret = str; + + /* Create new memory bio for reading the public key */ + bio = BIO_new(BIO_s_mem()); + i2d_PUBKEY_bio(bio, X509_REQ_get_pubkey(req)); + len = BIO_get_mem_data(bio, &data); + + /* Calculate MD5 hash: */ + MD5_Init(&ctx); + MD5_Update(&ctx, data, len); + MD5_Final(md, &ctx); + + /* Copy as ASCII string and return: */ + for (c = 0; c < MD5_DIGEST_LENGTH; c++, str += 2) { + sprintf((char *)str, "%02X", md[c]); + + } + *(str+2) = '\0'; + return(ret); +} + + diff --git a/sscep.c b/sscep.c new file mode 100644 index 0000000..6440536 --- /dev/null +++ b/sscep.c @@ -0,0 +1,785 @@ + +/* + * sscep -- Simple SCEP client implementation + * Copyright (c) Jarkko Turkulainen 2003. All rights reserved. + * See the file COPYRIGHT for licensing information. + */ + + +/* Main routine */ + + +#include "sscep.h" + +static char * +handle_serial (char * serial) +{ + int hex = NULL != strchr (serial, ':'); + + /* Convert serial to a decimal serial when input is + a hexidecimal representation of the serial */ + if (hex) + { + unsigned int i,ii; + char *tmp_serial = (char*) calloc (strlen (serial) + 1,1); + + for (i=0,ii=0; '\0'!=serial[i];i++) + { + if (':'!=serial[i]) + tmp_serial[ii++]=serial[i]; + } + serial=tmp_serial; + } + else + { + unsigned int i; + for (i=0; ! hex && '\0' != serial[i]; i++) + hex = 'a'==serial[i]||'b'==serial[i]||'c'==serial[i]||'d'==serial[i]||'e'==serial[i]||'f'==serial[i]; + } + + if (hex) + { + ASN1_INTEGER* ai; + BIGNUM *ret; + BIO* in = BIO_new_mem_buf(serial, -1); + char buf[1025]; + ai=ASN1_INTEGER_new(); + if (ai == NULL) return NULL; + if (!a2i_ASN1_INTEGER(in,ai,buf,1024)) + { + return NULL; + } + ret=ASN1_INTEGER_to_BN(ai,NULL); + if (ret == NULL) + { + return NULL; + } + else + { + serial = BN_bn2dec(ret); + } + } + + return serial; +} /* handle_serial */ + +int +main(int argc, char **argv) { + int c, host_port = 80, count = 1; + char *host_name, *p, *dir_name = NULL; + char http_string[16384]; + struct http_reply reply; + unsigned int n; + unsigned char md[EVP_MAX_MD_SIZE]; + struct scep scep_t; + FILE *fp = NULL; + BIO *bp; + + /* Initialize scep layer */ + init_scep(); + + /* Set program name */ + pname = argv[0]; + + /* Define signal trap */ + (void)signal(SIGALRM, catchalarm); + + /* Set timeout */ + timeout = TIMEOUT; + + /* Check operation parameter */ + if (!argv[1]) { + usage(); + } else if (!strncmp(argv[1], "getca", 5)) { + operation_flag = SCEP_OPERATION_GETCA; + } else if (!strncmp(argv[1], "enroll", 6)) { + operation_flag = SCEP_OPERATION_ENROLL; + } else if (!strncmp(argv[1], "getcert", 7)) { + operation_flag = SCEP_OPERATION_GETCERT; + } else if (!strncmp(argv[1], "getcrl", 6)) { + operation_flag = SCEP_OPERATION_GETCRL; + } else { + fprintf(stderr, "%s: missing or illegal operation parameter\n", + argv[0]); + usage(); + } + /* Skip first parameter and parse the rest of the command */ + optind++; + while ((c = getopt(argc, argv, "c:de:E:f:F:i:k:K:l:L:n:O:p:r:Rs:S:t:T:u:vw:")) != -1) + switch(c) { + case 'c': + c_flag = 1; + c_char = optarg; + break; + case 'd': + d_flag = 1; + break; + case 'e': + e_flag = 1; + e_char = optarg; + break; + case 'E': + E_flag = 1; + E_char = optarg; + break; + case 'F': + F_flag = 1; + F_char = optarg; + break; + case 'f': + f_flag = 1; + f_char = optarg; + break; + case 'i': + i_flag = 1; + i_char = optarg; + break; + case 'k': + k_flag = 1; + k_char = optarg; + break; + case 'K': + K_flag = 1; + K_char = optarg; + break; + case 'l': + l_flag = 1; + l_char = optarg; + break; + case 'L': + L_flag = 1; + L_char = optarg; + break; + case 'n': + n_flag = 1; + n_num = atoi(optarg); + break; + case 'O': + O_flag = 1; + O_char = optarg; + break; + case 'p': + p_flag = 1; + p_char = optarg; + break; + case 'r': + r_flag = 1; + r_char = optarg; + break; + case 'R': + R_flag = 1; + break; + case 's': + s_flag = 1; + /*s_char = optarg;*/ + s_char = handle_serial(optarg); + break; + case 'S': + S_flag = 1; + S_char = optarg; + break; + case 't': + t_flag = 1; + t_num = atoi(optarg); + break; + case 'T': + T_flag = 1; + T_num = atoi(optarg); + break; + case 'u': + u_flag = 1; + url_char = optarg; + break; + case 'v': + v_flag = 1; + break; + case 'w': + w_flag = 1; + w_char = optarg; + break; + default: + printf("argv: %s\n", argv[optind]); + usage(); + } + argc -= optind; + argv += optind; + + /* If we debug, include verbose messages also */ + if (d_flag) + v_flag = 1; + + /* Read in the configuration file: */ + if (f_char) { + if (!(fp = fopen(f_char, "r"))) + fprintf(stderr, "%s: cannot open %s\n", pname, f_char); + else { + init_config(fp); + (void)fclose(fp); + } + } + if (v_flag) + fprintf(stdout, "%s: starting sscep, version %s\n", + pname, VERSION); + /* + * Check argument logic. + */ + if (!c_flag) { + if (operation_flag == SCEP_OPERATION_GETCA) { + fprintf(stderr, + "%s: missing CA certificate filename (-c)\n", pname); + exit (SCEP_PKISTATUS_ERROR); + } else { + fprintf(stderr, + "%s: missing CA certificate (-c)\n", pname); + exit (SCEP_PKISTATUS_ERROR); + } + } + if (operation_flag == SCEP_OPERATION_ENROLL) { + if (!k_flag) { + fprintf(stderr, "%s: missing private key (-k)\n",pname); + exit (SCEP_PKISTATUS_ERROR); + } + if (!r_flag) { + fprintf(stderr, "%s: missing request (-r)\n",pname); + exit (SCEP_PKISTATUS_ERROR); + + } + if (!l_flag) { + fprintf(stderr, "%s: missing local cert (-l)\n",pname); + exit (SCEP_PKISTATUS_ERROR); + } + /* Set polling limits */ + if (!n_flag) + n_num = MAX_POLL_COUNT; + if (!t_flag) + t_num = POLL_TIME; + if (!T_flag) + T_num = MAX_POLL_TIME; + } + if (operation_flag == SCEP_OPERATION_GETCERT) { + if (!l_flag) { + fprintf(stderr, "%s: missing local cert (-l)\n",pname); + exit (SCEP_PKISTATUS_ERROR); + } + if (!s_flag) { + fprintf(stderr, "%s: missing serial no (-s)\n", pname); + exit (SCEP_PKISTATUS_ERROR); + } + if (!w_flag) { + fprintf(stderr, "%s: missing cert file (-w)\n",pname); + exit (SCEP_PKISTATUS_ERROR); + } + if (!k_flag) { + fprintf(stderr, "%s: missing private key (-k)\n",pname); + exit (SCEP_PKISTATUS_ERROR); + } + } + if (operation_flag == SCEP_OPERATION_GETCRL) { + if (!l_flag) { + fprintf(stderr, "%s: missing local cert (-l)\n",pname); + exit (SCEP_PKISTATUS_ERROR); + } + if (!w_flag) { + fprintf(stderr, "%s: missing crl file (-w)\n",pname); + exit (SCEP_PKISTATUS_ERROR); + } + if (!k_flag) { + fprintf(stderr, "%s: missing private key (-k)\n",pname); + exit (SCEP_PKISTATUS_ERROR); + } + } + + /* Break down the URL */ + if (!u_flag) { + fprintf(stderr, "%s: missing URL (-u)\n", pname); + exit (SCEP_PKISTATUS_ERROR); + } + if (strncmp(url_char, "http://", 7) && !p_flag) { + fprintf(stderr, "%s: illegal URL %s\n", pname, url_char); + exit (SCEP_PKISTATUS_ERROR); + } + if (p_flag) { + host_name = strdup(p_char); + dir_name = url_char; + } + + /* Break down the URL */ + if (!u_flag) { + fprintf(stderr, "%s: missing URL (-u)\n", pname); + exit (SCEP_PKISTATUS_ERROR); + } + if (strncmp(url_char, "http://", 7) && !p_flag) { + fprintf(stderr, "%s: illegal URL %s\n", pname, url_char); + exit (SCEP_PKISTATUS_ERROR); + } + if (p_flag) { + host_name = strdup(p_char); + dir_name = url_char; + } else if (!(host_name = strdup(url_char + 7))) + error_memory(); + p = host_name; + c = 0; + while (*p != '\0') { + if (*p == '/' && !p_flag && !c) { + *p = '\0'; + if (*(p+1)) dir_name = p + 1; + c = 1; + } + if (*p == ':') { + *p = '\0'; + if (*(p+1)) host_port = atoi(p+1); + } + p++; + } + if (!dir_name) { + fprintf(stderr, "%s: illegal URL\n", pname); + exit (SCEP_PKISTATUS_ERROR); + } + if (host_port < 1 || host_port > 65550) { + fprintf(stderr, "%s: illegal port number %d\n", pname, + host_port); + exit (SCEP_PKISTATUS_ERROR); + } + if (v_flag) { + fprintf(stdout, "%s: hostname: %s\n", pname, host_name); + fprintf(stdout, "%s: directory: %s\n", pname, dir_name); + fprintf(stdout, "%s: port: %d\n", pname, host_port); + } + + /* Check algorithms */ + if (!E_flag) { + enc_alg = (EVP_CIPHER *)EVP_des_cbc(); + } else if (!strncmp(E_char, "blowfish", 8)) { + enc_alg = (EVP_CIPHER *)EVP_bf_cbc(); + } else if (!strncmp(E_char, "des", 3)) { + enc_alg = (EVP_CIPHER *)EVP_des_cbc(); + } else if (!strncmp(E_char, "3des", 4)) { + enc_alg = (EVP_CIPHER *)EVP_des_ede3_cbc(); + } else { + fprintf(stderr, "%s: unsupported algorithm: %s\n", + pname, E_char); + exit (SCEP_PKISTATUS_ERROR); + } + if (!S_flag) { + sig_alg = (EVP_MD *)EVP_md5(); + } else if (!strncmp(S_char, "md5", 3)) { + sig_alg = (EVP_MD *)EVP_md5(); + } else if (!strncmp(S_char, "sha1", 4)) { + sig_alg = (EVP_MD *)EVP_sha1(); + } else { + fprintf(stderr, "%s: unsupported algorithm: %s\n", + pname, S_char); + exit (SCEP_PKISTATUS_ERROR); + } + /* Fingerprint algorithm */ + if (!F_flag) { + fp_alg = (EVP_MD *)EVP_md5(); + } else if (!strncmp(F_char, "md5", 3)) { + fp_alg = (EVP_MD *)EVP_md5(); + } else if (!strncmp(F_char, "sha1", 4)) { + fp_alg = (EVP_MD *)EVP_sha1(); + } else { + fprintf(stderr, "%s: unsupported algorithm: %s\n", + pname, F_char); + exit (SCEP_PKISTATUS_ERROR); + } + + /* + * Switch to operation specific code + */ + switch(operation_flag) { + case SCEP_OPERATION_GETCA: + if (v_flag) + fprintf(stdout, "%s: SCEP_OPERATION_GETCA\n", + pname); + + /* Set CA identifier */ + if (!i_flag) + i_char = CA_IDENTIFIER; + + /* Forge the HTTP message */ + snprintf(http_string, sizeof(http_string), + "GET %s%s?operation=GetCACert&message=%s " + "HTTP/1.0\r\n\r\n", p_flag ? "" : "/", dir_name, + i_char); + printf("%s: requesting CA certificate\n", pname); + if (d_flag) + fprintf(stdout, "%s: scep msg: %s", pname, + http_string); + /* + * Send http message. + * Response is written to http_response struct "reply". + */ + reply.payload = NULL; + if ((c = send_msg (&reply, http_string, host_name, + host_port, operation_flag)) == 1) { + fprintf(stderr, "%s: error while sending " + "message\n", pname); + exit (SCEP_PKISTATUS_NET); + } + if (reply.payload == NULL) { + fprintf(stderr, "%s: no data, perhaps you " + "should define CA identifier (-i)\n", pname); + exit (SCEP_PKISTATUS_SUCCESS); + } + printf("%s: valid response from server\n", pname); + if (reply.type == SCEP_MIME_GETCA_RA) { + /* XXXXXXXXXXXXXXXXXXXXX chain not verified */ + write_ca_ra(&reply); + } + /* Read payload as DER X.509 object: */ + bp = BIO_new_mem_buf(reply.payload, reply.bytes); + cacert = d2i_X509_bio(bp, NULL); + + /* Read and print certificate information */ + if (!X509_digest(cacert, fp_alg, md, &n)) { + ERR_print_errors_fp(stderr); + exit (SCEP_PKISTATUS_ERROR); + } + printf("%s: %s fingerprint: ", pname, + OBJ_nid2sn(EVP_MD_type(fp_alg))); + for (c = 0; c < (int)n; c++) { + printf("%02X%c",md[c], + (c + 1 == (int)n) ?'\n':':'); + } + + /* Write PEM-formatted file: */ + if (!(fp = fopen(c_char, "w"))) { + fprintf(stderr, "%s: cannot open CA file for " + "writing\n", pname); + exit (SCEP_PKISTATUS_ERROR); + } + if (PEM_write_X509(fp, cacert) != 1) { + fprintf(stderr, "%s: error while writing CA " + "file\n", pname); + ERR_print_errors_fp(stderr); + exit (SCEP_PKISTATUS_ERROR); + } + printf("%s: CA certificate written as %s\n", + pname, c_char); + (void)fclose(fp); + pkistatus = SCEP_PKISTATUS_SUCCESS; + break; + + case SCEP_OPERATION_GETCERT: + case SCEP_OPERATION_GETCRL: + /* Read local certificate */ + if (!l_flag) { + fprintf(stderr, "%s: missing local cert (-l)\n", pname); + exit (SCEP_PKISTATUS_FILE); + } + read_cert(&localcert, l_char); + + case SCEP_OPERATION_ENROLL: + /* + * Read in CA cert, private key and certificate + * request in global variables. + */ + read_ca_cert(); + + if (!k_flag) { + fprintf(stderr, "%s: missing private key (-k)\n", pname); + exit (SCEP_PKISTATUS_FILE); + } + read_key(&rsa, k_char); + + if ((K_flag && !O_flag) || (!K_flag && O_flag)) { + fprintf(stderr, "%s: -O also requires -K (and vice-versa)\n", pname); + exit (SCEP_PKISTATUS_FILE); + } + + if (K_flag) { + read_key(&renewal_key, K_char); + } + + if (O_flag) { + read_cert(&renewal_cert, O_char); + } + + if (operation_flag == SCEP_OPERATION_ENROLL) + read_request(); + + /* + * Create a new SCEP transaction and self-signed + * certificate based on cert request + */ + if (v_flag) + fprintf(stdout, "%s: new transaction\n", pname); + new_transaction(&scep_t); + if (operation_flag != SCEP_OPERATION_ENROLL) + goto not_enroll; + if (v_flag) + fprintf(stdout, "%s: generating selfsigned " + "certificate\n", pname); + + if (! O_flag) + new_selfsigned(&scep_t); + else { + /* Use existing certificate */ + scep_t.signercert = renewal_cert; + scep_t.signerkey = renewal_key; + } + + /* Write the selfsigned certificate if requested */ + if (L_flag) { + /* Write PEM-formatted file: */ + if (!(fp = fopen(L_char, "w"))) { + fprintf(stderr, "%s: cannot open " + "file for writing\n", pname); + exit (SCEP_PKISTATUS_ERROR); + } + if (PEM_write_X509(fp,scep_t.signercert) != 1) { + fprintf(stderr, "%s: error while " + "writing certificate file\n", pname); + ERR_print_errors_fp(stderr); + exit (SCEP_PKISTATUS_ERROR); + } + printf("%s: selfsigned certificate written " + "as %s\n", pname, L_char); + (void)fclose(fp); + } + /* Write issuer name and subject (GetCertInitial): */ + if (!(scep_t.ias_getcertinit->subject = + X509_REQ_get_subject_name(request))) { + fprintf(stderr, "%s: error getting subject " + "for GetCertInitial\n", pname); + ERR_print_errors_fp(stderr); + exit (SCEP_PKISTATUS_ERROR); + } +not_enroll: + if (!(scep_t.ias_getcertinit->issuer = + X509_get_issuer_name(cacert))) { + fprintf(stderr, "%s: error getting issuer " + "for GetCertInitial\n", pname); + ERR_print_errors_fp(stderr); + exit (SCEP_PKISTATUS_ERROR); + } + /* Write issuer name and serial (GETC{ert,rl}): */ + scep_t.ias_getcert->issuer = + scep_t.ias_getcertinit->issuer; + scep_t.ias_getcrl->issuer = + scep_t.ias_getcertinit->issuer; + if (!(scep_t.ias_getcrl->serial = + X509_get_serialNumber(cacert))) { + fprintf(stderr, "%s: error getting serial " + "for GetCertInitial\n", pname); + ERR_print_errors_fp(stderr); + exit (SCEP_PKISTATUS_ERROR); + } + /* User supplied serial number */ + if (s_flag) { + if (!(ASN1_INTEGER_set(scep_t.ias_getcert->serial, + (long)atoi(s_char)))) { + fprintf(stderr, "%s: error converting " + "serial\n", pname); + ERR_print_errors_fp(stderr); + exit (SCEP_PKISTATUS_ERROR); + } + } + break; + } + switch(operation_flag) { + case SCEP_OPERATION_ENROLL: + if (v_flag) + fprintf(stdout, + "%s: SCEP_OPERATION_ENROLL\n", pname); + /* Resum mode: set GetCertInitial */ + if (R_flag) { + if (n_num == 0) + exit (SCEP_PKISTATUS_SUCCESS); + printf("%s: requesting certificate (#1)\n", + pname); + scep_t.request_type = SCEP_REQUEST_GETCERTINIT; + count++; + } else { + printf("%s: sending certificate request\n", + pname); + scep_t.request_type = SCEP_REQUEST_PKCSREQ; + } + break; + + case SCEP_OPERATION_GETCERT: + if (v_flag) + fprintf(stdout, + "%s: SCEP_OPERATION_GETCERT\n", pname); + + scep_t.request_type = SCEP_REQUEST_GETCERT; + printf("%s: requesting certificate\n",pname); + break; + + case SCEP_OPERATION_GETCRL: + if (v_flag) + fprintf(stdout, + "%s: SCEP_OPERATION_GETCRL\n", pname); + + scep_t.request_type = SCEP_REQUEST_GETCRL; + printf("%s: requesting crl\n",pname); + break; + } + + /* Enter polling loop */ + while (scep_t.pki_status != SCEP_PKISTATUS_SUCCESS) { + /* create payload */ + pkcs7_wrap(&scep_t); + + /* URL-encode */ + p = url_encode(scep_t.request_payload, + scep_t.request_len); + + /* Forge the HTTP message */ + snprintf(http_string, sizeof(http_string), + "GET %s%s?operation=" + "PKIOperation&message=" + "%s HTTP/1.0\r\n\r\n", + p_flag ? "" : "/", dir_name, p); + + if (d_flag) + fprintf(stdout, "%s: scep msg: %s", + pname, http_string); + + /* send http */ + reply.payload = NULL; + if ((c = send_msg (&reply, http_string, host_name, + host_port, operation_flag)) == 1) { + fprintf(stderr, "%s: error while sending " + "message\n", pname); + exit (SCEP_PKISTATUS_NET); + } + /* Verisign Onsite returns strange reply... + * XXXXXXXXXXXXXXXXXXX */ + if ((reply.status == 200) && (reply.payload == NULL)) { + /* + scep_t.pki_status = SCEP_PKISTATUS_PENDING; + break; + */ + exit (SCEP_PKISTATUS_ERROR); + } + printf("%s: valid response from server\n", pname); + + /* Check payload */ + scep_t.reply_len = reply.bytes; + scep_t.reply_payload = reply.payload; + pkcs7_unwrap(&scep_t); + pkistatus = scep_t.pki_status; + + switch(scep_t.pki_status) { + case SCEP_PKISTATUS_SUCCESS: + break; + case SCEP_PKISTATUS_PENDING: + /* Check time limits */ + if (((t_num * count) >= T_num) || + (count > n_num)) { + exit (pkistatus); + } + scep_t.request_type = + SCEP_REQUEST_GETCERTINIT; + + /* Wait for poll interval */ + if (v_flag) + printf("%s: waiting for %d secs\n", + pname, t_num); + sleep(t_num); + printf("%s: requesting certificate " + "(#%d)\n", pname, count); + + /* Add counter */ + count++; + break; + + case SCEP_PKISTATUS_FAILURE: + + /* Handle failure */ + switch (scep_t.fail_info) { + case SCEP_FAILINFO_BADALG: + exit (SCEP_PKISTATUS_BADALG); + case SCEP_FAILINFO_BADMSGCHK: + exit (SCEP_PKISTATUS_BADMSGCHK); + case SCEP_FAILINFO_BADREQ: + exit (SCEP_PKISTATUS_BADREQ); + case SCEP_FAILINFO_BADTIME: + exit (SCEP_PKISTATUS_BADTIME); + case SCEP_FAILINFO_BADCERTID: + exit (SCEP_PKISTATUS_BADCERTID); + /* Shouldn't be there... */ + default: + exit (SCEP_PKISTATUS_ERROR); + } + default: + fprintf(stderr, "%s: unknown " + "pkiStatus\n", pname); + exit (SCEP_PKISTATUS_ERROR); + } + } + /* We got SUCCESS, analyze the reply */ + switch (scep_t.request_type) { + + /* Local certificate */ + case SCEP_REQUEST_PKCSREQ: + case SCEP_REQUEST_GETCERTINIT: + write_local_cert(&scep_t); + break; + + /* Other end entity certificate */ + case SCEP_REQUEST_GETCERT: + write_other_cert(&scep_t); + break; + + break; + /* CRL */ + case SCEP_REQUEST_GETCRL: + write_crl(&scep_t); + break; + } + return (pkistatus); +} + +void +usage() { + fprintf(stdout, "\nsscep version %s\n\n" , VERSION); + fprintf(stdout, "Usage: %s OPERATION [OPTIONS]\n" + "\nAvailable OPERATIONs are\n" + " getca Get CA/RA certificate(s)\n" + " enroll Enroll certificate\n" + " getcert Query certificate\n" + " getcrl Query CRL\n" + "\nGeneral OPTIONS\n" + " -u SCEP server URL\n" + " -p Use proxy server at host:port\n" + " -f Use configuration file\n" + " -c CA certificate file (write if OPERATION is getca)\n" + " -E PKCS#7 encryption algorithm (des|3des|blowfish)\n" + " -S PKCS#7 signature algorithm (md5|sha1)\n" + " -v Verbose operation\n" + " -d Debug (even more verbose operation)\n" + "\nOPTIONS for OPERATION getca are\n" + " -i CA identifier string\n" + " -F Fingerprint algorithm\n" + "\nOPTIONS for OPERATION enroll are\n" + " -k Private key file\n" + " -r Certificate request file\n" + " -K Signature private key file, use with -O\n" + " -O Signature certificate (used instead of self-signed)\n" + " -l Write enrolled certificate in file\n" + " -e Use different CA cert for encryption\n" + " -L Write selfsigned certificate in file\n" + " -t Polling interval in seconds\n" + " -T Max polling time in seconds\n" + " -n Max number of GetCertInitial requests\n" + " -R Resume interrupted enrollment\n" + "\nOPTIONS for OPERATION getcert are\n" + " -k Private key file\n" + " -l Local certificate file\n" + " -s Certificate serial number\n" + " -w Write certificate in file\n" + "\nOPTIONS for OPERATION getcrl are\n" + " -k Private key file\n" + " -l Local certificate file\n" + " -w Write CRL in file\n\n", pname); + exit(0); +} + +void +catchalarm(int signo) { + fprintf(stderr, "%s: connection timed out\n", pname); + exit (SCEP_PKISTATUS_TIMEOUT); +} diff --git a/sscep.conf b/sscep.conf new file mode 100644 index 0000000..6c3f12c --- /dev/null +++ b/sscep.conf @@ -0,0 +1,106 @@ +# +# sscep.conf -- configuration file for SSCEP +# +# All configuration options are key-value pairs separated with one +# or more space characters: +# +# "Key" [spaces] "Value" +# +# Quotation marks are optional - they are needed only if the value contains +# space characters (space or tab). Quotation marks inside the value string +# must be escaped using a backslash: +# +# "Key" [spaces] "Value \"containing quotation marks\"" +# +# Comment lines (lines starting with '#') and empty lines are discarded. +# + +# +# Common options for all operations +# +# URL of the SCEP server. +URL http://localhost/cgi-bin/pkiclient.exe + +# Use HTTP proxy server +#Proxy localhost:8080 + +# This is one is needed with all operations. +CACertFile ./ca.crt + +# Possible values: yes or no. +Verbose no +Debug no + + +# +# Options for getca +# +# Some CAs require you to define this +#CAIdentifier "CA Identifier" + +# Display fingerprint algorithm (md5/sha1) +FingerPrint md5 + + +# +# Common options for enroll, getcert and getcrl +# +# Private key created with mkrequest +PrivateKeyFile ./local.key + +# Where to write successfully enrolled certificate +LocalCertFile ./local.crt + +# If your CA/RA uses a different certificates for encyption +# and signing, define this +#EncCertFile ./enc.crt + +# PKCS#7 encryption/signing +# Note: this could be very misleading, current SCEP draft provides no +# mechanism to "negotiate" the algorithm - even if you send 3des, reply +# might be des. + +# Encryption algorithm: des, 3des or blowfish. Default: des +#EncAlgorithm 3des +# Signature algorithm: md5 or sha1. Default: md5 +#SigAlgorithm sha1 + + +# +# Options for enroll +# + +# Certificate request file created with mkrequest +CertReqFile ./local.csr + +# Write optionally the selfsigned certificate in file +#SelfSignedFile ./selfsigned.crt + +# Poll periodically for pending certificate (seconds) +PollInterval 60 + +# Maximum polling time +MaxPollTime 28800 + +# Maximum polling count +MaxPollCount 256 + + + +# +# Options for getcert +# +# Certificate serial number (decimal) +GetCertSerial 1 + +# Write certificate as +GetCertFile ./cert.crt + + +# +# Options for getcrl +# +# Write CRL as +GetCrlFile ./crl.crl + + diff --git a/sscep.h b/sscep.h new file mode 100644 index 0000000..d10debc --- /dev/null +++ b/sscep.h @@ -0,0 +1,308 @@ + +/* + * sscep -- Simple SCEP client implementation + * Copyright (c) Jarkko Turkulainen 2003. All rights reserved. + * See the file COPYRIGHT for licensing information. + */ + + +#include "conf.h" +#include "cmd.h" + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +/* Global defines */ + +#define VERSION "20081211" + +/* SCEP operations */ +int operation_flag; +#define SCEP_OPERATION_GETCA 1 +#define SCEP_OPERATION_ENROLL 3 +#define SCEP_OPERATION_GETCERT 5 +#define SCEP_OPERATION_GETCRL 7 + +/* SCEP MIME headers */ +#define MIME_GETCA "application/x-x509-ca-cert" +#define MIME_GETCA_RA "application/x-x509-ca-ra-cert" +/* Entrust VPN connector uses different MIME types */ +#define MIME_PKI "x-pki-message" +#define MIME_GETCA_RA_ENTRUST "application/x-x509-ra-ca-certs" + +/* SCEP reply types based on MIME headers */ +#define SCEP_MIME_GETCA 1 +#define SCEP_MIME_GETCA_RA 3 +#define SCEP_MIME_PKI 5 + +/* SCEP request types */ +#define SCEP_REQUEST_NONE 0 +#define SCEP_REQUEST_PKCSREQ 19 +#define SCEP_REQUEST_PKCSREQ_STR "19" +#define SCEP_REQUEST_GETCERTINIT 20 +#define SCEP_REQUEST_GETCERTINIT_STR "20" +#define SCEP_REQUEST_GETCERT 21 +#define SCEP_REQUEST_GETCERT_STR "21" +#define SCEP_REQUEST_GETCRL 22 +#define SCEP_REQUEST_GETCRL_STR "22" + +/* SCEP reply types */ +#define SCEP_REPLY_NONE 0 +#define SCEP_REPLY_CERTREP 3 +#define SCEP_REPLY_CERTREP_STR "3" + +/* SCEP pkiStatus values (also used as SSCEP return values) */ +#define SCEP_PKISTATUS_SUCCESS 0 +#define SCEP_PKISTATUS_FAILURE 2 +#define SCEP_PKISTATUS_PENDING 3 + +/* SSCEP return values (not in SCEP draft) */ +#define SCEP_PKISTATUS_ERROR 1 /* General error */ +#define SCEP_PKISTATUS_BADALG 70 /* BADALG failInfo */ +#define SCEP_PKISTATUS_BADMSGCHK 71 /* BADMSGCHK failInfo */ +#define SCEP_PKISTATUS_BADREQ 72 /* BADREQ failInfo */ +#define SCEP_PKISTATUS_BADTIME 73 /* BADTIME failInfo */ +#define SCEP_PKISTATUS_BADCERTID 74 /* BADCERTID failInfo */ +#define SCEP_PKISTATUS_TIMEOUT 89 /* Network timeout */ +#define SCEP_PKISTATUS_SS 91 /* Error generating selfsigned */ +#define SCEP_PKISTATUS_FILE 93 /* Error in file handling */ +#define SCEP_PKISTATUS_NET 95 /* Network sending message */ +#define SCEP_PKISTATUS_P7 97 /* Error in pkcs7 routines */ +#define SCEP_PKISTATUS_UNSET 99 /* Unset pkiStatus */ + +/* SCEP failInfo values */ +#define SCEP_FAILINFO_BADALG 0 +#define SCEP_FAILINFO_BADALG_STR \ + "Unrecognized or unsupported algorithm ident" +#define SCEP_FAILINFO_BADMSGCHK 1 +#define SCEP_FAILINFO_BADMSGCHK_STR \ + "Integrity check failed" +#define SCEP_FAILINFO_BADREQ 2 +#define SCEP_FAILINFO_BADREQ_STR \ + "Transaction not permitted or supported" +#define SCEP_FAILINFO_BADTIME 3 +#define SCEP_FAILINFO_BADTIME_STR \ + "Message time field was not sufficiently close to the system time" +#define SCEP_FAILINFO_BADCERTID 4 +#define SCEP_FAILINFO_BADCERTID_STR \ + "No certificate could be identified matching" + +/* End of Global defines */ + + +/* Global variables */ + +/* Program name */ +char *pname; + +/* Network timeout */ +int timeout; + +/* Certificates, requests, keys.. */ +X509 *cacert; +X509 *encert; +X509 *localcert; +X509 *othercert; +X509 *renewal_cert; +X509_REQ *request; +EVP_PKEY *rsa; +EVP_PKEY *renewal_key; +X509_CRL *crl; +FILE *cafile; +FILE *reqfile; +FILE *otherfile; +FILE *crlfile; + +/* Fingerprint, signing and encryption algorithms */ +EVP_MD *fp_alg; +EVP_MD *sig_alg; +EVP_CIPHER *enc_alg; + +/* OpenSSL OID handles */ +int nid_messageType; +int nid_pkiStatus; +int nid_failInfo; +int nid_senderNonce; +int nid_recipientNonce; +int nid_transId; +int nid_extensionReq; + +/* Global pkistatus */ +int pkistatus; + +/* End of Global variables */ + + +/* Structures */ + +/* GETCertInital data structure */ + +typedef struct { + X509_NAME *issuer; + X509_NAME *subject; +} pkcs7_issuer_and_subject; + +/* HTTP reply structure */ +struct http_reply { + + /* SCEP reply type */ + int type; + + /* Status */ + int status; + + /* Payload */ + char *payload; + + /* Payload size */ + int bytes; +}; + +/* SCEP transaction structure */ +struct scep { + + /* SCEP message types */ + int request_type; + char *request_type_str; + int reply_type; + char *reply_type_str; + + /* SCEP message status */ + int pki_status; + char *pki_status_str; + int fail_info; + char *fail_info_str; + + /* SCEP transaction attributes */ + char *transaction_id; + unsigned char *sender_nonce; + int sender_nonce_len; + unsigned char *reply_recipient_nonce; + unsigned char *reply_sender_nonce; + int recipient_nonce_len; + + /* Certificates */ + X509 *signercert; + EVP_PKEY *signerkey; + + EVP_PKEY *pkey; + + /* Request */ + PKCS7 *request_p7; + unsigned char *request_payload; + int request_len; + pkcs7_issuer_and_subject *ias_getcertinit; + PKCS7_ISSUER_AND_SERIAL *ias_getcert; + PKCS7_ISSUER_AND_SERIAL *ias_getcrl; + + /* Reply */ + PKCS7 *reply_p7; + unsigned char *reply_payload; + int reply_len; + +}; +/* End of structures */ + + +/* Functions */ + +/* Print usage information */ +void usage(void); + +/* Send HTTP message */ +int send_msg (struct http_reply *, char *, char *, int, int); + +/* Catch SIGALRM */ +void catchalarm (int); + +/* Get config file parameter */ +char *get_string (char *); + +/* Report memory error */ +void error_memory(void); + +/* Initialize config file */ +void init_config(FILE *); + +/* Initialize SCEP layer */ +int init_scep(void); + +/* Read RSA private key file */ +void read_key(EVP_PKEY** key, char* filename); + +/* Read CA certificate file */ +void read_ca_cert(void); + +/* Read local certificate file */ +void read_cert(X509** cert, char* filename); + +/* Read certificate request and private key */ +void read_request(void); + +/* Write CRL */ +void write_crl(struct scep *); + +/* Write local certificate file */ +void write_local_cert(struct scep *); + +/* Write other certificate file */ +void write_other_cert(struct scep *); + +/* Write CA files */ +int write_ca_ra(struct http_reply *); + +/* Create new SCEP session */ +int new_transaction(struct scep *); + +/* Create self-signed certificate */ +int new_selfsigned(struct scep *); + +/* Get key fingerprint */ +char * key_fingerprint(X509_REQ *); + +/* PKCS#7 encode message */ +int pkcs7_wrap(struct scep *); + +/* PKCS#7 decode message */ +int pkcs7_unwrap(struct scep *); + +/* Add signed string attribute */ +int add_attribute_string(STACK_OF(X509_ATTRIBUTE) *, int, char *); + +/* Add signed octet attribute */ +int add_attribute_octet(STACK_OF(X509_ATTRIBUTE) *, int, char *, int); + +/* Find signed attributes */ +int get_signed_attribute(STACK_OF(X509_ATTRIBUTE) *, int, int, char **); +int get_attribute(STACK_OF(X509_ATTRIBUTE) *, int, ASN1_TYPE **); + +/* URL-endcode */ +char *url_encode (char *, size_t); + +/* End of Functions */ + +