Subject: Re: I-D ACTION:draft-ietf-smime-rfc2634-update-00.txt

From: "Sean P. Turner" <[email-masked]>
Date: Fri, 03 Dec 2004 22:43:35 -0500

All,

I'd like to ask people to please review this document.

spt

[email-masked] wrote:

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the S/MIME Mail Security Working Group of the IETF.

Title : Enhanced Security Services for S/MIME
Author(s) : J. Schaad
Filename : draft-ietf-smime-rfc2634-update-00.txt
Pages : 31
Date : 2004-11-29

This document describes the structures and procedures necessary to
provide a number of additional security services for S/MIME. These
services are:

- signed receipts
- security labels
- secure mailing lists
- signing certificate validation

These services can be used by any CMS (Cryptographic Message Syntax)
based protocol.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-rfc2634-update-00.txt

To remove yourself from the I-D Announcement list, send a message to
[email-masked] with the word unsubscribe in the body of the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-smime-rfc2634-update-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
[email-masked].
In the body type:
"FILE /internet-drafts/draft-ietf-smime-rfc2634-update-00.txt".

NOTE: The mail server at ietf.org can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e. documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: "Tony Capel" <[email-masked]>
Date: Thu, 9 Dec 2004 16:00:18 -0500

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

---

From: Denis Pinkas <[email-masked]>
Date: Fri, 10 Dec 2004 14:46:48 +0100

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

---

From: "Tony Capel" <[email-masked]>
Date: Fri, 10 Dec 2004 10:05:14 -0500

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: [email-masked] 
| [mailto:[email-masked]] On Behalf Of Denis Pinkas
| Sent: December 10, 2004 8:47 AM
| To: Tony Capel
| Cc: [email-masked]; 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
| > 
| > 
| 
|