Tony,
3. This is already done with RFC 3126, "Electronic Signature
Formats for long term electronic signatures".
RFC 3126 does not support the exact solution you propose, but provides a
solution to the problem you want to solve.
Denis
This is not a comment on the proposed draft text, but rather a question as to
whether the issue discussed below should be addressed by adding another
"enhanced service" to ESS or rather to consider a separate draft.
The inclination is to keep it separate to avoid delaying ESS-bis, but it MAY
logically fit within ESS...
The response to this e-mail could be:
1. Lets add a section to ESS to address this issue.
2. Issue sounds interesting but it should be proposed as a separate draft and
we'll look at it.
3. This can already be done with "XYZ".
4. Not interested (silence).
In any event, it provides an opportunity to breach the issue to the list and
invite opinions!
What is all this about?
It is argued that there is a need for a scheme to permit the inclusion of "proof
of signing-certificate validation" in signed messages (and potentially in signed
receipts). ESS section 5 discusses a related issue.
Traditional signed messaging using CMS and MSG is based on the originator
appending a signature to a message which is subsequently checked by the message
receiver(s), with receivers checking the validity (e.g. revocation status) of
the corresponding public key certificate. This method has problems (detailed
below) which could be mitigated if there was a way to force the certificate (and
certificate use) validation to occur at signing time (or close to signing time).
The traditional method has shortcomings in situations where signature validation
occurs some time after signature creation, as is common in S/MIME environments
where signed messages, including archived messages, may be checked months and
possibly years later. If a key compromise and revocation were to occur in the
meantime, or the certificate were to expire, the signature will be incorrectly
judged as invalid (or incapable of being verified). (Some implementations try to
cache old crls to permit old messages to be validated, but this opens security
holes.)
It is also a concern when attempting to use this method for non-repudiation;
since the subsequent compromise of the key (accidentally or otherwise) permits
the originator to retroactively refute its creation. (And non-repudiation is
not supported past certificate expiry.)
A Time Stamp Server may be used to establish that the message existed prior to a
certain time so that subsequent key compromise (or certificate expiry) will not
invalidate the signature. However, this requires adjustment to the way in which
the messages are handled (e.g. copied to time stamp servers) and these services
normally do not fully understand originator security policies and cannot fully
validate "correct use" of the certificate (as will be discussed next).
Another issue arises if enterprises want to enforce how signatures are applied
using their certificates. For example the enterprises may wish to enforce the
X.509 privateKeyUsagePeriod attribute. Enforcement of the "not Before" time is
not possible with current approaches, and enforcement of "not After" suffers
from the same limitations discussed above. That is, the signature may have been
applied at a valid time, but the subsequent check by the receiver may occur
after signing key usage expiry, producing an erroneous negative result (and
realizing that the "signing time" in the message cannot be trusted since it is
only protected by the signature being verified).
Uncommon or unique-to-the-originating-enterprise signing-key usage restrictions
may also not be capable of being enforced by receivers (or time stamp servers)
since only the originating enterprise may understand their relevance.
Some environments may further require the inclusion of fixed "boilerplate" or
dynamically generated text statements limiting liability, or the inclusion of
attribute certificates. While such statements may be included in certificates,
or the security policies associated with certificates, some enterprises may need
to use dynamic approaches which can be applied when the signature is applied.
For example, authorization to commit the organization (e.g. in a purchase order)
may be dynamically altered based on the date or temporarily delegated to
specific identities (to support "acting" authorities, to designate current
signing authority -"this signature is valid only for purchases up to $10,000"-,
etc).
Finally, in automated applications, for example SCADA (Supervisory Control and
Data Acquisition) and telecontrol applications, the relaxation of receiver
revocation checking requirements will permit the deployment of receivers (e.g.
actuators) with limited processing and on-line access capabilities. For example,
a programmable controller creating a command for a remote actuator could be
required to obtain and include the "proof" signerInfo obtained from a local
security server. By using short certificate periods in the server and trusted
clocks in the server and actuator, an adequately secure (potentially
unidirectional simplex) command/control link might be established.
Proposal:
It is initially proposed to only define the "proof of signing certificate
validation" signerInfo structure. The specification of how the originator, or
any intermediate element, obtains this signerInfo from a "security server" could
be left open since this is not required for interoperability between the
originator and receiver. This operation will occur within the originating
enterprise and thus it MAY be implemented in a proprietary manner. Depending
upon interest it might be advantageous to expose this interface and identify a
protocol however.
The "proof of certificate validation" SignerInfo itself will rely on the use of
a public certificate and so one might argue that this only replaces one
validation with another. However, it is argued that the "proof of certificate
validation" SignerInfo is created by a device high in the organization's trust
hierarchy which can have better key protection, potentially shorter certificate
periods, and implement other measures to reduced the probability of compromise,
and thus the need for automated certificate validation may be avoided (e.g.
replaced by manual means).
If there is interest on the list, Peter Gutmann and I will put together a draft.
HOWEVER, if Jim Schaad and the list were to prefer it be included in the ESS
revision we would happily turn it over!
Tony