tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 5126

 
 
 

CMS Advanced Electronic Signatures (CAdES)

Part 6 of 7, p. 109 to 128
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 109 
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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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 RFC Part