As inspired by this paper on S/MIME signing, I (quickly) surveyed what the RFCs say about S/MIME signature semantics. In brief, RFCs suggest that the signature is for the purpose of:
In increasing order of sophistication. What the RFCs do not say is that a digital signature used in an S/MIME packet should be for a particular purpose, and should be construed to a particular meaning.
That is, they do not say that the signature means precisely some set of the above, and excluding others. Is it one? Is it all? Is one more important than another?
RFC2459 sheds more light on where this is defined:
A certificate user should review the certificate policy generated by the certification authority (CA) before relying on the authentication or non-repudiation services associated with the public key in a particular certificate. To this end, this standard does not prescribe legally binding rules or duties.
There, we can probably make a guess that the RFC uses the term "non-repudiation" when it means all of the legal semantics that might apply to a human act of signing. (Non-repudiation, as we know, is a fundamentally broken concept and should not be used.) So we can guess that any human semantics are deferred to the CA's documents.
Indeed, RFC2459 goes even further by suggesting that the user refer to the CP before relying on the authentication services. This is a direct recognition that all CAs are different, and therefore the semantics of identity must also differ from CA to CA. In this sense, RFC2459 is correct, as we know that many certificates are issued according to domain-control, others are issued according to web-of-trust, and yet others are issued to the EV draft.
So when the paper mentioned above refers to weaknesses, it seems to be drifting into semantics that are not backed up by its references. Although the commentary raises interesting problems, it is not easy to ascribe the problem to any particular area. Indeed, few of the documents specified have a definition of security, as indicated by (lack of) requirements, and neither does the paper supply one. Hence the complaint that "naïve sign & encrypt is vulnerable" is itself vulnerable to definitions assumed but not clearly stated by the author.
Where did these confused semantics come from? This is a common trap that most of the net and much of the cryptographic community has fallen into; The wider problem is simply not doing the requirements, something that serious software engineers know is paramount.
A narrower problem is that the digital signature can be confused with a human signature, perhaps by using the same word for very different concepts. Many people have then thought it has something to do with a human signature, or human identification, confusing its real utility and complicating architectures built on such confusion.
MOSS:
As long as the private keys are protected from disclosure, i.e., the private keys are accessible only to the user to whom they have been assigned, the recipient of a digitally signed message will know from whom the message was sent and the originator of an encrypted message will know that only the intended recipient is able to read it.
ESS:
Some of the features of each service use the concept of a "triple wrapped" message. A triple wrapped message is one that has been signed, then encrypted, then signed again. The signers of the inner and outer signatures may be different entities or the same entity....1.1.1 Purpose of Triple Wrapping
Not all messages need to be triple wrapped. Triple wrapping is used when a message must be signed, then encrypted, and then have signed attributes bound to the encrypted body. Outer attributes may be added or removed by the message originator or intermediate agents, and may be signed by intermediate agents or the final recipient.
The inside signature is used for content integrity, non-repudiation with proof of origin, and binding attributes (such as a security label) to the original content. These attributes go from the originator to the recipient, regardless of the number of intermediate entities such as mail list agents that process the message. The signed attributes can be used for access control to the inner body. Requests for signed receipts by the originator are carried in the inside signature as well.....
The outside signature provides authentication and integrity for information that is processed hop-by-hop, where each hop is an intermediate entity such as a mail list agent. The outer signature binds attributes (such as a security label) to the encrypted body. These attributes can be used for access control and routing decisions.
S/MIME Version 3 Certificate Handling:
2.3 ... Agents MAY send CA certificates, that is, certificates that are self-signed and can be considered the "root" of other chains. Note that receiving agents SHOULD NOT simply trust any self-signed certificates as valid CAs, but SHOULD use some other mechanism to determine if this is a CA that should be trusted. Also note that in the case of DSA certificates the parameters may be located in the root certificate. This would require that the recipient possess the root certificate in order to perform a signature verification, and is a valid example of a case where transmitting the root certificate may be required.
S/MIME Version 3 Message Specification
1. IntroductionS/MIME (Secure/Multipurpose Internet Mail Extensions) provides a consistent way to send and receive secure MIME data. Based on the popular Internet MIME standard, S/MIME provides the following cryptographic security services for electronic messaging applications: authentication, message integrity and non-repudiation of origin (using digital signatures) and privacy and data security (using encryption).
Internet X.509 Public Key Infrastructure Certificate and CRL Profile
This specification profiles the format and semantics of certificates and certificate revocation lists for the Internet PKI. ...Posted by iang at May 5, 2007 09:23 AM | TrackBackIn order to relieve some of the obstacles to using X.509 certificates, this document defines a profile to promote the development of certificate management systems; development of application tools; and interoperability determined by policy.
Some communities will need to supplement, or possibly replace, this profile in order to meet the requirements of specialized application domains or environments with additional authorization, assurance, or operational requirements. However, for basic applications, common representations of frequently used attributes are defined so that application developers can obtain necessary information without regard to the issuer of a particular certificate or certificate revocation list (CRL).
A certificate user should review the certificate policy generated by the certification authority (CA) before relying on the authentication or non-repudiation services associated with the public key in a particular certificate. To this end, this standard does not prescribe legally binding rules or duties.
when we were asked in to help word smith the cal state (and later federal) electronic signature act ... the lawyers had quite a bit to say about this ... some past posts
http://www.garlic.com/~lynn/subpubkey.html#signature
i've joked that it involves semantic confusion because the terms "digital signature" and "human signature" both contains the word "signature"
the whole idea that past certification events has anything to do with (future) intent, non-repudiation, and/or human signature (i.e. read, understood, agrees, approves, and/or authorizes) has been severely depreciated since the heyday of the enormous (semantic) confusion if the 90s.
furthermore, it can be considered that even bringing up anything to do with non-repudiation, intent, and human signature in conjunction with issuing a digital certificate is enormous misdirection and obfuscation.
the issue of certification authorities, certification process, and digital certificates are analogous to the letters of credit/introduction from the sailing ship days (and before) when the relying party had no other means of obtaining information about the party they were dealing with. in those days, relying parties realized that the letter of introduction might have something to do with the truth of what a stranger might possibly claim. However, the letter of introduction was specifically with respect to specific facts that were verified at the time the letter was written.
There was NEVER any implication that the act of certifying information included in the letter of introduction was in any way associated with the subject's subsequent human signature that carried with it any implication of intent, non-repudiation, read, understood, agrees, authorizes, and/or approves.
In fact, it was physically and temporal impossibility that the act of certifying some information at some point distant in the past had any bearing on the future human act of applying a (human) signature.
Subsequent work (after the 90s) in the area of intent, non-repudiation, having read, understood, agrees, approves, and/or authorizes ... all revolved around services that happened at the moment a signature was applied ... somewhat equivalent to having "witnesses" involved in the signing of a will (and severely depreciated any possible prior work in relating any past work of certification authorities to any future demonstration of intent).
In this subsequent work, there was nobody confused that the act of certification at some point in the past (which is what a digital certificate represents) .... was in any possible way related to the conditions around the future application of a signature. This would be on par with trying to make some connection between the issuance of a birth certificate being related to proving that some person had intended to sign a specific will. Part of the issue is that the two events; some certification and some signing (demonstrating read, understood, approves, agrees, and/or authorizes), are typically separated by quite a distance ... both physically and temporally.
Posted by: Lynn Wheeler at May 5, 2007 10:14 AMre:
http://www.garlic.com/~lynn/aadsm26.htm#67 survey of RFC S/MIME signature handling
or to be (only slightly) more facetious ... require that all birth certificates to carry a disclaimer that the document in no way is met to carry any implication as to the validity of any signatures that the named person may place on wills (at any time in the future). the birth certificate disclaimer then would have to be extended to include the enumeration of all possible documents on which a person might place their signature.
Posted by: Lynn Wheeler at May 5, 2007 02:28 PM