Tech-invite3GPPspaceIETF RFCsSIP
929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 5126

CMS Advanced Electronic Signatures (CAdES)

Pages: 141
Informational
Obsoletes:  3126
Part 6 of 7 – Pages 109 to 128
First   Prev   Next

Top   ToC   RFC5126 - Page 109   prevText

C.4. Components of Validation Data

C.4.1. Revocation Status Information

A verifier will have to ascertain that the certificate of the signer was valid at the time of the signature. This can be done by either: - using Certificate Revocation Lists (CRLs); - using responses from an online certificate status server (for example, obtained through the OCSP protocol). NOTE 1: The time of the signature may not be known, so time-stamping or time-marking may be used to provide the time indication of when it was known that the signature existed. NOTE 2: When validating an electronic signature and checking revocation status information, if a "grace period" is required, it needs to be suitably long enough to allow the involved authority to process a "last-minute" revocation request and for the request to propagate through the revocation system. This grace period is to be added to the time included with the time-stamp token or the time-mark, and thus the revocation status information should be captured after the end of the grace period.
Top   ToC   RFC5126 - Page 110
C.4.1.1. CRL Information
When using CRLs to get revocation information, a verifier will have to make sure that he or she gets, at the time of the first verification, the appropriate certificate revocation information from the signer's CA. This should be done as soon as possible to minimize the time delay between the generation and verification of the signature. However, a "grace period" is required to allow CAs time to process revocation requests. For example, a revocation request may arrive at a CA just before issuing the next CRL, and there may not enough time to include the revised revocation status information. This involves checking that the signer certificate serial number is not included in the CRL. Either the signer, the initial verifier, or a subsequent verifier may obtain this CRL. If obtained by the signer, then it shall be conveyed to the verifier. It may be convenient to archive the CRL for ease of subsequent verification or arbitration. Alternatively, provided the CRL is archived elsewhere, which is accessible for the purpose of arbitration, then the serial number of the CRL used may be archived together with the verified electronic signature as a CAdES-C form. Even if the certificate serial number appears in the CRL with the status "suspended" (i.e., on hold), the signature is not to be deemed as valid since a suspended certificate is not supposed to be used even by its rightful owner.
C.4.1.2. OCSP Information
When using OCSP to get revocation information, a verifier will have to make sure that he or she gets, at the time of the first verification, an OCSP response that contains the status "valid". This should be done as soon as possible after the generation of the signature, still providing a "grace period" suitable enough to allow the involved authority to process a "last-minute" revocation request. The signer, the verifier, or any other third party may fetch this OCSP response. Since OCSP responses are transient and thus are not archived by any TSP, including CA, it is the responsibility of every verifier to make sure that it is stored in a safe place. The simplest way is to store them associated with the electronic signature. An alternative would be to store them so that they can then be easily retrieved and incorporate references to them in the electronic signature itself as a CAdES-C form.
Top   ToC   RFC5126 - Page 111
   In the same way as for the case of the CRL, it may happen that the
   certificate is declared as invalid but with the secondary status
   "suspended".  In such a case, the same comment as for the CRL
   applies.

C.4.2. Certification Path

A verifier may have to ascertain that the certification path was valid, at the time of the signature, up to a trust point, according to the: - naming constraints; - certificate policy constraints; - signature policy, when applicable. Since the time of the signature cannot be known with certainty, an upper limit of it should be used as indicated by either the time-stamp or time-mark. In this case, it will be necessary to capture all the certificates from the certification path, starting with those from the signer and ending up with those of the self-signed certificate from one trusted root; when applicable, this may be specified as part of the Signature Policy. In addition, it will be necessary to capture the Certificate Authority Revocation Lists (CARLs) to prove that none of the CAs from the chain were revoked at the time of the signature. Again, all this material may be incorporated in the electronic signature (ES X forms). An alternative would be to store this information so that it can be easily retrieved and incorporate references to it in the electronic signature itself as a CAdES-C form.

C.4.3. Time-Stamping for Long Life of Signatures

An important property for long-standing signatures is that a signature, having been found once to be valid, shall continue to be so months or years later. A signer, verifier, or both may be required to provide, on request, proof that a digital signature was created or verified during the validity period of all the certificates that make up the certificate path. In this case, the signer, verifier, or both will also be required to provide proof that the signer's certificate and all the CA certificates used to form a valid certification path were not revoked when the signature was created or verified.
Top   ToC   RFC5126 - Page 112
   It would be quite unacceptable to consider a signature as invalid
   even if the keys or certificates were later compromised.  Thus, there
   is a need to be able to demonstrate that the signature keys were
   valid at the time that the signature was created to provide long-term
   evidence of the validity of a signature.

   It could be the case that a certificate was valid at the time of the
   signature but revoked some time later.  In this event, evidence shall
   be provided that the document was signed before the signing key was
   revoked.  Time-stamping by a Time-Stamping Authority (TSA) can
   provide such evidence.  A time-stamp is obtained by sending the hash
   value of the given data to the TSA.  The returned "time-stamp" is a
   signed document that contains the hash value, the identity of the
   TSA, and the time of stamping.  This proves that the given data
   existed before the time of stamping.  Time-stamping a digital
   signature (by sending a hash of the signature to the TSA) before the
   revocation of the signer's private key provides evidence that the
   signature had been created before the certificate was revoked.

   If a recipient wants to hold a valid electronic signature, he will
   have to ensure that he has obtained a valid time-stamp for it before
   that key (and any key involved in the validation) is revoked.  The
   sooner the time-stamp is obtained after the signing time, the better.
   Any time-stamp or time-mark that is taken after the expiration date
   of any certificate in the certification path has no value in proving
   the validity of a signature.

   It is important to note that signatures may be generated "off-line"
   and time-stamped at a later time by anyone, for example, by the
   signer or any recipient interested in the value of the signature.
   The time-stamp can thus be provided by the signer, together with the
   signed document, or obtained by the recipient following receipt of
   the signed document.

   The time-stamp is NOT a component of the Basic Electronic Signature,
   but it is the essential component of the ES with Time.

   It is required, in the present document, that if a signer's digital
   signature value is to be time-stamped, the time-stamp token is issued
   by a trusted source, known as a Time-Stamping Authority.

   The present document requires that the signer's digital signature
   value be time-stamped by a trusted source before the electronic
   signature can become an ES with Complete validation data.  Acceptable
   TSAs may be specified in a Signature Validation Policy.

   This technique is referred to as CAdES-C in the present document.
Top   ToC   RFC5126 - Page 113
   Should both the signer and verifier be required to time-stamp the
   signature value to meet the requirements of the signature policy, the
   signature policy may specify a permitted time delay between the two
   time-stamps.

C.4.4. Time-Stamping for Long Life of Signature before CA Key Compromises

Time-stamped, extended electronic signatures are needed when there is a requirement to safeguard against the possibility of a CA key in the certificate chain ever being compromised. A verifier may be required to provide, on request, proof that the certification path and the revocation information used at the time of the signature were valid, even in the case where one of the issuing keys or OCSP responder keys is later compromised. The present document defines two ways of using time-stamps to protect against this compromise: - time-stamp the ES with Complete validation data, when an OCSP response is used to get the status of the certificate from the signer (CAdES-X Type 1). This format is suitable to be used with an OCSP response, and it offers the additional advantage of providing an integrity protection over the whole data; - time-stamp only the certification path and revocation information references when a CRL is used to get the status of the certificate from the signer (CAdES-X Type2). This format is suitable to be used with CRLs, since the time-stamped information may be used for more than one signature (when signers have their certificates issued by the same CA and when signatures can be checked using the same CRLs). NOTE: The signer, verifier, or both may obtain the time-stamp.
C.4.4.1. Time-Stamping the ES with Complete Validation Data (CAdES-X Type 1)
When an OCSP response is used, it is necessary to time-stamp in particular that response in the case the key from the responder would be compromised. Since the information contained in the OCSP response is user specific and time specific, an individual time-stamp is needed for every signature received. Instead of placing the time-stamp only over the certification path references and revocation information references, which include the OCSP response, the time-stamp is placed on the CAdES-C. Since the certification path and revocation information references are included in the ES with Complete validation data, they are also protected. For the same
Top   ToC   RFC5126 - Page 114
   cryptographic price, this provides an integrity mechanism over the ES
   with Complete validation data.  Any modification can be immediately
   detected.  It should be noticed that other means of
   protecting/detecting the integrity of the ES with Complete validation
   data exist and could be used.  Although the technique requires a
   time-stamp for every signature, it is well suited for individual
   users wishing to have an integrity-protected copy of all the
   validated signatures they have received.

   By time-stamping the complete electronic signature, including the
   digital signature as well as the references to the certificates and
   revocation status information used to support validation of that
   signature, the time-stamp ensures that there is no ambiguity in the
   means of validating that signature.

   This technique is referred to as CAdES-X Type 1 in the present
   document.

      NOTE: Trust is achieved in the references by including a hash of
      the data being referenced.

   If it is desired for any reason to keep a copy of the additional data
   being referenced, the additional data may be attached to the
   electronic signature, in which case the electronic signature becomes
   a CAdES-X Long Type 1, as defined by the present document.

   A CAdES-X Long Type 1 is simply the concatenation of a CAdES-X Type
   1, with a copy of the additional data being referenced.

C.4.4.2. Time-Stamping Certificates and Revocation Information References (CAdES-X Type 2)
Time-stamping each ES with Complete validation data, as defined above, may not be efficient, particularly when the same set of CA certificates and CRL information is used to validate many signatures. Time-stamping CA certificates will stop any attacker from issuing bogus CA certificates that could be claimed to exist before the CA key was compromised. Any bogus time-stamped CA certificates will show that the certificate was created after the legitimate CA key was compromised. In the same way, time-stamping CA CRLs will stop any attacker from issuing bogus CA CRLs that could be claimed to exist before the CA key was compromised. Time-stamping of commonly used certificates and CRLs can be done centrally, e.g., inside a company or by a service provider. This method reduces the amount of data the verifier has to time-stamp; for example, it could be reduced to just one time-stamp per day (i.e., in
Top   ToC   RFC5126 - Page 115
   the case where all the signers use the same CA, and the CRL applies
   for the whole day).  The information that needs to be time-stamped is
   not the actual certificates and CRLs, but the unambiguous references
   to those certificates and CRLs.

   This technique is referred to as CAdES-X Type 2 in the present
   document and requires the following:

      - all the CA certificates references and revocation information
        references (i.e., CRLs) used in validating the CAdES-C are
        covered by one or more time-stamps.

   Thus, a CAdES-C with a time-stamp signature value at time T1 can be
   proved valid if all the CA and CRL references are time-stamped at
   time T1+.

C.4.5. Time-Stamping for Archive of Signature

Advances in computing increase the probability of being able to break algorithms and compromise keys. There is therefore a requirement to be able to protect electronic signatures against this possibility. Over a period of time, weaknesses may occur in the cryptographic algorithms used to create an electronic signature (e.g., due to the time available for cryptoanalysis, or improvements in cryptoanalytical techniques). Before such weaknesses become likely, a verifier should take extra measures to maintain the validity of the electronic signature. Several techniques could be used to achieve this goal, depending on the nature of the weakened cryptography. In order to simplify matters, a single technique called Archive validation data, covering all the cases, is being used in the present document. Archive validation data consists of the validation data and the complete certificate and revocation data, time-stamped together with the electronic signature. The Archive validation data is necessary if the hash function and the crypto algorithms that were used to create the signature are no longer secure. Also, if it cannot be assumed that the hash function used by the Time-Stamping Authority is secure, then nested time-stamps of the Archived Electronic Signature are required. The potential for a Trusted Service Provider (TSP) key compromise should be significantly lower than user keys because TSP(s) are expected to use stronger cryptography and better key protection. It can be expected that new algorithms (or old ones with greater key lengths) will be used. In such a case, a sequence of time-stamps will protect against forgery. Each time-stamp needs to be affixed
Top   ToC   RFC5126 - Page 116
   before either the compromise of the signing key or the cracking of
   the algorithms used by the TSA.  TSAs (Time-Stamping Authorities)
   should have long keys (e.g., which at the time of drafting the
   present document was at least 2048 bits for the signing RSA
   algorithm) and/or a "good" or different algorithm.

   Nested time-stamps will also protect the verifier against key
   compromise or cracking the algorithm on the old electronic
   signatures.

   The process will need to be performed and iterated before the
   cryptographic algorithms used for generating the previous time-stamp
   are no longer secure.  Archive validation data may thus bear multiple
   embedded time-stamps.

   This technique is referred to as CAdES-A in the present document.

C.4.6. Reference to Additional Data

Using CAdES-X Type 1 or CAdES-X Type 2 extended validation data, verifiers still need to keep track of all the components that were used to validate the signature, in order to be able to retrieve them again later on. These components may be archived by an external source, like a Trusted Service Provider; in which case, referenced information that is provided as part of the ES with Complete validation data (CAdES-C) is adequate. The actual certificates and CRL information reference in the CAdES-C can be gathered when needed for arbitration. If references to additional data are not adequate, then the actual values of all the certificates and revocation information required may be part of the electronic signature. This technique is referred to as CAdES-X Long Type 1 or CAdES-X Long Type 2 in the present document.

C.4.7. Time-Stamping for Mutual Recognition

In some business scenarios, both the signer and the verifier need to time-stamp their own copy of the signature value. Ideally, the two time-stamps should be as close as possible to each other. EXAMPLE: A contract is signed by two parties, A and B, representing their respective organizations; to time-stamp the signer and verifier data, two approaches are possible: - under the terms of the contract, a predefined common "trusted" TSA may be used;
Top   ToC   RFC5126 - Page 117
         - if both organizations run their own time-stamping services, A
           and B can have the transaction time-stamped by these two
           time-stamping services.

   In the latter case, the electronic signature will only be considered
   valid if both time-stamps were obtained in due time (i.e., there
   should not be a long delay between obtaining the two time-stamps).
   Thus, neither A nor B can repudiate the signing time indicated by
   their own time-stamping service.  Therefore, A and B do not need to
   agree on a common "trusted" TSA to get a valid transaction.

   It is important to note that signatures may be generated "off-line"
   and time-stamped at a later time by anyone, e.g., by the signer or
   any recipient interested in validating the signature.  The time-stamp
   over the signature from the signer can thus be provided by the
   signer, together with the signed document, and/or be obtained by the
   verifier following receipt of the signed document.

   The business scenarios may thus dictate that one or more of the
   long-term signature time-stamping methods described above be used.
   This may be part of a mutually agreed Signature Validation Policy
   that is part of an agreed signature policy under which digital
   signatures may be used to support the business relationship between
   the two parties.

C.4.8. TSA Key Compromise

TSA servers should be built in such a way that once the private signature key is installed, there is minimal likelihood of compromise over as long as a possible period. Thus, the validity period for the TSA's keys should be as long as possible. Both the CAdES-T and the CAdES-C contain at least one time-stamp over the signer's signature. In order to protect against the compromise of the private signature key used to produce that time-stamp, the Archive validation data can be used when a different Time-Stamping Authority key is involved to produce the additional time-stamp. If it is believed that the TSA key used in providing an earlier time-stamp may ever be compromised (e.g., outside its validity period), then the CAdES-A should be used. For extremely long periods, this may be applied repeatedly using new TSA keys. This technique is referred to as a nested CAdES-A in the present document.
Top   ToC   RFC5126 - Page 118

C.5. Multiple Signatures

Some electronic signatures may only be valid if they bear more than one signature. This is generally the case when a contract is signed between two parties. The ordering of the signatures may or may not be important, i.e., one may or may not need to be applied before the other. Several forms of multiple and counter signatures need to be supported, which fall into two basic categories: - independent signatures; - embedded signatures. Independent signatures are parallel signatures where the ordering of the signatures is not important. The capability to have more than one independent signature over the same data shall be provided. Embedded signatures are applied one after the other and are used where the order in which the signatures are applied is important. The capability to sign over signed data shall be provided. These forms are described in Section 5.13. All other multiple signature schemes, e.g., a signed document with a countersignature, double countersignatures, or multiple signatures can be reduced to one or more occurrences of the above two cases.

Annex D (Informative): Data Protocols to Interoperate with TSPs

D.1. Operational Protocols

The following protocols can be used by signers and verifiers to interoperate with Trusted Service Providers during the electronic signature creation and validation.

D.1.1. Certificate Retrieval

User certificates, CA certificates, and cross-certificates can be retrieved from a repository using the Lightweight Directory Access Protocol as defined in RFC 3494 [RFC3494], with the schema defined in RFC 4523 [RFC4523].

D.1.2. CRL Retrieval

Certificate revocation lists, including authority revocation lists and partial CRL variants, can be retrieved from a repository using the Lightweight Directory Access Protocol, as defined in RFC 3494 [RFC3494], with the schema defined in RFC 4523 [RFC4523].
Top   ToC   RFC5126 - Page 119

D.1.3. Online Certificate Status

As an alternative to the use of certificate revocation lists, the status of a certificate can be checked using the Online Certificate Status Protocol (OCSP), as defined in RFC 2560 [3].

D.1.4. Time-Stamping

The time-stamping service can be accessed using the Time-Stamping Protocol defined in RFC 3161 [7].

D.2. Management Protocols

Signers and verifiers can use the following management protocols to manage the use of certificates.

D.2.1. Request for Certificate Revocation

Request for a certificate to be revoked can be made using the revocation request and response messages defined in RFC 4210 [RFC4210].

Annex E (Informative): Security Considerations

E.1. Protection of Private Key

The security of the electronic signature mechanism defined in the present document depends on the privacy of the signer's private key. Implementations should take steps to ensure that private keys cannot be compromised.

E.2. Choice of Algorithms

Implementers should be aware that cryptographic algorithms become weaker with time. As new cryptoanalysis techniques are developed and computing performance improves, the work factor to break a particular cryptographic algorithm will reduce. Therefore, cryptographic algorithm implementations should be modular, allowing new algorithms to be readily inserted. That is, implementers should be prepared for the set of mandatory-to-implement algorithms to change over time.
Top   ToC   RFC5126 - Page 120

Annex F (Informative): Example Structured Contents and MIME

F.1. Use of MIME to Encode Data

The signed content may be structured using MIME (Multipurpose Internet Mail Extensions -- RFC 2045 [6]). Whilst the MIME structure was initially developed for Internet email, it has a number of features that make it useful to provide a common structure for encoding a range of electronic documents and other multi-media data (e.g., photographs, video). These features include: - providing a means of signalling the type of "object" being carried (e.g., text, image, ZIP file, application data); - providing a means of associating a file name with an object; - associating several independent objects (e.g., a document and image) to form a multi-part object; - handling data encoded in text or binary and, if necessary, re-encoding the binary as text. When encoding a single object, MIME consists of: - header information, followed by; - encoded content. This structure can be extended to support multi-part content.

F.1.1. Header Information

A MIME header includes: MIME Version information: e.g., MIME-Version: 1.0 Content type information, which includes information describing the content sufficient for it to be presented to a user or application process, as required. This includes information on the "media type" (e.g., text, image, audio) or whether the data is for passing to a particular type of application. In the case of text, the content type includes information on the character set used, e.g., Content-Type: text/plain; charset="us-ascii". Content-encoding information, which defines how the content is encoded (see below about encoding supported by MIME).
Top   ToC   RFC5126 - Page 121
   Other information about the content, such as a description or an
   associated file name.

   An example MIME header for text object is:

   Mime-Version: 1.0
   Content-Type: text/plain; charset=ISO-8859-1
   Content-Transfer-Encoding: quoted-printable

   An example MIME header for a binary file containing a pdf document
   is:

   Content-Type: application/pdf
   Content-Transfer-Encoding: base64
   Content-Description: JCFV201.pdf
   Content-Disposition: filename="JCFV201.pdf"

F.1.2. Content Encoding

MIME supports a range of mechanisms for encoding both text and binary data. Text data can be carried transparently as lines of text data encoded in 7- or 8-bit ASCII characters. MIME also includes a "quoted-printable" encoding that converts characters other than the basic ASCII into an ASCII sequence. Binary can either be carried: - transparently as 8-bit octets; or - converted to a basic set of characters using a system called Base64. NOTE: As there are some mail relays that can only handle 7-bit ASCII, Base64 encoding is usually used on the Internet.

F.1.3. Multi-Part Content

Several objects (e.g., text and a file attachment) can be associated together using a special "multi-part" content type. This is indicated by the content type "multipart" with an indication of the string to be used indicating a separation between each part. In addition to a header for the overall multipart content, each part includes its own header information indicating the inner content type and encoding.
Top   ToC   RFC5126 - Page 122
   An example of a multipart content is:

Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="----
=_NextPart_000_01BC4599.98004A80"
Content-Transfer-Encoding: 7bit

------=_NextPart_000_01BC4599.98004A80
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Per your request, I've attached our proposal for the Java Card Version
2.0 API and the Java Card FAQ.

------=_NextPart_000_01BC4599.98004A80
Content-Type: application/pdf; name="JCFV201.pdf"
Content-Transfer-Encoding: base64
Content-Description: JCFV201.pdf
Content-Disposition: attachment; filename="JCFV201.pdf"

0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAACAAAAAgAAAAA
AAAAAEAAAtAAAAAEAAAD+////AAAAAAMAAAAGAAAA//////////////////////////////
//////////AANhAAQAYg==

------=_NextPart_000_01BC4599.98004A80--

   Multipart content can be nested.  So a set of associated objects
   (e.g., HTML text and images) can be handled as a single attachment to
   another object (e.g., text).

   The Content-Type from each part of the S/MIME message indicates the
   type of content.

F.2. S/MIME

The specific use of MIME to carry CMS (extended as defined in the present document) secured data is called S/MIME (see [RFC3851]). S/MIME carries electronic signatures as either: - an "application/pkcs7-mime" object with the CMS carried as a binary attachment (PKCS7 is the name of the early version of CMS). The signed data may be included in the SignedData, which itself may be included in a single S/MIME object. See [RFC3851], Section 3.4.2: "Signing Using application/pkcs7-mime with SignedData" and Figure F.1 hereafter.
Top   ToC   RFC5126 - Page 123
   or

      - a "multipart/signed" object with the signed data and the
        signature encoded as separate MIME objects.

        The signed data is not included in the SignedData, and the CMS
        structure only includes the signature.  See [RFC3851], Section
        3.4.3: "Signing Using the multipart/signed Format" and Figure
        F.2 hereafter.

        +-------------++----------++-------------++------------+
        |             ||          ||             ||            |
        |   S/MIME    ||  CAdES   ||    MIME     ||  pdf file  |
        |             ||          ||             ||            |
        |Content-Type=||SignedData||Content-Type=||Dear MrSmith|
        |application/ || eContent ||application/ ||Received    |
        |pkcs7-mime   ||          ||pdf          ||  100 tins  |
        |             ||          ||             ||            |
        |smime-type=  ||     /|   ||       /|    ||  Mr.Jones  |
        |signed-data  ||    / -----+      / ------+            |
        |             ||    \ -----+      \ ------+            |
        |             ||     \|   ||       \|    |+------------+
        |             ||          |+-------------+
        |             |+----------+
        +-------------+

            Figure F.1: Signing Using application/pkcs7-mime

F.2.1. Using application/pkcs7-mime

This approach is similar to handling signed data as any other binary file attachment. An example of signed data encoded using this approach is: Content-Type: application/pkcs7-mime; smime-type=signed-data; Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=smime.p7m 567GhIGfHfYT6ghyHhHUujpfyF4f8HHGTrfvhJhjH776tbB9HG4VQbnj7 77n8HHGT9HG4VQpfyF467GhIGfHfYT6rfvbnj756tbBghyHhHUujhJhjH HUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H7n8HHGghyHh 6YT64V0GhIGfHfQbnj75
Top   ToC   RFC5126 - Page 124

F.2.2. Using application/pkcs7-signature

CMS also supports an alternative structure where the signature and data being protected are separate MIME objects carried within a single message. In this case, the signed data is not included in the SignedData, and the CMS structure only includes the signature. See [RFC3851], Section 3.4.3: "Signing Using the multipart/signed Format" and Figure F.2 hereafter. An example of signed data encoded using this approach is: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary=boundary42 --boundary42 Content-Type: text/plain This is a clear-signed message. --boundary42 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=smime.p7s ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6 4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 7GhIGfHfYT64VQbnj756 --boundary42-- With this second approach, the signed data passes through the CMS process and is carried as part of a multiple-parts signed MIME structure, as illustrated in Figure F.2. The CMS structure just holds the electronic signature.
Top   ToC   RFC5126 - Page 125
   +---------------++----------++-------------++------------+
   |               ||          ||             ||            |
   |     MIME      ||  CAdES   ||    MIME     ||  pdf file  |
   |               ||          ||             ||            |
   |Content-Type=  ||SignedData||Content-Type=||Dear MrSmith|
   |multipart/     ||          ||application/ ||Received    |
   |signed         ||          ||pdf          ||  100 tins  |
   |        /|     ||          ||             ||            |
   |       / -------------------+        /|   ||  Mr.Jones  |
   |       \ -------------------+       / -----+            |
   |        \|     ||          ||       \ -----+            |
   |Content-Type=  ||          ||        \|   |+------------+
   |application/   ||          |+-------------+
   |pdf            ||          |
   |               ||          |
   |Content-Type=  ||          |
   |application/   ||          |
   |pkcs7-signature||          |
   |               ||          |
   |        /|     ||          |
   |       / -------+          |
   |       \ -------+          |
   |        \|     ||----------+
   |               |
   +---------------+

       Figure F.2: Signing Using application/pkcs7-signature

   This second approach (multipart/signed) has the advantage that the
   signed data can be decoded by any MIME-compatible system even if it
   does not recognize CMS-encoded electronic signatures.

Annex G (Informative): Relationship to the European Directive and EESSI

G.1. Introduction

This annex provides an indication of the relationship between electronic signatures created under the present document and requirements under the European Parliament and Council Directive on a Community framework for electronic signatures. NOTE: Legal advice should be sought on the specific national legislation regarding use of electronic signatures. The present document is one of a set of standards that has been defined under the "European Electronic Signature Standardization Initiative" (EESSI) for electronic signature products and solutions compliant with the European Directive for Electronic Signatures.
Top   ToC   RFC5126 - Page 126

G.2. Electronic Signatures and the Directive

This directive defines electronic signatures as: - "data in electronic form which are attached to or logically associated with other electronic data and which serve as a method of authentication". The directive states that an electronic signature should not be denied "legal effectiveness and admissibility as evidence in legal proceedings" solely on the grounds that it is in electronic form. The directive identifies an electronic signature as having equivalence to a hand-written signature if it meets specific criteria: - it is an "advanced electronic signature" with the following properties: a) it is uniquely linked to the signatory; b) it is capable of identifying the signatory; c) it is created using means that the signatory can maintain under his sole control; and d) it is linked to the data to which it relates in such a manner that any subsequent change of the data is detectable. - it is based on a certificate that meets detailed criteria given in Annex I of the directive and is issued by a "certification-service-provider" that meets requirements given in Annex II of the directive. Such a certificate is referred to as a "qualified certificate"; - it is created by a "device", for which detailed criteria are given in Annex III of the directive. Such a device is referred to a "secure-signature-creation device". This form of electronic signature is referred to as a "qualified electronic signature" in EESSI (see below).
Top   ToC   RFC5126 - Page 127

G.3. ETSI Electronic Signature Formats and the Directive

An electronic signature created in accordance with the present document is: a) considered to be an "electronic signature" under the terms of the Directive; b) considered to be an "advanced electronic signature" under the terms of the Directive; c) considered to be a "Qualified Electronic Signature", provided the additional requirements in Annex I, II, and III of the Directive are met. The requirements in Annex I, II, and III of the Directive are outside the scope of the present document, and are subject to standardization elsewhere.

G.4. EESSI Standards and Classes of Electronic Signature

G.4.1. Structure of EESSI Standardization

EESSI looks at standards in several areas. See the ETSI and CEN web sites for the latest list of standards and their versions: - use of X.509 public key certificates as qualified certificates; - security Management and Certificate Policy for CSPs Issuing Qualified Certificates; - security requirements for trustworthy systems used by CSPs Issuing Qualified Certificates; - security requirements for Secure Signature Creation Devices; - security requirements for Signature Creation Systems; - procedures for Electronic Signature Verification; - electronic signature syntax and encoding formats; - protocol to interoperate with a Time-Stamping Authority; - Policy requirements for Time-Stamping Authorities; and - XML electronic signature formats.
Top   ToC   RFC5126 - Page 128
   Each of these standards addresses a range of requirements, including
   the requirements of Qualified Electronic Signatures, as specified in
   Article 5.1 of the Directive.  However, some of them also address
   general requirements of electronic signatures for business and
   electronic commerce, which all fall into the category of Article 5.2
   of the Directive.  Such variation in the requirements may be
   identified either as different levels or different options.

G.4.2. Classes of Electronic Signatures

Since some of these standards address a range of requirements, it may be useful to identify a set of standards to address a specific business need. Such a set of standards and their uses define a class of electronic signature. The first class already identified is the qualified electronic signature, fulfilling the requirements of Article 5.1 of the Directive. A limited number of "classes of electronic signatures" and corresponding profiles could be defined in close cooperation with actors on the market (business, users, suppliers). The need for such standards is envisaged, in addition to those for qualified electronic signatures, in areas such as: - different classes of electronic signatures with long-term validity; - electronic signatures for business transactions with limited value.

G.4.3. Electronic Signature Classes and the ETSI Electronic Signature Format

The electronic signature format defined in the present document is applicable to the EESSI area "electronic signature and encoding formats". An electronic signature produced by a signer (see Section 5 and conformance Section 10.1) is applicable to the proposed class of electronic signature: "qualified electronic signatures fulfilling article 5.1". With the addition of attributes by the verifier (see Section 6 and conformance Section 10.2) the qualified electronic signature supports long-term validity.


(next page on part 7)

Next Section