Subject: Girls will love this Tag Heuer watch

From: "Catalina Winkler" <[email-masked]>
Date: Sat, 28 Feb 2009 06:07:55 -0800

Why waste your hard-earned money on an expensive watch when you can have the next best thing for a tenth of its price?
http://iffiwwp.cn

At Exquisite Reps you will find exactly the watch you're looking for, at prices that will make you blink twice. That's right! Here you can get a Rolex, a Breitling, a Tag or pretty much every fine brand timepiece for less than ten percent their original price!
http://iffiwwp.cn

Only Exquisite Reps offers you unsurpassed quality and award-winning customer service. So, what are you waiting for?

From: The IESG <[email-masked]>
To: IETF-Announce <[email-masked]>
Cc: Internet Architecture Board <[email-masked]>, RFC Editor <[email-masked]>, smime mailing list <[email-masked]>, smime chair <[email-masked]>
Subject: Protocol Action: 'Using SHA2 Algorithms with  Cryptographic Message Syntax' to Proposed Standard 
Date: Thu, 19 Feb 2009 06:37:34 -0800 (PST)
Sender: [email-masked]

The IESG has approved the following document:

- 'Using SHA2 Algorithms with Cryptographic Message Syntax '
   <draft-ietf-smime-sha2-11.txt> as a Proposed Standard

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

The IESG contact persons are Tim Polk and Pasi Eronen.

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

Technical Summary

This ID contains algorithm identifiers for use with CMS. It includes
the OIDs for the following digest algorithms: SHA-224, SHA-256, SHA-384,
and SHA-512.  It also includes the OIDs for the following signature
algorithms: DSA with SHA-224 and SHA-256; RSA with SHA-224, SHA-256,
SHA-384, and SHA-512; RSA-KEM; ECDSA with SHA-224, SHA-256, SHA-384,
and SHA-512.

Working Group Summary

This ID was lightly discussed on the mailing list. It basically just
lists OIDs so there's not much to discuss.

Document Quality

Some of the OIDs in this ID have been implemented by many. Some of the
other OIDs are included for completeness.

Personnel

Blake Ramsdell is the document Shepherd.  Tim Polk is the responsible
Security Area AD.

RFC Editor Note

Please make the following substitution in section 2.1:

OLD
   The parameters are as specified in Section 2. 
NEW
   The parameters are as specified in the beginning of Section 2.

From: "Anders Rundgren" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: Invention Disclosure: Attested Key-Pair Generation with "Key Escrow"
Date: Sun, 15 Feb 2009 08:57:10 +0100
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0098_01C98F4B.633581E0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

The following public posting is intended to function as a record of an =
invention disclosure where the inventor gives up any IPR claims as well =
as hoping that the described invention is not already filed as a patent =
application.

A PDF version is currently available at:
http://webpki.org/papers/keygen2/keygen2-key-escrow.pdf

Attested Key-Pair Generation with Key "Escrow"

Occasionally credential issuers want (or require) that encryption =
private keys are backuped in order to be able to restore data (AKA "key =
escrow") in case an encryption-key is lost or is replaced.

This document shows how KeyGen2's key-attestation scheme has been =
augmented by an end-to-end-secured escrow mechanism as well. The concept =
is as follows: An issuer sends a key-generation request to a client =
presumably having an SE (Security Element) for keeping user-keys in. The =
SE responds with attested public keys where each attest consists of a =
signature over the generated public key, key-usage, key-exportability, =
and a nonce, using an embedded SE device-key as an attestation signature =
key.

By also including a key-escrow public key (supplied by the issuer during =
the request), in the attest signature hash, the issuer gets a =
cryptographically strong evidence enabling it to detect if something in =
the transport layer or in the SE middleware temporarily swapped the =
escrow-key in order to steal the private key and then changed it back to =
cover-up the operation.

A prerequisite for this to be trustworthy is that the entire operation =
(key-pair generation, private-key escrow-key encryption, and device-key =
attest-signing) is carried out inside of the SE in a fully atomic =
fashion. In addition to successful signature validation, the issuer (of =
course) also has to recognize and trust the SE device type identified by =
the public key certificate received in the response.

For details on the original key-attestation scheme see:
http://webpki.org/papers/keygen2/keygen2-fips140-2.pdf

Note that although the referred document exploits KeyGen2's DIAS (Device =
Internal Attestation Signature) single device-key scheme, the core =
principle is equally applicable to designs relying on separate =
device-keys for attestations, authentications, and encryptions performed =
by an SE.

Request Phase

The following is a slightly simplified version of a KeyGen2 key =
generation request where the issuer asks for two keys; an encryption key =
with escrow and an authentication without escrow (actually KeyGen2 only =
allows escrow for encryption keys).

<KeyOperationRequest ... >
  <CreateObject>

    <KeyPair ID=3D"Key.1" KeyUsage=3D"encryption">
      <RSA KeySize=3D"2048"/>
      <EscrowKey>
        <ds:X509Data>
          <ds:X509Certificate>MIIB2 ... FLlck8SX</ds:X509Certificate>
        </ds:X509Data>
      </EscrowKey>
    </KeyPair>

    <KeyPair ID=3D"Key.2" KeyUsage=3D"authentication">
      <RSA KeySize=3D"2048"/>
    </KeyPair>

  </CreateObject>
</KeyOperationRequest>

Response Phase

Below is a condensed version of the anticipated KeyGen2 response. The =
only thing that differs from a regular KeyGen2 response is the element =
EncryptedPrivateKey which contains a copy of the generated private key =
in PKCS #8 PrivateKeyInfo format, wrapped by a 128-bit random AES key, =
which in turn is wrapped by the issuer-supplied escrow public key.  The =
EndorsementKey contains the device public key as well as an enveloped =
signature over the entire response.

<KeyOperationResponse ...  >

  <GeneratedPublicKey ID=3D"Key.1" KeyAttestation=3D"H8USg ... =
ZixaYVw=3D=3D">
    <ds:KeyInfo>
      <ds:KeyValue>
        <ds:RSAKeyValue>
          <ds:Modulus>AKu4uVZ8 ... 4mjS422CqxwAt</ds:Modulus>
          <ds:Exponent>AQAB</ds:Exponent>
        </ds:RSAKeyValue>
      </ds:KeyValue>
    </ds:KeyInfo>
    <EncryptedPrivateKey =
Format=3D"http://xmlns.webpki.org/keygen2/1.0#format.pkcs8">
      <xenc:EncryptedKey>
        <xenc:EncryptionMethod =
Algorithm=3D"http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>
        <ds:KeyInfo>
          <ds:KeyName>Key.1.Private</ds:KeyName>
        </ds:KeyInfo>
        <xenc:CipherData>
          <xenc:CipherValue>mWi94IJ ... Xk/HbWM2o=3D</xenc:CipherValue>
        </xenc:CipherData>
      </xenc:EncryptedKey>
      <xenc:EncryptedKey>
        <xenc:EncryptionMethod =
Algorithm=3D"http://www.w3.org/2001/04/xmlenc#rsa-1_5"/>
        <xenc:CipherData>
          <xenc:CipherValue>RbDx5WbN ... =
D3GjL7qIhD59s=3D</xenc:CipherValue>
        </xenc:CipherData>
        <xenc:CarriedKeyName>Key.1.Private</xenc:CarriedKeyName>
      </xenc:EncryptedKey>
    </EncryptedPrivateKey>
  </GeneratedPublicKey>

  <GeneratedPublicKey ID=3D"Key.2" KeyAttestation=3D"k6QN ... =
dUpyTA=3D=3D">
    <ds:KeyInfo>
      <ds:KeyValue>
        <ds:RSAKeyValue>
          <ds:Modulus>AIOwQTj ... Dfi2WeJLQ2k=3D</ds:Modulus>
          <ds:Exponent>AQAB</ds:Exponent>
        </ds:RSAKeyValue>
      </ds:KeyValue>
    </ds:KeyInfo>
  </GeneratedPublicKey>

  <EndorsementKey =
KeyAttestationAlgorithm=3D"http://xmlns.webpki.org/keygen2/1.0#algorithm.=
key-attestation-1">
    <ds:Signature>
          .
          .
    </ds:Signature>
  </EndorsementKey>

</KeyOperationResponse

Anders Rundgren

------=_NextPart_000_0098_01C98F4B.633581E0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.6000.20996" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>The following public posting is =
intended to=20
function as a record of an invention disclosure where the inventor gives =

up&nbsp;any IPR claims as well as hoping that the described invention is =
not=20
already filed as a patent application.<BR><BR>A PDF version is currently =

available at:<BR></FONT><A=20
href=3D"http://webpki.org/papers/keygen2/keygen2-key-escrow.pdf"><FONT =
face=3DArial=20
size=3D2>http://webpki.org/papers/keygen2/keygen2-key-escrow.pdf</FONT></=
A><BR><BR><BR><FONT=20
face=3DArial size=3D2><FONT size=3D3>Attested Key-Pair Generation with =
Key=20
"Escrow"<BR></FONT><BR>Occasionally credential issuers want (or require) =
that=20
encryption private keys are backuped in order to be able to restore data =
(AKA=20
"key escrow") in case an encryption-key is lost or is =
replaced.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>This document shows how KeyGen2's =
key-attestation=20
scheme has been augmented&nbsp;by an end-to-end-secured escrow mechanism =
as=20
well. The concept is as follows: An issuer sends a key-generation =
request to a=20
client presumably having an SE (Security Element) for keeping user-keys =
in. The=20
SE responds with attested public keys where each attest consists of a =
signature=20
over the <EM>generated public key</EM>, <EM>key-usage</EM>,=20
<EM>key-exportability</EM>, and a <EM>nonce</EM>, using an embedded SE=20
device-key as an attestation signature key.<BR><BR>By also including a=20
key-escrow public key (supplied by the issuer during the request), in =
the attest=20
signature hash, the issuer gets a cryptographically strong evidence =
enabling it=20
to detect if something in the transport layer or in the SE middleware=20
temporarily swapped the escrow-key in order to steal the private key and =
then=20
changed it back to cover-up the operation.<BR><BR>A prerequisite for =
this to be=20
trustworthy is that the entire operation (<EM>key-pair generation</EM>,=20
<EM>private-key escrow-key encryption</EM>, and <EM>device-key=20
attest-signing</EM>) is carried out inside of the SE <EM>in a fully =
atomic=20
fashion</EM>. In addition to successful signature validation, the issuer =
(of=20
course) also has to recognize and trust the SE <EM>device=20
type</EM>&nbsp;identified by&nbsp;the public key certificate received in =
the=20
response.<BR><BR>For details on the original key-attestation scheme=20
see:<BR></FONT><A=20
href=3D"http://webpki.org/papers/keygen2/keygen2-fips140-2.pdf"><FONT =
face=3DArial=20
size=3D2>http://webpki.org/papers/keygen2/keygen2-fips140-2.pdf</FONT></A=
><BR></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Note that although the referred =
document exploits=20
KeyGen2's DIAS (Device Internal Attestation Signature) single device-key =
scheme,=20
the core principle is equally applicable to designs relying on separate=20
device-keys for attestations, authentications, and encryptions performed =
by an=20
SE.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT><FONT face=3DArial =
size=3D2></FONT><BR><FONT=20
face=3DArial size=3D2><STRONG>Request Phase<BR></STRONG><BR>The =
following is a=20
slightly simplified version of a KeyGen2 key generation request where =
the issuer=20
asks for two keys;&nbsp;an encryption key with escrow and an =
authentication=20
without escrow (actually KeyGen2 only allows escrow for encryption=20
keys).<BR><BR><FONT face=3D"Courier New">&lt;KeyOperationRequest ...=20
&gt;<BR>&nbsp; &lt;CreateObject&gt;<BR><BR>&nbsp;&nbsp;&nbsp; =
&lt;KeyPair=20
ID=3D"Key.1" =
KeyUsage=3D"encryption"&gt;<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;RSA=20
KeySize=3D"2048"/&gt;<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
&lt;EscrowKey&gt;<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
&lt;ds:X509Data&gt;<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;=20
&lt;ds:X509Certificate&gt;MIIB2 ...=20
FLlck8SX&lt;/ds:X509Certificate&gt;<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;=20
&lt;/ds:X509Data&gt;<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
&lt;/EscrowKey&gt;<BR>&nbsp;&nbsp;&nbsp;&nbsp;&lt;/KeyPair&gt;<BR><BR>&nb=
sp;&nbsp;&nbsp;=20
&lt;KeyPair ID=3D"Key.2"=20
KeyUsage=3D"authentication"&gt;<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&lt;RSA=20
KeySize=3D"2048"/&gt;<BR>&nbsp;&nbsp;&nbsp; =
&lt;/KeyPair&gt;<BR><BR>&nbsp;=20
&lt;/CreateObject&gt;<BR>&lt;/KeyOperationRequest&gt;<BR></FONT><BR><STRO=
NG>Response=20
Phase<BR></STRONG><BR>Below is a condensed version of the anticipated =
KeyGen2=20
response. The only thing that differs from&nbsp;a regular KeyGen2 =
response is=20
the element <FONT face=3D"Courier New">EncryptedPrivateKey</FONT> which =
contains a=20
copy of the generated private key in PKCS #8 PrivateKeyInfo format, =
wrapped by a=20
128-bit random AES key, which in turn is wrapped by the issuer-supplied =
escrow=20
public key.&nbsp; The <FONT face=3D"Courier New">EndorsementKey</FONT> =
contains=20
the device public key as well as an enveloped signature over the entire=20
response.<BR><BR><FONT face=3D"Courier New">&lt;KeyOperationResponse =
...&nbsp;=20
&gt;<BR><BR>&nbsp; &lt;GeneratedPublicKey ID=3D"Key.1" =
KeyAttestation=3D"H8USg ...=20
ZixaYVw=3D=3D"&gt;<BR>&nbsp;&nbsp;&nbsp;=20
&lt;ds:KeyInfo&gt;<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
&lt;ds:KeyValue&gt;<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
&lt;ds:RSAKeyValue&gt;<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;=20
&lt;ds:Modulus&gt;AKu4uVZ8 ...=20
4mjS422CqxwAt&lt;/ds:Modulus&gt;<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;=20
&lt;ds:Exponent&gt;AQAB&lt;/ds:Exponent&gt;<BR>&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;=20
&lt;/ds:RSAKeyValue&gt;<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
&lt;/ds:KeyValue&gt;<BR>&nbsp;&nbsp;&nbsp;=20
&lt;/ds:KeyInfo&gt;<BR>&nbsp;&nbsp;&nbsp; &lt;EncryptedPrivateKey=20
Format=3D"</FONT></FONT><A=20
href=3D"http://xmlns.webpki.org/keygen2/1.0#format.pkcs8"><FONT =
face=3D"Courier New"=20
size=3D2>http://xmlns.webpki.org/keygen2/1.0#format.pkcs8</FONT></A><FONT=
=20
face=3D"Courier New" size=3D2>"&gt;<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
&lt;xenc:EncryptedKey&gt;<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
&lt;xenc:EncryptionMethod Algorithm=3D"</FONT><A=20
href=3D'http://www.w3.org/2001/04/xmlenc#aes128-cbc"/'><FONT =
face=3D"Courier New"=20
size=3D2>http://www.w3.org/2001/04/xmlenc#aes128-cbc"/</FONT></A><FONT=20
face=3D"Courier New" =
size=3D2>&gt;<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
&lt;ds:KeyInfo&gt;<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;=20
&lt;ds:KeyName&gt;Key.1.Private&lt;/ds:KeyName&gt;<BR>&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;=20
&lt;/ds:KeyInfo&gt;<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
&lt;xenc:CipherData&gt;<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&lt;xenc:CipherValue&gt;mWi94IJ=20
...=20
Xk/HbWM2o=3D&lt;/xenc:CipherValue&gt;<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&lt;/xenc:CipherData&gt;<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&lt;/xenc:EncryptedKey&gt;<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&lt;xenc:EncryptedKey&gt;<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
&lt;xenc:EncryptionMethod Algorithm=3D"</FONT><A=20
href=3D'http://www.w3.org/2001/04/xmlenc#rsa-1_5"/'><FONT =
face=3D"Courier New"=20
size=3D2>http://www.w3.org/2001/04/xmlenc#rsa-1_5"/</FONT></A><FONT=20
face=3D"Courier New" =
size=3D2>&gt;<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
&lt;xenc:CipherData&gt;<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;=20
&lt;xenc:CipherValue&gt;RbDx5WbN ...=20
D3GjL7qIhD59s=3D&lt;/xenc:CipherValue&gt;<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;=20
&lt;/xenc:CipherData&gt;<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
&lt;xenc:CarriedKeyName&gt;Key.1.Private&lt;/xenc:CarriedKeyName&gt;<BR>&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
&lt;/xenc:EncryptedKey&gt;<BR>&nbsp;&nbsp;&nbsp;&nbsp;&lt;/EncryptedPriva=
teKey&gt;<BR>&nbsp;&nbsp;&lt;/GeneratedPublicKey&gt;<BR><BR>&nbsp;=20
&lt;GeneratedPublicKey ID=3D"Key.2" KeyAttestation=3D"k6QN ...=20
dUpyTA=3D=3D"&gt;<BR>&nbsp;&nbsp;&nbsp;=20
&lt;ds:KeyInfo&gt;<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
&lt;ds:KeyValue&gt;<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
&lt;ds:RSAKeyValue&gt;<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;=20
&lt;ds:Modulus&gt;AIOwQTj ...=20
Dfi2WeJLQ2k=3D&lt;/ds:Modulus&gt;<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;=20
&lt;ds:Exponent&gt;AQAB&lt;/ds:Exponent&gt;<BR>&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;=20
&lt;/ds:RSAKeyValue&gt;<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
&lt;/ds:KeyValue&gt;<BR>&nbsp;&nbsp;&nbsp;&nbsp;&lt;/ds:KeyInfo&gt;<BR>&n=
bsp;=20
&lt;/GeneratedPublicKey&gt;<BR><BR>&nbsp; &lt;EndorsementKey=20
KeyAttestationAlgorithm=3D"</FONT><A=20
href=3D"http://xmlns.webpki.org/keygen2/1.0#algorithm.key-attestation-1">=
<FONT=20
face=3D"Courier New"=20
size=3D2>http://xmlns.webpki.org/keygen2/1.0#algorithm.key-attestation-1<=
/FONT></A><FONT=20
face=3DArial size=3D2><FONT face=3D"Courier =
New">"&gt;<BR>&nbsp;&nbsp;&nbsp;=20
&lt;ds:Signature&gt;<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;=20
.<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
.<BR>&nbsp;&nbsp;&nbsp; &lt;/ds:Signature&gt;<BR>&nbsp;=20
&lt;/EndorsementKey&gt;<BR></FONT></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><FONT=20
face=3D"Courier =
New">&lt;/KeyOperationResponse<BR></FONT><BR></DIV></FONT>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Anders =
Rundgren<BR></DIV></FONT></BODY></HTML>

------=_NextPart_000_0098_01C98F4B.633581E0--

Date: Thu, 12 Feb 2009 11:58:37 -0500
From: Sean Turner <[email-masked]>
To: [email-masked]
Subject: Re: WG Last Call: draft-ietf-smime-new-asn1-02
Sender: [email-masked]

This WG LC has closed, comments were received, and a new version will be 
posted prior to it being forwarded to the Security AD.

spt

Blake Ramsdell wrote:
> This message initiates an SMIME Working Group Last Call on the document:
> 
> 	Title           : New ASN.1 Modules for CMS and S/MIME
> 	Author(s)       : P. Hoffman, J. Schaad
> 	Filename        : draft-ietf-smime-new-asn1-02.txt
> 	Pages           : 61
> 	Date            : 2009-01-09
> 
> 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-ietf-smime-new-asn1-02.txt
> 
> The purpose of this WG Last Call is to ensure that the Working Group has
> achieved consensus that the document is suitable for publication as a
> Standards Track RFC.
> 
> Please review the document for both technical and editorial problems.
> Technical issues should be discussed on this list. Editorial issues may be
> sent to the document editor.
> 
> The Last Call period will end on 30 January 2009.
> 
> Upon completion of the last call, the WG chairs will take action based upon
> the consensus of the WG. Possible actions include:
> 
>     1) recommending to the IETF Security Area Directors
>        that the document, after possible editorial or
>        other minor changes, be considered by the IESG
>        for publication as an Informational RFC
>        (which generally involves an IETF-wide Last Call); or
> 
>     2) requiring that outstanding issues be adequately
>        addressed prior to further action (including,
>        possibly, another WG Last Call).
> 
> Remember that it is our responsibility as Working Group members to ensure
> the quality of our documents and of the Internet Standards process.  So,
> please read and comment!
> 
> Blake

Date: Thu, 12 Feb 2009 16:34:56 +0000
From: Dr Stephen Henson <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: Re: RFC 3274 - Compressed Data Content Type for Cryptographic Message Syntax (CMS)
Sender: [email-masked]

Timothy J. Miller wrote:
> 
> You know, I asked that very same questions a couple of months ago with
> no response, and I never found any *client* that did other than yours.
> Certainly the top tier mail clients do not.
> 

I tested a couple of well known clients and not only did they not support it
they gave misleading error messages.

I'd expect something like "unsupported content type" instead one said it
couldn't find the correct private key the other said it had an unexpected
problem and I should check for low memory or disk space.

Steve.
-- 
Dr Stephen N. Henson.
Core developer of the   OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: [email-masked], PGP key: via homepage.

Date: Thu, 12 Feb 2009 07:54:37 -0600
From: "Timothy J. Miller" <[email-masked]>
To: Peter Gutmann <[email-masked]>
CC: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: RFC 3274 - Compressed Data Content Type for Cryptographic Message Syntax (CMS)
Sender: [email-masked]

--------------ms050806060201070700040306
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Peter Gutmann wrote:

> One strong driving force for this was people doing secure messaging (EDI and
> the like), so you're more likely to find it being used at that level rather
> than with MTAs.

True, but as DoD policy shifts toward "Thou shalt encrypt email with the 
following types of information contained therein," we keep hearing 
complaints about increased bandwidth consumption.

To which my best answer is "Thou shalt not use email as a file transfer 
protocol," but obviously that's not gaining any traction.  :)

Automated compress-before-encrypt in a couple of common MUAs would at 
least make salving the worried planners easier.

-- Tim

--------------ms050806060201070700040306
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms050806060201070700040306--

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: RFC 3274 - Compressed Data Content Type for Cryptographic Message Syntax (CMS)
Cc: [email-masked]
Date: Thu, 12 Feb 2009 21:48:23 +1300
Sender: [email-masked]

"Timothy J. Miller" <[email-masked]> writes:

>You know, I asked that very same questions a couple of months ago with 
>no response, and I never found any *client* that did other than yours. 
>Certainly the top tier mail clients do not.

One strong driving force for this was people doing secure messaging (EDI and
the like), so you're more likely to find it being used at that level rather
than with MTAs.

Peter.

Date: Wed, 11 Feb 2009 15:46:04 -0500
From: Sean Turner <[email-masked]>
To: [email-masked]
Subject: CMS Questionnaire
Sender: [email-masked]

This is a multi-part message in MIME format.
--------------020900050504070308010102
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

I'd like to thank those who have responded and remind others that 
haven't about the questionnaire.

spt

-------- Original Message --------
Subject: CMS Questionnaire
Date: Mon, 26 Jan 2009 15:48:47 -0500
From: Sean Turner <[email-masked]>
To: [email-masked]

Russ and Tim have challenged me to try to advance CMS to Draft Standard
using the process in BCP 97 to deal with the dependencies that have not
yet advanced (or aren't advancing).  To that end, I've drawn up the
following questionnaire that I'd like implementers to complete and
return to me.  What we're shooting for is to find two implementations
that generate messages for each feature, and two implementations that
process each feature.  We don't think it should matter if the same two
implementations are used in both stages.

Thanks in advance,

spt

--------------020900050504070308010102
Content-Type: text/plain;
 name="cms-questionnaire.txt"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
 filename="cms-questionnaire.txt"

--------------020900050504070308010102--

Date: Wed, 11 Feb 2009 08:12:21 -0600
From: "Timothy J. Miller" <[email-masked]>
To: Maxim Masiutin <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Subject: Re: RFC 3274 - Compressed Data Content Type for Cryptographic Message Syntax (CMS)
Sender: [email-masked]

--------------ms000004050903090801070900
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Maxim Masiutin wrote:

>   Do you know any S/MIME implementation that supports RFC 3274? I would like to test the interoperability of our software (The Bat!) with other software. When RFC 3274, our software was the only to support RFC 3274, so we didn't have anything else to test with, but maybe now the situation have changed?

You know, I asked that very same questions a couple of months ago with 
no response, and I never found any *client* that did other than yours. 
Certainly the top tier mail clients do not.

Some S/MIME frameworks may, but I didn't dig down that far (I was 
looking for capabilities to measure, not compatibility).

-- Tim

--------------ms000004050903090801070900
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms000004050903090801070900--

Date: Wed, 11 Feb 2009 12:14:14 +0000
From: Dr Stephen Henson <[email-masked]>
To: Maxim Masiutin <[email-masked]>
CC: [email-masked]
Subject: Re: RFC 3274 - Compressed Data Content Type for Cryptographic Message Syntax (CMS)
Sender: [email-masked]

Maxim Masiutin wrote:
> Hello All,
> 
>   Do you know any S/MIME implementation that supports RFC 3274? I would like to test the interoperability of our software (The Bat!) with other software. When RFC 3274, our software was the only to support RFC 3274, so we didn't have anything else to test with, but maybe now the situation have changed?
> 
> 

OpenSSL's CMS implementation supports RFC3274.

Steve.
-- 
Dr Stephen N. Henson.
Core developer of the   OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: [email-masked], PGP key: via homepage.

Date: Wed, 11 Feb 2009 12:27:48 +0200
From: "Maxim Masiutin" <[email-masked]>
Reply-To: "Maxim Masiutin" <[email-masked]>
Subject: RFC 3274 - Compressed Data Content Type for Cryptographic Message Syntax (CMS)
To: [email-masked]
Sender: [email-masked]

Hello All,

  Do you know any S/MIME implementation that supports RFC 3274? I would like to test the interoperability of our software (The Bat!) with other software. When RFC 3274, our software was the only to support RFC 3274, so we didn't have anything else to test with, but maybe now the situation have changed?

-- 
Best regards,
Maxim Masiutin                          mailto:[email-masked]