> From: owner-openssl-us...@openssl.org On Behalf Of Jakob Bohm > Sent: Thursday, 11 October, 2012 10:45
> On 10/11/2012 4:16 PM, redpath wrote: > > > > Well the situation is I have a file which has been signed > for its contents. > > This signature > > is used to verify the authentication of the file. The > signature works great > > but I want to use > > best practices to package the signature. A PKCS7 was > suggested. So I assume > > I can extract this signature from the PKCS7 to verify the > file contents > > which I create the message digest SHA2 from. > > This sounds like you want a "detached" PKCS#7 signature, where the > PKCS#7 structure itself contains some meta-information about the file > (such as what hash algorithm to use and what date the signature was > made), but not the actual file contents. > > Detached PKCS#7 signatures are very common, this is how PKCS#7 is used > with signed (but not encrypted) e-mails, Microsoft Authenticode > signatures and many other uses. > > The function families suggested to you also contain functions that can > generate and validate detached PKCS7 signatures. > Yes. PKCS#7 is now officially Cryptographic Message Syntax (CMS), much like SSL is now officially Transport Level Security (TLS). We often still use the old names loosely to mean both, but when implementing you may need to be more precise. > > Is there something I am missing here. Just want to use best > practices. > > The challenger has the file and the PKCS7 (signature) to verify the > > contents. The challenger has the > > public key. > > > It is currently considered "best practice" to provide the public key > in the form of an X.509 certificate issued by someone the challenger > probably trusts with the ability to independently verify that you are > who you say you are. This will be provided to the challenger in two > places (that must agree): > That "someone" is called a Certificate Authority or CA. The cert should be from a CA the "challenger" (this is usually called verifier or relier) *does* trust; the issue is whether the signer knows, at signing time, who the reliers are or will be and what CAs they do or will trust. If you do know, use that; otherwise you must guess. With PKCS7/CMS signed-data you can generate and include multiple signatures on the same data; these could be signatures using 2 (or 5 or 42) different certs that different reliers do or are expected or hoped to trust. > 1. Inside the PKCS#7 structure (there is a field specifically > for that). > The PKCS7/CMS SignerInfo always includes a field to *identify* the signing key, usually by issuer+serial of the signer's cert. Signed-data *may* also include copies of any or all certs the relier(s) may need, starting with the signer's cert and going up the chain as necessary or desired. > 2. Separately over a trusted delivery mechanism (so the challenger has > another reason to be certain he has the proper public key to trust > with signing the file contents). > Not (normally) the signer's cert. A main feature of certs is they are signed and thus tamperprotected and authenticable, and so can be transmitted and/or stored without authentication or integrity protection. What does need to be passed to the relier(s) in a trusted way is the CA *root*, or other trust anchor, for the signer's cert. For public CAs like Verisign, this is usually done by the relier application or system installing a vendor-chosen set of public roots, which may be manually adjusted if necessary. E.g. Windows does this, and Firefox, and Java. Windows occasionally pushes updates as well, if you use Windows autoupdate (or one of Microsoft's enterprise updaters), which you pretty much must to handle the stream of security fixes in Windows. <snip rest> ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
