mpeylo / cmpossl Goto Github PK

openssl/ts.h, included by cmp.h and used in cmp_msg.c for setting the CL specific id-aa-signingCertificate "generalInfo" of the CMP header is breaking the downwards compatibility for the OpenSSL 0.9.8g backport as described on https://sourceforge.net/apps/mediawiki/cmpforopenssl/index.php?title=OpenSSL\_0.9.8g

In cmp.h the include for openssl/ts.h must be made dependant on the openssl version. In cmp_msg.c the whole ifclose below that following part in the code must also be dependant on new OpenSSL versions. (that would break CL compatibility for 0.9.8g backporting so re-establishing the old code there for old versions might be considered)

/* this is like CL likes it:
* set id-aa-signingCertificate "generalInfo" of the CMP header */
if( ctx->compatibility == CMP_COMPAT_CRYPTLIB) {

Reported by: mpeylo

Original Ticket: cmpforopenssl/bugs/7

Field 'infoValue' in CMP_INFOTYPEANDVALUE should be defined using ASN1_ADB* macros.

Reported by: mviljane

Original Ticket: cmpforopenssl/bugs/5

Using ECC keys/certs instead produces strange misleading errors:

2675996:error:3306D073:CRMF routines:CRMF_poposigningkey_new:unsupported alg for popsigningkey:crmf_lib.c:601:
2675996:error:3306D06D:CRMF routines:CRMF_poposigningkey_new:error setting popsigningkey:crmf_lib.c:623:
2675996:error:3306B067:CRMF routines:CRMF_CERTREQMSG_calc_and_set_popo:error calculating and setting popo:crmf_lib.c:695:
2675996:error:3206808E:CMP routines:CMP_CERTREPMESSAGE_get_certificate:request rejected by ca:cmp_lib.c:1393:PKIFailureInfo: badPOP, statusString: "CRMF template verification failed: PoP verification failed: invalid PoP (type: ir from: 192.35.17.16 transaction: a2a8761c36c80aa50004c0773ca03589): "

Reported by: mpeylo

Original Ticket: cmpforopenssl/bugs/14

HTTP transport should be done using libcurl. So far this is just a hack.

(As also mentioned in another feature request, it should be possible to set the source IP for that.)

Reported by: mpeylo

Original Ticket: cmpforopenssl/feature-requests/2

The PBM parameters are hardcoded in the CTX to the most common ones, but they cannot yet be changed through a CTX function or the command line (at least OWF should also honor the -digest option).

hardcoded CTX parameters in cmp_ctx.c:

ctx->pbm_slen = 16;
ctx->pbm_owf = NID_sha256;
ctx->pbm_itercnt = 500;
ctx->pbm_mac = NID_hmac_sha1;

Reported by: mpeylo

Original Ticket: cmpforopenssl/feature-requests/16

I am building under openssl's current stable release: openssl-1.1.0e, and there is a build issue:

apps/cmp.c lines 173-175 should be:

#endif
#if OPENSSL_VERSION_NUMBER >= 0x10101000L
const
#endif

It seems that OPTIONS only becomes 'const' at 1.1.1-dev and beyond.

Reported by: nhathaway

Original Ticket: cmpforopenssl/bugs/31

In crmf_lib.c function CRMF_CERTREQMSG_set1_control_oldCertId:

1. The code creates certID using CRMF_CERTID_new() -> the issuer and serialNumber members of CRMF_CERTID are allocated from memory and the pointers are set.
2. Code creates new instances of GENERAL_NAME and ASN1_ITEGER and assigns them to certId. The pointers for the structs created by CRMF_CERTID_new in step 1 are overwritten
3. CRMF_CERTREQMSG_free fails to free the issuer and serialNumber allocated in step 1 -> memory leak

Reported by: junuutin

Original Ticket: cmpforopenssl/bugs/33

The transaction ID shouldn't be created (from random) while from CMP_PKIHEADER_init(), but rather through a context setting. The current way of events is somewhat non-natural.

This should then give more control to the API user to do all of the following from RFC 4210 - if ever needed:

The transactionID field within the message header is to be used to
allow the recipient of a message to correlate this with an ongoing
transaction. This is needed for all transactions that consist of
more than just a single request/response pair. For transactions that
consist of a single request/response pair, the rules are as follows.
A client MAY populate the transactionID field of the request. If a
server receives such a request that has the transactionID field set,
then it MUST set the transactionID field of the response to the same
value. If a server receives such request with a missing
transactionID field, then it MAY set transactionID field of the
response.

This will need changes to of CMP_CTX_set1_transactionID() and CMP_PKIHEADER_set1_transactionID().

Reported by: mpeylo

Original Ticket: cmpforopenssl/bugs/34

From RFC 4210 D.3's last sentence it seems as if clients need to implement all 3 cases of RFC 4211 4.1 need to be fully RFC compliant.

So far only case 3 is supported (see crmf/crmf_lib.c).

Case 1 seems to be needed for IR with user/pass where the EE subject name is not yet known
Case 2 seems to be needed for IR when the EE desires a new subject name or expects to get a different one by the CA anyway (and therefore doesn't set its currently known one)
Case 3 is when the EE knows its own subject name

Reported by: mpeylo

Original Ticket: cmpforopenssl/feature-requests/12

Hello

I found an examples of CMPv2 message flow on the following page: http://wiki.wireshark.org/CMP
However, it does not match ASN.1 notation defined for IR message. See this dump for details: http://wiki.wireshark.org/SampleCaptures?action=AttachFile&do=view&target=cmp\_IR\_sequence\_OpenSSL-Cryptlib.pcap

Assume the following definitions:
SubjectPublicKeyInfo ::= SEQUENCE { algorithm AlgorithmIdentifier, subjectPublicKey BIT STRING }
AlgorithmIdentifier ::= SEQUENCE { algorithm OBJECT IDENTIFIER, parameters ANY DEFINED BY algorithm OPTIONAL }

Than, if we look into body:ir->certreqmsg->certreq->certtemplate->publickey (in wireshark view), we will find that algorithm is encoded not as a ASN.1 SEQUENCE (see hex dump). In fact, SEQUENCE tag and length fields are missed. Therefore, request cannot be decoded by any other implementation of RFC4210.

Could you please take a look and provide your view?
Thank you.

Reported by: *anonymous

Original Ticket: cmpforopenssl/bugs/10

I am compiling under gcc 4.4.7, and the build aborts with the following errors:

In file included from crypto/cmp/cmp_asn.c:72:
include/openssl/crmf.h:149: error: redefinition of typedef 'CRMF_CERTTEMPLATE'
include/openssl/crmf.h:104: note: previous declaration of 'CRMF_CERTTEMPLATE' was here
In file included from crypto/cmp/cmp_asn.c:74:
crypto/cmp/cmp_int.h:126: error: redefinition of typedef 'CMP_CTX'
include/openssl/cmp.h:252: note: previous declaration of 'CMP_CTX' was here
crypto/cmp/cmp_int.h:235: error: redefinition of typedef 'CMP_INFOTYPEANDVALUE'
include/openssl/cmp.h:256: note: previous declaration of 'CMP_INFOTYPEANDVALUE' was here
crypto/cmp/cmp_int.h:275: error: redefinition of typedef 'CMP_PKISTATUSINFO'
include/openssl/cmp.h:259: note: previous declaration of 'CMP_PKISTATUSINFO' was here
crypto/cmp/cmp_int.h:315: error: redefinition of typedef 'CMP_REVREPCONTENT'
include/openssl/cmp.h:258: note: previous declaration of 'CMP_REVREPCONTENT' was here
crypto/cmp/cmp_int.h:363: error: redefinition of typedef 'CMP_CERTSTATUS'
include/openssl/cmp.h:255: note: previous declaration of 'CMP_CERTSTATUS' was here
crypto/cmp/cmp_int.h:387: error: redefinition of typedef 'CMP_CERTRESPONSE'
include/openssl/cmp.h:261: note: previous declaration of 'CMP_CERTRESPONSE' was here
crypto/cmp/cmp_int.h:400: error: redefinition of typedef 'CMP_CERTREPMESSAGE'
include/openssl/cmp.h:260: note: previous declaration of 'CMP_CERTREPMESSAGE' was here
crypto/cmp/cmp_int.h:519: error: redefinition of typedef 'CMP_PKIHEADER'
include/openssl/cmp.h:253: note: previous declaration of 'CMP_PKIHEADER' was here
In file included from crypto/cmp/cmp_asn.c:74:
crypto/cmp/cmp_int.h:670: error: redefinition of typedef 'CMP_PKIMESSAGE'
include/openssl/cmp.h:254: note: previous declaration of 'CMP_PKIMESSAGE' was here

However, gcc 4.6.3 seems to tolerate this (that's the one with Ubuntu 12.04)

Reported by: nhathaway

Original Ticket: cmpforopenssl/bugs/32

There should be the functionality to read/add certificates from/to the extraCerts fields.

In the cmpclient implementation
- the added extraCerts (multiple!) should be loadable from disk
- the read/saved extraCerts should be clearly distinguishable from the caPubs ones.

Reported by: mpeylo

Original Ticket: cmpforopenssl/feature-requests/3

Field 'value' of CRMF_ATTRIBUTETYPEANDVALUE is currently defined as ASN1_IMP(CRMF_ATTRIBUTETYPEANDVALUE, value, ASN1_ANY, 0), which gets decoded incorrectly in e.g. Wireshark.

Reported by: mviljane

Original Ticket: cmpforopenssl/bugs/1

The logic how subjectName and subjectAltNames are set from ctx->subject, ctx->subjectAltNames and ctx->clCert and ctx->oldClCert must be overworked for IR, CR, and KUR.

The logic must be properly documented.

Reported by: mpeylo

Original Ticket: cmpforopenssl/bugs/36

Add support for Key Recovery Request.

Reported by: mviljane

Original Ticket: cmpforopenssl/feature-requests/6

There are many CMP/CRMF definitions included in safestack.h in SVN, but these changes are not included in the generated patch, say openssl-1.0.0i_cmp.diff.

Reported by: shenshu

Original Ticket: cmpforopenssl/bugs/11

It should be possible to add X509 Extensions to the certificate template when doing an IR. For example, subjectAltName could be set in the context and then read by CRMF_cr_new().

Reported by: mviljane

Original Ticket: cmpforopenssl/feature-requests/4

The RFC section 5.3.2 says that
...if the PKI
Message Protection is "shared secret information" (see Section
5.1.3), then any certificate transported in the caPubs field may be
directly trusted as a root CA certificate by the initiator.

So caPubs are stored in context in cmp_ses.c - but so far there is no way to figure out whether the CA actually used shared secret, as it could use MSG_SIG_ALG eventhough the client was using MSG_MAC_ALG.

So, the information which protection was used when sending caPubs should be made available to the recipient.

Reported by: mpeylo

Original Ticket: cmpforopenssl/feature-requests/15

Add support for Cross Certification Request (RFC 4210 section 5.3.11).

Reported by: mviljane

Original Ticket: cmpforopenssl/feature-requests/8

I've added a couple of new command-line options:

• -digest: Digest algorithm to be used for signatures. Defaults to 'sha1'
• -issuer: X509 name of the issuer. Defaults to recipient
• -raverified: Assume that Proof-of-Possession (POPO) has been verified by RA
• -implicitconfirm: Request implicit confirmation of enrolled certificate
• -timeout: Connect timeout in seconds (or 0 for none). Default 120

Doing so, I generalized the code for signature generation to arbitrary combinations of digest/hash algorithms and signature algorithms. This not only makes the code fully general in this respect, but also more concise. This improvement is critical for us using the latest EJBCA version, which misbehaves when using SHA-1 (but works well with SHA256 and up).

I corrected the use of the HttpTimeout context parameter and added a FIXME that it sould be respected not only for connecting to the server but also for waiting for a response messge (in case libCURL is not used).

Error output has been inproved for the case receiving a bogus response (in case libCURL is used).

I added eror handling in case X509_LOOKUP_load_file() fails and added resource cleanup also for other error cases within create_cert_store(),

I improved the way the server and path info is handed to libCURL and made the tool slightly less verbose on success and allow for unsigned error responses.

Finally, I fixed a couple of error message texts and source-code comments.

The respective patch is attached. In case you prefer to receive individual patches for each of the changes, please let me know and I can split this cumulative patch into independent pieces.

Reported by: DDVO

Original Ticket: cmpforopenssl/bugs/25

PBM caluclation - in crmf_pbm.c - should also use the configurable digest.

Reported by: mpeylo

Original Ticket: cmpforopenssl/bugs/29

The Challenge-Response method of proof-of-posession is not supported yet.

Reported by: mviljane

Original Ticket: cmpforopenssl/feature-requests/5

regToken as set in cmp_msg.c for EJBCA and associated functions like CMP_CTX_set1_regToken() might nowadays be redundant - as they are not actually used in the application.

Reported by: mpeylo

Original Ticket: cmpforopenssl/bugs/35

https://www.openssl.org/policies/codingstyle.html

Reported by: mpeylo

Original Ticket: cmpforopenssl/bugs/28

check transacationID thorroughly over messages

Reported by: mpeylo

Original Ticket: cmpforopenssl/bugs/30

Enhance CMP_PKIMESSAGE_protect() - and other functions - so that no protection is possible. This is allowed and useful if e.g. the protection is done by means of TLS or an otherwise protected connection.

Reported by: mpeylo

Original Ticket: cmpforopenssl/feature-requests/17

If one gives the -cacertsout option (to cmp ir), it is silently ignored.

Reported by: mpeylo

Original Ticket: cmpforopenssl/bugs/15

The "1" in the CMP_PKIHEADER_set1_recipient() function name indicates that a copy of the X509_NAME *nm should be used.

There seems to be a mixup of "nm" and "nmDup".

Reported by: mpeylo

Original Ticket: cmpforopenssl/bugs/2

The patched lighttpd is merely a study for a light CMP responder to eventually also provide server-side CMP capabilities in OpenSSL.
I'd be happy if you decide to continue on it but Insta/EJBCA will usually be easier.

--> adding information like this to the README

Reported by: mpeylo

Original Ticket: cmpforopenssl/bugs/17

Add support for Revocation Request.

Reported by: mviljane

Original Ticket: cmpforopenssl/feature-requests/7

If one gives the -newkey option to cmp cr, it is silently ignored.

The enclosed patch makes the cr operation use the key given as -newkey argument, if present (instead of re-using the key given with as -key argument), for the creation of the new cert.

Reported by: DDVO

Original Ticket: cmpforopenssl/bugs/20

The syntax for addressing the proxy is inconsistent with the syntax for
addressing the server. Rather than having to use

-proxy <name_or_addr> -proxyport
the following might be better - or could be accepted additionally
-proxy <name_or_addr>:

Reported by: mpeylo

Original Ticket: cmpforopenssl/bugs/16

If the server side does not set senderKID but two or more certificates for the subject name exists then there is a risk that the wrong certificate is used when attempting message signature validation.

In that case, findSrvCert() should probably try going throught the certificates and figure out which one would be suitable.

However, in that case, the server side would not be standard conformant as 4210 says that it MUST set senderKID in such case ("These fields MUST be used if required to uniquely identify a key").

Reported by: mpeylo

Original Ticket: cmpforopenssl/bugs/23

It needs to be validated that the use of bitfields in cmp_ses.c, to communicate body types to send_receive-check() and pollForResponse() works accross platforms - especially as that will usually require that 32 bit types work.

E.g.
1U <<V_CMP_PKIBODY_IP

Note: The bitfield approach had been added by Martin on 2017-02-16 to fix the issue that polling didn't work anymore

Reported by: mpeylo

Original Ticket: cmpforopenssl/bugs/26

Upstream has created individual folders in openssl/doc. The CMP docu from the crypto folder needs to be sorted in accordingly.

Reported by: mpeylo

Original Ticket: cmpforopenssl/bugs/27

One of the options not yet (fully) implemented is useTLS.
Would be nice if the client had the possibility to use HTTPS, for instance because some servers require it and as an extra level of defense (e.g. against http disturbance).
Even TLS-level client-side authentication would make sense, allowing for extra cert-based authentication, e.g., when updating (TLS) certificates.

Reported by: DDvO

Original Ticket: cmpforopenssl/feature-requests/11

There are problems with the ASN1 definition of the "extensions" field of a cert template. Wireshark gives following error when decoding: "BER Error: Wrong field in sequence expected class:UNIVERSAL(0) tag:6(OBJECT IDENTIFIER) but found class:UNIVERSAL(0) tag:16"

Extensions field is needed for setting altName.

Reported by: mviljane

Original Ticket: cmpforopenssl/bugs/4

Hello,
we have observed 100%CPU of process which uses opensslcmp client, when incorrect certificate template was used and rejection message was sent by cmp server.

attachement:
gdb info, problem.pcap

Reported by: pawelfojcik

Original Ticket: cmpforopenssl/bugs/19

... as they're untested and in practice not used often

Reported by: mpeylo

Original Ticket: cmpforopenssl/bugs/18

Currently the different compatibility modes (insta, cryptlib) set some default values and options necessary for the specific CAs. These settings should be moved to their own separate option flags so that the compatibility modes could later be deprecated.

Reported by: mviljane

Original Ticket: cmpforopenssl/bugs/8

If the client has (either locally or from extraCerts) two certificates for the sender's subject name with same subject and subject key id, but one is e.g. not valid anymore, there is a risk that the client fails at message validation as it only tries with the certificate which is not valid anymore.

findSrvCert() should do more extensive checking
a) are there two certificates with same subjectKeyID
b) if so, then which one is better to use...?

Reported by: mpeylo

Original Ticket: cmpforopenssl/bugs/24

Automate resending the request with a newly generated transactionID in case the server replies with a PKIFailureInfo of transactionIdInUse as described in 5.1.1 (around line 1440) of RFC 4210.

Reported by: mpeylo

Original Ticket: cmpforopenssl/bugs/9

While developing the code to deal with issue 14, I found a double free bug in CRMF_passwordBasedMac_new() within crmf_pbm.c and fixed it.
Please find the little patch attached.

Reported by: DDVO

Original Ticket: cmpforopenssl/bugs/21

in general we might be too strict on the presence of the key to be when building up the request messages - as they could actually just be omitted, if we would have a RA or CA supporting centralized key generation and would be able to get the private key out of the reply message.

See https://tools.ietf.org/html/rfc4210#section-4.2.1.3 “centralized generation”. For thet to work, we’d need to generate and, set the “Protocol Encryption Key” - https://tools.ietf.org/html/rfc4211#section-6.6 - and then filter out the privateKey from the CertifidKeyPair message, decrypt it and write it.

… but the whole thing cannot be implemented before we have a server supporting that.…

Reported by: mpeylo

Original Ticket: cmpforopenssl/feature-requests/14

openssl cmp --help throws the following error and does not show the help:
3076380296:error:2006D080:BIO routines:BIO_new_file:no such file:bss_file.c:172:
3076380296:error:0E078072:configuration file routines:DEF_LOAD:no such file:conf_def.c:197:

Reported by: mpeylo

Original Ticket: cmpforopenssl/bugs/12

The code for doing a PKI Information Request is implemented, but is currently untested since no CAs appear to fully support the it.

Reported by: mviljane

Original Ticket: cmpforopenssl/feature-requests/9

The "switch" within cmp_lib.c's CMP_protection_new() should be made more general and all possibilities should be handled. Also the configure options of OpenSSL should be taken into account (e.g. if DSA would not be available).

Reported by: mpeylo

Original Ticket: cmpforopenssl/bugs/3

Add support for Certificate Revocation Lists and the CRL Announcement PKI Message.

Reported by: mviljane

Original Ticket: cmpforopenssl/feature-requests/10

It should be possible to set a specific IP address as source for the connection.

This might be first just a hack for the transport hack and then should also be a part of the libcurl implementation.

Reported by: mpeylo

Original Ticket: cmpforopenssl/feature-requests/1

Currently only CMP_doInitialRequestSeq only handles the first CMP_CERTREPMESSAGE received, but there could be more than one!

Reported by: mviljane

Original Ticket: cmpforopenssl/feature-requests/13