> From: owner-openssl-us...@openssl.org On Behalf Of Henrik Grindal Bakken > Sent: Friday, 05 October, 2012 03:47
> Hi. I have a list of (RSA) signatures made on the same digest, and > I'd like to store them in a single file. > > A simple solution is obviously to e.g. store the length of sig0 > (32 bits, network byte order) first, then sig0, then l(sig1), then > sig1, etc., but I was wondering if there was a standard way of doing > this that would make more sense. > Approximately. There is a standard, originally PKCS#7 by RSA Labs adopted by IETF and extended as CMS (Cryptographic Message Syntax) currently RFC 5652 which has options including pk-signed and/or "enveloped" (pk-encrypted) data. The signed-data option allows for multiple signatures on the same data, where each "signerInfo" has several pieces: the identity of the signing key, usually by a cert for it; optional signed attributes additional to the hash-of-data, and optional unsigned attributes; the algorithms used (e.g. can be ECDSA-SHA256 not RSA-SHA1) and the actual signature bits. In addition signed-data can optionally contain certs and CRLs for the recipient(s) to use in verifying the signature -- or for any purpose, and a "degenerate" PKCS7 containing zero signatures but several certs and/or CRLs is a fairly common/standard way of conveying those certs and/or CRLs as a group. The data signed can be "encapsulated" (embedded in) the signed-data, or it can be "external" aka "detached" and transmitted/stored separately. A detached PKCS7/CMS signed-data is similar to what you asked, but includes at least the identifiers and optionally/often other attributes that you didn't ask for. Similarly, enveloped-data symmetric-encrypts the data with a DEK, and then has a variable number of "recipientInfo" to transmit DEK to one or more (groups of) recipient(s). IIRC original PKCS7 only had pk-ie-RSA-encrypt the DEK using an identified key (again usually cert), and algorithm; CMS has (gradually) added other options. > >From what I could dig out, PEM doesn't support encoding signatures. > True PEM, that is RFC 1421-4, I vaguely recall did have some signed form(s?), but pretty much nobody uses true PEM. (S/MIME is a more popular standard today for secure email, and is based on CMS in a way similar to but not the same as PEM.) "PEM" nowadays, especially in OpenSSL, really means "PEM-style", namely encoding (any) ASN.1 data in base64 and adding "BEGIN" and "END" lines. E.g. a "PEM format" cert, or CRL, or CSR, or privatekey or publickey or key-parameters, etc. ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
