[4]:

["Popplewell" <[e-mail]>]

We offer the software for downloads only. 

http://qbyqybj.oemcheckoutplace.com





Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAUL9tmd091541 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Nov 2007 14:09:55 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lAUL9tPd091540; Fri, 30 Nov 2007 14:09:55 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from bosco.isi.edu (bosco.isi.edu [128.9.168.207]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAUL9s2A091533 for <[e-mail]>; Fri, 30 Nov 2007 14:09:54 -0700 (MST) (envelope-from [e-mail])
Received: by bosco.isi.edu (Postfix, from userid 70) id 97DF6F7450; Fri, 30 Nov 2007 13:09:49 -0800 (PST)
To: [e-mail], [e-mail]
Subject:  RFC 5083 on Cryptographic Message Syntax (CMS) Authenticated-Enveloped-Data Content Type
From: [e-mail]
Cc: [e-mail], [e-mail]
Message-Id: <[e-mail]>
Date: Fri, 30 Nov 2007 13:09:49 -0800 (PST)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

A new Request for Comments is now available in online RFC libraries.

        
        RFC 5083

        Title:      Cryptographic Message Syntax (CMS)  
                    Authenticated-Enveloped-Data 
                    Content Type 
        Author:     R. Housley
        Status:     Standards Track
        Date:       November 2007
        Mailbox:    [e-mail]
        Pages:      10
        Characters: 22810
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-smime-cms-auth-enveloped-06.txt

        URL:        http://www.rfc-editor.org/rfc/rfc5083.txt

This document describes an additional content type for the
Cryptographic Message Syntax (CMS).  The authenticated-enveloped-data
content type is intended for use with authenticated encryption modes.
All of the various key management techniques that are supported in
the CMS enveloped-data content type are also supported by the CMS
authenticated-enveloped-data content type.  [STANDARDS TRACK]

This document is a product of the S/MIME Mail Security
Working Group of the IETF.

This is now a Proposed Standard Protocol.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and suggestions
for improvements.Please refer to the current edition of the Internet
 Official Protocol Standards (STD 1) for the standardization state and
 status of this protocol.  Distribution of this memo is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to [e-mail].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [e-mail].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [e-mail] with the message body 

help: ways_to_get_rfcs. For example:

        To: [e-mail]
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [e-mail].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

Submissions for Requests for Comments should be sent to
[e-mail].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.


The RFC Editor Team
USC/Information Sciences Institute

...




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAUL9rqX091529 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Nov 2007 14:09:53 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lAUL9q5N091528; Fri, 30 Nov 2007 14:09:52 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from bosco.isi.edu (bosco.isi.edu [128.9.168.207]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAUL9qTS091522 for <[e-mail]>; Fri, 30 Nov 2007 14:09:52 -0700 (MST) (envelope-from [e-mail])
Received: by bosco.isi.edu (Postfix, from userid 70) id B1B92F7452; Fri, 30 Nov 2007 13:09:51 -0800 (PST)
To: [e-mail], [e-mail]
Subject:  RFC 5084 on Using AES-CCM and AES-GCM Authenticated Encryption in the Cryptographic Message Syntax (CMS)
From: [e-mail]
Cc: [e-mail], [e-mail]
Message-Id: <[e-mail]>
Date: Fri, 30 Nov 2007 13:09:51 -0800 (PST)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

A new Request for Comments is now available in online RFC libraries.

        
        RFC 5084

        Title:      Using AES-CCM and AES-GCM Authenticated 
                    Encryption in the Cryptographic Message Syntax 
                    (CMS) 
        Author:     R. Housley
        Status:     Standards Track
        Date:       November 2007
        Mailbox:    [e-mail]
        Pages:      11
        Characters: 21822
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-smime-cms-aes-ccm-and-gcm-03.txt

        URL:        http://www.rfc-editor.org/rfc/rfc5084.txt

This document specifies the conventions for using the AES-CCM and the
AES-GCM authenticated encryption algorithms with the Cryptographic
Message Syntax (CMS) authenticated-enveloped-data content type.  
[STANDARDS TRACK]

This document is a product of the S/MIME Mail Security
Working Group of the IETF.

This is now a Proposed Standard Protocol.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and suggestions
for improvements.Please refer to the current edition of the Internet
 Official Protocol Standards (STD 1) for the standardization state and
 status of this protocol.  Distribution of this memo is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to [e-mail].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [e-mail].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [e-mail] with the message body 

help: ways_to_get_rfcs. For example:

        To: [e-mail]
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [e-mail].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

Submissions for Requests for Comments should be sent to
[e-mail].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.


The RFC Editor Team
USC/Information Sciences Institute

...




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lASGOTFZ048637 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Nov 2007 09:24:29 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lASGOTha048636; Wed, 28 Nov 2007 09:24:29 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [192.160.51.76]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lASGOS7T048629 for <[e-mail]>; Wed, 28 Nov 2007 09:24:28 -0700 (MST) (envelope-from [e-mail])
Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.12.11.20060308/8.12.11) with SMTP id lASGORGT031710 for <[e-mail]>; Wed, 28 Nov 2007 11:24:27 -0500
Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (Postfix) with ESMTP id AEBADBF97 for <[e-mail]>; Wed, 28 Nov 2007 11:24:27 -0500 (EST)
Received: from IMCFE1.MITRE.ORG (imcfe1.mitre.org [129.83.29.3]) by smtp-bedford.mitre.org (8.12.11.20060308/8.12.11) with ESMTP id lASGORT1031693; Wed, 28 Nov 2007 11:24:27 -0500
Received: from [208.54.135.4] ([129.83.202.132]) by IMCFE1.MITRE.ORG with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Nov 2007 11:24:25 -0500
In-Reply-To: <00a701c82e7e$ecacbe40$82c5a8c0@arport2v>
References: <[e-mail]> <00a701c82e7e$ecacbe40$82c5a8c0@arport2v>
Mime-Version: 1.0 (Apple Message framework v752.3)
X-Priority: 3
Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-4-1063986942; protocol="application/pkcs7-signature"
Message-Id: <[e-mail]>
Cc: "Peter Gutmann" <[e-mail]>, <[e-mail]>
From: "Timothy J. Miller" <[e-mail]>
Subject: Re: S/MIME key distribution proposal
Date: Wed, 28 Nov 2007 10:23:52 -0600
To: Anders Rundgren <[e-mail]>
X-Mailer: Apple Mail (2.752.3)
X-OriginalArrivalTime: 28 Nov 2007 16:24:26.0950 (UTC) FILETIME=[25108E60:01C831DB]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--Apple-Mail-4-1063986942
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	delsp=yes;
	format=flowed

On Nov 24, 2007, at 3:46 AM, Anders Rundgren wrote:

> It seems that interrogating a Web Service associated with the target
> domain (like __mail_encryption.example.com) would be fairly simple to
> get going and facilitates immediate responses.  If the acquired  
> certificate
> is issued by a known party and conforms with the mail-address, it  
> seems
> that you can automate this.  Using a TLS connection to the service you
> might even accept any e-mail certificate issuer by "reusing" the  
> trust in the
> server certificate.  For encryption purposes this should be  
> satisfactory.

Depends on your needs.  DoD encrypted S/MIME is intended for end-to- 
end message privacy.  How do you get this by reusing a web service  
TLS certificate?

In addition, how do you get by the rfc822Name matching requirements?   
As far as I know *only* Microsoft Outlook can be configured to ignore  
the required match between the recipient's email address and the  
rfc822Name extension when encrypting a message.

> Using the most current key is also a factor that were missing in Ian's
> proposal.

This is a problem for all distribution methods *except* direct end  
user to end user exchanges.  Publication *always* lags issuance, and  
often enough fails completely.

> A security implication with using DNS + a WebService is that a bad
> provider could replace your encryption key with something that would
> allow it to read incoming messages in clear.

Not just a bad provider.  This exposes the key distribution mechanism  
to DNS hijacking as well.

> 						OTOH, that is what they
> already do today 99.9% of the time.  In fact, this scheme allows an
> enterprise to add content control by performing the decryption on the
> server.  For outgoing messages I believe Outlook already supports
> some kind of message "escrow" mechanism...

If the goal is end-to-end message privacy, then server-side  
decryption is a major violation.  If you allow *either* server-side  
decryption or end-user decryption, you've just made the protocol even  
more complex than it currently is (and now you have the problem of no  
knowing the complete security profile of your S/MIME deployment--are  
messages decrypted at the server or not, who chooses, and in what  
instances?).

-- Tim


--Apple-Mail-4-1063986942
Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Disposition: attachment;
	filename=smime.p7s

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIHUzCCA2cw
ggJPoAMCAQICAgaaMA0GCSqGSIb3DQEBBQUAMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UE
CxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3JhdGlvbiBQcmlt
YXJ5IENBLTEwHhcNMDcwMjI4MTM1MTI0WhcNMDgwODIxMTM1MTI0WjBaMRIwEAYDVQQKEwltaXRy
ZS5vcmcxDzANBgNVBAsTBnBlb3BsZTEXMBUGCgmSJomT8ixkAQETB3RtaWxsZXIxGjAYBgNVBAMT
EU1pbGxlciBUaW1vdGh5IEouMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDdpUHmSTmvwH16
KCBA3uXosw5bClu9nThq5kU/869taPaoWotpX1jnucczEnSrAwgBO9Ns7PIOpCtarIIOL2pRyX7e
xHs6IqmLY+3o3ew1lNZ5gJWhAiy+DBPGrhgDXkHqFAhLho0TA+09uroEmhCZARC3XZHk3pW8/jUS
+lHzLQIDAQABo4G3MIG0MA4GA1UdDwEB/wQEAwIF4DAdBgNVHQ4EFgQUXClSdJbPKPEdSSFG1e6J
IelCzrswHwYDVR0jBBgwFoAUh7QPSI1iM0LBLVEaSB7CnrsKsa0wRAYDVR0fBD0wOzA5oDegNYYz
aHR0cDovL3d3dy5taXRyZS5vcmcvdGVjaC9taWkvcGtpL2NhMV9taXRyZV9vcmcuY3JsMBwGA1Ud
EQQVMBOBEXRtaWxsZXJAbWl0cmUub3JnMA0GCSqGSIb3DQEBBQUAA4IBAQC6kURYV/MoIAl9Un6n
KXJ63Fi7y50uR7+f729M3QU3Em+/Is0XDAQ0oFERQu9kZQx6IQt0UFyTwZfDYmjYYOJAEB/691KS
DYBOeu4mzhwASbV7qSrTiDEbFqXupCKKXk5mRD6ECC0os8WF0kEkrUJPdGblBYfjta36hSqC8fOp
gvCLE8JNJIbPr3EmbSsApo0aeXtZZk/q8VNOvM/L25Pxb4TGF9puMUZ8nBolr1obM7aaGXmyGm5A
voGeZBbsnxG9LX+pRM4AP0S5Ttl1CtKReLX7PU0OVcing9RzC02dRxL8OUz53PYqNcJ0xmiwnPec
zCCEYjocKb0dx/U9yMJnMIID5DCCAsygAwIBAgIBBTANBgkqhkiG9w0BAQUFADBaMRIwEAYDVQQK
EwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0eTEkMCIGA1UEAxMbTUlU
UkUgQ29ycG9yYXRpb24gUm9vdCBDQS0xMB4XDTA2MDYwMzE3MTMyMloXDTEyMDYwMzE3MTMyMlow
XTESMBAGA1UEChMJbWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxJzAl
BgNVBAMTHk1JVFJFIENvcnBvcmF0aW9uIFByaW1hcnkgQ0EtMTCCASIwDQYJKoZIhvcNAQEBBQAD
ggEPADCCAQoCggEBAMjwe1ZdEIKoELdLvENnbkbO3mVD54ZX5SjxTzFxhvoqhqSJmLOp32xT7J9K
vBapJRbJv1BFdiSUN3O0q8H66nvQqwm1RYe+tTsWSO351FolGrDT9iDRtfWgH60PCKCbABLRsx3i
GnEvjOQjeAtMn1AugqQWU3PWZXYy1Grbya+NOytYvu1p60bDFSoSAn4Jojv14lUfWHl8s3kahay8
umLSQibiXdEEX8CrSkaXpOaFOuyM6+wpRw7TybO1Dk4zGAUtn0887QvsMDk6evgN2WxMprkHAGUc
JhpI1QXtkfDIl9ukdNiIoM/vdN2QC/+m6b8dA55K5UdlBa9SgRnwapkCAwEAAaOBsTCBrjASBgNV
HRMBAf8ECDAGAQH/AgECMA4GA1UdDwEB/wQEAwIBhjAdBgNVHQ4EFgQUh7QPSI1iM0LBLVEaSB7C
nrsKsa0wHwYDVR0jBBgwFoAUx3BRANhN/uQB1GiWxT2fmpf+dC8wSAYDVR0fBEEwPzA9oDugOYY3
aHR0cDovL3d3dy5taXRyZS5vcmcvdGVjaC9taWkvcGtpL3Jvb3RjYTFfbWl0cmVfb3JnLmNybDAN
BgkqhkiG9w0BAQUFAAOCAQEATW5u664p7N0iAj27Xl/akjdfkSQpaosf6cNyAHu7utCytFfY1WfR
NmvnNDGYkqI3XMFOa18SNjiNsMCH+sFQaO+oyDnPiIkEZQvlfGGrRpqIm6j//Fgz85bnf1kAM5I6
1Np7ofCnciRvp9ZB/+u+9i262tgiJPJrvBcqXmgeT9riCc3RPjxqPNmYslOvNLpIifchelJhF7nI
ge+7RkAUcTJenj8yKwK0J3+PEpgYRQ+V2C62rnjohuxPgMw/fYoNTOlh3MVl7adwyK1ahPw2a9eO
jSWglqoPTaBNeHJqRJZZ6Vi7S55+VAWCfkAqM5m3tUiVzjsp2dFcTJxnYezaoDGCAlQwggJQAgEB
MGMwXTESMBAGA1UEChMJbWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkx
JzAlBgNVBAMTHk1JVFJFIENvcnBvcmF0aW9uIFByaW1hcnkgQ0EtMQICBpowCQYFKw4DAhoFAKCC
AUcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDcxMTI4MTYyMzUz
WjAjBgkqhkiG9w0BCQQxFgQUt6LjPWlRh/e3V06BlWQ9CcSR9oswcgYJKwYBBAGCNxAEMWUwYzBd
MRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0eTEnMCUG
A1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIGmjB0BgsqhkiG9w0BCRACCzFl
oGMwXTESMBAGA1UEChMJbWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkx
JzAlBgNVBAMTHk1JVFJFIENvcnBvcmF0aW9uIFByaW1hcnkgQ0EtMQICBpowDQYJKoZIhvcNAQEB
BQAEgYBUeHxLNDNULTgJP+cu04qJRI8ala5ARbgXYBRz+rlOBuCMMyFZ0Apa1sDNGYN1xsssgkRM
Z/FhQoFImD4F2x/IXnEnwHOJtO60zrbKC2eM2LDYeFXHvxTHGJ6fY5RHTEJahXfDi/DYIDgwh3vA
UtmUh4NcBlLsMvur8qIefGcDlgAAAAAAAA==

--Apple-Mail-4-1063986942--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lASGENY9047726 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Nov 2007 09:14:23 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lASGENOD047725; Wed, 28 Nov 2007 09:14:23 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-bedford.mitre.org (smtpproxy1.mitre.org [192.160.51.76]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lASGELwY047718 for <[e-mail]>; Wed, 28 Nov 2007 09:14:22 -0700 (MST) (envelope-from [e-mail])
Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.12.11.20060308/8.12.11) with SMTP id lASGELQZ013384 for <[e-mail]>; Wed, 28 Nov 2007 11:14:21 -0500
Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (Postfix) with ESMTP id 4927DBF8F for <[e-mail]>; Wed, 28 Nov 2007 11:14:21 -0500 (EST)
Received: from imcfe2.MITRE.ORG (imcfe2.mitre.org [129.83.29.4]) by smtp-bedford.mitre.org (8.12.11.20060308/8.12.11) with ESMTP id lASGEKgI013369; Wed, 28 Nov 2007 11:14:20 -0500
Received: from [208.54.135.4] ([129.83.202.132]) by imcfe2.MITRE.ORG with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Nov 2007 11:14:19 -0500
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-3-1063381986; protocol="application/pkcs7-signature"
Message-Id: <[e-mail]>
Cc: [e-mail]
From: "Timothy J. Miller" <[e-mail]>
Subject: Re: S/MIME key distribution proposal
Date: Wed, 28 Nov 2007 10:13:47 -0600
To: Peter Gutmann <[e-mail]>
X-Mailer: Apple Mail (2.752.3)
X-OriginalArrivalTime: 28 Nov 2007 16:14:20.0161 (UTC) FILETIME=[BB63E710:01C831D9]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--Apple-Mail-3-1063381986
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	delsp=yes;
	format=flowed

On Nov 23, 2007, at 2:53 AM, Peter Gutmann wrote:

> That's *way* outside the scope of the proposal.  The point is that  
> if the user
> has an email key then chances are the MUA will already have it  
> available,
> since it needs to use it to process incoming mail.  In that case  
> it's a
> relatively trivial step to send it out in response to a "gimme your  
> key"
> request.  Things like CRLs are an entirely different matter, you go  
> to a CA
> for those (or wherever you choose to get them from).

And it may be too large to email, anyway.  DoD CRLs currently stand  
at about 120MB in the aggregate, averaging about 12MB per CA.

Everyone should be using OCSP anyway.  Do we have OCSP stapling for S/ 
MIME?

> At most I'd go for:
>
>   GETKEYS protocols addresses
>
>   protocols := SMIME, OpenPGP, ...
>   addresses := <optional email addresses to get keys for>
>
>   mesage-body = <human-readable message to say something like "Your  
> mailer
>   doesn't understand this message, please reply with your public  
> key if you
>   can">
>
> I'm not sure about the ability to include an optional email  
> address, on the
> one hand it makes things more flexible, but then you're starting to  
> bloat it
> up into a general-purpose key-server protocol, which it absolutely  
> isn't meant
> to be.  It's just a request to the MUA for the public key(s) that  
> it holds for
> the user/owner of the email address, in a manner that doesn't  
> require manual
> user processing if the MUA understands the request.

My concern would be with email address mismatches.  This is common in  
the DoD, where currently email addresses are assigned by location  
(this is changing, slowly, to permanent email addresses), but  
locations change frequently.  With the additional wrinkles of  
organizational mailboxes and XOs doing sent-on-behalf-of, the current  
RFC and implementation requirement of matching the rfc822Name  
extension with the originating email address causes us real  
significant operational pain.

In short, if you send a GETKEYS to the CO's email and the XO is  
running the MUA when it gets received, whose encryption cert should  
be returned?

-- Tim
--Apple-Mail-3-1063381986
Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Disposition: attachment;
	filename=smime.p7s

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIHUzCCA2cw
ggJPoAMCAQICAgaaMA0GCSqGSIb3DQEBBQUAMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UE
CxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3JhdGlvbiBQcmlt
YXJ5IENBLTEwHhcNMDcwMjI4MTM1MTI0WhcNMDgwODIxMTM1MTI0WjBaMRIwEAYDVQQKEwltaXRy
ZS5vcmcxDzANBgNVBAsTBnBlb3BsZTEXMBUGCgmSJomT8ixkAQETB3RtaWxsZXIxGjAYBgNVBAMT
EU1pbGxlciBUaW1vdGh5IEouMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDdpUHmSTmvwH16
KCBA3uXosw5bClu9nThq5kU/869taPaoWotpX1jnucczEnSrAwgBO9Ns7PIOpCtarIIOL2pRyX7e
xHs6IqmLY+3o3ew1lNZ5gJWhAiy+DBPGrhgDXkHqFAhLho0TA+09uroEmhCZARC3XZHk3pW8/jUS
+lHzLQIDAQABo4G3MIG0MA4GA1UdDwEB/wQEAwIF4DAdBgNVHQ4EFgQUXClSdJbPKPEdSSFG1e6J
IelCzrswHwYDVR0jBBgwFoAUh7QPSI1iM0LBLVEaSB7CnrsKsa0wRAYDVR0fBD0wOzA5oDegNYYz
aHR0cDovL3d3dy5taXRyZS5vcmcvdGVjaC9taWkvcGtpL2NhMV9taXRyZV9vcmcuY3JsMBwGA1Ud
EQQVMBOBEXRtaWxsZXJAbWl0cmUub3JnMA0GCSqGSIb3DQEBBQUAA4IBAQC6kURYV/MoIAl9Un6n
KXJ63Fi7y50uR7+f729M3QU3Em+/Is0XDAQ0oFERQu9kZQx6IQt0UFyTwZfDYmjYYOJAEB/691KS
DYBOeu4mzhwASbV7qSrTiDEbFqXupCKKXk5mRD6ECC0os8WF0kEkrUJPdGblBYfjta36hSqC8fOp
gvCLE8JNJIbPr3EmbSsApo0aeXtZZk/q8VNOvM/L25Pxb4TGF9puMUZ8nBolr1obM7aaGXmyGm5A
voGeZBbsnxG9LX+pRM4AP0S5Ttl1CtKReLX7PU0OVcing9RzC02dRxL8OUz53PYqNcJ0xmiwnPec
zCCEYjocKb0dx/U9yMJnMIID5DCCAsygAwIBAgIBBTANBgkqhkiG9w0BAQUFADBaMRIwEAYDVQQK
EwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0eTEkMCIGA1UEAxMbTUlU
UkUgQ29ycG9yYXRpb24gUm9vdCBDQS0xMB4XDTA2MDYwMzE3MTMyMloXDTEyMDYwMzE3MTMyMlow
XTESMBAGA1UEChMJbWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxJzAl
BgNVBAMTHk1JVFJFIENvcnBvcmF0aW9uIFByaW1hcnkgQ0EtMTCCASIwDQYJKoZIhvcNAQEBBQAD
ggEPADCCAQoCggEBAMjwe1ZdEIKoELdLvENnbkbO3mVD54ZX5SjxTzFxhvoqhqSJmLOp32xT7J9K
vBapJRbJv1BFdiSUN3O0q8H66nvQqwm1RYe+tTsWSO351FolGrDT9iDRtfWgH60PCKCbABLRsx3i
GnEvjOQjeAtMn1AugqQWU3PWZXYy1Grbya+NOytYvu1p60bDFSoSAn4Jojv14lUfWHl8s3kahay8
umLSQibiXdEEX8CrSkaXpOaFOuyM6+wpRw7TybO1Dk4zGAUtn0887QvsMDk6evgN2WxMprkHAGUc
JhpI1QXtkfDIl9ukdNiIoM/vdN2QC/+m6b8dA55K5UdlBa9SgRnwapkCAwEAAaOBsTCBrjASBgNV
HRMBAf8ECDAGAQH/AgECMA4GA1UdDwEB/wQEAwIBhjAdBgNVHQ4EFgQUh7QPSI1iM0LBLVEaSB7C
nrsKsa0wHwYDVR0jBBgwFoAUx3BRANhN/uQB1GiWxT2fmpf+dC8wSAYDVR0fBEEwPzA9oDugOYY3
aHR0cDovL3d3dy5taXRyZS5vcmcvdGVjaC9taWkvcGtpL3Jvb3RjYTFfbWl0cmVfb3JnLmNybDAN
BgkqhkiG9w0BAQUFAAOCAQEATW5u664p7N0iAj27Xl/akjdfkSQpaosf6cNyAHu7utCytFfY1WfR
NmvnNDGYkqI3XMFOa18SNjiNsMCH+sFQaO+oyDnPiIkEZQvlfGGrRpqIm6j//Fgz85bnf1kAM5I6
1Np7ofCnciRvp9ZB/+u+9i262tgiJPJrvBcqXmgeT9riCc3RPjxqPNmYslOvNLpIifchelJhF7nI
ge+7RkAUcTJenj8yKwK0J3+PEpgYRQ+V2C62rnjohuxPgMw/fYoNTOlh3MVl7adwyK1ahPw2a9eO
jSWglqoPTaBNeHJqRJZZ6Vi7S55+VAWCfkAqM5m3tUiVzjsp2dFcTJxnYezaoDGCAlQwggJQAgEB
MGMwXTESMBAGA1UEChMJbWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkx
JzAlBgNVBAMTHk1JVFJFIENvcnBvcmF0aW9uIFByaW1hcnkgQ0EtMQICBpowCQYFKw4DAhoFAKCC
AUcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDcxMTI4MTYxMzQ4
WjAjBgkqhkiG9w0BCQQxFgQUruJ8tYSmw/CHXBARGVLY28+qvEYwcgYJKwYBBAGCNxAEMWUwYzBd
MRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0eTEnMCUG
A1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIGmjB0BgsqhkiG9w0BCRACCzFl
oGMwXTESMBAGA1UEChMJbWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkx
JzAlBgNVBAMTHk1JVFJFIENvcnBvcmF0aW9uIFByaW1hcnkgQ0EtMQICBpowDQYJKoZIhvcNAQEB
BQAEgYBit41Y5WG1yPeVGfjpWKzHEb4iw7sdfrqInNo0fLO7qd+0ZMZY9EjeeI+9qYctnUbF0Av7
oy5UiAzriwrqowlYgN5bX6KCN4Mc4Jmjy9Z7Ff3xDwoTbgDTBI4fSiW19cWZUQ5krFYLJMU4/lDU
IcyKgXNa3KLfAMJzcxeWUq2XfwAAAAAAAA==

--Apple-Mail-3-1063381986--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lARCnqBZ038439 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Nov 2007 05:49:53 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lARCnqlD038438; Tue, 27 Nov 2007 05:49:52 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mx1.rz.ruhr-uni-bochum.de (mx1.rz.ruhr-uni-bochum.de [134.147.32.86]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id lARCnkNw038423 for <[e-mail]>; Tue, 27 Nov 2007 05:49:47 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 31224 invoked by uid 281); 27 Nov 2007 12:49:42 -0000
Received: from 134.147.64.5 by mx1.rz.ruhr-uni-bochum.de (envelope-from <[e-mail]>, uid 80) with qmail-scanner-2.01  (sophie: 3.05/2.49/4.21.   Clear:RC:1(134.147.64.5):.  Processed in 0.049569 secs); 27 Nov 2007 12:49:42 -0000
Received: from c2-3-4.rz.ruhr-uni-bochum.de (134.147.64.5) by mx1.rz.ruhr-uni-bochum.de with SMTP; 27 Nov 2007 12:49:42 -0000
Received: (qmail 13919 invoked by uid 281); 27 Nov 2007 12:49:42 -0000
Received: from 141.48.94.26 (mNHiDSxtQuUn/2ePWqDRDg==@141.48.94.26) by c2-3-4.rz.ruhr-uni-bochum.de (envelope-from <[e-mail]>, uid 80) with qmail-scanner-2.01  (sophie: 3.05/2.49/4.21.   Clear:RC:1(141.48.94.26):.  Processed in 0.039528 secs); 27 Nov 2007 12:49:42 -0000
Received: from unknown (HELO jotop) (mNHiDSxtQuUn/2ePWqDRDg==@141.48.94.26) by c2-3-4.rz.ruhr-uni-bochum.de with (RC4-MD5 encrypted) SMTP; 27 Nov 2007 12:49:41 -0000
From: =?iso-8859-1?Q?J=F6rg_Schwenk?= <[e-mail]>
To: "'Anders Rundgren'" <[e-mail]>, "'Peter Gutmann'" <[e-mail]>, <[e-mail]>
References: <[e-mail]> <00a701c82e7e$ecacbe40$82c5a8c0@arport2v>
Subject: AW: S/MIME key distribution proposal
Date: Tue, 27 Nov 2007 13:49:35 +0100
MIME-Version: 1.0
Message-ID: <003e01c830f3$f6c1eeb0$1a5e308d@jotop>
X-Mailer: Microsoft Office Outlook 11
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_003A_01C830FC.58223DB0"
In-Reply-To: <00a701c82e7e$ecacbe40$82c5a8c0@arport2v>
Thread-Index: Acgugu5gMdxayM5hSwaW1wfuP5Cn/ACcKb3A
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_003A_01C830FC.58223DB0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I'd think that since email is asynchronous communication anyway, the =
delay
in the MUA's response does not matter.

Also in contrast to a DNS or Web Service based solution, you will reach =
the
only entity that EXACTLY knows where the certificate is from only by =
email.

CRLs can later be retrieved by the requesting MUA from the URL given in =
the
certificate.

J=F6rg

-----Urspr=FCngliche Nachricht-----
Von: [e-mail] =
[mailto:[e-mail]] Im
Auftrag von Anders Rundgren
Gesendet: Samstag, 24. November 2007 10:47
An: Peter Gutmann; [e-mail]
Betreff: Re: S/MIME key distribution proposal


>Conversely, if you want [e-mail]'s public key, the best way
>to get it is to go straight to the horse's mouth and ask =
[e-mail],
>or in this case a proxy, his MUA.

If MUA means mail-client this introduces a noticeable latency as well as
only working when the MUA is on-line.   This alone makes this proposal
a rather handicapped scheme IMO.

It seems that interrogating a Web Service associated with the target
domain (like __mail_encryption.example.com) would be fairly simple to
get going and facilitates immediate responses.  If the acquired =
certificate
is issued by a known party and conforms with the mail-address, it seems
that you can automate this.  Using a TLS connection to the service you
might even accept any e-mail certificate issuer by "reusing" the trust =
in
the
server certificate.  For encryption purposes this should be =
satisfactory.

Using the most current key is also a factor that were missing in Ian's
proposal.

A security implication with using DNS + a WebService is that a bad
provider could replace your encryption key with something that would
allow it to read incoming messages in clear.  OTOH, that is what they
already do today 99.9% of the time.  In fact, this scheme allows an
enterprise to add content control by performing the decryption on the
server.  For outgoing messages I believe Outlook already supports
some kind of message "escrow" mechanism...

Anders


------=_NextPart_000_003A_01C830FC.58223DB0
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGtzCCA1Mw
ggK8oAMCAQICDgPYAAEAAuYuTmNUEqhuMA0GCSqGSIb3DQEBBAUAMIG8MQswCQYDVQQGEwJERTEQ
MA4GA1UECBMHSGFtYnVyZzEQMA4GA1UEBxMHSGFtYnVyZzE6MDgGA1UEChMxVEMgVHJ1c3RDZW50
ZXIgZm9yIFNlY3VyaXR5IGluIERhdGEgTmV0d29ya3MgR21iSDEiMCAGA1UECxMZVEMgVHJ1c3RD
ZW50ZXIgQ2xhc3MgMSBDQTEpMCcGCSqGSIb3DQEJARYaY2VydGlmaWNhdGVAdHJ1c3RjZW50ZXIu
ZGUwHhcNMDcwNzAyMTA1MzUyWhcNMDgwODIxMTA1MzUyWjBKMQswCQYDVQQGEwJERTEWMBQGA1UE
AxMNSm9lcmcgU2Nod2VuazEjMCEGCSqGSIb3DQEJARYUam9lcmcuc2Nod2Vua0BydWIuZGUwgZ8w
DQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAL87hBfH2WpWbqzzSHa01D/EXd+mumSJaTjgMAq3Jzte
NBcMZ0/0P9TSjc/CAXkFsaxrEHd+2ddr8rVMjgyL1ACJ8yYsSL0Xl2bYKPjxPBL1Hhj7Npn+Gx1I
BRH23trbSlXYyyf23zBK9/zSaJCX1lrYOh9uABAh4lUayTWBLowTAgMBAAGjgcgwgcUwDAYDVR0T
AQH/BAIwADAOBgNVHQ8BAf8EBAMCBeAwMwYJYIZIAYb4QgEIBCYWJGh0dHA6Ly93d3cudHJ1c3Rj
ZW50ZXIuZGUvZ3VpZGVsaW5lczARBglghkgBhvhCAQEEBAMCBaAwXQYJYIZIAYb4QgEDBFAWTmh0
dHBzOi8vd3d3LnRydXN0Y2VudGVyLmRlL2NnaS1iaW4vY2hlY2stcmV2LmNnaS8wM0Q4MDAwMTAw
MDJFNjJFNEU2MzU0MTJBODZFPzANBgkqhkiG9w0BAQQFAAOBgQAX7f7Uf+07c7YnZjsJAk8Vokbp
RPyQmtjmuTjBGhmI3Bebt+KHiEc1IK0HsoXIygouWghdUf4wiz3rWPWPsHNhzUCpiL4R7tYr3BDI
ntjOj91o67QETMR+zp840S7H4UyUiBYw3eZKMsUISOA7xV51knhlegxjUx/zmjLOsAMxXzCCA1ww
ggLFoAMCAQICAgPpMA0GCSqGSIb3DQEBBAUAMIG8MQswCQYDVQQGEwJERTEQMA4GA1UECBMHSGFt
YnVyZzEQMA4GA1UEBxMHSGFtYnVyZzE6MDgGA1UEChMxVEMgVHJ1c3RDZW50ZXIgZm9yIFNlY3Vy
aXR5IGluIERhdGEgTmV0d29ya3MgR21iSDEiMCAGA1UECxMZVEMgVHJ1c3RDZW50ZXIgQ2xhc3Mg
MSBDQTEpMCcGCSqGSIb3DQEJARYaY2VydGlmaWNhdGVAdHJ1c3RjZW50ZXIuZGUwHhcNOTgwMzA5
MTE1OTU5WhcNMTEwMTAxMTE1OTU5WjCBvDELMAkGA1UEBhMCREUxEDAOBgNVBAgTB0hhbWJ1cmcx
EDAOBgNVBAcTB0hhbWJ1cmcxOjA4BgNVBAoTMVRDIFRydXN0Q2VudGVyIGZvciBTZWN1cml0eSBp
biBEYXRhIE5ldHdvcmtzIEdtYkgxIjAgBgNVBAsTGVRDIFRydXN0Q2VudGVyIENsYXNzIDEgQ0Ex
KTAnBgkqhkiG9w0BCQEWGmNlcnRpZmljYXRlQHRydXN0Y2VudGVyLmRlMIGfMA0GCSqGSIb3DQEB
AQUAA4GNADCBiQKBgQCwKeu0drOu17ZbtF7nveOxnEkEV1uhq9l/Exv9umGr2Odx3y0AlF1RSH0j
73VihJA8Ch9ZEXQvjoCl/TACPSlSzXIaSSGcvMtSjkihY5bIEIUwaVd0RcBahsbVPeBoV30xaiSN
RZc+MX5oZjJuJG3sMjbJQcrwMUTIo2HKG6A2HwIDAQABo2swaTAPBgNVHRMBAf8EBTADAQH/MA4G
A1UdDwEB/wQEAwIBhjAzBglghkgBhvhCAQgEJhYkaHR0cDovL3d3dy50cnVzdGNlbnRlci5kZS9n
dWlkZWxpbmVzMBEGCWCGSAGG+EIBAQQEAwIABzANBgkqhkiG9w0BAQQFAAOBgQBPmVmFyGRWgsVv
PdhGCS88UcGncFiBkhLq9NQWAJZecijn1jZfGpyvH8KDGrQFVZmmWFw3KPJXHutdv7HTRQ9yHAPS
AMcsVdr+X4l2i+LUd/VNCRevxLqrMCtPuB3q2f9Z8FB0Rrpe6jaw65J7D1jaMuFSvSM3D/XzAEqu
sF7ebjGCBAgwggQEAgEBMIHPMIG8MQswCQYDVQQGEwJERTEQMA4GA1UECBMHSGFtYnVyZzEQMA4G
A1UEBxMHSGFtYnVyZzE6MDgGA1UEChMxVEMgVHJ1c3RDZW50ZXIgZm9yIFNlY3VyaXR5IGluIERh
dGEgTmV0d29ya3MgR21iSDEiMCAGA1UECxMZVEMgVHJ1c3RDZW50ZXIgQ2xhc3MgMSBDQTEpMCcG
CSqGSIb3DQEJARYaY2VydGlmaWNhdGVAdHJ1c3RjZW50ZXIuZGUCDgPYAAEAAuYuTmNUEqhuMAkG
BSsOAwIaBQCgggKOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA3
MTEyNzEyNDkzNFowIwYJKoZIhvcNAQkEMRYEFMyDGUcdMAKf95bE5hWZ42sly7r5MGcGCSqGSIb3
DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsO
AwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMIHgBgkrBgEEAYI3EAQxgdIw
gc8wgbwxCzAJBgNVBAYTAkRFMRAwDgYDVQQIEwdIYW1idXJnMRAwDgYDVQQHEwdIYW1idXJnMTow
OAYDVQQKEzFUQyBUcnVzdENlbnRlciBmb3IgU2VjdXJpdHkgaW4gRGF0YSBOZXR3b3JrcyBHbWJI
MSIwIAYDVQQLExlUQyBUcnVzdENlbnRlciBDbGFzcyAxIENBMSkwJwYJKoZIhvcNAQkBFhpjZXJ0
aWZpY2F0ZUB0cnVzdGNlbnRlci5kZQIOA9gAAQAC5i5OY1QSqG4wgeIGCyqGSIb3DQEJEAILMYHS
oIHPMIG8MQswCQYDVQQGEwJERTEQMA4GA1UECBMHSGFtYnVyZzEQMA4GA1UEBxMHSGFtYnVyZzE6
MDgGA1UEChMxVEMgVHJ1c3RDZW50ZXIgZm9yIFNlY3VyaXR5IGluIERhdGEgTmV0d29ya3MgR21i
SDEiMCAGA1UECxMZVEMgVHJ1c3RDZW50ZXIgQ2xhc3MgMSBDQTEpMCcGCSqGSIb3DQEJARYaY2Vy
dGlmaWNhdGVAdHJ1c3RjZW50ZXIuZGUCDgPYAAEAAuYuTmNUEqhuMA0GCSqGSIb3DQEBAQUABIGA
q7o8xyC5xbcVg3XzjxxBAxaF6pOowhvsMUR7t3C7rZ8nlf2snfmIqjA3uDr5uHDkejuSbAakziFL
znUYicNsVakm83TEWS2tLdyNBZ/4G52uvAyFXuXWs7GugCFUyNytpCDmxuJA34qremQ+hvmUqis5
EhbLEUAszeMH83Xfk6EAAAAAAAA=

------=_NextPart_000_003A_01C830FC.58223DB0--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAQDm8JP039764 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Nov 2007 06:48:08 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lAQDm8ao039763; Mon, 26 Nov 2007 06:48:08 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp103.biz.mail.re2.yahoo.com (smtp103.biz.mail.re2.yahoo.com [68.142.229.217]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id lAQDm6Fk039754 for <[e-mail]>; Mon, 26 Nov 2007 06:48:07 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 72470 invoked from network); 26 Nov 2007 13:46:58 -0000
Received: from unknown (HELO Wylie) ([e-mail]@70.108.25.230 with login) by smtp103.biz.mail.re2.yahoo.com with SMTP; 26 Nov 2007 13:46:58 -0000
X-YMail-OSG: uF.xy0kVM1kK_DfLXNanqOam0ae6.W57puS2JcbtRZ9kxsiJZmDJa7MsQL8JY.fdS2DbrOFty8xKuO6kcRy2x9pahCt2H1Eco.aA1EV.bi91WmHfrZA-
From: "Turner, Sean P." <[e-mail]>
To: <[e-mail]>
Subject: Agenda Posted
Date: Mon, 26 Nov 2007 08:43:04 -0500
Organization: IECA, Inc.
Message-ID: <008301c83032$451aa010$0301a8c0@Wylie>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0084_01C83008.5C449810"
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
Thread-Index: AcgwMkS7HQYKq9+WS9q2zGHht1kQyw==
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_0084_01C83008.5C449810
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

I have posted a draft agenda at:

http://www3.ietf.org/proceedings/07dec/agenda/smime.txt

spt

------=_NextPart_000_0084_01C83008.5C449810
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7036.0">
<TITLE>Agenda Posted</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->

<P><FONT SIZE=3D2 FACE=3D"Arial">I have posted a draft agenda at:</FONT>
</P>

<P><A =
HREF=3D"http://www3.ietf.org/proceedings/07dec/agenda/smime.txt"><U><FONT=
 COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">http://www3.ietf.org/proceedings/07dec/agenda/smime.txt</F=
ONT></U></A>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">spt</FONT>
</P>

</BODY>
</HTML>
------=_NextPart_000_0084_01C83008.5C449810--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAQ9VkiL017937 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Nov 2007 02:31:46 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lAQ9Vk2Q017936; Mon, 26 Nov 2007 02:31:46 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail1relay.itmaster.local (host48-104-static.43-193-b.business.telecomitalia.it [193.43.104.48] (may be forged)) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAQ9Vh77017896; Mon, 26 Nov 2007 02:31:44 -0700 (MST) (envelope-from [e-mail])
Received: from POSTA02.itmaster.local ([193.43.104.10]) by mail1relay.itmaster.local with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Nov 2007 10:31:24 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: R: R: TimeStampedData draft updated - please comment
Date: Mon, 26 Nov 2007 10:31:23 +0100
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: R: TimeStampedData draft updated - please comment
Thread-Index: AcguJXpgV1zMMyMPS7OomtFFcupLmgB5qdCA
References: <[e-mail]><[e-mail]><[e-mail]> <[e-mail]>
From: "Santoni Adriano" <[e-mail]>
To: "Russ Housley" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 26 Nov 2007 09:31:24.0258 (UTC) FILETIME=[1C9A5C20:01C8300F]
X-TM-AS-Product-Ver: SMEX-7.0.0.1345-5.0.1023-15568.003
X-TM-AS-Result: No--22.151800-0.000000-2
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id lAQ9Vj77017924
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

So you are suggesting that in the TimeStampedData structure:

1) the 'content' field should be a MIME element (and therefore contain a MIME content-type header), 

2) the 'mimeType' field should be removed (as a consequence of the previous point).

Did I take your right?

I would not oppose to this arrangement, if it helped gathering more consensus.

My only objection is that it will require a mix of text- and BER-based processing in order to fully open and disassemble a TimeStampedData instance. This is a bit unelegant IMO (but I know it is just normal in the S/MIME field, which I was not specifically addressing btw).

Adriano



-----Messaggio originale-----
Da: [e-mail] [mailto:[e-mail]] Per conto di Russ Housley
Inviato: venerdì 23 novembre 2007 20.41
A: Santoni Adriano
Cc: [e-mail]; [e-mail]
Oggetto: Re: R: TimeStampedData draft updated - please comment


Santoni:

Sorry for not being clear.  My comment is directed toward you, but I included the ASN.1 fragment from Denis to highlight my point.

Please take a look at RFC 3852.  You will see that content types (object identifiers) are used to identify the format of any content.  Many have been registered over the years.  If you see TimeStampedData as an addition to the CMS, then this same technique needs to be employed.  In the CMS, as I said in my earlier message, the id-data object identifier is used when the content is MIME encoded.  The MIME type is not carried in the fields of the CMS.

Russ

At 02:46 AM 11/21/2007, Santoni Adriano wrote:

>Russ,
>
>I am not sure if you were addressing your comment to me or to Denis...
>
>At any rate, I would like to point out that the syntax I am proposing 
>implies no MIME encoding at all. The data (like e.g. a patent, an 
>offer, a contract, an income statement, a device driver, a security 
>patch, a sensitive database, etc) is bundled in its native form, "as 
>is". And thus, there is no MIME header to speak of.
>That's why I have provided for a 'mimeType' field: as a hint for the 
>recipient/verifying application to guess what kind of data is carried 
>within the TimeStampedData block, and what to do with it.
>
>Adriano
>
>
>-----Messaggio originale-----
>Da: [e-mail]
>[mailto:[e-mail]] Per conto di Russ Housley
>Inviato: martedì 20 novembre 2007 22.53
>A: [e-mail]; [e-mail]
>Oggetto: Re: TimeStampedData draft updated - please comment
>
>
>In S/MIME, the id-data content type is used when the content is MIME 
>encoded.  Then, then MIME header in the content is used to determine 
>the format of the content.  Why does this suggest a different approach?
>
>Russ
>
>At 08:16 AM 11/19/2007, Denis Pinkas wrote:
>
> >Adriano,
> >
> >Thank you for this new proposal. I skimmed through it.
> >
> >It is interesting, but I fear that it is targeted to the wrong WG.
> >Since this would be an extension of CMS, this work item would rather 
> >belong to the S-MIME WG.
> >For this reason, I copy the S-MIME WG.
> >
> >In addition, some polishing would be needed.
> >
> >Rather than long words, you will find hereafter a rewriting of the
> >ASN.1 with a few explanatory comments.
> >
> >    TimeStampedData ::= SEQUENCE {
> >       version        [0] Version DEFAULT v1,
> >       fileName           UTF8String,
> >       mimeType           PrintableString,
> >       fileLocation       UTF8String OPTIONAL,
> >       -- fileLocation is only a hint.
> >       -- The file may or may not be stored at that location.
> >       content            OCTET STRING,
> >       temporalEvidences  TemporalEvidences }
> >
> >    Version  ::=  INTEGER  { v1(0) }
> >    TemporalEvidences ::= SEQUENCE (SIZE(1..MAX)) OF TemporalEvidence
> >
> >-- This structure allows multiple levels of temporal evidences.
> >
> >    TemporalEvidence ::= SEQUENCE {
> >       evidences            Evidences,
> >       certificateLists     CertificateLists  OPTIONAL
> >}
> >
> >    CertificateLists :: = SEQUENCE (SIZE(1..MAX)) OF CertificateList
> >
> >    Evidence ::= CHOICE {
> >       timeStamps     [0] SEQUENCE (SIZE(1..MAX)) OF TimeStampToken }
> >
> >-- For each level there can be one or more time-stamps tokens.
> >
> >-- Before re-time stamping a set of former time-stamp tokens,
> >-- the CRLs of the previous level of time-stamps tokens can be 
> >captured
> >-- and inserted in the data structure.
> >
> >Denis
> >
> >
> > >Hello there,
> > >
> > >here I am again with my TimeStampedData proposal.
> > >
> > >I have submitted a new draft (also attached here) that takes into
> > account some of the remarks and suggestions received so far.
> > >
> > >I have made room for additional types of temporal evidence, like
> > e.g. RFC 4998, while keeping RFC 3161 as the basis of interoperability.
> > >
> > >I would like to invite everybody involved in time-stamping and
> > archiving e-documents to comment upon it: has it improved?
> > something is missing?
> > >
> > >In particular, please state:
> > >- are you interested in this work?
> > >- do you agree to adopt it as a new PKIX work item?
> > >- are you going to use this format, once it is finished?
> > >
> > >Is anybody willing to spend a few words on this draft during the
> > IETF meeting in Vancouver (as I cannot attend myself) ?
> > >
> > >And finally, is anybody willing to invest a little time in
> > co-authoring this draft with me?
> > >
> > >Adriano
> > >Actalis S.p.A.
> > >Milano, ITALY
> > >
> > >
> > >
> > >
> > >-----Messaggio originale-----
> > >Da: [e-mail]
> > [mailto:[e-mail]] Per conto di Santoni Adriano
> > >Inviato: lunedì 3 settembre 2007 10.42
> > >A: [e-mail]
> > >Oggetto: R: R: Draft on TimeStampedData
> > >
> > >
> > >Let me summarize the issues discussed so far:
> > >
> > >1) allow EvidenceRecord (RFC 4998) in addition to TimeStampToken 
> > >(RFC
> > >3161)
> > >
> > >In principle, I have no objections as long as we do not complicate
> > things too much and do not hamper interoperability.
> > >
> > >There are at least two possible approaches to accomodate RFC 4998:
> > >
> > >   a) explicitly provide for (one) ER in the TimeStampedData
> > syntax, as an alternative to the SET OF TimeStampToken;
> > >   b) do not mention any specific standard for the "evidence", but
> > just mention RFC 3161 and RFC 4998 as two possibilities;
> > >
> > >In any case, it must be possible for the verifying application to
> > easily detect which of the two (or more) kind of "evidence" has been 
> > used in the TimeStampedData envelope under examination. If we 
> > restrict the kinds of evidence to the two above, then a extra 
> > tagging may not be necessary, as an EvidenceRecord is a SEQUENCE, 
> > while the other choice would be a SET OF. Although unelegant, it 
> > would work. On the other hand, if we do not want to restrict the 
> > kinds of evidence to the two above, then of course we should somehow 
> > add an extra tagging level, because nobody knows at this time what 
> > syntax a third kind of evidence would conform to.
> > >
> > >In any case, for the sake of interoperability, strong emphasis
> > should be given to RFC 3161 as today this is the most widely 
> > implemented type of evidence.
> > >
> > >In conclusion: I agree with allowing RFC 4998 if we do that in a
> > way that does not modify the strong emphasis on RFC 3161 and does 
> > not hamper interoperability (which must be based on supporting RFC 
> > 3161, even though certain applications may also support RFC 4998).
> > >
> > >2) filename vs. URI
> > >
> > >Some remarked that an URI (or URI Reference) would be more
> > versatile than a simple filename. That is obviously true, but it 
> > implies that the 'content' field of TimeStampedData may be empty.
> > This is not what I was addressing in my original proposal. It would 
> > not just require the 'content' field to be declared OPTIONAL: it 
> > would make interoperability very difficult to achieve unless we 
> > restrict the URI schemes to a very small subset (e.g. http:, cid:, 
> > file:, ldap:) of the myriad possibilities. In any case, it would 
> > require ages of interoperability testing. And it would make life 
> > much harder for software implementors, without much of a benefit in 
> > view. I strongly believe in keeping things simple as much as possible.
> > >
> > >3) multiple contents and RFC 4073
> > >
> > >The 'content' field in the TimeStampedData envelope is not
> > structured, in my original proposal. It is just an OCTET STRING.
> > That allows for any kind of content to be conveyed, even a 
> > ContentCollection according to RFC 4073.
> > >
> > >Another remark has been made with reference to RFC 4073: the
> > ContentWithAttributes structure, also defined in RFC 4073, could in 
> > principle be used to bundle some content with the corrisponding 
> > evidence (the goal of my draft). Although this is true, it would 
> > require definining some additional OIDs, and mandating the presence 
> > of certain Attributes tagged by those OIDs. I frankly believe the 
> > TimeStampedData structure that I am proposing is better, first 
> > because it is dedicated and second because it "implements the 
> > ContentInfo interface", so to speak. It is simpler to manage for 
> > applications already able to parse different kinds of ContentInfo 
> > envelopes (there are a great many), possibly in a recursive way.
> > >
> > >Adriano
> > >
> > >
> > >-----Messaggio originale-----
> > >Da: Young H Etheridge [mailto:[e-mail]]
> > >Inviato: venerdì 31 agosto 2007 17.48
> > >A: Santoni Adriano
> > >Cc: [e-mail]
> > >Oggetto: Re: R: Draft on TimeStampedData
> > >
> > >Adriano,
> > >
> > >To add to your thought processes:  I believe that a URI of
> > "file:///private.stuff" addresses your concern for privacy of the 
> > physical URI.  But, allowing URI in the syntax will make less 
> > private repositories, not necessarily file systems, more universally 
> > accessible.  The intent of the URI in RFC 3986 is to also allow for 
> > abstractly identifying a resource, not necessarily providing a 
> > physical resource.  In this manner the URI could then be used as an 
> > object identity in database(s).
> > >
> > >Take care,
> > >
> > >yhe
> > >
> > >Santoni Adriano wrote:
> > >> To accomodate for RFC 4998, I would propose the following syntax:
> > >>
> > >> TimeStampedData ::= SEQUENCE {
> > >>      version                 INTEGER { v1(1) },
> > >>      fileName                UTF8String,
> > >>      mimeType                PrintableString,
> > >>      content         OCTET STRING,
> > >>      evidence                Evidence
> > >> }
> > >>
> > >> Evidence ::= CHOICE {
> > >>      timeStamps              [0] SET (SIZE(1..MAX)) OF TimeStampToken,
> > >>      evidenceRecord  [1] EvidenceRecord -- according to RFC 4998 
> > >> }
> > >>
> > >> (I am not sure whether it would be better to use explicit or 
> > >> implicit
> > >> tags...)
> > >>
> > >> Regarding the idea of having an URI instead of a filename: I'd
> > prefer to think over things a little bit more, and maybe collect
> more feedback.
> > >>
> > >> In my mind, I can send a TimeStampedData envelope to business
> > partners and/or public agencies via email. If the timestamped 
> > document is a local one, which I think is a meaningful and realistic 
> > scenario, then I do not want my company's hostnames and pathnames to 
> > be included in the envelope so that the recipient can see them.
> > >>
> > >> Adriano
> > >>
> > >>
> > >>
> > >> -----Messaggio originale-----
> > >> Da: [e-mail]
> > >> [mailto:[e-mail]]
> > >> Per conto di Julien Stern
> > >> Inviato: venerdì 31 agosto 2007 13.43
> > >> A: [e-mail]
> > >> Oggetto: Re: Draft on TimeStampedData
> > >>
> > >>
> > >> On Fri, Aug 31, 2007 at 12:06:00PM +0200, Tilo Kienitz wrote:
> > >>
> > >>> Adriano,
> > >>>
> > >>>
> > >>>> After pondering on this and other remarks, I cannot help but 
> > >>>> agree with Steve.
> > >>>>
> > >>>> My original and essential goal is that of facilitating 
> > >>>> interoperability in a currently unregulated field. If we allow 
> > >>>> for several "degrees of freedom", than interoperability will be
> > hampered from the beginning.
> > >>>> So I'd better stick to RFC 3161 for now. We could include 
> > >>>> support for RFC 4998 Evidence Records later on, at the time 
> > >>>> when they become a widespread reality comparable to RFC 3161 
> > >>>> TimeStampTokens (which are widely implemented).
> > >>>>
> > >>> I would prefer to have both options: RFC 3161 and RFC 4998. For 
> > >>> our customers evidence records are a widespread reality already.
> > >>> A standardized way to put some data and their evidence record 
> > >>> into a single file would be useful.
> > >>>
> > >>
> > >> I strongly concur with this comment. Allowing the usage of ERS
> > as well as simple timestamps would allow the TimestampedData to 
> > leverage all the work of RFC 4998 regarding timestamps instead of 
> > reinventing the wheel in the future.
> > >>
> > >> Regards,
> > >>
> > >> --
> > >> Julien
> > >>
> > >>
> > >>> Kind regards
> > >>> Tilo
> > >>>
> > >>>
> > >>>
> > >>>> -----Messaggio originale-----
> > >>>> Da: Stephen Kent [mailto:[e-mail]]
> > >>>> Inviato: giovedì 30 agosto 2007 23.05
> > >>>> A: Young H Etheridge
> > >>>> Cc: Santoni Adriano; [e-mail]
> > >>>> Oggetto: Re: R: Draft on TimeStampedData
> > >>>>
> > >>>> At 4:33 PM -0400 8/30/07, Young H Etheridge wrote:
> > >>>>
> > >>>>>> ...
> > >>>>>>
> > >>>>> Agreed, w.r.t. normative vs informative.  The above quote from
> > >>>>> RFC-4998 merely underscores that this draft should also 
> > >>>>> suggest, informatively, that the choice of Timestamp should be 
> > >>>>> one that meets the normative syntax for Timestamp and not 
> > >>>>> specify that which is in RFC-3161.  Nothing gets broken by 
> > >>>>> being less restrictive and generally more informative to the community-at-large.
> > >>>>>
> > >>>> I have to disagree with your conclusion. If we require 3161
> > time stamps in an RFC of the sort Adriano proposed, then everyone 
> > can parse them if they comply with the RFC. If the RFC says "insert 
> > the time stamp from any standard you want here, and just tell us 
> > which one you used" then we have a problem. A compliant 
> > implementation can generate data structures containing time stamps 
> > that other compliant implementations cannot parse. That's the sort 
> > of interoperability problem we try to avoid in the IETF.
> > >>>>
> > >>>>
> > >>>>> My notion of resilience does not mean "more encompassing" but 
> > >>>>> that of providing the user community with choice and an 
> > >>>>> enhanced safeguard against the possibility of the weakening of an algorithm.
> > >>>>>
> > >>>> Choices can be good, but they can create interoperability
> > problems in some cases, like this one. Also, we have algorithm 
> > agility as a requirement in all of our work, so the second concern 
> > you cite does not seem to apply here.
> > >>>>
> > >>>> Steve
> > >>>>
> > >>> --
> > >>> Tilo Kienitz
> > >>> SecCommerce Informationssysteme GmbH Obenhauptstr. 5 D - 22335 
> > >>> Hamburg
> > >>> Germany                                   http://www.seccommerce.de




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAO9kmdT007108 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 24 Nov 2007 02:46:48 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lAO9kmmY007107; Sat, 24 Nov 2007 02:46:48 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from pne-smtpout1-sn2.hy.skanova.net (pne-smtpout1-sn2.hy.skanova.net [81.228.8.83]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAO9kl09007097 for <[e-mail]>; Sat, 24 Nov 2007 02:46:47 -0700 (MST) (envelope-from [e-mail])
Received: from arport2v (81.232.45.243) by pne-smtpout1-sn2.hy.skanova.net (7.3.129) (authenticated as u18116613) id 471A56C0009DF22F; Sat, 24 Nov 2007 10:46:19 +0100
Message-ID: <00a701c82e7e$ecacbe40$82c5a8c0@arport2v>
From: "Anders Rundgren" <[e-mail]>
To: "Peter Gutmann" <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: S/MIME key distribution proposal
Date: Sat, 24 Nov 2007 10:46:44 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1914
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1914
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>Conversely, if you want [e-mail]'s public key, the best way
>to get it is to go straight to the horse's mouth and ask [e-mail],
>or in this case a proxy, his MUA.

If MUA means mail-client this introduces a noticeable latency as well as
only working when the MUA is on-line.   This alone makes this proposal
a rather handicapped scheme IMO.

It seems that interrogating a Web Service associated with the target
domain (like __mail_encryption.example.com) would be fairly simple to
get going and facilitates immediate responses.  If the acquired certificate
is issued by a known party and conforms with the mail-address, it seems
that you can automate this.  Using a TLS connection to the service you
might even accept any e-mail certificate issuer by "reusing" the trust in the
server certificate.  For encryption purposes this should be satisfactory.

Using the most current key is also a factor that were missing in Ian's
proposal.

A security implication with using DNS + a WebService is that a bad
provider could replace your encryption key with something that would
allow it to read incoming messages in clear.  OTOH, that is what they
already do today 99.9% of the time.  In fact, this scheme allows an
enterprise to add content control by performing the decryption on the
server.  For outgoing messages I believe Outlook already supports
some kind of message "escrow" mechanism...

Anders



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lANN2Y2q066566 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 23 Nov 2007 16:02:34 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lANN2YSN066564; Fri, 23 Nov 2007 16:02:34 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [8.8.40.152]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id lANN2W5s066547 for <[e-mail]>; Fri, 23 Nov 2007 16:02:33 -0700 (MST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
Received: (qmail 21406 invoked by uid 0); 23 Nov 2007 23:02:24 -0000
Received: from unknown (HELO THINKPADR52.vigilsec.com) (24.131.121.208) by woodstock.binhost.com with SMTP; 23 Nov 2007 23:02:24 -0000
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Fri, 23 Nov 2007 14:41:28 -0500
To: "Santoni Adriano" <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: R: TimeStampedData draft updated - please comment
Cc: <[e-mail]>, <[e-mail]>
In-Reply-To: <[e-mail] cal>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Santoni:

Sorry for not being clear.  My comment is directed toward you, but I 
included the ASN.1 fragment from Denis to highlight my point.

Please take a look at RFC 3852.  You will see that content types 
(object identifiers) are used to identify the format of any 
content.  Many have been registered over the years.  If you see 
TimeStampedData as an addition to the CMS, then this same technique 
needs to be employed.  In the CMS, as I said in my earlier message, 
the id-data object identifier is used when the content is MIME 
encoded.  The MIME type is not carried in the fields of the CMS.

Russ

At 02:46 AM 11/21/2007, Santoni Adriano wrote:

>Russ,
>
>I am not sure if you were addressing your comment to me or to Denis...
>
>At any rate, I would like to point out that the syntax I am 
>proposing implies no MIME encoding at all. The data (like e.g. a 
>patent, an offer, a contract, an income statement, a device driver, 
>a security patch, a sensitive database, etc) is bundled in its 
>native form, "as is". And thus, there is no MIME header to speak of. 
>That's why I have provided for a 'mimeType' field: as a hint for the 
>recipient/verifying application to guess what kind of data is 
>carried within the TimeStampedData block, and what to do with it.
>
>Adriano
>
>
>-----Messaggio originale-----
>Da: [e-mail] 
>[mailto:[e-mail]] Per conto di Russ Housley
>Inviato: martedì 20 novembre 2007 22.53
>A: [e-mail]; [e-mail]
>Oggetto: Re: TimeStampedData draft updated - please comment
>
>
>In S/MIME, the id-data content type is used when the content is MIME 
>encoded.  Then, then MIME header in the content is used to determine 
>the format of the content.  Why does this suggest a different approach?
>
>Russ
>
>At 08:16 AM 11/19/2007, Denis Pinkas wrote:
>
> >Adriano,
> >
> >Thank you for this new proposal. I skimmed through it.
> >
> >It is interesting, but I fear that it is targeted to the wrong WG.
> >Since this would be an extension of CMS, this work item would rather
> >belong to the S-MIME WG.
> >For this reason, I copy the S-MIME WG.
> >
> >In addition, some polishing would be needed.
> >
> >Rather than long words, you will find hereafter a rewriting of the
> >ASN.1 with a few explanatory comments.
> >
> >    TimeStampedData ::= SEQUENCE {
> >       version        [0] Version DEFAULT v1,
> >       fileName           UTF8String,
> >       mimeType           PrintableString,
> >       fileLocation       UTF8String OPTIONAL,
> >       -- fileLocation is only a hint.
> >       -- The file may or may not be stored at that location.
> >       content            OCTET STRING,
> >       temporalEvidences  TemporalEvidences }
> >
> >    Version  ::=  INTEGER  { v1(0) }
> >    TemporalEvidences ::= SEQUENCE (SIZE(1..MAX)) OF TemporalEvidence
> >
> >-- This structure allows multiple levels of temporal evidences.
> >
> >    TemporalEvidence ::= SEQUENCE {
> >       evidences            Evidences,
> >       certificateLists     CertificateLists  OPTIONAL
> >}
> >
> >    CertificateLists :: = SEQUENCE (SIZE(1..MAX)) OF CertificateList
> >
> >    Evidence ::= CHOICE {
> >       timeStamps     [0] SEQUENCE (SIZE(1..MAX)) OF TimeStampToken }
> >
> >-- For each level there can be one or more time-stamps tokens.
> >
> >-- Before re-time stamping a set of former time-stamp tokens,
> >-- the CRLs of the previous level of time-stamps tokens can be captured
> >-- and inserted in the data structure.
> >
> >Denis
> >
> >
> > >Hello there,
> > >
> > >here I am again with my TimeStampedData proposal.
> > >
> > >I have submitted a new draft (also attached here) that takes into
> > account some of the remarks and suggestions received so far.
> > >
> > >I have made room for additional types of temporal evidence, like
> > e.g. RFC 4998, while keeping RFC 3161 as the basis of interoperability.
> > >
> > >I would like to invite everybody involved in time-stamping and
> > archiving e-documents to comment upon it: has it improved?
> > something is missing?
> > >
> > >In particular, please state:
> > >- are you interested in this work?
> > >- do you agree to adopt it as a new PKIX work item?
> > >- are you going to use this format, once it is finished?
> > >
> > >Is anybody willing to spend a few words on this draft during the
> > IETF meeting in Vancouver (as I cannot attend myself) ?
> > >
> > >And finally, is anybody willing to invest a little time in
> > co-authoring this draft with me?
> > >
> > >Adriano
> > >Actalis S.p.A.
> > >Milano, ITALY
> > >
> > >
> > >
> > >
> > >-----Messaggio originale-----
> > >Da: [e-mail]
> > [mailto:[e-mail]] Per conto di Santoni Adriano
> > >Inviato: lunedì 3 settembre 2007 10.42
> > >A: [e-mail]
> > >Oggetto: R: R: Draft on TimeStampedData
> > >
> > >
> > >Let me summarize the issues discussed so far:
> > >
> > >1) allow EvidenceRecord (RFC 4998) in addition to TimeStampToken (RFC
> > >3161)
> > >
> > >In principle, I have no objections as long as we do not complicate
> > things too much and do not hamper interoperability.
> > >
> > >There are at least two possible approaches to accomodate RFC 4998:
> > >
> > >   a) explicitly provide for (one) ER in the TimeStampedData
> > syntax, as an alternative to the SET OF TimeStampToken;
> > >   b) do not mention any specific standard for the "evidence", but
> > just mention RFC 3161 and RFC 4998 as two possibilities;
> > >
> > >In any case, it must be possible for the verifying application to
> > easily detect which of the two (or more) kind of "evidence" has been
> > used in the TimeStampedData envelope under examination. If we restrict
> > the kinds of evidence to the two above, then a extra tagging may not
> > be necessary, as an EvidenceRecord is a SEQUENCE, while the other
> > choice would be a SET OF. Although unelegant, it would work. On the
> > other hand, if we do not want to restrict the kinds of evidence to the
> > two above, then of course we should somehow add an extra tagging
> > level, because nobody knows at this time what syntax a third kind of
> > evidence would conform to.
> > >
> > >In any case, for the sake of interoperability, strong emphasis
> > should be given to RFC 3161 as today this is the most widely
> > implemented type of evidence.
> > >
> > >In conclusion: I agree with allowing RFC 4998 if we do that in a
> > way that does not modify the strong emphasis on RFC 3161 and does not
> > hamper interoperability (which must be based on supporting RFC 3161,
> > even though certain applications may also support RFC 4998).
> > >
> > >2) filename vs. URI
> > >
> > >Some remarked that an URI (or URI Reference) would be more
> > versatile than a simple filename. That is obviously true, but it
> > implies that the 'content' field of TimeStampedData may be empty.
> > This is not what I was addressing in my original proposal. It would
> > not just require the 'content' field to be declared OPTIONAL: it would
> > make interoperability very difficult to achieve unless we restrict the
> > URI schemes to a very small subset (e.g. http:, cid:, file:, ldap:) of
> > the myriad possibilities. In any case, it would require ages of
> > interoperability testing. And it would make life much harder for
> > software implementors, without much of a benefit in view. I strongly
> > believe in keeping things simple as much as possible.
> > >
> > >3) multiple contents and RFC 4073
> > >
> > >The 'content' field in the TimeStampedData envelope is not
> > structured, in my original proposal. It is just an OCTET STRING.
> > That allows for any kind of content to be conveyed, even a
> > ContentCollection according to RFC 4073.
> > >
> > >Another remark has been made with reference to RFC 4073: the
> > ContentWithAttributes structure, also defined in RFC 4073, could in
> > principle be used to bundle some content with the corrisponding
> > evidence (the goal of my draft). Although this is true, it would
> > require definining some additional OIDs, and mandating the presence of
> > certain Attributes tagged by those OIDs. I frankly believe the
> > TimeStampedData structure that I am proposing is better, first because
> > it is dedicated and second because it "implements the ContentInfo
> > interface", so to speak. It is simpler to manage for applications
> > already able to parse different kinds of ContentInfo envelopes (there
> > are a great many), possibly in a recursive way.
> > >
> > >Adriano
> > >
> > >
> > >-----Messaggio originale-----
> > >Da: Young H Etheridge [mailto:[e-mail]]
> > >Inviato: venerdì 31 agosto 2007 17.48
> > >A: Santoni Adriano
> > >Cc: [e-mail]
> > >Oggetto: Re: R: Draft on TimeStampedData
> > >
> > >Adriano,
> > >
> > >To add to your thought processes:  I believe that a URI of
> > "file:///private.stuff" addresses your concern for privacy of the
> > physical URI.  But, allowing URI in the syntax will make less private
> > repositories, not necessarily file systems, more universally
> > accessible.  The intent of the URI in RFC 3986 is to also allow for
> > abstractly identifying a resource, not necessarily providing a
> > physical resource.  In this manner the URI could then be used as an
> > object identity in database(s).
> > >
> > >Take care,
> > >
> > >yhe
> > >
> > >Santoni Adriano wrote:
> > >> To accomodate for RFC 4998, I would propose the following syntax:
> > >>
> > >> TimeStampedData ::= SEQUENCE {
> > >>      version                 INTEGER { v1(1) },
> > >>      fileName                UTF8String,
> > >>      mimeType                PrintableString,
> > >>      content         OCTET STRING,
> > >>      evidence                Evidence
> > >> }
> > >>
> > >> Evidence ::= CHOICE {
> > >>      timeStamps              [0] SET (SIZE(1..MAX)) OF TimeStampToken,
> > >>      evidenceRecord  [1] EvidenceRecord -- according to RFC 4998 }
> > >>
> > >> (I am not sure whether it would be better to use explicit or
> > >> implicit
> > >> tags...)
> > >>
> > >> Regarding the idea of having an URI instead of a filename: I'd
> > prefer to think over things a little bit more, and maybe collect 
> more feedback.
> > >>
> > >> In my mind, I can send a TimeStampedData envelope to business
> > partners and/or public agencies via email. If the timestamped document
> > is a local one, which I think is a meaningful and realistic scenario,
> > then I do not want my company's hostnames and pathnames to be included
> > in the envelope so that the recipient can see them.
> > >>
> > >> Adriano
> > >>
> > >>
> > >>
> > >> -----Messaggio originale-----
> > >> Da: [e-mail]
> > >> [mailto:[e-mail]]
> > >> Per conto di Julien Stern
> > >> Inviato: venerdì 31 agosto 2007 13.43
> > >> A: [e-mail]
> > >> Oggetto: Re: Draft on TimeStampedData
> > >>
> > >>
> > >> On Fri, Aug 31, 2007 at 12:06:00PM +0200, Tilo Kienitz wrote:
> > >>
> > >>> Adriano,
> > >>>
> > >>>
> > >>>> After pondering on this and other remarks, I cannot help but
> > >>>> agree with Steve.
> > >>>>
> > >>>> My original and essential goal is that of facilitating
> > >>>> interoperability in a currently unregulated field. If we allow
> > >>>> for several "degrees of freedom", than interoperability will be
> > hampered from the beginning.
> > >>>> So I'd better stick to RFC 3161 for now. We could include support
> > >>>> for RFC 4998 Evidence Records later on, at the time when they
> > >>>> become a widespread reality comparable to RFC 3161
> > >>>> TimeStampTokens (which are widely implemented).
> > >>>>
> > >>> I would prefer to have both options: RFC 3161 and RFC 4998. For
> > >>> our customers evidence records are a widespread reality already.
> > >>> A standardized way to put some data and their evidence record into
> > >>> a single file would be useful.
> > >>>
> > >>
> > >> I strongly concur with this comment. Allowing the usage of ERS
> > as well as simple timestamps would allow the TimestampedData to
> > leverage all the work of RFC 4998 regarding timestamps instead of
> > reinventing the wheel in the future.
> > >>
> > >> Regards,
> > >>
> > >> --
> > >> Julien
> > >>
> > >>
> > >>> Kind regards
> > >>> Tilo
> > >>>
> > >>>
> > >>>
> > >>>> -----Messaggio originale-----
> > >>>> Da: Stephen Kent [mailto:[e-mail]]
> > >>>> Inviato: giovedì 30 agosto 2007 23.05
> > >>>> A: Young H Etheridge
> > >>>> Cc: Santoni Adriano; [e-mail]
> > >>>> Oggetto: Re: R: Draft on TimeStampedData
> > >>>>
> > >>>> At 4:33 PM -0400 8/30/07, Young H Etheridge wrote:
> > >>>>
> > >>>>>> ...
> > >>>>>>
> > >>>>> Agreed, w.r.t. normative vs informative.  The above quote from
> > >>>>> RFC-4998 merely underscores that this draft should also suggest,
> > >>>>> informatively, that the choice of Timestamp should be one that
> > >>>>> meets the normative syntax for Timestamp and not specify that
> > >>>>> which is in RFC-3161.  Nothing gets broken by being less
> > >>>>> restrictive and generally more informative to the community-at-large.
> > >>>>>
> > >>>> I have to disagree with your conclusion. If we require 3161
> > time stamps in an RFC of the sort Adriano proposed, then everyone can
> > parse them if they comply with the RFC. If the RFC says "insert the
> > time stamp from any standard you want here, and just tell us which one
> > you used" then we have a problem. A compliant implementation can
> > generate data structures containing time stamps that other compliant
> > implementations cannot parse. That's the sort of interoperability
> > problem we try to avoid in the IETF.
> > >>>>
> > >>>>
> > >>>>> My notion of resilience does not mean "more encompassing" but
> > >>>>> that of providing the user community with choice and an enhanced
> > >>>>> safeguard against the possibility of the weakening of an algorithm.
> > >>>>>
> > >>>> Choices can be good, but they can create interoperability
> > problems in some cases, like this one. Also, we have algorithm agility
> > as a requirement in all of our work, so the second concern you cite
> > does not seem to apply here.
> > >>>>
> > >>>> Steve
> > >>>>
> > >>> --
> > >>> Tilo Kienitz
> > >>> SecCommerce Informationssysteme GmbH Obenhauptstr. 5 D - 22335
> > >>> Hamburg
> > >>> Germany                                   http://www.seccommerce.de



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAN8rWW1093188 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 23 Nov 2007 01:53:32 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lAN8rWTm093187; Fri, 23 Nov 2007 01:53:32 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mailhost.auckland.ac.nz (moe.its.auckland.ac.nz [130.216.12.35]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAN8rQPF093175 for <[e-mail]>; Fri, 23 Nov 2007 01:53:31 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 4DB2A48064C for <[e-mail]>; Fri, 23 Nov 2007 21:53:26 +1300 (NZDT)
X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz
Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (moe.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9XEhvTnwzEvp for <[e-mail]>; Fri, 23 Nov 2007 21:53:26 +1300 (NZDT)
Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 2A542480636 for <[e-mail]>; Fri, 23 Nov 2007 21:53:25 +1300 (NZDT)
Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id ED475E080B5 for <[e-mail]>; Fri, 23 Nov 2007 21:53:17 +1300 (NZDT)
Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from <[e-mail]>) id 1IvUHl-0004Gz-Rt for [e-mail]; Fri, 23 Nov 2007 21:53:17 +1300
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: Re: S/MIME key distribution proposal
Message-Id: <[e-mail]>
Date: Fri, 23 Nov 2007 21:53:17 +1300
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

[Replying to several messages at once]

"Tony Capel" <[e-mail]> writes:

>and also recommended to include current CRL (especially for parties who have
>not gotten around to making them available publicly!)

That's *way* outside the scope of the proposal.  The point is that if the user
has an email key then chances are the MUA will already have it available,
since it needs to use it to process incoming mail.  In that case it's a
relatively trivial step to send it out in response to a "gimme your key"
request.  Things like CRLs are an entirely different matter, you go to a CA
for those (or wherever you choose to get them from).

Conversely, if you want [e-mail]'s public key, the best way to get it
is to go straight to the horse's moutn and ask [e-mail], or in this
case a proxy, his MUA.

Peter Sylvester <[e-mail]> writes:

>One has to think a bit what to do if a user has multiple keys, well, open the
>same dialogue as with SSL client keys for example. Should requester be able
>to send a list of trusteworthy CA DNs?

I'd prefer to avoid building an entire email-key-request protocol for this.
It's more an official record of a convenient convention, "If you get email
with a key request in the subject, respond with the public keys that you hold
for the user" (so it'd be a purely informational RFC, not a standards-track
one).  It's up to the recipient what they do with them, whether they trust
them, whether they do a CRL lookup, ...

At most I'd go for:

  GETKEYS protocols addresses

  protocols := SMIME, OpenPGP, ...
  addresses := <optional email addresses to get keys for>

  mesage-body = <human-readable message to say something like "Your mailer
  doesn't understand this message, please reply with your public key if you
  can">

I'm not sure about the ability to include an optional email address, on the
one hand it makes things more flexible, but then you're starting to bloat it
up into a general-purpose key-server protocol, which it absolutely isn't meant
to be.  It's just a request to the MUA for the public key(s) that it holds for
the user/owner of the email address, in a manner that doesn't require manual
user processing if the MUA understands the request.

(To put it another way, let's see if the basic GETKEYS gets adopted.  We can
always bloat it up in version 2 if there's a demand for it).

"Anders Rundgren" <[e-mail]> writes:

>If this is good or not depends on what you want to achieve.
>
>If the goal is establishing confidential communication between a limited
>number of parties it seems that on-line based schemes (IM, Skype) tailored
>after TLS could also be a viable alternative.

That's too complicated, I'll leave it to someone else.  The point of this is
to automate the current manual process of "Hey, could you send me your key so
we can talk", replacing the need for tedious manual processing with an
automated method.  If the MUA knows the user's key, they can send it out.  If
not they can notify the user as per the current situation (or whatever the MUA
author decides to do in response to the message).

Peter.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAMLl5Cn055120 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 22 Nov 2007 14:47:05 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lAMLl51p055119; Thu, 22 Nov 2007 14:47:05 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from pne-smtpout1-sn2.hy.skanova.net (pne-smtpout1-sn2.hy.skanova.net [81.228.8.83]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAMLl4TX055113 for <[e-mail]>; Thu, 22 Nov 2007 14:47:04 -0700 (MST) (envelope-from [e-mail])
Received: from arport2v (81.232.45.243) by pne-smtpout1-sn2.hy.skanova.net (7.3.129) (authenticated as u18116613) id 471A56C0009813C6; Thu, 22 Nov 2007 22:46:27 +0100
Message-ID: <002401c82d51$300b58b0$82c5a8c0@arport2v>
From: "Anders Rundgren" <[e-mail]>
To: "Peter Gutmann" <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: S/MIME key distribution proposal
Date: Thu, 22 Nov 2007 22:46:18 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1914
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1914
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

If this is good or not depends on what you want to achieve.

If the goal is establishing confidential communication between a limited number of parties it seems that on-line based schemes (IM,
Skype) tailored after TLS could also be a viable alternative.   Message encryption is a PITA and doesn't really work for the
mass-market due to the absence of a working key recovery scheme.

For ordinary enterprise-messaging server-to-server encryption is the only realistic alternative in order to comply with various
information leakage and content control policies that are currently being put in place.  Massive use of end-to-end encryption is
simply not feasible no matter how useful it may appear to be.

Another fly in Ian's soup is that the US government (which is the entity who have thrown the most money on this since long dead
horse called S/MIME) so far haven't actually published their keys.  BTW, in this context it is worth mentioning that for citizens,
you rather often deal with a department rather than an officer since you typically do not know the government people that well.
The only working and [almost] established way of securely communicating with a department is through the web.

It seems that S/MIME encryption works fine for communities having strong IT support.  On the Internet it doesn't work equally well
and has also been displaced by the web.  On the Internet we primarily need to improve authentication and reducing spam.

AR

----- Original Message ----- 
From: "Peter Gutmann" <[e-mail]>
To: <[e-mail]>
Sent: Thursday, November 22, 2007 15:50
Subject: S/MIME key distribution proposal



https://financialcryptography.com/mt/archives/000966.html

  If an email can be used to send the key (signed), then why can't an email be
  used to request a key? Imagine that we added an email convention, a little
  like those old maillist conventions, that did this:

    Subject: GETSMIME [e-mail]

  and send it off. A mailclient like Thunderbird could simply reply by
  forwarding the key. (How this is done is an exercise for the reader. If you
  can't think of 3 ways in the next 3 minutes, you need more exercise.)

Seems like a very simple, straightforward way to automate getting someone's
key for S/MIME email purposes.  Is it worth doing this as an RFC to get it
standardised in mailers?

Peter.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAMEokRG020373 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 22 Nov 2007 07:50:46 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lAMEokFB020372; Thu, 22 Nov 2007 07:50:46 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mailhost.auckland.ac.nz (moe.its.auckland.ac.nz [130.216.12.35]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAMEoePP020361 for <[e-mail]>; Thu, 22 Nov 2007 07:50:45 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 37EB348057C for <[e-mail]>; Fri, 23 Nov 2007 03:50:40 +1300 (NZDT)
X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz
Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (moe.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id spDNPs2emv2H for <[e-mail]>; Fri, 23 Nov 2007 03:50:40 +1300 (NZDT)
Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 2004448057B for <[e-mail]>; Fri, 23 Nov 2007 03:50:39 +1300 (NZDT)
Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 2DE1819EC0B6 for <[e-mail]>; Fri, 23 Nov 2007 03:50:34 +1300 (NZDT)
Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from <[e-mail]>) id 1IvDNy-0003Bc-2J for [e-mail]; Fri, 23 Nov 2007 03:50:34 +1300
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: S/MIME key distribution proposal
Message-Id: <[e-mail]>
Date: Fri, 23 Nov 2007 03:50:34 +1300
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

https://financialcryptography.com/mt/archives/000966.html

  If an email can be used to send the key (signed), then why can't an email be
  used to request a key? Imagine that we added an email convention, a little
  like those old maillist conventions, that did this:

    Subject: GETSMIME [e-mail]

  and send it off. A mailclient like Thunderbird could simply reply by
  forwarding the key. (How this is done is an exercise for the reader. If you
  can't think of 3 ways in the next 3 minutes, you need more exercise.)

Seems like a very simple, straightforward way to automate getting someone's
key for S/MIME email purposes.  Is it worth doing this as an RFC to get it
standardised in mailers?

Peter.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAL7kRAx075764 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Nov 2007 00:46:27 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lAL7kR5k075762; Wed, 21 Nov 2007 00:46:27 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail1relay.itmaster.local (host48-104-static.43-193-b.business.telecomitalia.it [193.43.104.48] (may be forged)) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAL7kP7C075743; Wed, 21 Nov 2007 00:46:26 -0700 (MST) (envelope-from [e-mail])
Received: from POSTA02.itmaster.local ([193.43.104.10]) by mail1relay.itmaster.local with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Nov 2007 08:46:20 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: R: TimeStampedData draft updated - please comment
Date: Wed, 21 Nov 2007 08:46:18 +0100
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: TimeStampedData draft updated - please comment
Thread-Index: AcgrwE3L7IFHNypBQBGtWwvyBOinsgAUTX1g
References: <[e-mail]> <[e-mail]>
From: "Santoni Adriano" <[e-mail]>
To: "Russ Housley" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 21 Nov 2007 07:46:20.0204 (UTC) FILETIME=[9B074EC0:01C82C12]
X-TM-AS-Product-Ver: SMEX-7.0.0.1345-5.0.1023-15558.002
X-TM-AS-Result: No--20.848300-0.000000-2
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id lAL7kR7C075751
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Russ,

I am not sure if you were addressing your comment to me or to Denis...

At any rate, I would like to point out that the syntax I am proposing implies no MIME encoding at all. The data (like e.g. a patent, an offer, a contract, an income statement, a device driver, a security patch, a sensitive database, etc) is bundled in its native form, "as is". And thus, there is no MIME header to speak of. That's why I have provided for a 'mimeType' field: as a hint for the recipient/verifying application to guess what kind of data is carried within the TimeStampedData block, and what to do with it.

Adriano


-----Messaggio originale-----
Da: [e-mail] [mailto:[e-mail]] Per conto di Russ Housley
Inviato: martedì 20 novembre 2007 22.53
A: [e-mail]; [e-mail]
Oggetto: Re: TimeStampedData draft updated - please comment


In S/MIME, the id-data content type is used when the content is MIME encoded.  Then, then MIME header in the content is used to determine the format of the content.  Why does this suggest a different approach?

Russ

At 08:16 AM 11/19/2007, Denis Pinkas wrote:

>Adriano,
>
>Thank you for this new proposal. I skimmed through it.
>
>It is interesting, but I fear that it is targeted to the wrong WG.
>Since this would be an extension of CMS, this work item would rather 
>belong to the S-MIME WG.
>For this reason, I copy the S-MIME WG.
>
>In addition, some polishing would be needed.
>
>Rather than long words, you will find hereafter a rewriting of the 
>ASN.1 with a few explanatory comments.
>
>    TimeStampedData ::= SEQUENCE {
>       version        [0] Version DEFAULT v1,
>       fileName           UTF8String,
>       mimeType           PrintableString,
>       fileLocation       UTF8String OPTIONAL,
>       -- fileLocation is only a hint.
>       -- The file may or may not be stored at that location.
>       content            OCTET STRING,
>       temporalEvidences  TemporalEvidences }
>
>    Version  ::=  INTEGER  { v1(0) }
>    TemporalEvidences ::= SEQUENCE (SIZE(1..MAX)) OF TemporalEvidence
>
>-- This structure allows multiple levels of temporal evidences.
>
>    TemporalEvidence ::= SEQUENCE {
>       evidences            Evidences,
>       certificateLists     CertificateLists  OPTIONAL
>}
>
>    CertificateLists :: = SEQUENCE (SIZE(1..MAX)) OF CertificateList
>
>    Evidence ::= CHOICE {
>       timeStamps     [0] SEQUENCE (SIZE(1..MAX)) OF TimeStampToken }
>
>-- For each level there can be one or more time-stamps tokens.
>
>-- Before re-time stamping a set of former time-stamp tokens,
>-- the CRLs of the previous level of time-stamps tokens can be captured
>-- and inserted in the data structure.
>
>Denis
>
>
> >Hello there,
> >
> >here I am again with my TimeStampedData proposal.
> >
> >I have submitted a new draft (also attached here) that takes into
> account some of the remarks and suggestions received so far.
> >
> >I have made room for additional types of temporal evidence, like
> e.g. RFC 4998, while keeping RFC 3161 as the basis of interoperability.
> >
> >I would like to invite everybody involved in time-stamping and
> archiving e-documents to comment upon it: has it improved? 
> something is missing?
> >
> >In particular, please state:
> >- are you interested in this work?
> >- do you agree to adopt it as a new PKIX work item?
> >- are you going to use this format, once it is finished?
> >
> >Is anybody willing to spend a few words on this draft during the
> IETF meeting in Vancouver (as I cannot attend myself) ?
> >
> >And finally, is anybody willing to invest a little time in
> co-authoring this draft with me?
> >
> >Adriano
> >Actalis S.p.A.
> >Milano, ITALY
> >
> >
> >
> >
> >-----Messaggio originale-----
> >Da: [e-mail]
> [mailto:[e-mail]] Per conto di Santoni Adriano
> >Inviato: lunedì 3 settembre 2007 10.42
> >A: [e-mail]
> >Oggetto: R: R: Draft on TimeStampedData
> >
> >
> >Let me summarize the issues discussed so far:
> >
> >1) allow EvidenceRecord (RFC 4998) in addition to TimeStampToken (RFC 
> >3161)
> >
> >In principle, I have no objections as long as we do not complicate
> things too much and do not hamper interoperability.
> >
> >There are at least two possible approaches to accomodate RFC 4998:
> >
> >   a) explicitly provide for (one) ER in the TimeStampedData
> syntax, as an alternative to the SET OF TimeStampToken;
> >   b) do not mention any specific standard for the "evidence", but
> just mention RFC 3161 and RFC 4998 as two possibilities;
> >
> >In any case, it must be possible for the verifying application to
> easily detect which of the two (or more) kind of "evidence" has been 
> used in the TimeStampedData envelope under examination. If we restrict 
> the kinds of evidence to the two above, then a extra tagging may not 
> be necessary, as an EvidenceRecord is a SEQUENCE, while the other 
> choice would be a SET OF. Although unelegant, it would work. On the 
> other hand, if we do not want to restrict the kinds of evidence to the 
> two above, then of course we should somehow add an extra tagging 
> level, because nobody knows at this time what syntax a third kind of 
> evidence would conform to.
> >
> >In any case, for the sake of interoperability, strong emphasis
> should be given to RFC 3161 as today this is the most widely 
> implemented type of evidence.
> >
> >In conclusion: I agree with allowing RFC 4998 if we do that in a
> way that does not modify the strong emphasis on RFC 3161 and does not 
> hamper interoperability (which must be based on supporting RFC 3161, 
> even though certain applications may also support RFC 4998).
> >
> >2) filename vs. URI
> >
> >Some remarked that an URI (or URI Reference) would be more
> versatile than a simple filename. That is obviously true, but it 
> implies that the 'content' field of TimeStampedData may be empty.
> This is not what I was addressing in my original proposal. It would 
> not just require the 'content' field to be declared OPTIONAL: it would 
> make interoperability very difficult to achieve unless we restrict the 
> URI schemes to a very small subset (e.g. http:, cid:, file:, ldap:) of 
> the myriad possibilities. In any case, it would require ages of 
> interoperability testing. And it would make life much harder for 
> software implementors, without much of a benefit in view. I strongly 
> believe in keeping things simple as much as possible.
> >
> >3) multiple contents and RFC 4073
> >
> >The 'content' field in the TimeStampedData envelope is not
> structured, in my original proposal. It is just an OCTET STRING. 
> That allows for any kind of content to be conveyed, even a 
> ContentCollection according to RFC 4073.
> >
> >Another remark has been made with reference to RFC 4073: the
> ContentWithAttributes structure, also defined in RFC 4073, could in 
> principle be used to bundle some content with the corrisponding 
> evidence (the goal of my draft). Although this is true, it would 
> require definining some additional OIDs, and mandating the presence of 
> certain Attributes tagged by those OIDs. I frankly believe the 
> TimeStampedData structure that I am proposing is better, first because 
> it is dedicated and second because it "implements the ContentInfo 
> interface", so to speak. It is simpler to manage for applications 
> already able to parse different kinds of ContentInfo envelopes (there 
> are a great many), possibly in a recursive way.
> >
> >Adriano
> >
> >
> >-----Messaggio originale-----
> >Da: Young H Etheridge [mailto:[e-mail]]
> >Inviato: venerdì 31 agosto 2007 17.48
> >A: Santoni Adriano
> >Cc: [e-mail]
> >Oggetto: Re: R: Draft on TimeStampedData
> >
> >Adriano,
> >
> >To add to your thought processes:  I believe that a URI of
> "file:///private.stuff" addresses your concern for privacy of the 
> physical URI.  But, allowing URI in the syntax will make less private 
> repositories, not necessarily file systems, more universally 
> accessible.  The intent of the URI in RFC 3986 is to also allow for 
> abstractly identifying a resource, not necessarily providing a 
> physical resource.  In this manner the URI could then be used as an 
> object identity in database(s).
> >
> >Take care,
> >
> >yhe
> >
> >Santoni Adriano wrote:
> >> To accomodate for RFC 4998, I would propose the following syntax:
> >>
> >> TimeStampedData ::= SEQUENCE {
> >>      version                 INTEGER { v1(1) },
> >>      fileName                UTF8String,
> >>      mimeType                PrintableString,
> >>      content         OCTET STRING,
> >>      evidence                Evidence
> >> }
> >>
> >> Evidence ::= CHOICE {
> >>      timeStamps              [0] SET (SIZE(1..MAX)) OF TimeStampToken,
> >>      evidenceRecord  [1] EvidenceRecord -- according to RFC 4998 }
> >>
> >> (I am not sure whether it would be better to use explicit or 
> >> implicit
> >> tags...)
> >>
> >> Regarding the idea of having an URI instead of a filename: I'd
> prefer to think over things a little bit more, and maybe collect more feedback.
> >>
> >> In my mind, I can send a TimeStampedData envelope to business
> partners and/or public agencies via email. If the timestamped document 
> is a local one, which I think is a meaningful and realistic scenario, 
> then I do not want my company's hostnames and pathnames to be included 
> in the envelope so that the recipient can see them.
> >>
> >> Adriano
> >>
> >>
> >>
> >> -----Messaggio originale-----
> >> Da: [e-mail] 
> >> [mailto:[e-mail]]
> >> Per conto di Julien Stern
> >> Inviato: venerdì 31 agosto 2007 13.43
> >> A: [e-mail]
> >> Oggetto: Re: Draft on TimeStampedData
> >>
> >>
> >> On Fri, Aug 31, 2007 at 12:06:00PM +0200, Tilo Kienitz wrote:
> >>
> >>> Adriano,
> >>>
> >>>
> >>>> After pondering on this and other remarks, I cannot help but 
> >>>> agree with Steve.
> >>>>
> >>>> My original and essential goal is that of facilitating 
> >>>> interoperability in a currently unregulated field. If we allow 
> >>>> for several "degrees of freedom", than interoperability will be
> hampered from the beginning.
> >>>> So I'd better stick to RFC 3161 for now. We could include support 
> >>>> for RFC 4998 Evidence Records later on, at the time when they 
> >>>> become a widespread reality comparable to RFC 3161 
> >>>> TimeStampTokens (which are widely implemented).
> >>>>
> >>> I would prefer to have both options: RFC 3161 and RFC 4998. For 
> >>> our customers evidence records are a widespread reality already.
> >>> A standardized way to put some data and their evidence record into 
> >>> a single file would be useful.
> >>>
> >>
> >> I strongly concur with this comment. Allowing the usage of ERS
> as well as simple timestamps would allow the TimestampedData to 
> leverage all the work of RFC 4998 regarding timestamps instead of 
> reinventing the wheel in the future.
> >>
> >> Regards,
> >>
> >> --
> >> Julien
> >>
> >>
> >>> Kind regards
> >>> Tilo
> >>>
> >>>
> >>>
> >>>> -----Messaggio originale-----
> >>>> Da: Stephen Kent [mailto:[e-mail]]
> >>>> Inviato: giovedì 30 agosto 2007 23.05
> >>>> A: Young H Etheridge
> >>>> Cc: Santoni Adriano; [e-mail]
> >>>> Oggetto: Re: R: Draft on TimeStampedData
> >>>>
> >>>> At 4:33 PM -0400 8/30/07, Young H Etheridge wrote:
> >>>>
> >>>>>> ...
> >>>>>>
> >>>>> Agreed, w.r.t. normative vs informative.  The above quote from
> >>>>> RFC-4998 merely underscores that this draft should also suggest, 
> >>>>> informatively, that the choice of Timestamp should be one that 
> >>>>> meets the normative syntax for Timestamp and not specify that 
> >>>>> which is in RFC-3161.  Nothing gets broken by being less 
> >>>>> restrictive and generally more informative to the community-at-large.
> >>>>>
> >>>> I have to disagree with your conclusion. If we require 3161
> time stamps in an RFC of the sort Adriano proposed, then everyone can 
> parse them if they comply with the RFC. If the RFC says "insert the 
> time stamp from any standard you want here, and just tell us which one 
> you used" then we have a problem. A compliant implementation can 
> generate data structures containing time stamps that other compliant 
> implementations cannot parse. That's the sort of interoperability 
> problem we try to avoid in the IETF.
> >>>>
> >>>>
> >>>>> My notion of resilience does not mean "more encompassing" but 
> >>>>> that of providing the user community with choice and an enhanced 
> >>>>> safeguard against the possibility of the weakening of an algorithm.
> >>>>>
> >>>> Choices can be good, but they can create interoperability
> problems in some cases, like this one. Also, we have algorithm agility 
> as a requirement in all of our work, so the second concern you cite 
> does not seem to apply here.
> >>>>
> >>>> Steve
> >>>>
> >>> --
> >>> Tilo Kienitz
> >>> SecCommerce Informationssysteme GmbH Obenhauptstr. 5 D - 22335 
> >>> Hamburg
> >>> Germany                                   http://www.seccommerce.de




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAKLsKTa035014 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Nov 2007 14:54:20 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lAKLsKVT035013; Tue, 20 Nov 2007 14:54:20 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [8.8.40.152]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id lAKLsJs9035000 for <[e-mail]>; Tue, 20 Nov 2007 14:54:19 -0700 (MST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
Received: (qmail 11850 invoked by uid 0); 20 Nov 2007 21:54:11 -0000
Received: from unknown (HELO THINKPADR52.vigilsec.com) (24.131.121.208) by woodstock.binhost.com with SMTP; 20 Nov 2007 21:54:11 -0000
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Tue, 20 Nov 2007 16:53:20 -0500
To: [e-mail], [e-mail]
From: Russ Housley <[e-mail]>
Subject: Re: TimeStampedData draft updated - please comment
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

In S/MIME, the id-data content type is used when the content is MIME 
encoded.  Then, then MIME header in the content is used to determine 
the format of the content.  Why does this suggest a different approach?

Russ

At 08:16 AM 11/19/2007, Denis Pinkas wrote:

>Adriano,
>
>Thank you for this new proposal. I skimmed through it.
>
>It is interesting, but I fear that it is targeted to the wrong WG.
>Since this would be an extension of CMS, this work item
>would rather belong to the S-MIME WG.
>For this reason, I copy the S-MIME WG.
>
>In addition, some polishing would be needed.
>
>Rather than long words, you will find hereafter a rewriting of the ASN.1
>with a few explanatory comments.
>
>    TimeStampedData ::= SEQUENCE {
>       version        [0] Version DEFAULT v1,
>       fileName           UTF8String,
>       mimeType           PrintableString,
>       fileLocation       UTF8String OPTIONAL,
>       -- fileLocation is only a hint.
>       -- The file may or may not be stored at that location.
>       content            OCTET STRING,
>       temporalEvidences  TemporalEvidences
>}
>
>    Version  ::=  INTEGER  { v1(0) }
>    TemporalEvidences ::= SEQUENCE (SIZE(1..MAX)) OF TemporalEvidence
>
>-- This structure allows multiple levels of temporal evidences.
>
>    TemporalEvidence ::= SEQUENCE {
>       evidences            Evidences,
>       certificateLists     CertificateLists  OPTIONAL
>}
>
>    CertificateLists :: = SEQUENCE (SIZE(1..MAX)) OF CertificateList
>
>    Evidence ::= CHOICE {
>       timeStamps     [0] SEQUENCE (SIZE(1..MAX)) OF TimeStampToken }
>
>-- For each level there can be one or more time-stamps tokens.
>
>-- Before re-time stamping a set of former time-stamp tokens,
>-- the CRLs of the previous level of time-stamps tokens can be captured
>-- and inserted in the data structure.
>
>Denis
>
>
> >Hello there,
> >
> >here I am again with my TimeStampedData proposal.
> >
> >I have submitted a new draft (also attached here) that takes into 
> account some of the remarks and suggestions received so far.
> >
> >I have made room for additional types of temporal evidence, like 
> e.g. RFC 4998, while keeping RFC 3161 as the basis of interoperability.
> >
> >I would like to invite everybody involved in time-stamping and 
> archiving e-documents to comment upon it: has it improved? 
> something is missing?
> >
> >In particular, please state:
> >- are you interested in this work?
> >- do you agree to adopt it as a new PKIX work item?
> >- are you going to use this format, once it is finished?
> >
> >Is anybody willing to spend a few words on this draft during the 
> IETF meeting in Vancouver (as I cannot attend myself) ?
> >
> >And finally, is anybody willing to invest a little time in 
> co-authoring this draft with me?
> >
> >Adriano
> >Actalis S.p.A.
> >Milano, ITALY
> >
> >
> >
> >
> >-----Messaggio originale-----
> >Da: [e-mail] 
> [mailto:[e-mail]] Per conto di Santoni Adriano
> >Inviato: lunedì 3 settembre 2007 10.42
> >A: [e-mail]
> >Oggetto: R: R: Draft on TimeStampedData
> >
> >
> >Let me summarize the issues discussed so far:
> >
> >1) allow EvidenceRecord (RFC 4998) in addition to TimeStampToken (RFC 3161)
> >
> >In principle, I have no objections as long as we do not complicate 
> things too much and do not hamper interoperability.
> >
> >There are at least two possible approaches to accomodate RFC 4998:
> >
> >   a) explicitly provide for (one) ER in the TimeStampedData 
> syntax, as an alternative to the SET OF TimeStampToken;
> >   b) do not mention any specific standard for the "evidence", but 
> just mention RFC 3161 and RFC 4998 as two possibilities;
> >
> >In any case, it must be possible for the verifying application to 
> easily detect which of the two (or more) kind of "evidence" has 
> been used in the TimeStampedData envelope under examination. If we 
> restrict the kinds of evidence to the two above, then a extra 
> tagging may not be necessary, as an EvidenceRecord is a SEQUENCE, 
> while the other choice would be a SET OF. Although unelegant, it 
> would work. On the other hand, if we do not want to restrict the 
> kinds of evidence to the two above, then of course we should 
> somehow add an extra tagging level, because nobody knows at this 
> time what syntax a third kind of evidence would conform to.
> >
> >In any case, for the sake of interoperability, strong emphasis 
> should be given to RFC 3161 as today this is the most widely 
> implemented type of evidence.
> >
> >In conclusion: I agree with allowing RFC 4998 if we do that in a 
> way that does not modify the strong emphasis on RFC 3161 and does 
> not hamper interoperability (which must be based on supporting RFC 
> 3161, even though certain applications may also support RFC 4998).
> >
> >2) filename vs. URI
> >
> >Some remarked that an URI (or URI Reference) would be more 
> versatile than a simple filename. That is obviously true, but it 
> implies that the 'content' field of TimeStampedData may be empty. 
> This is not what I was addressing in my original proposal. It would 
> not just require the 'content' field to be declared OPTIONAL: it 
> would make interoperability very difficult to achieve unless we 
> restrict the URI schemes to a very small subset (e.g. http:, cid:, 
> file:, ldap:) of the myriad possibilities. In any case, it would 
> require ages of interoperability testing. And it would make life 
> much harder for software implementors, without much of a benefit in 
> view. I strongly believe in keeping things simple as much as possible.
> >
> >3) multiple contents and RFC 4073
> >
> >The 'content' field in the TimeStampedData envelope is not 
> structured, in my original proposal. It is just an OCTET STRING. 
> That allows for any kind of content to be conveyed, even a 
> ContentCollection according to RFC 4073.
> >
> >Another remark has been made with reference to RFC 4073: the 
> ContentWithAttributes structure, also defined in RFC 4073, could in 
> principle be used to bundle some content with the corrisponding 
> evidence (the goal of my draft). Although this is true, it would 
> require definining some additional OIDs, and mandating the presence 
> of certain Attributes tagged by those OIDs. I frankly believe the 
> TimeStampedData structure that I am proposing is better, first 
> because it is dedicated and second because it "implements the 
> ContentInfo interface", so to speak. It is simpler to manage for 
> applications already able to parse different kinds of ContentInfo 
> envelopes (there are a great many), possibly in a recursive way.
> >
> >Adriano
> >
> >
> >-----Messaggio originale-----
> >Da: Young H Etheridge [mailto:[e-mail]]
> >Inviato: venerdì 31 agosto 2007 17.48
> >A: Santoni Adriano
> >Cc: [e-mail]
> >Oggetto: Re: R: Draft on TimeStampedData
> >
> >Adriano,
> >
> >To add to your thought processes:  I believe that a URI of 
> "file:///private.stuff" addresses your concern for privacy of the 
> physical URI.  But, allowing URI in the syntax will make less 
> private repositories, not necessarily file systems, more 
> universally accessible.  The intent of the URI in RFC 3986 is to 
> also allow for abstractly identifying a resource, not necessarily 
> providing a physical resource.  In this manner the URI could then 
> be used as an object identity in database(s).
> >
> >Take care,
> >
> >yhe
> >
> >Santoni Adriano wrote:
> >> To accomodate for RFC 4998, I would propose the following syntax:
> >>
> >> TimeStampedData ::= SEQUENCE {
> >>      version                 INTEGER { v1(1) },
> >>      fileName                UTF8String,
> >>      mimeType                PrintableString,
> >>      content         OCTET STRING,
> >>      evidence                Evidence
> >> }
> >>
> >> Evidence ::= CHOICE {
> >>      timeStamps              [0] SET (SIZE(1..MAX)) OF TimeStampToken,
> >>      evidenceRecord  [1] EvidenceRecord -- according to RFC 4998
> >> }
> >>
> >> (I am not sure whether it would be better to use explicit or implicit
> >> tags...)
> >>
> >> Regarding the idea of having an URI instead of a filename: I'd 
> prefer to think over things a little bit more, and maybe collect more feedback.
> >>
> >> In my mind, I can send a TimeStampedData envelope to business 
> partners and/or public agencies via email. If the timestamped 
> document is a local one, which I think is a meaningful and 
> realistic scenario, then I do not want my company's hostnames and 
> pathnames to be included in the envelope so that the recipient can see them.
> >>
> >> Adriano
> >>
> >>
> >>
> >> -----Messaggio originale-----
> >> Da: [e-mail] [mailto:[e-mail]]
> >> Per conto di Julien Stern
> >> Inviato: venerdì 31 agosto 2007 13.43
> >> A: [e-mail]
> >> Oggetto: Re: Draft on TimeStampedData
> >>
> >>
> >> On Fri, Aug 31, 2007 at 12:06:00PM +0200, Tilo Kienitz wrote:
> >>
> >>> Adriano,
> >>>
> >>>
> >>>> After pondering on this and other remarks, I cannot help but agree
> >>>> with Steve.
> >>>>
> >>>> My original and essential goal is that of facilitating
> >>>> interoperability in a currently unregulated field. If we allow for
> >>>> several "degrees of freedom", than interoperability will be 
> hampered from the beginning.
> >>>> So I'd better stick to RFC 3161 for now. We could include support
> >>>> for RFC 4998 Evidence Records later on, at the time when they become
> >>>> a widespread reality comparable to RFC 3161 TimeStampTokens (which
> >>>> are widely implemented).
> >>>>
> >>> I would prefer to have both options: RFC 3161 and RFC 4998. For our
> >>> customers evidence records are a widespread reality already.
> >>> A standardized way to put some data and their evidence record into a
> >>> single file would be useful.
> >>>
> >>
> >> I strongly concur with this comment. Allowing the usage of ERS 
> as well as simple timestamps would allow the TimestampedData to 
> leverage all the work of RFC 4998 regarding timestamps instead of 
> reinventing the wheel in the future.
> >>
> >> Regards,
> >>
> >> --
> >> Julien
> >>
> >>
> >>> Kind regards
> >>> Tilo
> >>>
> >>>
> >>>
> >>>> -----Messaggio originale-----
> >>>> Da: Stephen Kent [mailto:[e-mail]]
> >>>> Inviato: giovedì 30 agosto 2007 23.05
> >>>> A: Young H Etheridge
> >>>> Cc: Santoni Adriano; [e-mail]
> >>>> Oggetto: Re: R: Draft on TimeStampedData
> >>>>
> >>>> At 4:33 PM -0400 8/30/07, Young H Etheridge wrote:
> >>>>
> >>>>>> ...
> >>>>>>
> >>>>> Agreed, w.r.t. normative vs informative.  The above quote from
> >>>>> RFC-4998 merely underscores that this draft should also suggest,
> >>>>> informatively, that the choice of Timestamp should be one that
> >>>>> meets the normative syntax for Timestamp and not specify that which
> >>>>> is in RFC-3161.  Nothing gets broken by being less restrictive and
> >>>>> generally more informative to the community-at-large.
> >>>>>
> >>>> I have to disagree with your conclusion. If we require 3161 
> time stamps in an RFC of the sort Adriano proposed, then everyone 
> can parse them if they comply with the RFC. If the RFC says "insert 
> the time stamp from any standard you want here, and just tell us 
> which one you used" then we have a problem. A compliant 
> implementation can generate data structures containing time stamps 
> that other compliant implementations cannot parse. That's the sort 
> of interoperability problem we try to avoid in the IETF.
> >>>>
> >>>>
> >>>>> My notion of resilience does not mean "more encompassing" but that
> >>>>> of providing the user community with choice and an enhanced
> >>>>> safeguard against the possibility of the weakening of an algorithm.
> >>>>>
> >>>> Choices can be good, but they can create interoperability 
> problems in some cases, like this one. Also, we have algorithm 
> agility as a requirement in all of our work, so the second concern 
> you cite does not seem to apply here.
> >>>>
> >>>> Steve
> >>>>
> >>> --
> >>> Tilo Kienitz
> >>> SecCommerce Informationssysteme GmbH
> >>> Obenhauptstr. 5
> >>> D - 22335 Hamburg
> >>> Germany                                   http://www.seccommerce.de



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAKF1sfv096449 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Nov 2007 08:01:54 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lAKF1sCr096448; Tue, 20 Nov 2007 08:01:54 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from people.com.cn ([202.99.23.227]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id lAKF1r4O096442 for <[e-mail]>; Tue, 20 Nov 2007 08:01:53 -0700 (MST) (envelope-from [e-mail])
Received: from people.com.cn([127.0.0.1]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm14847433746; Tue, 20 Nov 2007 23:14:51 +0800
Received: from megatron.ietf.org([156.154.16.145]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm22c473e2240; Sat, 17 Nov 2007 05:14:14 +0800
Received: from megatron.ietf.org([156.154.16.145]) by people.com.cn(AIMC 2.9.5.8) with SMTP id AISP action; Sat, 17 Nov 2007 05:14:14 +0800
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1It8In-0004UP-D1; Fri, 16 Nov 2007 16:00:37 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1It8Ij-0004Th-1R for [e-mail]; Fri, 16 Nov 2007 16:00:33 -0500
Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1It8Ii-0000y8-9C for [e-mail]; Fri, 16 Nov 2007 16:00:32 -0500
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 266812AC88; Fri, 16 Nov 2007 21:00:02 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1It8ID-0004KG-TG; Fri, 16 Nov 2007 16:00:01 -0500
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
From: [e-mail]
Message-Id: <[e-mail]>
Date: Fri, 16 Nov 2007 16:00:01 -0500
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632
Cc: [e-mail]
Subject: I-D Action:draft-ietf-smime-multisig-03.txt 
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Reply-To: [e-mail]
List-Id: i-d-announce.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/i-d-announce>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/i-d-announce>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/i-d-announce>, <mailto:[e-mail]?subject=subscribe>
X-AIMC-AUTH: (null)
X-AIMC-MAILFROM: [e-mail]
X-AIMC-AUTH: (null)
X-AIMC-MAILFROM: [e-mail]
X-Auto-Forward: [e-mail] [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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           : Multiple Signatures in S/MIME
	Author(s)       : I. Property
	Filename        : draft-ietf-smime-multisig-03.txt
	Pages           : 19
	Date            : 2007-11-16

CMS SignedData includes the SignerInfo structure to convey per-signer 
information. SignedData supports multiple signers and multiple 
signature algorithms per-signer with multiple SignerInfo structures. 
If a signer attaches more than one SignerInfo, there are concerns 
that an attacker could perform a downgrade attack by removing the 
SignerInfo(s) with the 'strong' algorithm(s). This document defines 
 
 
 the multiple-signatures attribute, its generation rules, and its 
processing rules to allow signers to convey multiple SignerInfo while 
protecting against downgrade attacks. Additionally, this attribute 
may assist during periods of algorithm migration. 

Conventions used in this document 

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 

Discussion 

This draft is being discussed on the 'ietf-smime' mailing list. To 
subscribe, send a message to [e-mail] with the 
single word subscribe in the body of the message. There is a Web site 
for the mailing list at <http://www.imc.org/ietf-smime/>.

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

To remove yourself from the I-D Announcement list, send a message to
[e-mail] 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-multisig-03.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:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-smime-multisig-03.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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body; access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID: <[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-smime-multisig-03.txt

--OtherAccess
Content-Type: Message/External-body; name="draft-ietf-smime-multisig-03.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2007-11-16155945.I-D\@ietf.org>


--OtherAccess--

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
I-D-Announce mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/i-d-announce

--NextPart--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAJNO0Cf033805 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Nov 2007 16:24:00 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lAJNO0gN033804; Mon, 19 Nov 2007 16:24:00 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from [10.20.30.108] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAJNNvKc033798 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Nov 2007 16:23:58 -0700 (MST) (envelope-from [e-mail])
Mime-Version: 1.0
Message-Id: <p0624080ec367cb1a1d72@[10.20.30.108]>
Date: Mon, 19 Nov 2007 15:23:13 -0800
To: [e-mail], [e-mail], [e-mail]
From: Paul Hoffman <[e-mail]>
Subject: Fwd: Document Action: 'Additional Diffie-Hellman Groups for   use with IETF Standards' to Informational RFC
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>The IESG has approved the following document:
>
>- 'Additional Diffie-Hellman Groups for use with IETF Standards '
>    <draft-lepinski-dh-groups-03.txt> as an Informational RFC
>
>This document has been reviewed in the IETF but is not the product of an
>IETF Working Group.
>
>The IESG contact person is Tim Polk.
>
>A URL of this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-lepinski-dh-groups-03.txt
>
>Technical Summary
>
>This document specifies (eight) Diffie-Hellman groups for use with
>security protocols developed by five different IETF WGs (IPsec, PKIX,
>S/MIME, SSH, SSL, and TLS).  The specified groups include three
>modular exponentiation groups and five elliptic curve groups.  Several
>of the Diffie-Hellman groups specified in this draft are already
>defined in WG-specific RFCs (e.g., RFC 3526 and RFC 4753) and I-Ds,
>but without the test data provided here. The group definitions and
>test data are derived from a NIST document that is available only
>on the NIST web site as a PDF.  This draft translates the parameter
>terminology from the with NIST document into a form consistent with
>RFCs that define Diffie-Hellman groups (in protocol-specific contexts),
>and removes extraneous test data that would not be relevant to IETF
>protocols.
>
>Working Group Summary
>
>This document was not the product of any working group, but has been
>reviewed by experts from several relevant wgs.  Specifically, this
>document
>incorporates comments from: Tero Kivinen, the designated
>approver of additional Diffie-Hellman groups for IKE; Sean
>Turner S/MIME WG co-chair;  and Pasi Eronen (TLS WG co-chair).  Steve
>Kent (PKIX co-chair) is a co-author of this document and he ensured
>that PKIX concerns were addressed. No input was solicited form the
>SSH WG co-chairs, as that protocol provides a trivial means of
>accommodating additional (mod p) Diffie-Hellman groups. SSH provides
>no means of accommodating Elliptic Curve Diffie-Hellman groups, and
>as a result, the document is silent on use of Elliptic Curve
>Diffie-Hellman groups with SSH. (There is an expired I-D that
>describes how to use Elliptic Curve Diffie-Hellman with SSH. If it
>is re-submitted and adopted by the SSH WG, it would be appropriate
>to amend this draft to include it as well.)
>
>Protocol Quality
>
>Tim Polk reviewed this specification for the IESG.  Larry Bassham, who
>drafted the base NIST document, has also reviewed the specification.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAJJfUv3015415 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Nov 2007 12:41:30 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lAJJfUBO015414; Mon, 19 Nov 2007 12:41:30 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ns1.neustar.com (ns1.neustar.com [156.154.16.138]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAJJfS4C015406 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Mon, 19 Nov 2007 12:41:29 -0700 (MST) (envelope-from [e-mail])
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 93258327C1; Mon, 19 Nov 2007 19:41:27 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IuCUp-0000Sd-FM; Mon, 19 Nov 2007 14:41:27 -0500
X-test-idtracker: no
From: The IESG <[e-mail]>
To: IETF-Announce <[e-mail]>
Cc: Internet Architecture Board <[e-mail]>, RFC Editor <[e-mail]>, smime mailing list <[e-mail]>, smime chair <[e-mail]>
Subject: Document Action: 'CMS Advanced Electronic Signatures  (CAdES)' to Informational RFC 
Message-Id: <[e-mail]>
Date: Mon, 19 Nov 2007 14:41:27 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The IESG has approved the following document:

- 'CMS Advanced Electronic Signatures (CAdES) '
   <draft-ietf-smime-cades-07.txt> as an Informational RFC

This document is the product of the S/MIME Mail Security Working Group. 

The IESG contact persons are Tim Polk and Sam Hartman.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-cades-07.txt

Technical Summary
 
   This document defines the format of an electronic signature that can
   remain valid over long periods.  This includes evidence as to its
   validity even if the signer or verifying party later attempts to deny
   (i.e., repudiates the validity of the signature).    The format can be
   considered as an extension to RFC 3852 [4] and RFC 2634 [5],
   where, when appropriate additional signed and unsigned attributes
   have been defined.  

   The contents of this Informational RFC amounts to a 
   transposition of the ETSI TS 101 733 V.1.7.3 (CMS Advanced 
   Electronic Signatures - CAdES) [TS101733] and is technically 
   equivalent to it.
 
Working Group Summary
 
   While this work was initatiated in ETSI, this document was also
   discussed  by the S/MIME working group.  Issues were identified
   and resolved to maintain compatibility with implementations of
   RFC 3126, which it obsoletes.
 
Protocol Quality
 
Tim Polk reviewed this document for the IESG.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAJDHXTi077459 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Nov 2007 06:17:33 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lAJDHXHQ077458; Mon, 19 Nov 2007 06:17:33 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAJDHTgD077441; Mon, 19 Nov 2007 06:17:30 -0700 (MST) (envelope-from [e-mail])
Received: from MSGA-001.frcl.bull.fr (msga-001.frcl.bull.fr [129.184.87.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id OAA55058; Mon, 19 Nov 2007 14:25:17 +0100
Received: from frcls4013 ([129.182.108.120]) by MSGA-001.frcl.bull.fr (Lotus Domino Release 5.0.11) with SMTP id 2007111914170173:22070 ; Mon, 19 Nov 2007 14:17:01 +0100 
Date: Mon, 19 Nov 2007 14:16:58 +0100
From: "Denis Pinkas" <[e-mail]>
To: "[e-mail]" <[e-mail]>
Cc: "S-MIME / IETF" <[e-mail]>
Subject: Re: TimeStampedData draft updated - please comment
X-mailer: Foxmail 5.0 [-fr-]
Mime-Version: 1.0
X-MIMETrack: Itemize by SMTP Server on MSGA-001/FR/BULL(Release 5.0.11  |July 24, 2002) at 19/11/2007 14:17:01, Serialize by Router on MSGA-001/FR/BULL(Release 5.0.11  |July 24, 2002) at 19/11/2007 14:17:28, Serialize complete at 19/11/2007 14:17:28
Message-ID: <[e-mail]>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by balder-227.proper.com id lAJDHWgE077448
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Adriano,

Thank you for this new proposal. I skimmed through it.

It is interesting, but I fear that it is targeted to the wrong WG.
Since this would be an extension of CMS, this work item 
would rather belong to the S-MIME WG.
For this reason, I copy the S-MIME WG. 

In addition, some polishing would be needed.

Rather than long words, you will find hereafter a rewriting of the ASN.1 
with a few explanatory comments.

   TimeStampedData ::= SEQUENCE { 
      version        [0] Version DEFAULT v1, 
      fileName           UTF8String, 
      mimeType           PrintableString, 
      fileLocation       UTF8String OPTIONAL, 
      -- fileLocation is only a hint. 
      -- The file may or may not be stored at that location.
      content            OCTET STRING, 
      temporalEvidences  TemporalEvidences 
}

   Version  ::=  INTEGER  { v1(0) } 
   TemporalEvidences ::= SEQUENCE (SIZE(1..MAX)) OF TemporalEvidence 

-- This structure allows multiple levels of temporal evidences.

   TemporalEvidence ::= SEQUENCE {
      evidences            Evidences,
      certificateLists     CertificateLists  OPTIONAL
}

   CertificateLists :: = SEQUENCE (SIZE(1..MAX)) OF CertificateList

   Evidence ::= CHOICE { 
      timeStamps     [0] SEQUENCE (SIZE(1..MAX)) OF TimeStampToken }

-- For each level there can be one or more time-stamps tokens.

-- Before re-time stamping a set of former time-stamp tokens, 
-- the CRLs of the previous level of time-stamps tokens can be captured 
-- and inserted in the data structure.

Denis


>Hello there,
>
>here I am again with my TimeStampedData proposal.
>
>I have submitted a new draft (also attached here) that takes into account some of the remarks and suggestions received so far.
>
>I have made room for additional types of temporal evidence, like e.g. RFC 4998, while keeping RFC 3161 as the basis of interoperability.
>
>I would like to invite everybody involved in time-stamping and archiving e-documents to comment upon it: has it improved? something is missing?
>
>In particular, please state:
>- are you interested in this work?
>- do you agree to adopt it as a new PKIX work item?
>- are you going to use this format, once it is finished?
>
>Is anybody willing to spend a few words on this draft during the IETF meeting in Vancouver (as I cannot attend myself) ?
>
>And finally, is anybody willing to invest a little time in co-authoring this draft with me?
>
>Adriano
>Actalis S.p.A.
>Milano, ITALY
>
>
>
>
>-----Messaggio originale-----
>Da: [e-mail] [mailto:[e-mail]] Per conto di Santoni Adriano
>Inviato: lunedì 3 settembre 2007 10.42
>A: [e-mail]
>Oggetto: R: R: Draft on TimeStampedData
>
>
>Let me summarize the issues discussed so far:
>
>1) allow EvidenceRecord (RFC 4998) in addition to TimeStampToken (RFC 3161)
>
>In principle, I have no objections as long as we do not complicate things too much and do not hamper interoperability. 
>
>There are at least two possible approaches to accomodate RFC 4998:
>
>   a) explicitly provide for (one) ER in the TimeStampedData syntax, as an alternative to the SET OF TimeStampToken;
>   b) do not mention any specific standard for the "evidence", but just mention RFC 3161 and RFC 4998 as two possibilities;
>
>In any case, it must be possible for the verifying application to easily detect which of the two (or more) kind of "evidence" has been used in the TimeStampedData envelope under examination. If we restrict the kinds of evidence to the two above, then a extra tagging may not be necessary, as an EvidenceRecord is a SEQUENCE, while the other choice would be a SET OF. Although unelegant, it would work. On the other hand, if we do not want to restrict the kinds of evidence to the two above, then of course we should somehow add an extra tagging level, because nobody knows at this time what syntax a third kind of evidence would conform to.
>
>In any case, for the sake of interoperability, strong emphasis should be given to RFC 3161 as today this is the most widely implemented type of evidence.
>
>In conclusion: I agree with allowing RFC 4998 if we do that in a way that does not modify the strong emphasis on RFC 3161 and does not hamper interoperability (which must be based on supporting RFC 3161, even though certain applications may also support RFC 4998).
>
>2) filename vs. URI 
>
>Some remarked that an URI (or URI Reference) would be more versatile than a simple filename. That is obviously true, but it implies that the 'content' field of TimeStampedData may be empty. This is not what I was addressing in my original proposal. It would not just require the 'content' field to be declared OPTIONAL: it would make interoperability very difficult to achieve unless we restrict the URI schemes to a very small subset (e.g. http:, cid:, file:, ldap:) of the myriad possibilities. In any case, it would require ages of interoperability testing. And it would make life much harder for software implementors, without much of a benefit in view. I strongly believe in keeping things simple as much as possible.
>
>3) multiple contents and RFC 4073
>
>The 'content' field in the TimeStampedData envelope is not structured, in my original proposal. It is just an OCTET STRING. That allows for any kind of content to be conveyed, even a ContentCollection according to RFC 4073.
>
>Another remark has been made with reference to RFC 4073: the ContentWithAttributes structure, also defined in RFC 4073, could in principle be used to bundle some content with the corrisponding evidence (the goal of my draft). Although this is true, it would require definining some additional OIDs, and mandating the presence of certain Attributes tagged by those OIDs. I frankly believe the TimeStampedData structure that I am proposing is better, first because it is dedicated and second because it "implements the ContentInfo interface", so to speak. It is simpler to manage for applications already able to parse different kinds of ContentInfo envelopes (there are a great many), possibly in a recursive way.
>
>Adriano 
>
>
>-----Messaggio originale-----
>Da: Young H Etheridge [mailto:[e-mail]]
>Inviato: venerdì 31 agosto 2007 17.48
>A: Santoni Adriano
>Cc: [e-mail]
>Oggetto: Re: R: Draft on TimeStampedData
>
>Adriano,
>
>To add to your thought processes:  I believe that a URI of "file:///private.stuff" addresses your concern for privacy of the physical URI.  But, allowing URI in the syntax will make less private repositories, not necessarily file systems, more universally accessible.  The intent of the URI in RFC 3986 is to also allow for abstractly identifying a resource, not necessarily providing a physical resource.  In this manner the URI could then be used as an object identity in database(s).
>
>Take care,
>
>yhe
>
>Santoni Adriano wrote:
>> To accomodate for RFC 4998, I would propose the following syntax:
>>
>> TimeStampedData ::= SEQUENCE {
>> 	version			INTEGER { v1(1) },
>> 	fileName		UTF8String,
>> 	mimeType 	 	PrintableString,
>> 	content		OCTET STRING,
>> 	evidence		Evidence
>> }
>>
>> Evidence ::= CHOICE {
>> 	timeStamps		[0] SET (SIZE(1..MAX)) OF TimeStampToken,
>> 	evidenceRecord	[1] EvidenceRecord -- according to RFC 4998
>> }
>>
>> (I am not sure whether it would be better to use explicit or implicit
>> tags...)
>>
>> Regarding the idea of having an URI instead of a filename: I'd prefer to think over things a little bit more, and maybe collect more feedback.
>>
>> In my mind, I can send a TimeStampedData envelope to business partners and/or public agencies via email. If the timestamped document is a local one, which I think is a meaningful and realistic scenario, then I do not want my company's hostnames and pathnames to be included in the envelope so that the recipient can see them.
>>
>> Adriano
>>
>>
>>
>> -----Messaggio originale-----
>> Da: [e-mail] [mailto:[e-mail]]
>> Per conto di Julien Stern
>> Inviato: venerdì 31 agosto 2007 13.43
>> A: [e-mail]
>> Oggetto: Re: Draft on TimeStampedData
>>
>>
>> On Fri, Aug 31, 2007 at 12:06:00PM +0200, Tilo Kienitz wrote:
>>   
>>> Adriano,
>>>
>>>     
>>>> After pondering on this and other remarks, I cannot help but agree 
>>>> with Steve.
>>>>
>>>> My original and essential goal is that of facilitating 
>>>> interoperability in a currently unregulated field. If we allow for 
>>>> several "degrees of freedom", than interoperability will be hampered from the beginning.
>>>> So I'd better stick to RFC 3161 for now. We could include support 
>>>> for RFC 4998 Evidence Records later on, at the time when they become 
>>>> a widespread reality comparable to RFC 3161 TimeStampTokens (which 
>>>> are widely implemented).
>>>>       
>>> I would prefer to have both options: RFC 3161 and RFC 4998. For our 
>>> customers evidence records are a widespread reality already.
>>> A standardized way to put some data and their evidence record into a 
>>> single file would be useful.
>>>     
>>
>> I strongly concur with this comment. Allowing the usage of ERS as well as simple timestamps would allow the TimestampedData to leverage all the work of RFC 4998 regarding timestamps instead of reinventing the wheel in the future.
>>
>> Regards,
>>
>> --
>> Julien
>>
>>   
>>> Kind regards
>>> Tilo
>>>
>>>
>>>     
>>>> -----Messaggio originale-----
>>>> Da: Stephen Kent [mailto:[e-mail]]
>>>> Inviato: giovedì 30 agosto 2007 23.05
>>>> A: Young H Etheridge
>>>> Cc: Santoni Adriano; [e-mail]
>>>> Oggetto: Re: R: Draft on TimeStampedData
>>>>
>>>> At 4:33 PM -0400 8/30/07, Young H Etheridge wrote:
>>>>       
>>>>>> ...
>>>>>>           
>>>>> Agreed, w.r.t. normative vs informative.  The above quote from
>>>>> RFC-4998 merely underscores that this draft should also suggest, 
>>>>> informatively, that the choice of Timestamp should be one that 
>>>>> meets the normative syntax for Timestamp and not specify that which 
>>>>> is in RFC-3161.  Nothing gets broken by being less restrictive and 
>>>>> generally more informative to the community-at-large.
>>>>>         
>>>> I have to disagree with your conclusion. If we require 3161 time stamps in an RFC of the sort Adriano proposed, then everyone can parse them if they comply with the RFC. If the RFC says "insert the time stamp from any standard you want here, and just tell us which one you used" then we have a problem. A compliant implementation can generate data structures containing time stamps that other compliant implementations cannot parse. That's the sort of interoperability problem we try to avoid in the IETF.
>>>>
>>>>       
>>>>> My notion of resilience does not mean "more encompassing" but that 
>>>>> of providing the user community with choice and an enhanced 
>>>>> safeguard against the possibility of the weakening of an algorithm.
>>>>>         
>>>> Choices can be good, but they can create interoperability problems in some cases, like this one. Also, we have algorithm agility as a requirement in all of our work, so the second concern you cite does not seem to apply here.
>>>>
>>>> Steve
>>>>       
>>> --
>>> Tilo Kienitz
>>> SecCommerce Informationssysteme GmbH
>>> Obenhauptstr. 5
>>> D - 22335 Hamburg
>>> Germany                                   http://www.seccommerce.de




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAGL05fU027743 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 16 Nov 2007 14:00:05 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lAGL05vd027742; Fri, 16 Nov 2007 14:00:05 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ns4.neustar.com (ns4.neustar.com [156.154.24.139]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAGL04OJ027731 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Fri, 16 Nov 2007 14:00:04 -0700 (MST) (envelope-from [e-mail])
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 266812AC88; Fri, 16 Nov 2007 21:00:02 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1It8ID-0004KG-TG; Fri, 16 Nov 2007 16:00:01 -0500
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D Action:draft-ietf-smime-multisig-03.txt 
Message-Id: <[e-mail]>
Date: Fri, 16 Nov 2007 16:00:01 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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           : Multiple Signatures in S/MIME
	Author(s)       : I. Property
	Filename        : draft-ietf-smime-multisig-03.txt
	Pages           : 19
	Date            : 2007-11-16

CMS SignedData includes the SignerInfo structure to convey per-signer 
information. SignedData supports multiple signers and multiple 
signature algorithms per-signer with multiple SignerInfo structures. 
If a signer attaches more than one SignerInfo, there are concerns 
that an attacker could perform a downgrade attack by removing the 
SignerInfo(s) with the 'strong' algorithm(s). This document defines 
 
 
 the multiple-signatures attribute, its generation rules, and its 
processing rules to allow signers to convey multiple SignerInfo while 
protecting against downgrade attacks. Additionally, this attribute 
may assist during periods of algorithm migration. 

Conventions used in this document 

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 

Discussion 

This draft is being discussed on the 'ietf-smime' mailing list. To 
subscribe, send a message to [e-mail] with the 
single word subscribe in the body of the message. There is a Web site 
for the mailing list at <http://www.imc.org/ietf-smime/>.

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

To remove yourself from the I-D Announcement list, send a message to
[e-mail] 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-multisig-03.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:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-smime-multisig-03.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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:     <[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-smime-multisig-03.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-smime-multisig-03.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:     <2007-11-16155945.I-D\@ietf.org>

--OtherAccess--

--NextPart--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAELF5FL074029 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 14 Nov 2007 14:15:05 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lAELF5RM074028; Wed, 14 Nov 2007 14:15:05 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ns1.neustar.com (ns1.neustar.com [156.154.16.138]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAELF3Wr074013 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Wed, 14 Nov 2007 14:15:04 -0700 (MST) (envelope-from [e-mail])
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 0522D26E9D; Wed, 14 Nov 2007 21:15:02 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IsPZd-0008H3-T2; Wed, 14 Nov 2007 16:15:01 -0500
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-smime-cades-07.txt 
Message-Id: <[e-mail]>
Date: Wed, 14 Nov 2007 16:15:01 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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		: CMS Advanced Electronic Signatures (CAdES)
	Author(s)	: J. Ross, et al.
	Filename	: draft-ietf-smime-cades-07.txt
	Pages		: 132
	Date		: 2007-11-14
	
This document defines the format of an electronic signature that can
   remain valid over long periods.  This includes evidence as to its
   validity even if the signer or verifying party later attempts to deny
   (i.e., repudiates) the validity of the signature. 

   The format can be considered as an extension to RFC 3852 [4] and 
   RFC 2634 [5], where, when appropriate, additional signed and 
   unsigned attributes have been defined.  

   The contents of this Informational RFC amounts to a 
   transposition of the ETSI TS 101 733 V.1.7.4 (CMS Advanced 
   Electronic Signatures - CAdES) [TS101733] and is technically 
   equivalent to it.

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

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] 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-cades-07.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:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-smime-cades-07.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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-smime-cades-07.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-smime-cades-07.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lADIBUdN036585 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 Nov 2007 11:11:30 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lADIBUYd036584; Tue, 13 Nov 2007 11:11:30 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from [10.20.30.150] (adsl-66-125-125-65.dsl.pltn13.pacbell.net [66.125.125.65]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lADIBSCN036575 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 13 Nov 2007 11:11:29 -0700 (MST) (envelope-from [e-mail])
Mime-Version: 1.0
Message-Id: <p06240813c35f9852d8f6@[10.20.30.150]>
In-Reply-To: <000401c8260d$a15fce60$0301a8c0@Wylie>
References: <p06240839c359283193d8@[10.20.30.150]> <000401c8260d$a15fce60$0301a8c0@Wylie>
Date: Tue, 13 Nov 2007 10:11:14 -0800
To: <[e-mail]>
From: Paul Hoffman <[e-mail]>
Subject: Adding modules to draft-hoffman-cms-new-asn1
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 10:55 AM -0500 11/13/07, Turner, Sean P. wrote:
>We should add ASN.1 from RFC3274 - id-compressed-data.

Probably true, and there are a pile of others that might be 
appropriate as well.

One thought is to make this eventual RFC a repository of all 
standards-track CMS and S/MIME modules, even those that don't need to 
be updated for the 2002 syntax. That gives developers a single place 
to go for all ASN.1 modules, and maybe remind them of standards-track 
RFCs that they have forgotten but should pay attention to.

A different thought would be to make it a repository of just the ones 
that need to be updated. In this scenario, we could still have a list 
of CMS and S/MIME modules not included because they didn't need to 
be; that could serve as an equivalent reminder.

How do people here feel about these alternatives?

--Paul Hoffman, Director
--VPN Consortium



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lADFxOWQ022121 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 Nov 2007 08:59:24 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lADFxOvI022120; Tue, 13 Nov 2007 08:59:24 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp105.biz.mail.re2.yahoo.com (smtp105.biz.mail.re2.yahoo.com [206.190.52.174]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id lADFxMgS022108 for <[e-mail]>; Tue, 13 Nov 2007 08:59:22 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 25373 invoked from network); 13 Nov 2007 15:59:06 -0000
Received: from unknown (HELO Wylie) ([e-mail]@70.108.33.165 with login) by smtp105.biz.mail.re2.yahoo.com with SMTP; 13 Nov 2007 15:59:06 -0000
X-YMail-OSG: 31jAUC8VM1lYIi5WgTwYI.8bonFxn2cJSLuQ8N7ad5Loiur43XuEkA6vwTWNAnEmN8E9ji1L2R5k2dkZJJi7YrpCDwNn6_kTg3FrcNwa6xtkFSTrnz6NVEu0.MLZvKYyksAYkgXJSmlnq9w-
From: "Turner, Sean P." <[e-mail]>
To: "'Paul Hoffman'" <[e-mail]>, <[e-mail]>
References: <p06240839c359283193d8@[10.20.30.150]>
Subject: RE: I-D Action:draft-hoffman-cms-new-asn1-00.txt
Date: Tue, 13 Nov 2007 10:55:35 -0500
Organization: IECA, Inc.
Message-ID: <000401c8260d$a15fce60$0301a8c0@Wylie>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
In-Reply-To: <p06240839c359283193d8@[10.20.30.150]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
Thread-Index: AcgiTFZAfGRSfTJbTcK40YgSqWznuwDwR6zw
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

We should add ASN.1 from RFC3274 - id-compressed-data. 

>-----Original Message-----
>From: [e-mail] 
>[mailto:[e-mail]] On Behalf Of Paul Hoffman
>Sent: Thursday, November 08, 2007 3:59 PM
>To: [e-mail]
>Subject: Fwd: I-D Action:draft-hoffman-cms-new-asn1-00.txt
>
>
>Greetings again. Jim Schaad and I have created a draft that 
>contains revised ASN.1 modules for some of the standards-track 
>RFCs for S/MIME. These modules conform to ASN.1 2002. We want 
>to see if people are interested in bringing the S/MIME specs 
>up to the new ASN.1 now that there is an open source, freeware 
>ASN.1 compiler for ASN.1 2002, a2c (see 
><http://code.google.com/p/a2c/>).
>
>This is definitely a first draft. There is a list of issues 
>that we want to address, and we expect more issues to come up 
>in the WG. 
>Please review the draft and let us know what you think. FWIW, 
>there is a parallel draft for PKIX.
>
>>A New Internet-Draft is available from the on-line Internet-Drafts 
>>directories.
>>
>>	Title           : New ASN.1 Modules for CMS and S/MIME
>>	Author(s)       : P. Hoffman, J. Schaad
>>	Filename        : draft-hoffman-cms-new-asn1-00.txt
>>	Pages           : 32
>>	Date            : 2007-11-08
>>
>>The Cryptographic Message Syntax (CMS) format, and many associated 
>>formats, are expressed using ASN.1.  The current ASN.1 
>modules conform 
>>to the 1988 version of ASN.1.  This document updates those
>>ASN.1 modules to conform to the 2002 version of ASN.1.  There are no 
>>bits-on-the-wire changes to any of the formats; this is 
>simply a change 
>>to the syntax.
>>
>>A URL for this Internet-Draft is:
>>http://www.ietf.org/internet-drafts/draft-hoffman-cms-new-asn1-00.txt
>
>--Paul Hoffman, Director
>--VPN Consortium
>



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lA9EfeV3008806 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 Nov 2007 07:41:40 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lA9EfeX5008805; Fri, 9 Nov 2007 07:41:40 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from [10.20.30.150] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lA9EfPHk008778 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 Nov 2007 07:41:26 -0700 (MST) (envelope-from [e-mail])
Mime-Version: 1.0
Message-Id: <p06240803c35a219017ee@[10.20.30.150]>
In-Reply-To: <[e-mail]>
References: <p06240839c359283193d8@[10.20.30.150]> <[e-mail]> <[e-mail]>
Date: Fri, 9 Nov 2007 06:41:16 -0800
To: "Kemp, David P." <[e-mail]>, "Simon Josefsson" <[e-mail]>
From: Paul Hoffman <[e-mail]>
Subject: RE: Fwd: I-D Action:draft-hoffman-cms-new-asn1-00.txt
Cc: <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Wait wait wait!

The S/MIME WG mailing list is *not* the place for the discussion of 
how the IETF and/or GNU process should work; the IPR WG mailing list 
is.

Simon made a request (that we modify the drafts to make him believe 
that he can use the contents there). We are considering doing so. 
However, the "how" part is not for this mailing list.

--Paul Hoffman, Director
--VPN Consortium



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lA9EMr7w006466 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 Nov 2007 07:22:53 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lA9EMrNd006461; Fri, 9 Nov 2007 07:22:53 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lA9EMqHt006436 for <[e-mail]>; Fri, 9 Nov 2007 07:22:52 -0700 (MST) (envelope-from [e-mail])
Received: from Cerberus (cerberus.missi.ncsc.mil [144.51.51.8]) by stingray.missi.ncsc.mil with ESMTP id lA9EMnlM022423 for <[e-mail]>; Fri, 9 Nov 2007 09:22:49 -0500 (EST)
X-AuditID: 90333308-00001f2800000750-a9-47346d39000e
Received: from antigone.missi.ncsc.mil ([144.51.60.33]) by Cerberus with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Nov 2007 09:22:49 -0500
Received: from EXCH.missi.ncsc.mil ([144.51.60.21]) by antigone.missi.ncsc.mil with Microsoft SMTPSVC(6.0.3790.3959); Fri, 9 Nov 2007 09:22:48 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: Fwd: I-D Action:draft-hoffman-cms-new-asn1-00.txt
Date: Fri, 9 Nov 2007 09:22:47 -0500
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Fwd: I-D Action:draft-hoffman-cms-new-asn1-00.txt
Thread-Index: AcgitFssor1bQwnJQiK//+pV6NFO2QAJdt+A
References: <p06240839c359283193d8@[10.20.30.150]> <[e-mail]>
From: "Kemp, David P." <[e-mail]>
To: "Simon Josefsson" <[e-mail]>, "Paul Hoffman" <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 09 Nov 2007 14:22:48.0540 (UTC) FILETIME=[010651C0:01C822DC]
X-Brightmail-Tracker: AAAAAA==
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id lA9EMqHt006451
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Simon,

Perhaps I misunderstand the meaning of [1]:

"Dear Author,

The Debian GNU/Linux distribution wishes to incorporate the
IETF RFC xxxx as part of its distribution, and to allow
users to develop, modify and evolve the document."

but it sounds like a request to keep the name "IETF RFC xxxx"
while modifying the content.  This is, of course, completely
contrary to the IETF configuration management process where
RFCs are an archival document series, and no changes are
permitted once an RFC is issued.

Perhaps Debian should align its process with that of the
IETF, requesting permission to create derivative documents
provided that attribution is maintained, and requiring
that any derivative works DO NOT claim to be IETF RFCs.




-----Original Message-----
From: [e-mail]
[mailto:[e-mail]] On Behalf Of Simon Josefsson
Sent: Friday, November 09, 2007 6:07 AM
To: Paul Hoffman
Cc: [e-mail]
Subject: Re: Fwd: I-D Action:draft-hoffman-cms-new-asn1-00.txt


The initiative seems to be a good idea.

To be able to use these ASN.1 modules in free software, a license to
grant the necessary rights is needed.  (As far as I understand, RFC 3978
is not sufficient, see [1].)  After verifying that the ownership of the
contribution allows it, please consider adding a note (possibly the one
discussed in section 3 of [2]) or somehow release the modules under a
liberal license outside of the IETF process.

Thanks,
Simon

[1] http://wiki.debian.org/NonFreeIETFDocuments

[2] http://tools.ietf.org/html/draft-josefsson-free-standards-howto-01

Paul Hoffman <[e-mail]> writes:

> Greetings again. Jim Schaad and I have created a draft that contains
> revised ASN.1 modules for some of the standards-track RFCs for
> S/MIME. These modules conform to ASN.1 2002. We want to see if people
> are interested in bringing the S/MIME specs up to the new ASN.1 now
> that there is an open source, freeware ASN.1 compiler for ASN.1 2002,
> a2c (see <http://code.google.com/p/a2c/>).
>
> This is definitely a first draft. There is a list of issues that we
> want to address, and we expect more issues to come up in the
> WG. Please review the draft and let us know what you think. FWIW,
> there is a parallel draft for PKIX.
>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>>
>>	Title           : New ASN.1 Modules for CMS and S/MIME
>>	Author(s)       : P. Hoffman, J. Schaad
>>	Filename        : draft-hoffman-cms-new-asn1-00.txt
>>	Pages           : 32
>>	Date            : 2007-11-08
>>
>>The Cryptographic Message Syntax (CMS) format, and many associated
>>formats, are expressed using ASN.1.  The current ASN.1 modules
>>conform to the 1988 version of ASN.1.  This document updates those
>>ASN.1 modules to conform to the 2002 version of ASN.1.  There are no
>>bits-on-the-wire changes to any of the formats; this is simply a
>>change to the syntax.
>>
>>A URL for this Internet-Draft is:
>>http://www.ietf.org/internet-drafts/draft-hoffman-cms-new-asn1-00.txt
>
> --Paul Hoffman, Director
> --VPN Consortium




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lA997UP6080685 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 Nov 2007 02:07:30 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lA997UEc080684; Fri, 9 Nov 2007 02:07:30 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa.extundo.com (yxa.extundo.com [83.241.177.38]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lA997PaJ080673 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Fri, 9 Nov 2007 02:07:29 -0700 (MST) (envelope-from [e-mail])
Received: from mocca.josefsson.org (yxa.extundo.com [83.241.177.38]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id lA997IpD005166 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 Nov 2007 10:07:18 +0100
From: Simon Josefsson <[e-mail]>
To: Paul Hoffman <[e-mail]>
Cc: [e-mail]
Subject: Re: Fwd: I-D Action:draft-hoffman-cms-new-asn1-00.txt
References: <p06240839c359283193d8@[10.20.30.150]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:071109:[e-mail]::VsGF3ScJoGyzLfX4:0k5e
X-Hashcash: 1:22:071109:[e-mail]::0AZIqoZsMao/Vw4o:PHdC
Date: Fri, 09 Nov 2007 12:07:16 +0100
In-Reply-To: <p06240839c359283193d8@[10.20.30.150]> (Paul Hoffman's message of "Thu\, 8 Nov 2007 12\:59\:11 -0800")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110007 (No Gnus v0.7) Emacs/22.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-0.0 required=4.0 tests=SPF_PASS autolearn=disabled  version=3.1.1
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on yxa-iv
X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on yxa.extundo.com
X-Virus-Status: Clean
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The initiative seems to be a good idea.

To be able to use these ASN.1 modules in free software, a license to
grant the necessary rights is needed.  (As far as I understand, RFC 3978
is not sufficient, see [1].)  After verifying that the ownership of the
contribution allows it, please consider adding a note (possibly the one
discussed in section 3 of [2]) or somehow release the modules under a
liberal license outside of the IETF process.

Thanks,
Simon

[1] http://wiki.debian.org/NonFreeIETFDocuments

[2] http://tools.ietf.org/html/draft-josefsson-free-standards-howto-01

Paul Hoffman <[e-mail]> writes:

> Greetings again. Jim Schaad and I have created a draft that contains
> revised ASN.1 modules for some of the standards-track RFCs for
> S/MIME. These modules conform to ASN.1 2002. We want to see if people
> are interested in bringing the S/MIME specs up to the new ASN.1 now
> that there is an open source, freeware ASN.1 compiler for ASN.1 2002,
> a2c (see <http://code.google.com/p/a2c/>).
>
> This is definitely a first draft. There is a list of issues that we
> want to address, and we expect more issues to come up in the
> WG. Please review the draft and let us know what you think. FWIW,
> there is a parallel draft for PKIX.
>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>>
>>	Title           : New ASN.1 Modules for CMS and S/MIME
>>	Author(s)       : P. Hoffman, J. Schaad
>>	Filename        : draft-hoffman-cms-new-asn1-00.txt
>>	Pages           : 32
>>	Date            : 2007-11-08
>>
>>The Cryptographic Message Syntax (CMS) format, and many associated
>>formats, are expressed using ASN.1.  The current ASN.1 modules
>>conform to the 1988 version of ASN.1.  This document updates those
>>ASN.1 modules to conform to the 2002 version of ASN.1.  There are no
>>bits-on-the-wire changes to any of the formats; this is simply a
>>change to the syntax.
>>
>>A URL for this Internet-Draft is:
>>http://www.ietf.org/internet-drafts/draft-hoffman-cms-new-asn1-00.txt
>
> --Paul Hoffman, Director
> --VPN Consortium



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lA92Glm2056323 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Nov 2007 19:16:48 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lA92Gl8n056322; Thu, 8 Nov 2007 19:16:47 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp110.biz.mail.re2.yahoo.com (smtp110.biz.mail.re2.yahoo.com [206.190.53.9]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id lA92Gkvo056305 for <[e-mail]>; Thu, 8 Nov 2007 19:16:46 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 6890 invoked from network); 9 Nov 2007 02:16:45 -0000
Received: from unknown (HELO Wylie) ([e-mail]@70.108.46.209 with login) by smtp110.biz.mail.re2.yahoo.com with SMTP; 9 Nov 2007 02:16:45 -0000
X-YMail-OSG: 7e6mQSUVM1lXxqu2Ef3WS2gDvuqzyEQnn6b2ONh6pheANsHwJGhHx2fpvM93W70.knXQhkjO54EXnYiqrZbNqkLvbzWiNbtoWvM4v9CJSLjQuaMnHA8-
From: "Turner, Sean P." <[e-mail]>
To: "'Paul Hoffman'" <[e-mail]>, <[e-mail]>
References: <p06240839c359283193d8@[10.20.30.150]>
Subject: RE: I-D Action:draft-hoffman-cms-new-asn1-00.txt
Date: Thu, 8 Nov 2007 21:13:33 -0500
Organization: IECA, Inc.
Message-ID: <033f01c82276$21199870$0301a8c0@Wylie>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
Thread-Index: AcgiTFZAfGRSfTJbTcK40YgSqWznuwAKcVZg
In-Reply-To: <p06240839c359283193d8@[10.20.30.150]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I am interested in moving the specs up to the later ASN.1 version.

spt  

>-----Original Message-----
>From: [e-mail] 
>[mailto:[e-mail]] On Behalf Of Paul Hoffman
>Sent: Thursday, November 08, 2007 3:59 PM
>To: [e-mail]
>Subject: Fwd: I-D Action:draft-hoffman-cms-new-asn1-00.txt
>
>
>Greetings again. Jim Schaad and I have created a draft that 
>contains revised ASN.1 modules for some of the standards-track 
>RFCs for S/MIME. These modules conform to ASN.1 2002. We want 
>to see if people are interested in bringing the S/MIME specs 
>up to the new ASN.1 now that there is an open source, freeware 
>ASN.1 compiler for ASN.1 2002, a2c (see 
><http://code.google.com/p/a2c/>).
>
>This is definitely a first draft. There is a list of issues 
>that we want to address, and we expect more issues to come up 
>in the WG. 
>Please review the draft and let us know what you think. FWIW, 
>there is a parallel draft for PKIX.
>
>>A New Internet-Draft is available from the on-line Internet-Drafts 
>>directories.
>>
>>	Title           : New ASN.1 Modules for CMS and S/MIME
>>	Author(s)       : P. Hoffman, J. Schaad
>>	Filename        : draft-hoffman-cms-new-asn1-00.txt
>>	Pages           : 32
>>	Date            : 2007-11-08
>>
>>The Cryptographic Message Syntax (CMS) format, and many associated 
>>formats, are expressed using ASN.1.  The current ASN.1 
>modules conform 
>>to the 1988 version of ASN.1.  This document updates those
>>ASN.1 modules to conform to the 2002 version of ASN.1.  There are no 
>>bits-on-the-wire changes to any of the formats; this is 
>simply a change 
>>to the syntax.
>>
>>A URL for this Internet-Draft is:
>>http://www.ietf.org/internet-drafts/draft-hoffman-cms-new-asn1-00.txt
>
>--Paul Hoffman, Director
>--VPN Consortium
>



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lA8MF7jQ042011 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Nov 2007 15:15:07 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lA8MF7S8042009; Thu, 8 Nov 2007 15:15:07 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ns4.neustar.com (ns4.neustar.com [156.154.24.139]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lA8MF2Ds041964 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Thu, 8 Nov 2007 15:15:07 -0700 (MST) (envelope-from [e-mail])
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 35BA42AC7F; Thu,  8 Nov 2007 22:15:02 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IqFeP-0005xv-Oq; Thu, 08 Nov 2007 17:15:01 -0500
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-smime-bfibecms-08.txt 
Message-Id: <[e-mail]>
Date: Thu, 08 Nov 2007 17:15:01 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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		: Using the Boneh-Franklin and Boneh-Boyen 
                          identity-based encryption algorithms with the 
                          Cryptographic Message Syntax (CMS)
	Author(s)	: L. Martin, M. Schertler
	Filename	: draft-ietf-smime-bfibecms-08.txt
	Pages		: 16
	Date		: 2007-11-8
	
This document describes the conventions for using the Boneh-
        Franklin (BF) and Boneh-Boyen (BB1) identity-based 
        encryption algorithms in the Cryptographic Message Syntax 
        (CMS) to encrypt content-encryption keys. Object identifiers 
        and the convention for encoding a recipient's identity are 
        also defined.

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

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] 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-bfibecms-08.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:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-smime-bfibecms-08.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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-smime-bfibecms-08.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-smime-bfibecms-08.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lA8MF5Ot041993 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Nov 2007 15:15:05 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lA8MF5jS041992; Thu, 8 Nov 2007 15:15:05 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ns0.neustar.com (ns0.neustar.com [156.154.16.158]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lA8MF2NY041963 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Thu, 8 Nov 2007 15:15:05 -0700 (MST) (envelope-from [e-mail])
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id BA814328B9; Thu,  8 Nov 2007 22:15:01 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IqFeP-0005xY-JE; Thu, 08 Nov 2007 17:15:01 -0500
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-smime-3850bis-00.txt 
Message-Id: <[e-mail]>
Date: Thu, 08 Nov 2007 17:15:01 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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		: Secure/Multipurpose Internet Mail Extensions 
                          (S/MIME) Version 3.2 Certificate Handling 
	Author(s)	: S. Turner, B. Ramsdell
	Filename	: draft-ietf-smime-3850bis-00.txt
	Pages		: 18
	Date		: 2007-11-8
	
   This document specifies conventions for X.509 certificate usage by 
   Secure/Multipurpose Internet Mail Extensions (S/MIME) agents.  S/MIME 
   provides a method to send and receive secure MIME messages, and 
   certificates are an integral part of S/MIME agent processing.  S/MIME 
   agents validate certificates as described in RFC 3280bis, the 
   Internet X.509 Public Key Infrastructure Certificate and CRL Profile.  
   S/MIME agents must meet the certificate processing requirements in 
   this document as well as those in RFC 3280bis. This document 
   obsoletes RFC 3850. 

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

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] 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-3850bis-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:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-smime-3850bis-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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-smime-3850bis-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-smime-3850bis-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lA8MF30E041981 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Nov 2007 15:15:03 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lA8MF3Tn041977; Thu, 8 Nov 2007 15:15:03 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ns1.neustar.com (ns1.neustar.com [156.154.16.138]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lA8MF2lO041966 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Thu, 8 Nov 2007 15:15:03 -0700 (MST) (envelope-from [e-mail])
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 0874226E65; Thu,  8 Nov 2007 22:15:02 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IqFeP-0005y1-QR; Thu, 08 Nov 2007 17:15:01 -0500
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-smime-ibearch-06.txt 
Message-Id: <[e-mail]>
Date: Thu, 08 Nov 2007 17:15:01 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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		: Identity-based Encryption Architecture
	Author(s)	: M. Schertler, et al.
	Filename	: draft-ietf-smime-ibearch-06.txt
	Pages		: 28
	Date		: 2007-11-8
	
This document describes the security architecture required 
     to implement identity-based encryption, a public-key 
     encryption technology that uses a user's identity as a 
     public key.

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

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] 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-ibearch-06.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:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-smime-ibearch-06.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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-smime-ibearch-06.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-smime-ibearch-06.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lA8MF3D9041980 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Nov 2007 15:15:03 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lA8MF3in041978; Thu, 8 Nov 2007 15:15:03 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ns1.neustar.com (ns1.neustar.com [156.154.16.138]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lA8MF26s041962 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Thu, 8 Nov 2007 15:15:03 -0700 (MST) (envelope-from [e-mail])
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id B7A5A26E3D; Thu,  8 Nov 2007 22:15:01 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IqFeP-0005xb-Jx; Thu, 08 Nov 2007 17:15:01 -0500
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-smime-3851bis-00.txt 
Message-Id: <[e-mail]>
Date: Thu, 08 Nov 2007 17:15:01 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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		: Secure/Multipurpose Internet Mail Extensions 
                          (S/MIME) Version 3.2 Message Specification 
	Author(s)	: B. Ramsdell, S. Turner
	Filename	: draft-ietf-smime-3851bis-00.txt
	Pages		: 39
	Date		: 2007-11-8
	
   This document defines Secure/Multipurpose Internet Mail Extensions 
   (S/MIME) version 3.2.  S/MIME provides a consistent way to send and 
   receive secure MIME data.  Digital signatures provide authentication, 
   message integrity, and non-repudiation with proof of origin. 
   Encryption provides data confidentiality.  Compression can be used to 
   reduce data size.  This document obsoletes RFC 3851.

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

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] 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-3851bis-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:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-smime-3851bis-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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-smime-3851bis-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-smime-3851bis-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lA8L0CYk037340 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Nov 2007 14:00:12 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lA8L0C1E037339; Thu, 8 Nov 2007 14:00:12 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from [10.20.30.150] (adsl-66-125-125-65.dsl.pltn13.pacbell.net [66.125.125.65]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lA8L09Vr037333 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Thu, 8 Nov 2007 14:00:11 -0700 (MST) (envelope-from [e-mail])
Mime-Version: 1.0
Message-Id: <p06240839c359283193d8@[10.20.30.150]>
Date: Thu, 8 Nov 2007 12:59:11 -0800
To: [e-mail]
From: Paul Hoffman <[e-mail]>
Subject: Fwd: I-D Action:draft-hoffman-cms-new-asn1-00.txt
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Greetings again. Jim Schaad and I have created a draft that contains 
revised ASN.1 modules for some of the standards-track RFCs for 
S/MIME. These modules conform to ASN.1 2002. We want to see if people 
are interested in bringing the S/MIME specs up to the new ASN.1 now 
that there is an open source, freeware ASN.1 compiler for ASN.1 2002, 
a2c (see <http://code.google.com/p/a2c/>).

This is definitely a first draft. There is a list of issues that we 
want to address, and we expect more issues to come up in the WG. 
Please review the draft and let us know what you think. FWIW, there 
is a parallel draft for PKIX.

>A New Internet-Draft is available from the on-line Internet-Drafts 
>directories.
>
>	Title           : New ASN.1 Modules for CMS and S/MIME
>	Author(s)       : P. Hoffman, J. Schaad
>	Filename        : draft-hoffman-cms-new-asn1-00.txt
>	Pages           : 32
>	Date            : 2007-11-08
>
>The Cryptographic Message Syntax (CMS) format, and many associated
>formats, are expressed using ASN.1.  The current ASN.1 modules
>conform to the 1988 version of ASN.1.  This document updates those
>ASN.1 modules to conform to the 2002 version of ASN.1.  There are no
>bits-on-the-wire changes to any of the formats; this is simply a
>change to the syntax.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-hoffman-cms-new-asn1-00.txt

--Paul Hoffman, Director
--VPN Consortium



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lA5IDBsp071364 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 Nov 2007 11:13:11 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lA5IDBVv071363; Mon, 5 Nov 2007 11:13:11 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp110.biz.mail.re2.yahoo.com (smtp110.biz.mail.re2.yahoo.com [206.190.53.9]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id lA5ID92N071345 for <[e-mail]>; Mon, 5 Nov 2007 11:13:10 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 17633 invoked from network); 5 Nov 2007 18:13:09 -0000
Received: from unknown (HELO Wylie) ([e-mail]@70.108.21.222 with login) by smtp110.biz.mail.re2.yahoo.com with SMTP; 5 Nov 2007 18:13:08 -0000
X-YMail-OSG: wFcSkAsVM1nr.ODoI_EWlh3NN.0Bw7BqYdt9h3Q1Imx11SzuZOQn4xgMhjHfXCf7galxIuVMZA--
From: "Turner, Sean P." <[e-mail]>
To: <[e-mail]>
Subject: Agenda Topics
Date: Mon, 5 Nov 2007 13:10:01 -0500
Organization: IECA, Inc.
Message-ID: <00e201c81fd7$1544a8b0$0301a8c0@Wylie>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_00E3_01C81FAD.2C6EA0B0"
X-Mailer: Microsoft Office Outlook 11
Thread-Index: Acgf1xTNPhGSy2pJRP+lGTf4ae3+Ew==
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_00E3_01C81FAD.2C6EA0B0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

If anyone is interested in getting some time on the agenda please send Blake
or myself a note.

Cheers,

spt

------=_NextPart_000_00E3_01C81FAD.2C6EA0B0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7036.0">
<TITLE>Agenda Topics</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->

<P><FONT SIZE=3D2 FACE=3D"Arial">If anyone is interested in getting some =
time on the agenda please send Blake or myself a note.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Cheers,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">spt</FONT>
</P>

</BODY>
</HTML>
------=_NextPart_000_00E3_01C81FAD.2C6EA0B0--