Denis:
I did look at 3126 and indeed hope that the solution would be as close a subset
(profile) of that as possible.
3126 has many capabilities, but was hoping for a simple way for originators (or
originating domain gateways) to add information bound to the message instance
which would reduce the load on the ultimate receivers - and especially receivers
operating in foreign domains who do not want to understand certificate
restrictions imposed within the originating domain. Also reducing receiver load
is essential for telecontrol and SCADA where the actuators are simple and
potentially on the end of restrictive communications links.
I would not expect this to replace 3126 for more complex applications or where
formal legal requirements must be met.
An ideal solution could be a subset profile of 3126, potentially adding (as
necessary) optional attributes. Also simplifications are possible since the
"proof..." signerInfo is always constructed within the originating domain (so
cross-certification, cert chaining, third party servers (including time stamp
servers, arbiters, ...), etc. are not required).
Denis, I wonder if you could suggest a profile of 3126 which could be used? If
we can do this with a profile alone without anything new this would make
everything easier. I was hoping all we needed was an appropriate signerInfo
structure definition along with non-normative words describing how it is used.
Tony
| -----Original Message-----
| From: owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org
| [mailto:owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of Denis
Pinkas
| Sent: December 10, 2004 8:47 AM
| To: Tony Capel
| Cc: ietf-smime(_at_)imc(_dot_)org; Peter Gutmann
| Subject: Re: I-D ACTION:draft-ietf-smime-rfc2634-update-00.txt
|
|
|
| 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
| >
| >
|
|