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.
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.
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.
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.
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+.
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.
- 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.
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. RFC3494], with the schema defined in RFC 4523 [RFC4523]. RFC3494], with the schema defined in RFC 4523 [RFC4523].
RFC 2045 ). 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.
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"
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. 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.
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
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.
+---------------++----------++-------------++------------+ | || || || | | 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.
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. 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.