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 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 describe above be used.
This will need to be part of a mutually agreed the Signature
Validation Policy with is part of the overall signature policy under
which digital signature may be used to support the business
relationship between the two parties.
B.4.10 TSA Key Compromise
TSA servers should be built in such a way that once the private
signature key is installed, that there is minimal likelihood of
compromise over as long as possible period. Thus the validity period
for the TSA's keys should be as long as possible.
Both the ES-T and the ES-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 ES-A should be used. For extremely long periods this may be
applied repeatedly using new TSA keys.
B.5 Multiple Signatures
Some electronic signatures may only be valid if they bear more than
one signature. This is the case generally 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 may 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 must be provided.
Embedded signatures are applied one after the other and are used
where the order the signatures are applied is important. The
capability to sign over signed data must be provided.
These forms are described in clause 3.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 occurrence of the above two cases.
Annex C (informative): Identifiers and roles
C.1 Signer Name Forms
The name used by the signer, held as the subject in the signer's
certificate, must uniquely identify the entity. The name must be
allocated and verified on registration with the Certification
Authority, either directly or indirectly through a Registration
Authority, before being issued with a Certificate.
This document places no restrictions on the form of the name. The
subject's name may be a distinguished name, as defined in [RFC2459],
held in the subject field of the certificate, or any other name form
held in the X.509 subjectAltName certificate extension field. In the
case that the subject has no distinguished name, the subject name can
be an empty sequence and the subjectAltName extension must be
critical.
C.2 TSP Name Forms
All TSP name forms (Certification Authorities, Attribute Authorities
and Time-Stamping Authorities) must be in the form of a distinguished
name held in the subject field of the certificate.
The TSP name form must include the legal jurisdiction (i.e., country)
under which it operates and an identification for the organization
providing the service.
C.3 Roles and Signer Attributes
Where a signer signs as an individual but wishes to also identify
him/herself as acting on behalf of an organization, it may be
necessary to provide two independent forms of identification. The
first identity, with is directly associated with the signing key
identifies him/her as an individual. The second, which is managed
independently, identifies that person acting as part of the
organization, possibly with a given role.
In this case the first identity is carried in the
subject/subjectAltName field of the signer's certificate as described
above.
This document supports the following means of providing a second form
of identification:
* by placing a secondary name field containing a claimed role in
the CMS signed attributes field;
* by placing an attribute certificate containing a certified role
in the CMS signed attributes field.
Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFCEditor function is currently provided by the
Internet Society.