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 */ + +