> From: owner-openssl-us...@openssl.org On Behalf Of Mark Bishop > Sent: Thursday, 15 July, 2010 14:48 > To: openssl-users@openssl.org > Subject: Certificate Signature Creation > > Where can I find out the details on how a signature is created for a > certificate and how it differs from creating a signature on a > data file? > > Is it as simple as running MD5, SHA-1, SHA-256, etc on the cert, > encrypting the hash with the private key and sticking the results on > the end of the cert (X509)? Or am I missing a key concept?
You've got the idea just about but are somewhat imprecise. The biggest thing you left out is that there is more than one digital signature method: RSA is the oldest and most established on the Internet, but DSA and ECDSA are also used widely. First, I assume you mean an X.509 certificate. Those are the ones used in SSL (and OpenSSL) and some other applications. There are other certificate formats defined in some other places that are similar in concept but different in detail. Given that: - you form the DER encoding of the certificate 'body', also called 'to-be-signed', and within OpenSSL called X509_CINF and cert_info. This contains the information that needs integrity protection such as issuer, subject, key and period, plus for technical reasons a copy of the algorithm-identifier (see below) - you create a signature of the TBS according to a standardized and hence identifiable scheme. For RSA, this consists of taking a hash, padding the result in a defined way, and raising it to power d modulo n; this is mathematically similar to but not the same as RSA encryption. For DSA or ECDSA, you also take a hash but then do quite different things. In any case, you end up with a bit string which is the signature, but the recipient needs to know what algorithm to use to verify it, so: - you encode (again DER, although technically other encodings could work here) the TBS, plus the signature, plus an 'algorithm identifier' which unsurprisingly identifies the algorithm. For RSA this only needs an OID (ASN.1 Object Identifier) which identifies RSA and the hash used. For DSA or ECDSA, in addition to the OID it can include the 'parameters' aka 'field' used. In principle this is redundant since the issuer's key must be identifiable (normally from issuer name or AuthorityKeyIdentifier extension within TBS) and implies the algorithm and any parameters, but the ITU-T (or was it then CCITT?) folks didn't rely on that. The same concepts apply to (PK)signing other data such as a file, but details vary, in particular how you identify what signature applies to what data, who signed it with which key and what algorithm, and sometimes at what (verifiable) time. ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
