RE: RFC2632bis and subjectAltName

["Blake Ramsdell" <[e-mail]>]

> -----Original Message-----
> From: Russ Housley [mailto:[e-mail]] 
> Sent: Thursday, July 31, 2003 12:37 PM
> To: [e-mail]; [e-mail]
> Subject: RE: RFC2632bis and subjectAltName
> 
> In practice, if there is not an email address in the certificate, the 
> client needs to have additional stuff to bind email addresses to 
> certificates.  This could be done in an address book or elsewhere.

I agree.  This is the way I've written all my clients -- it's an
arbitrary binding of any certificate to any email address at the agent
level ("agent" has been both standard email clients and S/MIME-enabled
servers in my case).  An email address present in the certificate is
just a hint to me that I should probably bind it to that email address
-- the actual binding is a matter of configuration.

> What needs to go in the document?

Dunno -- I didn't bring this up ;).  There are other messages in this
thread that might be relevant, specifically from Tony Capel and Alberti
Antoine.

Blake




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6VLknqt013945 for <[e-mail]>; Thu, 31 Jul 2003 14:46:49 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6VLknDq013944 for ietf-smime-bks; Thu, 31 Jul 2003 14:46:49 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from brutesquadlabs.com (gtec136-m.isomedia.com [207.115.67.136] (may be forged)) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6VLkmqt013939 for <[e-mail]>; Thu, 31 Jul 2003 14:46:48 -0700 (PDT) (envelope-from [e-mail])
Received: from DEXTER ([192.168.0.5]) by brutesquadlabs.com with ESMTP ; Thu, 31 Jul 2003 14:46:45 -0700
From: "Blake Ramsdell" <[e-mail]>
To: "'Russ Housley'" <[e-mail]>, <[e-mail]>
Subject: RE: RFC2632bis and subjectAltName
Date: Thu, 31 Jul 2003 14:46:45 -0700
Message-ID: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAA[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
In-Reply-To: <[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>

> -----Original Message-----
> From: Russ Housley [mailto:[e-mail]] 
> Sent: Thursday, July 31, 2003 12:37 PM
> To: [e-mail]; [e-mail]
> Subject: RE: RFC2632bis and subjectAltName
> 
> In practice, if there is not an email address in the certificate, the 
> client needs to have additional stuff to bind email addresses to 
> certificates.  This could be done in an address book or elsewhere.

I agree.  This is the way I've written all my clients -- it's an
arbitrary binding of any certificate to any email address at the agent
level ("agent" has been both standard email clients and S/MIME-enabled
servers in my case).  An email address present in the certificate is
just a hint to me that I should probably bind it to that email address
-- the actual binding is a matter of configuration.

> What needs to go in the document?

Dunno -- I didn't bring this up ;).  There are other messages in this
thread that might be relevant, specifically from Tony Capel and Alberti
Antoine.

Blake



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6VLUmqt013496 for <[e-mail]>; Thu, 31 Jul 2003 14:30:48 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6VLUmZR013495 for ietf-smime-bks; Thu, 31 Jul 2003 14:30:48 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [207.228.252.5]) by above.proper.com (8.12.9/8.12.8) with SMTP id h6VLUlqt013484 for <[e-mail]>; Thu, 31 Jul 2003 14:30:47 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 18182 invoked by uid 0); 31 Jul 2003 21:29:30 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (156.80.234.196) by woodstock.binhost.com with SMTP; 31 Jul 2003 21:29:30 -0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Thu, 31 Jul 2003 15:37:19 -0400
To: [e-mail], [e-mail]
From: Russ Housley <[e-mail]>
Subject: RE: RFC2632bis and subjectAltName
In-Reply-To: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAARMPfbnbp50S [e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
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>

Blake:

> > I understand that non-email applications of CMS and the associated MIME
> > types need other address forms.  But, RFC2632bis does not tell an
> > implementor what to do fir S/MIME (which is an email application) if the
> > certificate does not contain an email address.
>
>I'm still not clear whether S/MIME means "secure MIME used anywhere MIME
>can be used, such as XMPP or BEEP" or S/MIME means "secure MIME used for
>interpersonal email messaging".  Depending on the answer, you will get
>different answers if it's necessary to clarify any language about the
>absence of email addresses in the certificate.

Once could make a statement about email and a separate statement about 
other MIME-enabled applications if needed.

>The relevant text about current processing rules seems to be:
>
>Sending agents SHOULD make the address in the From or Sender header in
>a mail message match an Internet mail address in the signer's
>certificate. Receiving agents MUST check that the address in the From
>or Sender header of a mail message matches an Internet mail address,
>if present, in the signer's certificate, if mail addresses are present
>in the certificate. A receiving agent SHOULD provide some explicit
>alternate processing of the message if this comparison fails, which
>may be to display a message that shows the recipient the addresses in
>the certificate or other certificate details.
>
>So if there are not any email addresses found in the certificate, this
>is a mismatch (blank from the certificate doesn't match nonblank from
>the From or Sender), and you should go crazy insane and show a hex dump
>of the certificate.
>
>We could clarify that "failure" includes the case where there are zero
>email addresses in the certificate...

In practice, if there is not an email address in the certificate, the 
client needs to have additional stuff to bind email addresses to 
certificates.  This could be done in an address book or elsewhere.

What needs to go in the document?

Russ 



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6VEpAqt089456 for <[e-mail]>; Thu, 31 Jul 2003 07:51:10 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6VEpAaQ089455 for ietf-smime-bks; Thu, 31 Jul 2003 07:51:10 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mx2.magma.ca (mx2.magma.ca [206.191.0.250]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6VEp9qt089446 for <[e-mail]>; Thu, 31 Jul 2003 07:51:09 -0700 (PDT) (envelope-from [e-mail])
Received: from mail1.magma.ca (mail1.magma.ca [206.191.0.252]) by mx2.magma.ca Magma's Mail Server with ESMTP id h6VEp08j013962; Thu, 31 Jul 2003 10:51:00 -0400
Received: from tony (ottawa-hs-209-217-122-183.s-ip.magma.ca [209.217.122.183]) by mail1.magma.ca (Magma's Mail Server) with ESMTP id h6VEoqp4004926; Thu, 31 Jul 2003 10:51:01 -0400
From: "Tony Capel" <[e-mail]>
To: "'Blake Ramsdell'" <[e-mail]>, "'Russ Housley'" <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: RE: RFC2632bis and subjectAltName
Date: Thu, 31 Jul 2003 10:50:52 -0400
Message-ID: <000f01c35773$270aa350$01b5a8c0@tony>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
In-Reply-To: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAA[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h6VEp9qt089448
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>

Blake:

The absence of an rfc2822 e-mail address in the certificate should not be
considered a "failure" since its absence must have been permitted by the
certificate issuer - and we assume (!) that certificates are issued
according to issuer policy.

The current text (which you quoted) could be incomplete.  My interpretation*
of the middle sentence of this paragraph is that the check is only mandatory
if the address is present (so a comparison to an absent/"blank" field is not
mandatory).  The following sentence then suggests what action to take if the
check/comparison fails.  Since if the comparison is not done, it will not
fail, one could interpret that no indication is required if the address is
absent from the cert.

The paragraph following the quoted one addresses the display of the signer's
identity:

A receiving agent SHOULD display a subject name or other certificate
details when displaying an indication of successful or unsuccessful
signature verification.

Should this be stronger in cases where the certificate has an absent rfc2822
field (and no check against the From: header field was done)?

Maybe adding the sentence between these two paragraphs:

"Receiving agents which do not perform the foregoing check due to the
absence of an address in the certificate MUST display the subject name
from the certificate when displaying an indication of successful or
unsuccessful signature verification."

-leaving the following paragraph as a SHOULD, strongly encouraging
additional information to be displayed in this and all other cases.

Tony

* I interpret the phrase: "if mail addresses are present in the 
Certificate" to be a qualifier for the "MUST" in this sentence.

| -----Original Message-----
| From: [e-mail] 
| [mailto:[e-mail]] On Behalf Of Blake Ramsdell
| Sent: July 31, 2003 12:53 AM
| To: 'Russ Housley'; [e-mail]; [e-mail]
| Subject: RE: RFC2632bis and subjectAltName
| 
| 
| 
| > -----Original Message-----
| > From: Russ Housley [mailto:[e-mail]]
| > Sent: Tuesday, July 29, 2003 4:36 PM
| > To: [e-mail]; 'Blake Ramsdell'; [e-mail]
| > Subject: RE: RFC2632bis and subjectAltName
| > 
| > I understand that non-email applications of CMS and the
| > associated MIME 
| > types need other address forms.  But, RFC2632bis does not tell an 
| > implementor what to do fir S/MIME (which is an email 
| > application) if the 
| > certificate does not contain an email address.
| 
| I'm still not clear whether S/MIME means "secure MIME used 
| anywhere MIME can be used, such as XMPP or BEEP" or S/MIME 
| means "secure MIME used for interpersonal email messaging".  
| Depending on the answer, you will get different answers if 
| it's necessary to clarify any language about the absence of 
| email addresses in the certificate.
| 
| The relevant text about current processing rules seems to be:
| 
| 
| Sending agents SHOULD make the address in the From or Sender 
| header in a mail message match an Internet mail address in 
| the signer's certificate. Receiving agents MUST check that 
| the address in the From or Sender header of a mail message 
| matches an Internet mail address, if present, in the signer's 
| certificate, if mail addresses are present in the 
| certificate. A receiving agent SHOULD provide some explicit 
| alternate processing of the message if this comparison fails, 
| which may be to display a message that shows the recipient 
| the addresses in the certificate or other certificate details.
| 
| 
| So if there are not any email addresses found in the 
| certificate, this is a mismatch (blank from the certificate 
| doesn't match nonblank from the From or Sender), and you 
| should go crazy insane and show a hex dump of the certificate.
| 
| We could clarify that "failure" includes the case where there 
| are zero email addresses in the certificate...
| 
| Blake
| 





Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6VE4kqt082471 for <[e-mail]>; Thu, 31 Jul 2003 07:04:46 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6VE4kee082470 for ietf-smime-bks; Thu, 31 Jul 2003 07:04:46 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from sopragroup.com (smtp1.zpar1.sopragroup.com [213.223.36.98]) by above.proper.com (8.12.9/8.12.8) with SMTP id h6VE4iqt082438 for <[e-mail]>; Thu, 31 Jul 2003 07:04:45 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 5228 invoked from network); 31 Jul 2003 14:04:37 -0000
Received: from Antivirus (HELO Antivirus) (Antivirus@Antivirus) by smtp1.sopragroup.com with SMTP; 31 Jul 2003 14:04:37 -0000
Received: by nt1022.pa.sopra with Internet Mail Service (5.5.2653.19) id <PXB0FRL3>; Thu, 31 Jul 2003 16:04:36 +0200
Message-ID: <[e-mail]>
From: Alberti Antoine <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: RE: RFC2632bis and subjectAltName
Date: Thu, 31 Jul 2003 16:04:35 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
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>

> -----Original Message-----
> From: Russ Housley [mailto:[e-mail]] 

> I'm still not clear whether S/MIME means "secure MIME used anywhere MIME
> can be used, such as XMPP or BEEP" or S/MIME means "secure MIME used for
> interpersonal email messaging".  Depending on the answer, you will get
> different answers if it's necessary to clarify any language about the
> absence of email addresses in the certificate.

I agree. S/MIME is already used in AS2 (secured EDI), in an HTTP based
protocol. From my point of view, S/MIME is only a way of wrapping data, and
should not be mixed with the transport. So, managing e-mail addresses, or
URIs, or anything concerning transport is a problem when implementing an
S/MIME module that can be used in both (or more) contexts. I am presently
developping such a module, and facing such issues. And the only solution is
to let upper modules (AS1, AS2, S/MIME secured SMTP,...) handle the
constraints brought by the transport layer, or just ignore them, which is
the case with the subjectAltName. I'm sorry not to be compliant with the
SHOULD statement we are discussing, but what can I do?

Best regards.


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6V4qqqt022167 for <[e-mail]>; Wed, 30 Jul 2003 21:52:52 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6V4qqkt022166 for ietf-smime-bks; Wed, 30 Jul 2003 21:52:52 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from brutesquadlabs.com (gtec136-m.isomedia.com [207.115.67.136] (may be forged)) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6V4qpqt022158 for <[e-mail]>; Wed, 30 Jul 2003 21:52:52 -0700 (PDT) (envelope-from [e-mail])
Received: from DEXTER ([192.168.0.5]) by brutesquadlabs.com with ESMTP ; Wed, 30 Jul 2003 21:52:49 -0700
From: "Blake Ramsdell" <[e-mail]>
To: "'Russ Housley'" <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: RE: RFC2632bis and subjectAltName
Date: Wed, 30 Jul 2003 21:52:49 -0700
Message-ID: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAA[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
In-Reply-To: <[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>

> -----Original Message-----
> From: Russ Housley [mailto:[e-mail]] 
> Sent: Tuesday, July 29, 2003 4:36 PM
> To: [e-mail]; 'Blake Ramsdell'; [e-mail]
> Subject: RE: RFC2632bis and subjectAltName
> 
> I understand that non-email applications of CMS and the 
> associated MIME 
> types need other address forms.  But, RFC2632bis does not tell an 
> implementor what to do fir S/MIME (which is an email 
> application) if the 
> certificate does not contain an email address.

I'm still not clear whether S/MIME means "secure MIME used anywhere MIME
can be used, such as XMPP or BEEP" or S/MIME means "secure MIME used for
interpersonal email messaging".  Depending on the answer, you will get
different answers if it's necessary to clarify any language about the
absence of email addresses in the certificate.

The relevant text about current processing rules seems to be:


Sending agents SHOULD make the address in the From or Sender header in
a mail message match an Internet mail address in the signer's
certificate. Receiving agents MUST check that the address in the From
or Sender header of a mail message matches an Internet mail address,
if present, in the signer's certificate, if mail addresses are present
in the certificate. A receiving agent SHOULD provide some explicit
alternate processing of the message if this comparison fails, which
may be to display a message that shows the recipient the addresses in
the certificate or other certificate details.


So if there are not any email addresses found in the certificate, this
is a mismatch (blank from the certificate doesn't match nonblank from
the From or Sender), and you should go crazy insane and show a hex dump
of the certificate.

We could clarify that "failure" includes the case where there are zero
email addresses in the certificate...

Blake



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6TNZsqt094818 for <[e-mail]>; Tue, 29 Jul 2003 16:35:54 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6TNZstj094816 for ietf-smime-bks; Tue, 29 Jul 2003 16:35:54 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [207.228.252.5]) by above.proper.com (8.12.9/8.12.8) with SMTP id h6TNZrqt094811 for <[e-mail]>; Tue, 29 Jul 2003 16:35:53 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 4133 invoked by uid 0); 29 Jul 2003 23:34:37 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.93.183) by woodstock.binhost.com with SMTP; 29 Jul 2003 23:34:37 -0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Tue, 29 Jul 2003 19:35:50 -0400
To: <[e-mail]>, "'Blake Ramsdell'" <[e-mail]>, <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: RE: RFC2632bis and subjectAltName
In-Reply-To: <003201c3561d$e1a20d40$[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
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>

Jim:

I understand that non-email applications of CMS and the associated MIME 
types need other address forms.  But, RFC2632bis does not tell an 
implementor what to do fir S/MIME (which is an email application) if the 
certificate does not contain an email address.

Russ


At 03:08 PM 7/29/2003 -0700, Jim Schaad wrote:
>Russ,
>
>There was a big discussion about #1. -- It is a question not a
>statement.  The result was that this should not be required (at least
>for non e-mail applications).
>
>jim



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6TM7cqt087931 for <[e-mail]>; Tue, 29 Jul 2003 15:07:38 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6TM7cuk087930 for ietf-smime-bks; Tue, 29 Jul 2003 15:07:38 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.173]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6TM7bqt087924 for <[e-mail]>; Tue, 29 Jul 2003 15:07:37 -0700 (PDT) (envelope-from [e-mail])
Received: from ROMANS (ip237.c132.blk1.bel.nwlink.com [209.20.132.237]) by smtp3.pacifier.net (Postfix) with ESMTP id 1CEB26DB3A; Tue, 29 Jul 2003 15:07:38 -0700 (PDT)
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: "'Russ Housley'" <[e-mail]>, "'Blake Ramsdell'" <[e-mail]>, <[e-mail]>
Subject: RE: RFC2632bis and subjectAltName
Date: Tue, 29 Jul 2003 15:08:02 -0700
Message-ID: <003201c3561d$e1a20d40$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
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,

There was a big discussion about #1. -- It is a question not a
statement.  The result was that this should not be required (at least
for non e-mail applications).

jim

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Russ Housley
> Sent: Tuesday, July 29, 2003 2:08 PM
> To: Blake Ramsdell; [e-mail]
> Subject: RE: RFC2632bis and subjectAltName
> 
> 
> 
> Blake:
> 
> I do not think that the specification does #1.  SHOULD is 
> very different 
> than "required."
> 
> Russ
> 
> 
> At 02:04 PM 7/29/2003 -0700, Blake Ramsdell wrote:
> > > -----Original Message-----
> > > From: [e-mail] 
> > > [mailto:[e-mail]] On Behalf Of Russ Housley
> > > Sent: Tuesday, July 29, 2003 9:14 AM
> > > To: [e-mail]
> > > Subject: RFC2632bis and subjectAltName
> > >
> > > The document says:
> > >
> > >     The email address SHOULD be in the subjectAltName extension
> > >
> > > This is exactly the same thing that RFC 2632 says.
> > >
> > > If the certificate does not bind the public key to the email 
> > > address, how is this done?  Should we mandate an alternate 
> > > mechanism?  Or, should we
> > > change "SHOULD" to "MUST?"
> >
> >I think that the current spec tries to address at least two issues 
> >here:
> >
> >1. Is it required that an email address be present in the certificate
> >
> >2. If the email address is present, where should it be 
> located (subject 
> >DN vs. subjectAltName)
> >
> >Are you asking about:
> >
> >3. How do we understand if the CA was putting the email 
> address in the 
> >certificate purely for informational reasons vs. actually doing some 
> >work to make sure that the public key "belongs" to that email address
> >
> >If so, I have no idea -- it's "do what PKIX says" in this case.
> >
> >Blake
> 



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6TL85qt085720 for <[e-mail]>; Tue, 29 Jul 2003 14:08:05 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6TL85Xb085719 for ietf-smime-bks; Tue, 29 Jul 2003 14:08:05 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [207.228.252.5]) by above.proper.com (8.12.9/8.12.8) with SMTP id h6TL83qt085713 for <[e-mail]>; Tue, 29 Jul 2003 14:08:04 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 29793 invoked by uid 0); 29 Jul 2003 21:06:48 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.5.90) by woodstock.binhost.com with SMTP; 29 Jul 2003 21:06:48 -0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Tue, 29 Jul 2003 17:07:57 -0400
To: "Blake Ramsdell" <[e-mail]>, <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: RE: RFC2632bis and subjectAltName
In-Reply-To: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAARMPfbnbp50S [e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
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>

Blake:

I do not think that the specification does #1.  SHOULD is very different 
than "required."

Russ


At 02:04 PM 7/29/2003 -0700, Blake Ramsdell wrote:
> > -----Original Message-----
> > From: [e-mail]
> > [mailto:[e-mail]] On Behalf Of Russ Housley
> > Sent: Tuesday, July 29, 2003 9:14 AM
> > To: [e-mail]
> > Subject: RFC2632bis and subjectAltName
> >
> > The document says:
> >
> >     The email address SHOULD be in the subjectAltName extension
> >
> > This is exactly the same thing that RFC 2632 says.
> >
> > If the certificate does not bind the public key to the email
> > address, how
> > is this done?  Should we mandate an alternate mechanism?  Or,
> > should we
> > change "SHOULD" to "MUST?"
>
>I think that the current spec tries to address at least two issues here:
>
>1. Is it required that an email address be present in the certificate
>
>2. If the email address is present, where should it be located (subject
>DN vs. subjectAltName)
>
>Are you asking about:
>
>3. How do we understand if the CA was putting the email address in the
>certificate purely for informational reasons vs. actually doing some
>work to make sure that the public key "belongs" to that email address
>
>If so, I have no idea -- it's "do what PKIX says" in this case.
>
>Blake



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6TL4wqt085613 for <[e-mail]>; Tue, 29 Jul 2003 14:04:58 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6TL4wg5085612 for ietf-smime-bks; Tue, 29 Jul 2003 14:04:58 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from brutesquadlabs.com (gtec136-m.isomedia.com [207.115.67.136] (may be forged)) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6TL4vqt085605 for <[e-mail]>; Tue, 29 Jul 2003 14:04:57 -0700 (PDT) (envelope-from [e-mail])
Received: from DEXTER ([192.168.0.5]) by brutesquadlabs.com with ESMTP ; Tue, 29 Jul 2003 14:04:54 -0700
From: "Blake Ramsdell" <[e-mail]>
To: "'Russ Housley'" <[e-mail]>, <[e-mail]>
Subject: RE: RFC2632bis and subjectAltName
Date: Tue, 29 Jul 2003 14:04:54 -0700
Message-ID: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAA[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
In-Reply-To: <[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>

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Russ Housley
> Sent: Tuesday, July 29, 2003 9:14 AM
> To: [e-mail]
> Subject: RFC2632bis and subjectAltName
> 
> The document says:
> 
>     The email address SHOULD be in the subjectAltName extension
> 
> This is exactly the same thing that RFC 2632 says.
> 
> If the certificate does not bind the public key to the email 
> address, how 
> is this done?  Should we mandate an alternate mechanism?  Or, 
> should we 
> change "SHOULD" to "MUST?"

I think that the current spec tries to address at least two issues here:

1. Is it required that an email address be present in the certificate

2. If the email address is present, where should it be located (subject
DN vs. subjectAltName)

Are you asking about:

3. How do we understand if the CA was putting the email address in the
certificate purely for informational reasons vs. actually doing some
work to make sure that the public key "belongs" to that email address

If so, I have no idea -- it's "do what PKIX says" in this case.

Blake



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6TGDoqt070658 for <[e-mail]>; Tue, 29 Jul 2003 09:13:50 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6TGDoEX070656 for ietf-smime-bks; Tue, 29 Jul 2003 09:13:50 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [207.228.252.5]) by above.proper.com (8.12.9/8.12.8) with SMTP id h6TGDnqt070647 for <[e-mail]>; Tue, 29 Jul 2003 09:13:49 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 13761 invoked by uid 0); 29 Jul 2003 16:12:32 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.164.124) by woodstock.binhost.com with SMTP; 29 Jul 2003 16:12:32 -0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Tue, 29 Jul 2003 12:13:31 -0400
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: RFC2632bis and subjectAltName
Mime-Version: 1.0
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 document says:

    The email address SHOULD be in the subjectAltName extension

This is exactly the same thing that RFC 2632 says.

If the certificate does not bind the public key to the email address, how 
is this done?  Should we mandate an alternate mechanism?  Or, should we 
change "SHOULD" to "MUST?"

Russ



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6TF83qt068379 for <[e-mail]>; Tue, 29 Jul 2003 08:08:03 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6TF83Bf068378 for ietf-smime-bks; Tue, 29 Jul 2003 08:08:03 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6TF81qt068371 for <[e-mail]>; Tue, 29 Jul 2003 08:08:01 -0700 (PDT) (envelope-from [e-mail])
Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by hermes.cs.auckland.ac.nz (8.12.9/8.12.9) with ESMTP id h6TF7uOA022242 for <[e-mail]>; Wed, 30 Jul 2003 03:07:56 +1200
Received: (from pgut001@localhost) by medusa01.cs.auckland.ac.nz (8.11.6/8.11.6) id h6TF7up11514 for [e-mail]; Wed, 30 Jul 2003 03:07:56 +1200
Date: Wed, 30 Jul 2003 03:07:56 +1200
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: Off-list discussion of RTCS: An update
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 wrote:

>In order to resolve this problem, I'd like to invite anyone who's interested
>in discussing things further, or who's currently part of one of the private
>threads, to join the off-list discussion.  It's not a real mailing list, just
>a list of cc'd addresses, I can also bcc you if you'd prefer to lurk
>anonymously.

Due to the number of requests, this is now being handled as a standard mailing
list rather than via cc:/bcc:, which would have been a bit unwieldy.  Anyone
interested can join by sending mail to [e-mail] with
'subscribe' in the subject line, in the standard fashion.

Peter.


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6SH6Mqt072475 for <[e-mail]>; Mon, 28 Jul 2003 10:06:22 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6SH6MC0072474 for ietf-smime-bks; Mon, 28 Jul 2003 10:06:22 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from moorabbin.nexor.co.uk (moorabbin.nexor.co.uk [80.6.88.100]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6SH6Lqt072468 for <[e-mail]>; Mon, 28 Jul 2003 10:06:21 -0700 (PDT) (envelope-from [e-mail])
Received: from typhoon (actually host 210.53.63.193.in-addr.arpa) by moorabbin.nexor.co.uk with ESMTP (Mailer) with ESMTP; Mon, 28 Jul 2003 18:03:27 +0100
Reply-To: "g.lunt" <[e-mail]>
From: Graeme Lunt <[e-mail]>
To: "'Russ Housley'" <[e-mail]>
Cc: "'ietf-smime'" <[e-mail]>
Subject: RE: Signed Receipts and Mail Lists
Date: Mon, 28 Jul 2003 18:05:28 +0100
Organization: Nexor
Message-ID: <009001c3552a$723d8e50$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Spam-Status: No, hits=-101.0 required=5.0 tests=IN_REP_TO,NOSPAM_INC,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01, USER_IN_WHITELIST version=2.43
X-Spam-Level: 
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,
 
> When we designed the MLA mechanism, we assumed that each mail 
> list would have a separate key pair and certificate.  I do not 
> think that this is an unreasonable assumption.  Today, Web servers 
> that support more than one site have a certificate for each of the 
> sites.

I had reached this conclusion on further reading of 2634. Whilst being
able to use a single certificate (and ACs for example) for hundreds of
lists would be useful, it is not a major concern at the moment. 

My main issue was to have a mechanism to indicate on whose behalf of
whom a signed receipt was generated (e.g. in the case of an "All"
request from  a ML). 
Either a specific field in the Receipt structure, or just an extension
mechanism (which may be more generally useful).

Graeme



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6SDb9qt057754 for <[e-mail]>; Mon, 28 Jul 2003 06:37:10 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6SDb9oc057753 for ietf-smime-bks; Mon, 28 Jul 2003 06:37:09 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp001.bizmail.yahoo.com (smtp001.bizmail.yahoo.com [216.136.172.125]) by above.proper.com (8.12.9/8.12.8) with SMTP id h6SDb8qt057747 for <[e-mail]>; Mon, 28 Jul 2003 06:37:08 -0700 (PDT) (envelope-from [e-mail])
Received: from pool-138-88-5-194.res.east.verizon.net (HELO ieca.com) ([e-mail]@138.88.5.194 with plain) by smtp2.bm.vip.sc5.yahoo.com with SMTP; 28 Jul 2003 13:37:08 -0000
Message-ID: <[e-mail]>
Date: Mon, 28 Jul 2003 09:35:16 -0400
From: "Sean P. Turner" <[e-mail]>
Organization: IECA, Inc.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: SMIME <[e-mail]>
Subject: Draft Meeting Minutes
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
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>

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body>
Please provide feedback by August 1st.<br>
-------------<br>
<br>
Here are the draft minutes from the Austria meeting.<br>
<br>
Minutes for S/MIME Meeting<br>
IETF 57<br>
July 14, 2003<br>
<br>
Agenda: Sean Turner covered the agenda for the meeting. No changes were made.<br>
<br>
Working Group Status: Sean Turner covered the status of the active documents
in the working group. The documents that have changed status since the last
meeting are:<br>
<br>
Published as RFC:<br>
- 3395 Implementing Company Classification Policy with S/MIME Security Label.<br>
- 3537 Wrapping a Hashed Message Authentication Code (HMAC) key with Triple-Data
Encryption Standard (DES) Key or an Advanced Encryption Standard (AES) Keys.<br>
<br>
RFC Editor Queue:<br>
- aes-alg Use of the AES Encryption Algorithm in CMS.<br>
- cms-rsaes-oaep Use of RSAE-OAEP Key Transport Algorithm in CMS.<br>
<br>
With IESG:<br>
- Camellia Use of Camellia Encryption Algorithm in CMS.<br>
<br>
CMS and ESS Examples Draft: Paul Hoffman explained that new examples have
been added to the &#8211;11 draft, all of which need to be verified. After verification
by all, a new -12 will be issued and the ADs will be asked to issue an IETF
last call.<br>
<br>
MSGbis and CERTbis: Sean Turner presented Blake Ramsdell's presentation.&nbsp;
In MSGbis minor edits were included, id-dsa was changed to id-dsa-with-sha1,
and AES was made a SHOULD. MSGbis is ready for an IETF last call.&nbsp; In CERTbis
text is still needed for acknowlegements and a summary of changes to the
draft. There was an issue as to whether smime-types for every know CMS type
should be included in the document. It was decided that the smime-types currently
in the draft will remain but any new ones will be placed in new drafts so
as to not hold up MSGbis.<br>
<br>
X400WRAP and X400TRANS: Chris Bonatti explained that changes similar to those
in MSGbis were also made to X400WRAP - id-dsa was changed to id-dsa-with-sha1,
and AES was made a SHOULD. In X400TRANS, the security considerations section
was updated, as a result of IESG comments, to indicate that no new security
concerns are added other than those in CMS or S/MIME models. It is believed
that both documents are now ready for IETF last call.<br>
<br>
Interoperability Matrix: Jim Schaad indicated that the tests for both SignedData
and EncryptedData are complete and that only the final write-up is required.
The only remaining issues are with the Key Derivation Algorithm - PBKDF2
and the Message Authentication Code Algorithm - HMAC with SHA-1 neither of
which were tested will result in blocking the draft.<br>
<br>
RSA KEM: Jim Schaad presented an overview of the RSA KEM algorithm. The remaining
issues to complete the draft are defining matching rules for usage, SMIMECapabilities
attribute values, and a single ASN.1 module.<br>
<br>
RSA PSS: Jim Schaad presented an overview of the RSA PSS algorithm. The requirements
for the parameters H1 (digest hash algorithm parameters) and H2 (internal
hash algorithm parameters) SHOULD be the same, while H2 and H3 (message generation
function hash algorithm parameters) are RECOMMENDED to be the same. The resolved
outstanding issues are that the key identifier and signature identifier will
be the same OID and that PSS parameter comparison MUST be done if they are
present in the certificate. It is believed that his draft is ready for WG
last call.<br>
<br>
ESSbis: Jim Schaad presented updates to ESS which included splitting the
MLExpansionHistory attribute in to two new attributes - Receipt Behavior
and ML Loop Detection. The work required to rewrite the processing rules
is proving more difficult that originally thought. Jim also indicated that
there were outstanding issues on the list that deal with nested cases for
receipt processing and MLA attribute propagation.<br>
<br>
GOST Algorithm: Grigory Chudov presented the Russian national algorithm GOST
and an individual submission explaining how CMS can be used with GOST. The
WG agreed to publish the draft under the WG banner.<br>
<br>
OpenEvidence Project and ESS: Peter Sylvester explained a usage of the technology
developed in the OpenEvidence project, an open source projects financed by
the European commission and run by a small group of European companies. A
useful application of the technology addresses the problem to make email
more reliable by using a third party security infrastructure to provide more
traceability for users, service providers, and organizations. The tools developed
were based on existing standards, i.e., SMIME signed receipts and RFC 3029.
Two of the outputs of the project are the realization that there are few
toolkits to provide support for ESS and that the ASN.1, which is 88 based,
is problematic for new compilers. (A more detailed presentation of OpenEvidence
project has been made in the PKIX wg).<br>
<br>
NIST S/MIME Tester: Tim Polk discussed the NIST online S/MIME tester that
is intended to test the conformance of S/MIME implementations to the NIST
S/MIME profile. More information can be found at: <a class="moz-txt-link-freetext" href="http://csrc.nist.gov/pki/smime/smtest.htm">http://csrc.nist.gov/pki/smime/smtest.htm</a>.<br>
<br>
<br>
</body>
</html>



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6SCEgqt051320 for <[e-mail]>; Mon, 28 Jul 2003 05:14:42 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6SCEgQE051319 for ietf-smime-bks; Mon, 28 Jul 2003 05:14:42 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6SCEeqt051314 for <[e-mail]>; Mon, 28 Jul 2003 05:14:41 -0700 (PDT) (envelope-from [e-mail])
Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by hermes.cs.auckland.ac.nz (8.12.9/8.12.9) with ESMTP id h6SCEZV8021092 for <[e-mail]>; Tue, 29 Jul 2003 00:14:35 +1200
Received: (from pgut001@localhost) by medusa01.cs.auckland.ac.nz (8.11.6/8.11.6) id h6SCEaY04751 for [e-mail]; Tue, 29 Jul 2003 00:14:36 +1200
Date: Tue, 29 Jul 2003 00:14:36 +1200
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: Off-list discussion of RTCS
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>

After the previous RTCS posts I got a number of off-list replies, including
several in which the authors specifically said that they din't want to comment
in public, e.g:

  i did not post it to the list, because i do not think that a objective
  discussion is possible there. moreover, i do not want to waste my time in
  religious discussions.

This is unfortunate, because I'm now carrying on multiple private discussions
with potential spill-over between them, but only one person at a time is
seeing each thread, which is limiting its usefulness somewhat.

In order to resolve this problem, I'd like to invite anyone who's interested
in discussing things further, or who's currently part of one of the private
threads, to join the off-list discussion.  It's not a real mailing list, just
a list of cc'd addresses, I can also bcc you if you'd prefer to lurk
anonymously.

(This move is rather unfortunate because I'd like to get open feedback on
 RTCS, but it doesn't appear that this is possible).

Peter.


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6S66cqt008528 for <[e-mail]>; Sun, 27 Jul 2003 23:06:38 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6S66cee008526 for ietf-smime-bks; Sun, 27 Jul 2003 23:06:38 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from web8001.mail.in.yahoo.com (web8001.mail.in.yahoo.com [203.199.70.95]) by above.proper.com (8.12.9/8.12.8) with SMTP id h6S66Zqt008486 for <[e-mail]>; Sun, 27 Jul 2003 23:06:36 -0700 (PDT) (envelope-from [e-mail])
Message-ID: <[e-mail]>
Received: from [202.144.91.253] by web8001.mail.in.yahoo.com via HTTP; Mon, 28 Jul 2003 07:06:26 BST
Date: Mon, 28 Jul 2003 07:06:26 +0100 (BST)
From: =?iso-8859-1?q?Nagaraj=20Mandya?= <[e-mail]>
Subject: RFC 2634 and encryption for mailing list recipients
To: [e-mail]
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
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>

Hi,
  Though RFC2634 talks in detail about adding a
signature to a mail that is to be sent to a mailing
list, it only mentions that MLAs can encrypt the mail
for each recipient.

  It does not discuss this in detail. Where can I get
more information on what process should be followed by
MLAs to encrypt the mail for each recipient? Should it
be done after the outer signature has been added by
the MLA? Thanks.
--
Regards,
Nagaraj

________________________________________________________________________
Send free SMS using the Yahoo! Messenger. Go to http://in.mobile.yahoo.com/new/pc/


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6NK1Yqt067269 for <[e-mail]>; Wed, 23 Jul 2003 13:01:34 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6NK1YIq067268 for ietf-smime-bks; Wed, 23 Jul 2003 13:01:34 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.173]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6NK1Xqt067263 for <[e-mail]>; Wed, 23 Jul 2003 13:01:33 -0700 (PDT) (envelope-from [e-mail])
Received: from ROMANS (dialup-171.75.41.190.Dial1.Washington1.Level3.net [171.75.41.190]) by smtp3.pacifier.net (Postfix) with ESMTP id A92AF6D654; Wed, 23 Jul 2003 13:01:32 -0700 (PDT)
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: "'Blake Ramsdell'" <[e-mail]>, <[e-mail]>
Subject: RE: WG LAST CALL: draft-ietf-smime-rfc2632bis-03
Date: Wed, 23 Jul 2003 16:01:59 -0400
Message-ID: <001d01c35155$4c558950$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
In-Reply-To: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAARMPfbnbp50SwK3EZjypY2MKAAAAQAAAArOG3H4vmqkCKD2y8D/[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
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>

1. Section 1.2:  Does this need to be updated to refer to version 3.1
agents as well?

2. References need to be divided.

3. Acknowlegements is [TBD]

4. Section at beginning of document on changes since RFC2632 is
required.

5. KEYMAC as a reference sent me to keyed macs, not to key management
for ACs.

6.  Section 4.4.2 - Key Usage is not a required extension.  What happens
in para #4 if the extension is not present.  Does this imply that the
bits are set?

Jim



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6NK1Tqt067256 for <[e-mail]>; Wed, 23 Jul 2003 13:01:29 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6NK1TW4067255 for ietf-smime-bks; Wed, 23 Jul 2003 13:01:29 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.173]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6NK1Sqt067250 for <[e-mail]>; Wed, 23 Jul 2003 13:01:28 -0700 (PDT) (envelope-from [e-mail])
Received: from ROMANS (dialup-171.75.41.190.Dial1.Washington1.Level3.net [171.75.41.190]) by smtp3.pacifier.net (Postfix) with ESMTP id 130316DAF5; Wed, 23 Jul 2003 13:01:27 -0700 (PDT)
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: "'Blake Ramsdell'" <[e-mail]>, <[e-mail]>
Subject: RE: WG LAST CALL: draft-ietf-smime-rfc2633bis-04
Date: Wed, 23 Jul 2003 16:01:59 -0400
Message-ID: <001a01c35155$48f4ab10$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
In-Reply-To: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAA[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
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>

Comments are on the -05 version of the document.

1. Section 1.4 talks about version 3 not version 3.1 agents.

2. Section 2.1: Given your request for manditory inclusion of hash
algorithms in DigestAlgorithmIdentifier, is there a reason you don't
make population here atleast a SHOULD if not a MUST?

3. Section 2.2: There is no techincal reason that an S/MIME v2 client
cannot be augmented to verify an id-dsa-with-sha1 signature.  This
statement should be that S/MIME v2 clients are only REQUIRED to
implement rsaEncryption with either SHA-1 or MD5.

4. Section 2.2:  The required hash algorithms supported with
rsaEncryption needs to be noded as part of this section.

5. Section 2.3:  Agents should support ES Diffie-Hellman.  SS is not a
requirement.

6.  Section 2.4: CMS does not define the CompressedData content type
last time I checked.

7.  Section 2.4.4: Is there a reason why there is not any text
describing when one should and when one should not compress data?  (i.e.
don't compress after encryption).  Add reference to section 3.6?

8.  Section 2.5:  The text "Sending agents SHOULD generate one instance
of the signingCertificate
signed attribute in each S/MIME message." should state "signed attribute
in each SignerInfo structure".

9.  Section 2.5.2, para 4:  I would like to have the following text
added.  "
Because of the requirement for identical encoding, individuals
documenting algorithms to be used in the SMIMECapabilities attribute
should explicitly document the correct byte sequence for the common
cases."

10. Section 2.5.2, para 5:  I think we need to remove the "In the case
of symmetric algorithms,"  phrase from this paragraph.  The need for
dealing with parameters can occur for other algorithms such as OAEP, KEM
and PSS.  It may be necessary to distinguish more explicitly between
algorithm parameters such as rounds and block size as oppose to the IV.

11.  Section 2.5.2 - where do we document SMimeCapabilities for RC2?
Should be a 40-bit vs 128-bit difference between these which needs an
ASN.1 structure and encoding.  Based on reading of this document I could
not correctly encode these values.

12.  Section 2.5.3, last para:  what happended to the clock skew text
for SMIMECapabiltlies that clarifies what this sentence refers to? --
found it in section 2.7.1 - not immediately apparent should have some
type of reference in either 2.5.2 or 2.5.3 or both.

13.  Section 2.7.1, para 2:  Change reference to section 2.5.2

14. Section 2.7.1.2:  Should we remove this paragraph?  It does not
really follow from the fact that you recived a signed (by me) then
encrypted message that I was actually the party that enrypted the
message.  It could have been an DOS attacker, a gateway, an MLA and so
forth.

15. Section 2.7.1.3:  Need to be updated to comment on AES.

16.  Section 3.1, last para:  I would like to see some additional
comments provided to help people make the decision between a message
that is protecting the headers and a message which is an attachment.

17.  Section 3.1.2 para 3:  Change the "SHOULD NOT use 7-bit" to "SHOULD
use binary" to make a positive rather than a negative statement.

18.  Section 3.1, General:  Do you need to canonicalize before you
compress?

19.  Section 3.2.1:  Can we really justify limiting the file name to
eight characters any more?  All common windows platforms no longer have
this restriction.  Apple and Unix platforms have not had this
restriction for a long time (if ever).

20.  Section 3.2.2:  I would like to get some rewrites on this section
as to the purpose of S/MIME type.  I think it is JUST to provide
information about the information (misspelt in the document) about the
contained content.  It just happens that for display via UAs, the
distinction between signed and enveloped was consisted to be an
important part of the content.  Additionally, I think this is the
correct direction for us to tell people about how to define new
smime-types in the future.

The next question is weither a compressed only message would show up in
my mailbox.  I think that the correct smime-type for a compressed and
signed message is actually signed-data not compressed data.

21.  Section 3.4.1, last para:  Currently this reads

Messages signed using the signedData format cannot be viewed by a
recipient unless they have S/MIME facilities. However, if they have
S/MIME facilities, these messages can always be verified if they were
not changed in transit.

But duh for the last sentence.  The correct statement would be.
"However, the signedData format protects the message content from being
changed by benign intermediate agents.  Such agents might do line
wrapping or content-transfer encoding changes which would break the
signature."

22.  Section 3.4.3.2, algorithm table:  The last item in the table needs
to be removed.  The corect answer is that this value needs to be defined
by documents describing other hashing algorithms.

23.  Section 3.4.3.3:  Just for giggles, I think that adding a section
with the hex encoding of the acutal bytes hashed for this sample would
be a good idea.  This is one of the things people always have problems
with when doing multipart signed data.  Also it might be interesting to
make the body a multipart/alternative.  On the other hand this would
probably be better in an appendix.

24. Section 4:  Reference to [CERT3] needs updating.

25. Section 4.1:  Language and protocol statements needs to be updated
in this section to reflect the change in algorithms.

26. Appendix B:  Refernces need to be divided.


Jim



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6NJfqqt066811 for <[e-mail]>; Wed, 23 Jul 2003 12:41:52 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6NJfq7e066810 for ietf-smime-bks; Wed, 23 Jul 2003 12:41:52 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [207.228.252.5]) by above.proper.com (8.12.9/8.12.8) with SMTP id h6NJfpqt066804 for <[e-mail]>; Wed, 23 Jul 2003 12:41:51 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 23204 invoked by uid 0); 23 Jul 2003 19:40:37 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.154.159) by woodstock.binhost.com with SMTP; 23 Jul 2003 19:40:37 -0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Tue, 22 Jul 2003 22:51:17 -0400
To: "g.lunt" <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: RE: Signed Receipts and Mail Lists
Cc: "'ietf-smime'" <[e-mail]>
In-Reply-To: <001f01c340a1$cf01f470$[e-mail]>
References: <009701c33ce3$a86b4170$[e-mail]>
Mime-Version: 1.0
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>

Graeme:

When we designed the MLA mechanism, we assumed that each mail list would 
have a separate key pair and certificate.  I do not think that this is an 
unreasonable assumption.  Today, Web servers that support more than one 
site have a certificate for each of the sites.

Russ

>Jim,
>
> > If we adopted the solution you gave, what limits me from making
> > arbitrary statements about who I am in this field that then need to be
>
> > independently verified by the receipt processing code?  (I.e. what if
> > I put the fact that I am [e-mail] in this field and sign with
> > my [e-mail] certificate).
>
>First off, having looked in more detail at 2634 it implicitly requires
>each mail list to have its own certificate. In particular, the
>EntityIdentifier, used in MLExpansionHistory, refers only to a
>certificate. So having a single certificate for an MLA supporting
>multiple lists would cause the loop detection algorithm to fail.
>
>So what I was looking at (a single certificate for a mail list agent
>supporting multiple lists) is a more fundamental change than I first
>thought.
>
>But back to your question.
>
>The basic answer is that nothing would limit you. Do you see this as a
>major issue?
>
>x400wrap has a similar case where the content being signed contains an
>"originator" field.
>
>"Receiving agents SHOULD check that the originator address in the X.400
>content matches an X.400 address in the signer's certificate, if X.400
>addresses are present in the certificate and an originator address is
>available in the content. A receiving agent SHOULD provide some explicit
>alternate processing of the message if this comparison fails, which may
>be to display a message that shows the recipient the addresses in the
>certificate or other certificate details."
>
>I think that similar wording to section 4.3 of this draft may be
>acceptable?
>
>This wording allows us to take our own action to correlate the x400
>originator to the signer in the case that they don't match (we use
>attribute certificates to do the signer to originator validation).
>
>So for your example, I may see something like:
>
>"signed receipt from [e-mail] on behalf of [e-mail] at
><time>"
>
>The receiptFrom field I proposed is primarily aimed at supporting the
>correlation of the signed receipt to the original recipient by providing
>original address the signed receipt was requested from.
>
>There are a number of reasons why I may not be able to match the
>address[es] (subjectAltName) from the certificate to one of the
>addresses I to:
>
>a) Valid aliases not in the subjectAltNames of the certificate
>
>b) Signed receipt from a recipient who received the message as a result
>of ML expansion.
>
>c) Mail redirections - e.g. sent to "[e-mail]" which redirects to a
>personal mailbox.
>Similar to a).
>
>
>Graeme
>
>
> > > -----Original Message-----
> > > From: [e-mail]
> > > [mailto:[e-mail]] On Behalf Of Graeme Lunt
> > > Sent: Wednesday, June 25, 2003 12:40 AM
> > > To: 'Sean P. Turner'
> > > Cc: 'ietf-smime'
> > > Subject: RE: Signed Receipts and Mail Lists
> > >
> > >
> > >
> > > Sean,
> > >
> > > > I'm not sure that the MLA returns a receipt on behalf of the ML
> > > > members.
> > >
> > > OK - if an MLA should not return signed receipts then there is not a
>
> > > problem with my scenario.
> > >
> > > > I looked through ESS again and I couldn't find anything
> > > that said if a
> > > > message enters an MLA with a signed receipt request that it
> > >
> > > > shouldn't or should return a receipt.
> > >
> > > Is an MLA considered a "receiving agent"/"receiving
> > > software"/"processing software" in section 2.3 of ESS? I had assumed
>
> > > that it was but agree it is unclear.
> > >
> > > > Typically (I think), originators want to know that the
> > > final recipient
> > > got
> > > > the message not whether the MLA got it.
> > >
> > > I think there are arguments for both. If an originator
> > sends a message
> > > to:
> > >
> > > [e-mail]
> > >
> > > the originator probably only wants to know that it got to the
> > > complaints department at bigbank. The originator doesn't want to
> > > know (and bigbank doesn't want to let the originator know) which
> > > individuals within bigbank read the message.
> > >
> > > > Then again maybe I didn't understand your scenario.
> > >
> > > I don't think the originator needs to understand if the addresses
> > > they are requesting signed receipts from are address lists or not.
> > > If an originator sends a message to two recipients - one a mail
> > > list, one an individual - and requests first tier signed receipts,
> > > they will never receive a signed receipt from the mail list
> > > recipient. The user may find this unexpected. Correlation software
> > > *may* be able to detect a mail list recipient and handle it
> > > appropriately.
> > >
> > >
> > > Graeme
> > >
> > >
> >
> >



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6NIFDqt059448 for <[e-mail]>; Wed, 23 Jul 2003 11:15:13 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6NIFDKf059447 for ietf-smime-bks; Wed, 23 Jul 2003 11:15:13 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6NIFBqt059437 for <[e-mail]>; Wed, 23 Jul 2003 11:15:11 -0700 (PDT) (envelope-from [e-mail])
Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by gamma.isi.edu (8.11.6p2/8.11.2) with ESMTP id h6NIEIJ09010; Wed, 23 Jul 2003 11:14:18 -0700 (PDT)
Message-Id: <[e-mail]>
To: IETF-Announce: ;
Subject: RFC 3565 on Use of the Advanced Encryption Standard (AES) Encryption Algorithm in Cryptographic Message Syntax (CMS)
Cc: [e-mail], [e-mail]
From: [e-mail]
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Wed, 23 Jul 2003 11:14:18 -0700
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 Request for Comments is now available in online RFC libraries.


        RFC 3565

        Title:      Use of the Advanced Encryption Standard (AES)
                    Encryption Algorithm in Cryptographic Message
                    Syntax (CMS)
        Author(s):  J. Schaad
        Status:     Standards Track
        Date:       July 2003
        Mailbox:    [e-mail]
        Pages:      14
        Characters: 26773
        Updates/Obsoletes/SeeAlso:  None

        I-D Tag:    draft-ietf-smime-aes-alg-07.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3565.txt


This document specifies the conventions for using the Advanced
Encryption Standard (AES) algorithm for encryption with the
Cryptographic Message Syntax (CMS).

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

This is now a Proposed Standard Protocol.

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.echo 
Submissions for Requests for Comments should be sent to
[e-mail].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.


Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

Below is the data which will enable a MIME compliant Mail Reader 
implementation to automatically retrieve the ASCII version
of the RFCs.

--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]>

RETRIEVE: rfc
DOC-ID: rfc3565

--OtherAccess
Content-Type:   Message/External-body;
        name="rfc3565.txt";
        site="ftp.isi.edu";
        access-type="anon-ftp";
        directory="in-notes"

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

--OtherAccess--
--NextPart--


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6NIFEqt059450 for <[e-mail]>; Wed, 23 Jul 2003 11:15:14 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6NIFDAL059449 for ietf-smime-bks; Wed, 23 Jul 2003 11:15:13 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6NIFBqt059438 for <[e-mail]>; Wed, 23 Jul 2003 11:15:12 -0700 (PDT) (envelope-from [e-mail])
Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by gamma.isi.edu (8.11.6p2/8.11.2) with ESMTP id h6NICMJ08546; Wed, 23 Jul 2003 11:12:22 -0700 (PDT)
Message-Id: <[e-mail]>
To: IETF-Announce: ;
Subject: RFC 3560 on Use of the RSAES-OAEP Key Transport Algorithm in the Cryptographic Message Syntax (CMS)
Cc: [e-mail], [e-mail]
From: [e-mail]
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Wed, 23 Jul 2003 11:12:22 -0700
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 Request for Comments is now available in online RFC libraries.


        RFC 3560

        Title:      Use of the RSAES-OAEP Key Transport Algorithm in
                    Cryptographic Message Syntax (CMS)
        Author(s):  R. Housley
        Status:     Standards Track
        Date:       July 2003
        Mailbox:    [e-mail]
        Pages:      18
        Characters: 37381
        Updates/Obsoletes/SeeAlso:  None

        I-D Tag:    draft-ietf-smime-cms-rsaes-oaep-07.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3560.txt


This document describes the conventions for using the RSAES-OAEP key
transport algorithm with the Cryptographic Message Syntax (CMS).  The
CMS specifies the enveloped-data content type, which consists of an
encrypted content and encrypted content-encryption keys for one or
more recipients.  The RSAES-OAEP key transport algorithm can be used
to encrypt content-encryption keys for intended recipients.

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

This is now a Proposed Standard Protocol.

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.echo 
Submissions for Requests for Comments should be sent to
[e-mail].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.


Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

Below is the data which will enable a MIME compliant Mail Reader 
implementation to automatically retrieve the ASCII version
of the RFCs.

--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]>

RETRIEVE: rfc
DOC-ID: rfc3560

--OtherAccess
Content-Type:   Message/External-body;
        name="rfc3560.txt";
        site="ftp.isi.edu";
        access-type="anon-ftp";
        directory="in-notes"

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

--OtherAccess--
--NextPart--


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6N0Woqt081045 for <[e-mail]>; Tue, 22 Jul 2003 17:32:50 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6N0Wo5U081044 for ietf-smime-bks; Tue, 22 Jul 2003 17:32:50 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [207.228.252.5]) by above.proper.com (8.12.9/8.12.8) with SMTP id h6N0Wnqt081039 for <[e-mail]>; Tue, 22 Jul 2003 17:32:49 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 27722 invoked by uid 0); 23 Jul 2003 00:31:26 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (12.159.173.193) by woodstock.binhost.com with SMTP; 23 Jul 2003 00:31:26 -0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Tue, 22 Jul 2003 13:33:57 -0400
To: Tim Moses <[e-mail]>, [e-mail]
From: Russ Housley <[e-mail]>
Subject: Re: In this day and age ...
In-Reply-To: <[e-mail] .com>
Mime-Version: 1.0
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>

Tim:

Please take a look at draft-ietf-smime-rfc2633bis-05.  I believe that you 
will see improvements in this area.

Russ

At 10:32 AM 7/18/2003 -0400, Tim Moses wrote:

>Colleagues - As I read RFC 2633, it uses normative language in Section 3.1
>when discussing content-transfer encoding applied to MIME content prior to
>security processing.  But, the language relating to content transfer
>encoding applied to protected content is not normative.  Section 3.2 says
>"Since CMS objects are binary data, in most cases base-64 transfer encoding
>is appropriate".  That sounds like a SHOULD.
>
>It seems to me that message-transfer agents commonly apply content-transfer
>encoding to 8-bit data.  I am unsure whether they do this selectively or
>whether they only apply it when needed.
>
>I wonder whether it is still necessary for S/MIME to "recommend" the
>application of content-transfer encoding to secured sub-parts.
>
>Can anyone offer an informed view?  Thanks a lot.  All the best.  Tim.
>
>-----------------------------------------------------------------
>Tim Moses
>613.270.3183



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6IEWnqt002964 for <[e-mail]>; Fri, 18 Jul 2003 07:32:49 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6IEWniC002963 for ietf-smime-bks; Fri, 18 Jul 2003 07:32:49 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from sottmxssm.entrust.com (sottmxssm.entrust.com [216.191.252.10]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6IEWlqt002957 for <[e-mail]>; Fri, 18 Jul 2003 07:32:48 -0700 (PDT) (envelope-from [e-mail])
Received: from sottguard01.entrust.com (sottguard01.entrust.com [10.4.61.249]) by sottmxssm.entrust.com (Switch-2.2.6/Switch-2.2.4) with SMTP id V6IE0T7N14914 for <[e-mail]>; Fri, 18 Jul 2003 10:29:07 -0400
Received: (qmail 4724 invoked by uid 64014); 18 Jul 2003 14:26:50 -0000
Received: from [e-mail] by sottguard01.entrust.com with AmikaGuardian-Server-1.1.2 (Processed in 0.255903 secs); 18 Jul 2003 14:26:50 -0000
Received: from unknown (HELO SOTTMXS01.entrust.com) (10.4.61.7) by sottguard01.entrust.com with SMTP; 18 Jul 2003 14:26:49 -0000
Received: by sottmxs01.entrust.com with Internet Mail Service (5.5.2656.59) id <PFK4KBA4>; Fri, 18 Jul 2003 10:32:42 -0400
Message-ID: <[e-mail]>
From: Tim Moses <[e-mail]>
To: "'S/MIME'" <[e-mail]>
Subject: In this day and age ...
Date: Fri, 18 Jul 2003 10:32:41 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain; charset="iso-8859-1"
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>

Colleagues - As I read RFC 2633, it uses normative language in Section 3.1
when discussing content-transfer encoding applied to MIME content prior to
security processing.  But, the language relating to content transfer
encoding applied to protected content is not normative.  Section 3.2 says
"Since CMS objects are binary data, in most cases base-64 transfer encoding
is appropriate".  That sounds like a SHOULD.

It seems to me that message-transfer agents commonly apply content-transfer
encoding to 8-bit data.  I am unsure whether they do this selectively or
whether they only apply it when needed.

I wonder whether it is still necessary for S/MIME to "recommend" the
application of content-transfer encoding to secured sub-parts.

Can anyone offer an informed view?  Thanks a lot.  All the best.  Tim.

-----------------------------------------------------------------
Tim Moses
613.270.3183


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6I32aqt042434 for <[e-mail]>; Thu, 17 Jul 2003 20:02:36 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6I32Z8r042433 for ietf-smime-bks; Thu, 17 Jul 2003 20:02:35 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from brutesquadlabs.com (gtec136-m.isomedia.com [207.115.67.136] (may be forged)) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6I32Yqt042412; Thu, 17 Jul 2003 20:02:34 -0700 (PDT) (envelope-from [e-mail])
Received: from DEXTER ([192.168.0.5]) by brutesquadlabs.com with ESMTP ; Thu, 17 Jul 2003 20:02:31 -0700
From: "Blake Ramsdell" <[e-mail]>
To: <[e-mail]>, "'Ietf-Smime-Examples'" <[e-mail]>, <[e-mail]>, <[e-mail]>
Cc: "'Sean P. Turner'" <[e-mail]>, "'Russ Housley'" <[e-mail]>
Subject: RE: Draft-11Parital Results
Date: Thu, 17 Jul 2003 20:02:31 -0700
Message-ID: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAA[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
In-Reply-To: <001301c34c2c$c04b2cd0$[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>

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Jim Schaad
> Sent: Wednesday, July 16, 2003 11:29 PM
> To: 'Blake Ramsdell'; [e-mail]; 
> 'Ietf-Smime-Examples'; [e-mail]; [e-mail]
> Cc: 'Sean P. Turner'; 'Russ Housley'
> Subject: RE: Draft-11Parital Results
> 
> What needs to
> be changed is the commentary not the message.

OK, then we need to come up with language.  Maybe:

A full S/MIME message, including MIME, that includes a MIME encoded
version of the body part from 5.1.

Blake



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6HBMhqt084239 for <[e-mail]>; Thu, 17 Jul 2003 04:22:44 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6HBMhJg084238 for ietf-smime-bks; Thu, 17 Jul 2003 04:22:43 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp002.bizmail.yahoo.com (smtp002.bizmail.yahoo.com [216.136.172.126]) by above.proper.com (8.12.9/8.12.8) with SMTP id h6HBMgqt084233 for <[e-mail]>; Thu, 17 Jul 2003 04:22:42 -0700 (PDT) (envelope-from [e-mail])
Received: from tweety.ietf57.telekom.at (HELO ieca.com) ([e-mail]@81.160.172.151 with plain) by smtp2.bm.vip.sc5.yahoo.com with SMTP; 17 Jul 2003 11:22:33 -0000
Message-ID: <[e-mail]>
Date: Thu, 17 Jul 2003 13:21:41 +0200
From: "Sean P. Turner" <[e-mail]>
Organization: IECA, Inc.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: SMIME <[e-mail]>
Subject: SMIME WG Summary
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
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>

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <title></title>
</head>
<body>
All,<br>
<br>
Here is a short summary of the agenda topics discussed at the meeting in
Austria:<br>
<br>
* MSGbis fixed some nits believe it is ready for security ADs and IETF-wide
last call<br>
* CERTbis text needs to be added for acknowledgements but after that it's
ready for security ADs and IETF-wide last call<br>
* Examples added 11 new cases all need to be verified<br>
* X400Trans and X400Wrap had minor comments from IESG, which have all been
addressed<br>
* Interoperability Matrix is completed but final report needs to be written<br>
* RSA PSS and CMS going to WG LC as soon as next version is produced<br>
* RSA KEM has 3 remaining issues but then ready for WG LC<br>
* ESSbis separating MLExpansiionHistory in to ReceiptBehavior and MLLoopDetection
is proving more difficult than expected<br>
* GOST algorithm for CMS will be published under WG<br>
* Peter Sylvester gave a presentation on OpenEvidence<br>
* Tim Polk gave pointers to NIST's Online SMIME tester<br>
<br>
 I hope to have meeting minutes out by next week some time.<br>
<br>
spt
</body>
</html>



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6H6Spqt044447 for <[e-mail]>; Wed, 16 Jul 2003 23:28:51 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6H6SpRX044446 for ietf-smime-bks; Wed, 16 Jul 2003 23:28:51 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6H6Smqt044426; Wed, 16 Jul 2003 23:28:48 -0700 (PDT) (envelope-from [e-mail])
Received: from ROMANS (unknown [81.160.64.139]) by smtp1.pacifier.net (Postfix) with ESMTP id F1EB670450; Wed, 16 Jul 2003 23:28:45 -0700 (PDT)
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: "'Blake Ramsdell'" <[e-mail]>, <[e-mail]>, "'Ietf-Smime-Examples'" <[e-mail]>, <[e-mail]>, <[e-mail]>
Cc: "'Sean P. Turner'" <[e-mail]>, "'Russ Housley'" <[e-mail]>
Subject: RE: Draft-11Parital Results
Date: Thu, 17 Jul 2003 08:29:14 +0200
Message-ID: <001301c34c2c$c04b2cd0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
In-Reply-To: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAA[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
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>

Blake,

I completely agree that it was discussed.  (I think I raised the issue.)
And I agree that the content for the message is correct.  What needs to
be changed is the commentary not the message.

jim

> -----Original Message-----
> From: Blake Ramsdell [mailto:[e-mail]] 
> Sent: Wednesday, July 16, 2003 10:15 PM
> To: [e-mail]; 'Ietf-Smime-Examples'; 
> [e-mail]; [e-mail]
> Cc: 'Sean P. Turner'; 'Russ Housley'
> Subject: RE: Draft-11Parital Results
> 
> 
> > -----Original Message-----
> > From: Jim Schaad [mailto:[e-mail]]
> > Sent: Wednesday, July 16, 2003 7:19 AM
> > To: Ietf-Smime-Examples; [e-mail]; [e-mail]
> > Cc: Sean P. Turner; Blake Ramsdell; Russ Housley
> > Subject: Draft-11Parital Results
> > 
> > 5.9  failed 
> > 	Commentary text states that the body part is the same 
> as 5.1 - this 
> > is not correct as the signature values and exContent are different
> > (content is actually "\0xd\0xaThis is some sample content."
> 
> This is something we discussed a bit ago -- the problem is 
> that ExContent.bin is not valid MIME data.  The compromise we 
> reached was that a CRLF would be inserted at the beginning, 
> which would make it valid MIME data (implicit text/plain).  
> When the MIME wrapping is removed, it results in ExContent.bin.
> 
> Blake
> 



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6GKFLqt005616 for <[e-mail]>; Wed, 16 Jul 2003 13:15:21 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6GKFLSH005615 for ietf-smime-bks; Wed, 16 Jul 2003 13:15:21 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from brutesquadlabs.com (gtec136-m.isomedia.com [207.115.67.136] (may be forged)) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6GKFKqt005608; Wed, 16 Jul 2003 13:15:20 -0700 (PDT) (envelope-from [e-mail])
Received: from DEXTER ([192.168.0.5]) by brutesquadlabs.com with ESMTP ; Wed, 16 Jul 2003 13:15:16 -0700
From: "Blake Ramsdell" <[e-mail]>
To: <[e-mail]>, "'Ietf-Smime-Examples'" <[e-mail]>, <[e-mail]>, <[e-mail]>
Cc: "'Sean P. Turner'" <[e-mail]>, "'Russ Housley'" <[e-mail]>
Subject: RE: Draft-11Parital Results
Date: Wed, 16 Jul 2003 13:15:16 -0700
Message-ID: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAA[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
In-Reply-To: <000e01c34ba5$38ac5150$[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>

> -----Original Message-----
> From: Jim Schaad [mailto:[e-mail]] 
> Sent: Wednesday, July 16, 2003 7:19 AM
> To: Ietf-Smime-Examples; [e-mail]; [e-mail]
> Cc: Sean P. Turner; Blake Ramsdell; Russ Housley
> Subject: Draft-11Parital Results
> 
> 5.9  failed 
> 	Commentary text states that the body part is the same as 5.1 -
> this is not correct as the signature values and exContent are 
> different
> (content is actually "\0xd\0xaThis is some sample content."

This is something we discussed a bit ago -- the problem is that
ExContent.bin is not valid MIME data.  The compromise we reached was
that a CRLF would be inserted at the beginning, which would make it
valid MIME data (implicit text/plain).  When the MIME wrapping is
removed, it results in ExContent.bin.

Blake



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6GEIfqt083989 for <[e-mail]>; Wed, 16 Jul 2003 07:18:41 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6GEIf1w083988 for ietf-smime-bks; Wed, 16 Jul 2003 07:18:41 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.173]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6GEIdqt083974; Wed, 16 Jul 2003 07:18:39 -0700 (PDT) (envelope-from [e-mail])
Received: from ROMANS (unknown [81.160.64.139]) by smtp3.pacifier.net (Postfix) with ESMTP id 5F87E6DF25; Wed, 16 Jul 2003 07:18:37 -0700 (PDT)
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: "Ietf-Smime-Examples" <[e-mail]>, <[e-mail]>, <[e-mail]>
Cc: "Sean P. Turner" <[e-mail]>, "Blake Ramsdell" <[e-mail]>, "Russ Housley" <[e-mail]>
Subject: Draft-11Parital Results
Date: Wed, 16 Jul 2003 16:19:04 +0200
Message-ID: <000e01c34ba5$38ac5150$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h6GEIdqt083975
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>

People,

Here is the current state of draft 11 with my testing.  I will continue
to fill out more of the data in the this table as I get some more items
debugged in my code.  I am still trying to figure out why I cannot do
DH.

jim


4.1 	pass
4.2	pass
5.1	pass
5.2	pass
5.3  -- not checked ---
5.4	pass with comments
	1.  certificates are Alice DSS, Carl DSS (root), Alice RSA
	2.  unsigned attributes are JUST counter signature
5.5	pass
5.6	--- not checked --  - structurally fine - Diane signature
unchecked
5.7  	pass
5.8  -- not checked --
	I have an assumption that the wrong signature OID is used in the
message.
5.9  failed 
	id-dsa is the signature algorithm not id-dsa-with-sha1
	Commentary text states that the body part is the same as 5.1 -
this is not correct as the signature values and exContent are different
(content is actually "\0xd\0xaThis is some sample content."
5.10  pass with comments
	List of attributes is
		1. content type
		2. message digest
		3. 1.2.5555 (unknown)
		4. content hint
		5. smime capabilities
		6. security label
		7. content reference
		8. encrypt key preference
		9. ML expansion history
		10. Equivalent label
5.11 	pass with comments
	Text should be Alice's and Carl's DSS certificates.

6.1	-- not checked --
6.2	passed
6.3 	passed with comments
	RC2/128 for the content encryption algorithm.
6.4	-- not checked --
6.5 	-- not checked --
6.6 	-- not checked --
6.7	-- not checked -- fail on the RC2/40 not clear what the source
is yet.
6.8	-- not checked --
6.9	failed
	Content hints says the content is 1.2.6.5.4 not id-data
6.10	-- not checked --
6.11	FAIL
	test vectors are appended below on this message.  I don't know
where I am going wrong and this code worked in the past.

7.0	pass

8.1	passed
8.2	passed with comment
	Need to specify that this uses the same key value as does 8.1

9	-- checked--

10.1	-- not checked --
10.2	-- not checked --


11.1	fails
	Text states signed with RSA, message signed with DSA
	DSA signature OID incorrect
	Receipt is going to cn="AliceRSA" and [e-mail]
- should alice be an RFC822 name?
11.2	-- not checked --
11.3  passed
11.4  passed
11.5  -- not checked -- 
11.6 	-- not checked --


**************************************** 6.11 intermediate data from my
test ****************
But it fails....

Wrapped key
0x0012F248  74 31 c0 45 51 4c 3c 2d 2e da 63 50 8b ae d4 ac
t1ÀEQL<-.ÚcP.®Ô¬
0x0012F258  64 cc 95 ae af cd 0f 8c b6 48 1f 0b 45 12 4d fb
dÌ.®¯Í..¶H..E.M.
0x0012F268  a4 ab c7 83 30 4b 69 ad                         ¤«Ç.0Ki­

Mail list key
0x00324354  25 5e 0d 1c 07 b6 46 df b3 13 4c c8 43 ba 8a a7
%^...¶Fß³.LÈCº.§
0x00324364  1f 02 5b 7c 08 38 25 1f

After decrypt #1
0x00324630  d7 10 66 ee 9a 42 e0 80 62 a3 e5 de b5 ef 4e 7e
×.f..B..b£.Þµ.N~
0x00324640  5f 13 30 b5 13 d3 a8 4f be dc 02 d4 81 27 db 50
_.0µ.Ó¨O¾Ü.Ô.'ÛP
0x00324650  e5 d8 0f e9 25 38 f1 7b                         .Ø..%8.{

IV
0x00324630  7b f1 38 25 e9 0f d8 e5                         {.8%..Ø.

Post Decrypt #2
0x00324630  50 db 27 81 d4 02 dc be 4f a8 d3 13 b5 30 13 5f
PÛ'.Ô.ܾO¨Ó.µ0._
0x00324640  7e 4e ef b5 de e5 a3 62 80 e0 42 9a ee 66 10 d7
~N.µÞ.£b..B..f.×

Computed check sum
0x0012EFD8  53 fb 3e cc 8a 06 cc af                         S.>Ì..̯

Actual Check sum
 80 e0 42 9a ee 66 10 d7

--- they don't match!!!!!




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6FDR1qt079641 for <[e-mail]>; Tue, 15 Jul 2003 06:27:01 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6FDR136079640 for ietf-smime-bks; Tue, 15 Jul 2003 06:27:01 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail4.consignia.com (mail4.consignia.com [144.87.143.84]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6FDR0qt079635 for <[e-mail]>; Tue, 15 Jul 2003 06:27:00 -0700 (PDT) (envelope-from [e-mail])
Received: from postoffice.co.uk (mta2.int.consignia.com [144.87.146.16]) by mail4.consignia.com (Postfix) with SMTP id 42CDF12278B for <[e-mail]>; Tue, 15 Jul 2003 14:27:00 +0100 (BST)
Received: by postoffice.co.uk(Lotus SMTP MTA v4.6.6  (890.1 7-16-1999))  id 00256D64.004F63F6 ; Tue, 15 Jul 2003 14:27:09 +0000
X-Lotus-FromDomain: POSTOFFICE
From: [e-mail]
To: [e-mail]
Message-ID: <[e-mail]>
Date: Tue, 15 Jul 2003 14:26:44 +0000
Subject: Re: (Practical) S/MIME certificate chain handling
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
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>

Jim,

apologies for the delay. I've been on vacation and have just salvaged
your email from the 800 or so spams that were waiting for me :-) I also
got over enthusiastic about my mail box management and succeeded in
deleting the original of this. The headers are munged because I recovered
this text from the IETF archive!

Jim Schaad wrote:

> I hope there is a great deal more to this than what you are stating for
> a Best Practice recommendation.

Indeed. I did say it was 'a' recommendation without alluding to the
others, some of which concern the management of the root CA certificate
store.

> 1.  Acceptance of root certificates by end-users is a real problem.
> They tend to say yes without any good reason to do so.  This means that
> it is easy to stick "bad" root certificates on a persons machine

I agree completely. At the organisation level, however, the management
of the Root CA store is a administrative policy issue rather than a
technical one. The inclusion of the trust chain with outgoing emails
facilitates the distribution of trust in the continued absence of a
global recovery mechanism. It does not preclude correct and secure usage
of such paths, in-line with policy, at the recipient device.

> If you are really working in a single structure, then this information
> should be automatically distributed to people's machines and not send
> from the sender.

By a single structure do you mean a single organisation or a single
trust tree ? Policy should certainly be managed centrally although I'm
unconvinced that many organisations really understand the future,
legal implications of permitting their end-users to grow their own Root
CA stores. As you imply, we are not yet anywhere near widespread, correct
usage. In the main this is due to the fact that Digital Certificates are
still being used in many areas merely as technology enablers rather than
the trust mechanisms that they are designed to be. As such, acceptance of
trust (and thus liability) by end users is too easy and uncontrolled and
simply allows the software to work rather than trust be maintained.

Chris


Royal Mail is a trading name of Royal Mail Group plc. Registered in England and
Wales.
Registered number 4138203. Registered office at 148 Old Street, LONDON EC1V 9HQ




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6FD99qt077311 for <[e-mail]>; Tue, 15 Jul 2003 06:09:09 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6FD9949077310 for ietf-smime-bks; Tue, 15 Jul 2003 06:09:09 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mx2.magma.ca (mx2.magma.ca [206.191.0.250]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6FD98qt077301 for <[e-mail]>; Tue, 15 Jul 2003 06:09:08 -0700 (PDT) (envelope-from [e-mail])
Received: from mail1.magma.ca (mail1.magma.ca [206.191.0.252]) by mx2.magma.ca Magma's Mail Server with ESMTP id h6FD97Nq017320; Tue, 15 Jul 2003 09:09:07 -0400
Received: from tony (ottawa-hs-209-217-122-183.s-ip.magma.ca [209.217.122.183]) by mail1.magma.ca (Magma's Mail Server) with ESMTP id h6FD8qFU023765; Tue, 15 Jul 2003 09:09:07 -0400
From: "Tony Capel" <[e-mail]>
To: "'Blake Ramsdell'" <[e-mail]>, <[e-mail]>
Subject: RE: Discussing RTCS
Date: Tue, 15 Jul 2003 09:08:56 -0400
Message-ID: <000601c34ad2$42a0ae00$01b5a8c0@tony>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
In-Reply-To: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAA[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h6FD98qt077304
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>

Blake:

I see potential value in a "CMS style" request/response format for a
certificate validation service.

Specifically one might imagine that a (signed) CMS data structure returned
by a validating server could be integrated directing within the CMS message
types.  This would require compatibility between the server response and
CMS.

I realise that Peter's proposal makes a big deal about its ability to use
simplified database lookups, yes/no responses, etc. and that this aspect has
prompted strong PKIX reactions.

However, the ability to use directly compatible CMS structures is the
attraction for me.  How the server is implemented is arguably an
implementation (or maybe PKIX) issue.

So, yes I would like to see some discussion on this topic here; and if
Peter's proposal is a way to do that fine - although I agree that if we
discuss it, we should do it co-operatively with PKIX.  That is, we should
address CMS compatibility issues (and how this service might be used by CMS)
and leave the server side to them.

Tony

| -----Original Message-----
| From: [e-mail] 
| [mailto:[e-mail]] On Behalf Of Blake Ramsdell
| Sent: June 27, 2003 5:12 PM
| To: [e-mail]
| Subject: Discussing RTCS
| 
| 
| 
| Peter Gutmann has made an individual draft submission for his 
| CMS-based RTCS protocol.  A URL to this draft is:
| 
http://www.ietf.org/internet-drafts/draft-gutmann-cms-rtcs-00.txt

He would like to get some review of the CMS parts of this, and it seems
reasonable to discuss it here on the IETF-SMIME list if there is interest.

Since this draft is CMS based and potentially adds value to CMS or S/MIME in
general, should we consider bringing it into this working group?

Comments?

Blake
--
Blake Ramsdell | Brute Squad Labs | http://www.brutesquadlabs.com 





Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6FD10qt075190 for <[e-mail]>; Tue, 15 Jul 2003 06:01:00 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6FD102r075189 for ietf-smime-bks; Tue, 15 Jul 2003 06:01:00 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6FD0vqt075145; Tue, 15 Jul 2003 06:00:58 -0700 (PDT) (envelope-from [e-mail])
Received: from [81.160.154.187] (ssh.bbn.com [192.1.50.70]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h6FCxwDD029536; Tue, 15 Jul 2003 09:00:07 -0400 (EDT)
Mime-Version: 1.0
X-Sender: kent@localhost
Message-Id: <p05200f04bb39a7534e0a@[81.160.154.187]>
In-Reply-To: <000301c34ab3$cb30a4b0$[e-mail]>
References: <000301c34ab3$cb30a4b0$[e-mail]>
Date: Tue, 15 Jul 2003 08:46:24 -0400
To: <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: Discussing RTCS
Cc: "'Denis Pinkas'" <[e-mail]>, "'Sean P. Turner'" <[e-mail]>, <[e-mail]>, "'pkix'" <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
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 11:30 +0200 7/15/03, Jim Schaad wrote:
>I agree with Denis, this is a certificate validation issue and as such
>belongs in the PKIX WG if to be standardized by the IETF.  I think that
>we can provide a review of the document if requested for it's usage of
>CMS, but not it's general suitablity.
>
>jim
>

Jim,

I agree with you and Denis that this is really a PKIX matter, vs. an 
S/MIME matter. However, I had several problems with Peter bringing 
this in as a WG item:
	- we already have OCSP and OCSPv2 has been worked on

	- this protocol goes beyond the OCSP semantics to provide 
delegated cert (not cert path) validation. we have just agreed to 
adopt SCVP for delegated cert path validation, and I was worried that 
this overlap would conflict with SCVP

	- PKIX has been told to not take on new work items


Steve


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6FB3Oqt063647 for <[e-mail]>; Tue, 15 Jul 2003 04:03:24 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6FB3O9p063646 for ietf-smime-bks; Tue, 15 Jul 2003 04:03:24 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6FB3Lqt063633; Tue, 15 Jul 2003 04:03:22 -0700 (PDT) (envelope-from [e-mail])
Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by hermes.cs.auckland.ac.nz (8.12.9/8.12.9) with ESMTP id h6FB2YYM012981; Tue, 15 Jul 2003 23:02:34 +1200
Received: (from pgut001@localhost) by medusa01.cs.auckland.ac.nz (8.11.6/8.11.6) id h6FB2We15157; Tue, 15 Jul 2003 23:02:32 +1200
Date: Tue, 15 Jul 2003 23:02:32 +1200
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: Discussing RTCS
Cc: [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>

Denis Pinkas <[e-mail]> writes:

>This is a topic to be addressed by the PKIX WG, not by the SMIME WG.

We already tried that, but you made sure it wouldn't work.

For those who aren't on the PKIX list, a short summary:

- Denis has some sort of rabid opposition to what RTCS does.  I had private
  mail from another PKIX member to say that RTCS' crime is that it provides a
  basic yes/no response rather than a CRL-style revoked/not revoked/maybe/
  maybe not response.  Someone else thought that it was because it made OCSP
  look bad.  I'm not sure what it really is.

- The result of this was a series of increasingly hysterical attacks by Denis
  on RTCS, using every reason he could dream up (see the PKIX list from late
  last year some time).  The highlights were him posting several messages in
  which he quoted sections of text and claimed the exact opposite of what the
  text said.  In one message I got a quote of him saying something wasn't
  possible, after which I had another quote of him saying the exact opposite
  earlier on.  You get the idea... the debate wasn't very coherent, or useful,
  except perhaps for amusement value.

- When his hissy fit on the list failed, he tried a private appeal to the WG
  chair to get it killed.

- The only (unfortunate) effect of his fit was that it drove most of the
  discussion into private mail, because no-one (apart from me apparently :-)
  wanted to become the target of his attacks.  I did, however, get some good
  feedback, which made it into the new draft.

So because of Denis it isn't really possible to have any coherent discussion
on the PKIX list.  My last message to him on that list was:

  It's obvious from your messages (and others have commented on this as well)
  that you've barely read the RTCS draft (if at all), and even then only to
  pick out bits to complain about.  The posting of obviously incorrect claims
  such as the ones cited above aren't helping your credibility much either.

As the next sentence from his current post shows:

  The advantages of this new protocol versus draft-ietf-pkix-ocspv2-ext-01.txt
  (Online Certificate Status Protocol, version 2) and the differences should
  be first explained.

he still hasen't actually read the draft.  Hint for Denis: The answer to your
question is in Section 2, right after the Abstract, which is section 1.  I'm
now pointing this out for the third (or fourth) time, but I doubt it'll make
any difference.

So to summarise: Denis has some sort of strong religious objection to RTCS.
He will engage in whatever hysterics he thinks necessary to attack it.  If
anyone wants to see the rest, see the PKIX thread on this (or wait for Denis'
next message).

Peter (sorry for the sarcasm and whatnot, but I was hoping he'd finalled given
       up after the last time... it's like listening to a broken record.  In
       the meantime, as ever, I welcome constructive feedback on RTCS).


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6F9UUqt055338 for <[e-mail]>; Tue, 15 Jul 2003 02:30:30 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6F9UUq2055337 for ietf-smime-bks; Tue, 15 Jul 2003 02:30:30 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.174]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6F9USqt055320; Tue, 15 Jul 2003 02:30:28 -0700 (PDT) (envelope-from [e-mail])
Received: from ROMANS (unknown [81.160.64.139]) by smtp4.pacifier.net (Postfix) with ESMTP id 9023D6A9C8; Tue, 15 Jul 2003 02:08:03 -0700 (PDT)
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: "'Denis Pinkas'" <[e-mail]>, "'Sean P. Turner'" <[e-mail]>
Cc: <[e-mail]>, "'pkix'" <[e-mail]>
Subject: RE: Discussing RTCS
Date: Tue, 15 Jul 2003 11:30:53 +0200
Message-ID: <000301c34ab3$cb30a4b0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
In-Reply-To: <[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
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 agree with Denis, this is a certificate validation issue and as such
belongs in the PKIX WG if to be standardized by the IETF.  I think that
we can provide a review of the document if requested for it's usage of
CMS, but not it's general suitablity.

jim

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Denis Pinkas
> Sent: Tuesday, July 15, 2003 10:29 AM
> To: Sean P. Turner
> Cc: [e-mail]; pkix
> Subject: Re: Discussing RTCS
> 
> 
> 
> Sean,
> 
> > Does anyone have an opinion on bringing this to the working group?
> 
> This is a topic to be addressed by the PKIX WG, not by the SMIME WG.
> 
> The PKIX WG is attempting (but not always succeeding) to 
> avoid duplication 
> of protocols for the same topic.
> 
> We all know that it would have been better to use CMS for 
> building the OCSP 
>   protocol, but this was not the case.
> 
> The advantages of this new protocol versus 
> draft-ietf-pkix-ocspv2-ext-01.txt 
> (Online Certificate Status Protocol, version 2) and the 
> differences should 
> be first explained.
> 
> Denis
> 
> 
> > spt
> > 
> > Blake Ramsdell wrote:
> > 
> >>Peter Gutmann has made an individual draft submission for his 
> >>CMS-based RTCS protocol.  A URL to this draft is:
> >>
> >>http://www.ietf.org/internet-drafts/draft-gutmann-cms-rtcs-00.txt
> >>
> >>He would like to get some review of the CMS parts of this, and it 
> >>seems reasonable to discuss it here on the IETF-SMIME list 
> if there is 
> >>interest.
> >>
> >>Since this draft is CMS based and potentially adds value to CMS or 
> >>S/MIME in general, should we consider bringing it into this working 
> >>group?
> >>
> >>Comments?
> >>
> >>Blake
> >>--
> >>Blake Ramsdell | Brute Squad Labs | http://www.brutesquadlabs.com
> >>
> >>  
> >>
> > 
> 
> 



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6F8Suqt045009 for <[e-mail]>; Tue, 15 Jul 2003 01:28:56 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6F8SuZL045008 for ietf-smime-bks; Tue, 15 Jul 2003 01:28:56 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6F8Shqt044980; Tue, 15 Jul 2003 01:28:44 -0700 (PDT) (envelope-from [e-mail])
Received: from clbull.frcl.bull.fr (IDENT:[e-mail] [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id KAA37988; Tue, 15 Jul 2003 10:33:13 +0200
Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.3/8.9.3) with ESMTP id KAA06126; Tue, 15 Jul 2003 10:28:44 +0200
Message-ID: <[e-mail]>
Date: Tue, 15 Jul 2003 10:28:32 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: "Sean P. Turner" <[e-mail]>
CC: [e-mail], pkix <[e-mail]>
Subject: Re: Discussing RTCS
References: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAA[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
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>

Sean,

> Does anyone have an opinion on bringing this to the working group?

This is a topic to be addressed by the PKIX WG, not by the SMIME WG.

The PKIX WG is attempting (but not always succeeding) to avoid duplication 
of protocols for the same topic.

We all know that it would have been better to use CMS for building the OCSP 
  protocol, but this was not the case.

The advantages of this new protocol versus draft-ietf-pkix-ocspv2-ext-01.txt 
(Online Certificate Status Protocol, version 2) and the differences should 
be first explained.

Denis


> spt
> 
> Blake Ramsdell wrote:
> 
>>Peter Gutmann has made an individual draft submission for his CMS-based
>>RTCS protocol.  A URL to this draft is:
>>
>>http://www.ietf.org/internet-drafts/draft-gutmann-cms-rtcs-00.txt
>>
>>He would like to get some review of the CMS parts of this, and it seems
>>reasonable to discuss it here on the IETF-SMIME list if there is
>>interest.
>>
>>Since this draft is CMS based and potentially adds value to CMS or
>>S/MIME in general, should we consider bringing it into this working
>>group?
>>
>>Comments?
>>
>>Blake
>>--
>>Blake Ramsdell | Brute Squad Labs | http://www.brutesquadlabs.com 
>>
>>  
>>
> 




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6EB4Pqt063044 for <[e-mail]>; Mon, 14 Jul 2003 04:04:25 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6EB4PIe063043 for ietf-smime-bks; Mon, 14 Jul 2003 04:04:25 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from brutesquadlabs.com (gtec136-m.isomedia.com [207.115.67.136] (may be forged)) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6EB4Oqt063036; Mon, 14 Jul 2003 04:04:24 -0700 (PDT) (envelope-from [e-mail])
Received: from DEXTER ([192.168.0.5]) by brutesquadlabs.com with ESMTP ; Mon, 14 Jul 2003 04:04:19 -0700
From: "Blake Ramsdell" <[e-mail]>
To: "'Paul Hoffman / IMC'" <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: RE: Status of the examples draft
Date: Mon, 14 Jul 2003 04:04:19 -0700
Message-ID: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAARMPfbnbp50SwK3EZjypY2MKAAAAQAAAAY/[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
In-Reply-To: <p05210609bb28ab8d2f11@[63.202.92.152]>
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>

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Paul Hoffman / IMC
> Sent: Wednesday, July 02, 2003 8:44 AM
> To: [e-mail]; [e-mail]
> Subject: Status of the examples draft
> 
> Hi again. The -11 draft has the following changes:

The comments that I posted regarding the -10 draft stand for the -11
draft, and I have included them below for completeness.

The only thing that I've had trouble with so far is 5.6.bin appears to
have changed the order of the SignerInfos.  I don't believe that this
change is relevant, so I don't think there needs to be any modification
of the draft.

The files I have worked with:

5.1.bin -- Identified as a CMS SignedData with signatures and content,
checked certificates were present, matched content to ExContent.bin,
verified one signer

5.2.bin -- Checked certificates were present, matched content to
ExContent.bin, verified one signer

5.3.bin -- Identified as a CMS SignedData with signatures and no
content, checked certificates were present, verified one signer against
external content in ExContent.bin

5.4.bin -- Extracted signing time attribute, checked certificates were
present, checked CRLs were present, matched content to ExContent.bin,
verified one signer

5.5.bin -- Checked certificates were present, matched content to
ExContent.bin, verified one signer

5.6.bin -- Checked certificates were present, matched content to
ExContent.bin, verified two signers

5.7.bin -- Checked certificates were present, matched content to
ExContent.bin, verified one signer

5.8.eml -- Parsed content with MIME parser, matched extracted text
content from text part to ExContent.bin, checked certificates were
present, verified one signer against first part of message, identified
as a CMS SignedData with signatures and no content

5.9.eml -- Parsed content with MIME parser, matched extracted text
content from text part to ExContent.bin, checked certificates were
present, verified one signer, identified as a CMS SignedData with
signatures and content

5.10.bin -- Matched content to ExContent.bin, verified one signer

5.11.bin -- Identified as a CMS SignedData with no signatures and no
content, checked certificates were present

6.2.bin -- Decrypted message, matched content to ExContent.bin,
identified as a CMS EnvelopedData

6.3.bin -- Decrypted message, matched content to ExContent.bin

7.0.bin -- Verified hash, matched content to ExContent.bin

8.1.bin -- Decrypted data with given key, matched content to
ExContent.bin


I also worked with the following certificates and private keys:

AliceDSSSignByCarlNoInherit.cer
AlicePrivRSASign.pri
AliceRSASignByCarl.cer
BobPrivRSAEncrypt.pri
BobRSASignByCarl.cer
CarlDSSCRLForAll.crl
CarlDSSSelf.cer
CarlPrivDSSSign.pri
CarlPrivRSASign.pri
CarlRSASelf.cer
DianeDHEncryptByCarl.cer
DianeDSSSignByCarlInherit.cer
DianePrivRSASignEncrypt.pri
DianeRSASignByCarl.cer
EricaDHEncryptByCarl.cer

Blake



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6EAJtqt059596 for <[e-mail]>; Mon, 14 Jul 2003 03:19:55 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6EAJtis059595 for ietf-smime-bks; Mon, 14 Jul 2003 03:19:55 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp002.bizmail.yahoo.com (smtp002.bizmail.yahoo.com [216.136.172.126]) by above.proper.com (8.12.9/8.12.8) with SMTP id h6EAJqqt059588 for <[e-mail]>; Mon, 14 Jul 2003 03:19:54 -0700 (PDT) (envelope-from [e-mail])
Received: from tweety.ietf57.telekom.at (HELO ieca.com) ([e-mail]@81.160.152.206 with plain) by smtp2.bm.vip.sc5.yahoo.com with SMTP; 14 Jul 2003 10:19:52 -0000
Message-ID: <[e-mail]>
Date: Mon, 14 Jul 2003 12:19:44 +0200
From: "Sean P. Turner" <[e-mail]>
Organization: IECA, Inc.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Discussing RTCS
References: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAA[e-mail]>
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
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>

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body>
Does anyone have an opinion on bringing this to the working group?<br>
<br>
spt<br>
<br>
Blake Ramsdell wrote:<br>
<blockquote type="cite"
 cite="mid!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAA[e-mail]">
  <pre wrap="">Peter Gutmann has made an individual draft submission for his CMS-based
RTCS protocol.  A URL to this draft is:

<a class="moz-txt-link-freetext" href="http://www.ietf.org/internet-drafts/draft-gutmann-cms-rtcs-00.txt">http://www.ietf.org/internet-drafts/draft-gutmann-cms-rtcs-00.txt</a>

He would like to get some review of the CMS parts of this, and it seems
reasonable to discuss it here on the IETF-SMIME list if there is
interest.

Since this draft is CMS based and potentially adds value to CMS or
S/MIME in general, should we consider bringing it into this working
group?

Comments?

Blake
--
Blake Ramsdell | Brute Squad Labs | <a class="moz-txt-link-freetext" href="http://www.brutesquadlabs.com">http://www.brutesquadlabs.com</a> 

  </pre>
</blockquote>
<br>
</body>
</html>



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h69Mcpqt027896 for <[e-mail]>; Wed, 9 Jul 2003 15:38:51 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h69McpYO027895 for ietf-smime-bks; Wed, 9 Jul 2003 15:38:51 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from brutesquadlabs.com (gtec136-m.isomedia.com [207.115.67.136] (may be forged)) by above.proper.com (8.12.9/8.12.8) with ESMTP id h69Mcoqt027889 for <[e-mail]>; Wed, 9 Jul 2003 15:38:50 -0700 (PDT) (envelope-from [e-mail])
Received: from DEXTER ([192.168.0.5]) by brutesquadlabs.com with ESMTP ; Wed, 9 Jul 2003 15:38:46 -0700
From: "Blake Ramsdell" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Cc: "'Sean P. Turner'" <[e-mail]>
Subject: REVISED S/MIME Working Group Agenda for the 57th IETF
Date: Wed, 9 Jul 2003 15:38:46 -0700
Message-ID: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAA[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
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>

Revised agenda for the S/MIME working group meeting at IETF 57.

Introductions                     (Sean Turner)
Working group status              (Sean Turner)
CMS and ESS examples update       (Paul Hoffman)
MSGbis and CERTbis update         (Blake Ramsdell)
X400Wrap and X400Transport update (Chris Bonatti)
Interoperability matrix update    (Jim Schaad)
PSS status                        (Jim Schaad)
KEM overview                      (Jim Schaad)
ESSbis overview                   (Jim Schaad)
GOST overview                     (Gregory S. Chudov)
Project OpenEvidence and ESS      (Peter Sylvester)
Wrap up                           (Sean Turner)

Blake
--
Blake Ramsdell | Brute Squad Labs | http://www.brutesquadlabs.com 



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h69ENlqt098848 for <[e-mail]>; Wed, 9 Jul 2003 07:23:47 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h69ENlri098847 for ietf-smime-bks; Wed, 9 Jul 2003 07:23:47 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h69ENiqt098836; Wed, 9 Jul 2003 07:23:45 -0700 (PDT) (envelope-from [e-mail])
Received: from clbull.frcl.bull.fr (IDENT:[e-mail] [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id QAA33082; Wed, 9 Jul 2003 16:28:17 +0200
Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.3/8.9.3) with ESMTP id QAA07578; Wed, 9 Jul 2003 16:23:47 +0200
Message-ID: <[e-mail]>
Date: Wed, 09 Jul 2003 16:23:41 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: pkix <[e-mail]>, S-MIME / IETF <[e-mail]>
Subject: Policy Requirements for Attribute Authorities
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h69ENkqt098837
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>

ETSI is making available a draft document for public comments called:
"Policy requirements for certification service providers issuing Attribute 
Certificates".

The document is available at the following URL:
http://docbox.etsi.org/ESI/Open/ETSI%20TS%20102_158%20v01.zip

This document has been approved by ETSI Technical Committee - Electronic 
Signatures and Infrastructures for public review.  Comments are invited on 
it, to be submitted to the editor and/or the task leader by 2003.08.24.

Editor: Denis Pinkas <[e-mail]>
Task leader: Franco Ruggieri <[e-mail]>

Do not send your comments to the PKIX or to the SMIME mailing list.

This will allow the consolidation by 2003.09.07 of a final draft to be 
approved for publication at TC ESI # 05 in Sophia Antipolis, 23 – 24 
September 2003 as ETSI Technical Specification (TS) 102 158.

If you choose to place your comments in-line in the text of the document 
please return them under the same file name with the addition "&your initials".

If you are aware of other public lists whose members might benefit from 
awareness of this document and have their own views to offer, please feel 
free to forward the document to them with copy of this message.

Regards,

Denis Pinkas. Document editor.
Franco Ruggieri. Task leader.





Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h67NJHqt000558 for <[e-mail]>; Mon, 7 Jul 2003 16:19:17 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h67NJHPn000557 for ietf-smime-bks; Mon, 7 Jul 2003 16:19:17 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from brutesquadlabs.com (gtec136-m.isomedia.com [207.115.67.136] (may be forged)) by above.proper.com (8.12.9/8.12.8) with ESMTP id h67NJGqt000549 for <[e-mail]>; Mon, 7 Jul 2003 16:19:16 -0700 (PDT) (envelope-from [e-mail])
Received: from DEXTER ([192.168.0.5]) by brutesquadlabs.com with ESMTP ; Mon, 7 Jul 2003 16:19:13 -0700
From: "Blake Ramsdell" <[e-mail]>
To: <[e-mail]>
Cc: "'Sean P. Turner'" <[e-mail]>
Subject: Text conferencing at IETF 57
Date: Mon, 7 Jul 2003 16:19:13 -0700
Message-ID: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAARMPfbnbp50SwK3EZjypY2MKAAAAQAAAAzapNg5K/[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
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 following is information about XMPP conferencing at IETF 57.  In
order for us to participate, we will need a scribe.  Any volunteers,
please stand up...

Blake

	     Remote Access for the 57th IETF meeting in Vienna:
                             Text Conferencing

At each IETF meeting, two of the working group meeting rooms are
equipped
for video multicast and remote participation.  That is, for every IETF
meeting slot, two of the working groups can see and hear the
meeting. For the 57th IETF, in *addition* to the usual network A/V, text
conferencing will be provided for every working group that meets.

All of the conference rooms will be hosted on

    ietf.jabber.at

and each is named using the official IETF abbreviation found in the
agenda (e.g., "apparea",  "dhc", "forces", and so on -- for all the
examples that follow, we'll use "foobar" as the abbreviation).

Each conference room also has a 'bot which records everything that gets
sent. So, the minute taker can review this information right after the
meeting.

In addition to the conference rooms for each wg that is meeting, there
are three others of general interest: bar, hallway, and plenary.
    

1. Before the meeting:

1.1. If you want to participate
    
If you don't already have one, get yourself a Jabber client, here are
some
suggestions:

    platform    suggestion
    --------    ----------
    win32       http://exodus.jabberstudio.org
    'nix        http://gabber.sf.net
    macos       http://jabberfox.sf.net

When you start the client for the first time, it will eventually ask if
you want to register on a public server. Go ahead and do
that. 
    
If you want to find out more, instead of choosing these defaults, here
are pointers to some additional information:
    
    list of clients:    http://www.jabber.org/user/clientlist.php
              howto:    http://www.jabber.org/user/userguide/
        server list:    http://www.jabber.org/user/publicservers.php

To make sure everything is running ok, do a "Join Group Chat" with your
Jabber client:
    
    Group/Room: testing
    Server:     conference.ietf.jabber.com

This conference room is up and running right now (although probably no
one will be in it when you connect).
    
1.2. What the Chair does
    
If you want to make text conferencing available, you'll need to have a
volunteer scribe in the meeting room. The scribe will be typing in a
running commentary as to what's going on in the room (who's presenting,
what question is being asked, etc.)
    
So, why not send an email out on the mailing list now, before the
meeting, to ask for volunteers?
    
    
2. At the meeting

2.1. What the Chair does

When a session starts, the chair asks if someone in the room is willing
to act as "scribe". If no one volunteers, read no further, we're done!

Otherwise, the scribe should do a "Join Group Chat" with their Jabber
client, e.g.,

    Group/Room: foobar
    Server:     conference.ietf.jabber.com


2.2. What the Scribe does

The scribe types in a running commentary as to what's going on in the
room. For example, if a speaker makes a presentation, the scribe types
in the URL for the presentation (more on this in a bit).

Simlarly, during question time, a remote participant can type a question
into the room and the scribe can pass it on to the speaker.


2.3. What each Presenter does

Each presenter should put a copy of their presentation on a web server
somewhere, so remote participants can follow along. 
    

2.4. Where to find the conference log
    
[ tbd ]
    
                                  #######
--
Blake Ramsdell | Brute Squad Labs | http://www.brutesquadlabs.com 



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h665VOqt013827 for <[e-mail]>; Sat, 5 Jul 2003 22:31:24 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h665VOom013826 for ietf-smime-bks; Sat, 5 Jul 2003 22:31:24 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from brutesquadlabs.com (gtec136-m.isomedia.com [207.115.67.136] (may be forged)) by above.proper.com (8.12.9/8.12.8) with ESMTP id h665VNqt013819 for <[e-mail]>; Sat, 5 Jul 2003 22:31:23 -0700 (PDT) (envelope-from [e-mail])
Received: from DEXTER ([192.168.0.5]) by brutesquadlabs.com with ESMTP ; Sat, 5 Jul 2003 22:31:21 -0700
From: "Blake Ramsdell" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Cc: "'Sean P. Turner'" <[e-mail]>, "Housley, Russ" <[e-mail]>
Subject: S/MIME Working Group Agenda for the 57th IETF
Date: Sat, 5 Jul 2003 22:31:20 -0700
Message-ID: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAARMPfbnbp50SwK3EZjypY2MKAAAAQAAAATh+vk8BwM0af/[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
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>

Here is the agenda for the S/MIME working group meeting at IETF 57.

Introductions                  (Sean Turner)
Working group status           (Sean Turner)
CMS and ESS examples update    (Paul Hoffman)
MSGbis and CERTbis update      (Blake Ramsdell)
Interoperability matrix update (Jim Schaad)
KEM overview                   (Jim Schaad)
PSS status                     (Jim Schaad)
ESSbis overview                (Jim Schaad)
GOST overview                  (Gregory S. Chudov)
Wrap up                        (Sean Turner)

Blake
--
Blake Ramsdell | Brute Squad Labs | http://www.brutesquadlabs.com 



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h65Ma5qt005458 for <[e-mail]>; Sat, 5 Jul 2003 15:36:05 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h65Ma5Is005457 for ietf-smime-bks; Sat, 5 Jul 2003 15:36:05 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.174]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h65Ma4qt005452 for <[e-mail]>; Sat, 5 Jul 2003 15:36:04 -0700 (PDT) (envelope-from [e-mail])
Received: from ROMANS (ip237.c132.blk1.bel.nwlink.com [209.20.132.237]) by smtp4.pacifier.net (Postfix) with ESMTP id 84C956AA2D; Sat,  5 Jul 2003 15:14:06 -0700 (PDT)
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: "'Blake Ramsdell'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: proposed addition to application/pkcs7-mime smime parameter
Date: Sat, 5 Jul 2003 15:36:29 -0700
Message-ID: <00a301c34345$e13e5970$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
In-Reply-To: <00a801c33d34$976fdbf0$[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>

Blake,

In the process of looking at ESS, I notice that there is an smime-type
defined there.  So it appears that MSG will not contain the definitive
list no matter what is done.  I would like it to contain the definitive
list of all of CMS however.

jim

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Jim Schaad
> Sent: Friday, June 27, 2003 10:18 PM
> To: 'Blake Ramsdell'; [e-mail]
> Cc: [e-mail]
> Subject: RE: proposed addition to application/pkcs7-mime 
> smime parameter
> 
> 
> 
> Blake,
> 
> 
> > I see a few ways to proceed, in my personal preference order:
> > 
> > 1. Commit to the current direction of using the MSG draft to
> > define how to use MIME with everything in CMS, as well as 
> > providing a constrained subset of CMS for the purpose of 
> > interpersonal messaging.
> > 
> > 2. Don't put anything in MSG at all that doesn't have to do
> > with interpersonal messaging, but leave what's there (the 
> > definition of the application/pkcs7-mime and the currently 
> > used smime-types).  Any additional smime-type values are 
> > defined outside of the MSG draft.
> > 
> > 3. Separate everything that has to do with the MIME wrapping
> > of CMS objects into its own draft (CMS/MIME), and don't 
> > discuss anything about interpersonal messaging at all.  The 
> > MSG draft simply contains references to the CMS/MIME draft, 
> > and is a profile of it.  This is somewhat like the separation 
> > of CMS and CMSALG, I think.
> > 
> > I will admit that my preference order is influenced by my
> > role as the editor, and the desire to see MSG progress sooner 
> > rather than later.
> 
> I have one argument for varient 3 that I just thought of that 
> might be overwelming at a later date, but certiantly not 
> currently.  If SIP is dependent on the CMS/SMIME/Messaging 
> draft, and we update that draft for a messaging only item, 
> then SIP gets reset on its progression path as well.  I don't 
> think this is an immeadiate issue, but something to consider 
> in the future.
> 
> If we go with the version 1 draft, then we should perhaps 
> look at reorginaizing the draft along the lines of looking 
> like a profile of a previously defined item rather than 
> having items intermixed.  I have not looked at the documents 
> to see how intermixed messaging is with the document and will 
> do so later this weekend.
> 
> > 
> > Blake
> > 
> 
> Jim
> 



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h65M7Lqt003770 for <[e-mail]>; Sat, 5 Jul 2003 15:07:21 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h65M7LdF003769 for ietf-smime-bks; Sat, 5 Jul 2003 15:07:21 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h65M7Eqt003763 for <[e-mail]>; Sat, 5 Jul 2003 15:07:14 -0700 (PDT) (envelope-from [e-mail])
Received: from ROMANS (ip237.c132.blk1.bel.nwlink.com [209.20.132.237]) by smtp1.pacifier.net (Postfix) with ESMTP id 95CD76FF7E; Sat,  5 Jul 2003 15:07:15 -0700 (PDT)
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: "'Blake Ramsdell'" <[e-mail]>, <[e-mail]>
Cc: "'Gregory S. Chudov'" <[e-mail]>
Subject: RE: GOST with CMS
Date: Sat, 5 Jul 2003 15:07:39 -0700
Message-ID: <009d01c34341$da1880c0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
In-Reply-To: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAARMPfbnbp50SwK3EZjypY2MKAAAAQAAAAbWMMVYx/[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>

Please note that the link below was broken in half during transport to
my machine.


http://www.ietf.org/internet-drafts/draft-leontiev-cryptopro-cpcms-00.tx
t

jim

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Blake Ramsdell
> Sent: Wednesday, July 02, 2003 8:16 AM
> To: [e-mail]
> Cc: 'Gregory S. Chudov'
> Subject: GOST with CMS
> 
> 
> 
> A new draft is available, profiling the use of the Russian 
> national cryptography standards (GOST) in CMS:
> 
> Title: Cryptographic Message Syntax (CMS) algorithms for GOST 
> 28147-89, GOST R 34.10-94, GOST R 34.10-2001, GOST R 34.11-94.
> 
> Authors: Serguei Leontiev, Vladimir Popov
> 
> Filename: draft-leontiev-cryptopro-cpcms-00.txt
> 
http://www.ietf.org/internet-drafts/draft-leontiev-cryptopro-cpcms-00.tx
t

Gregory Chudov has asked to introduce this draft to the group at the
next working group meeting, and we will be providing him with some time
to do that.  I presume that this draft will become a draft of the
working group in the next revision.

Blake
--
Blake Ramsdell | Brute Squad Labs | http://www.brutesquadlabs.com 



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h64GrLqt004301 for <[e-mail]>; Fri, 4 Jul 2003 09:53:21 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h64GrLpD004300 for ietf-smime-bks; Fri, 4 Jul 2003 09:53:21 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from sottmxssm.entrust.com (sottmxssm.entrust.com [216.191.252.10]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h64GrKqt004282 for <[e-mail]>; Fri, 4 Jul 2003 09:53:20 -0700 (PDT) (envelope-from [e-mail])
Received: from sottguard01.entrust.com (sottguard01.entrust.com [10.4.61.249]) by sottmxssm.entrust.com (Switch-2.2.6/Switch-2.2.4) with SMTP id V64G3DBD27672 for <[e-mail]>; Fri, 04 Jul 2003 12:49:47 -0400
Received: (qmail 13035 invoked by uid 64014); 4 Jul 2003 16:48:05 -0000
Received: from [e-mail] by sottguard01.entrust.com with AmikaGuardian-Server-1.1.2 (Processed in 0.252055 secs); 04 Jul 2003 16:48:05 -0000
Received: from unknown (HELO SOTTMXS01.entrust.com) (10.4.61.7) by 10.4.61.249 with SMTP; 4 Jul 2003 16:48:05 -0000
Received: by sottmxs01.entrust.com with Internet Mail Service (5.5.2656.59) id <MX4BR338>; Fri, 4 Jul 2003 12:53:14 -0400
Message-ID: <[e-mail]>
From: Darrell Dykstra <[e-mail]>
To: "'Blake Ramsdell'" <[e-mail]>, "'Julien Stern'" <[e-mail]>, [e-mail], [e-mail]
Subject: RE: (Practical) S/MIME certificate chain handling
Date: Fri, 4 Jul 2003 12:53:07 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain
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 believe that most clients transmit the certificate chain (not 
> > including the root) today.
> 
> To the best of my knowledge, Outlook does not, and it has
> quite a large
> market share ... (Although, I'd be happy to know how to make 
> it do so if
> there is a way ;) ).

I believe an end user can configure to some degree, which certificates are
sent in a signed message.  To access the UI in Outlook 2002, go to
Tools/Options/Security/Settings...  There should be a check box for "Send
these certificates with signed messages".  I have not verified as to what
exactly this checkbox controls (I am in a strict 1 level hierarchy so I
can't verify if sub-CA's are included without some prep work).  I would
think that, despite its naming, Outlook 2002 will always send the signer's
certs, and depending on the state of the checkbox, the chain from the
signer's certs to a trusted root.

Can anybody confirm or deny my theory (do you have a more complex hierarchy
to test with)?

Thanks,
Darrell


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h64GG8qt099805 for <[e-mail]>; Fri, 4 Jul 2003 09:16:08 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h64GG6PV099802 for ietf-smime-bks; Fri, 4 Jul 2003 09:16:06 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from kraid.nerim.net (smtp-105-friday.nerim.net [62.4.16.105]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h64GG4qt099785 for <[e-mail]>; Fri, 4 Jul 2003 09:16:05 -0700 (PDT) (envelope-from [e-mail])
Received: from jupiter.cry.pto (cryptolog.net1.nerim.net [80.65.224.225]) by kraid.nerim.net (Postfix) with ESMTP id 6A28D40F0A; Fri,  4 Jul 2003 18:07:16 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by jupiter.cry.pto (Postfix) with ESMTP id 7724E40F5; Fri,  4 Jul 2003 18:07:12 +0200 (CEST)
Received: from jupiter.cry.pto ([127.0.0.1]) by localhost (jupiter [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 06213-09; Fri,  4 Jul 2003 18:07:12 +0200 (CEST)
Received: from callisto.cry.pto (callisto.cry.pto [10.0.1.4]) by jupiter.cry.pto (Postfix) with SMTP id 452F540E7; Fri,  4 Jul 2003 18:07:12 +0200 (CEST)
Received: by callisto.cry.pto (sSMTP sendmail emulation); Fri,  4 Jul 2003 18:07:12 +0200
From: "Julien Stern" <[e-mail]>
Date: Fri, 4 Jul 2003 18:07:12 +0200
To: Blake Ramsdell <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: Re: (Practical) S/MIME certificate chain handling
Message-ID: <[e-mail]>
References: <[e-mail]> <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAARMPfbnbp50SwK3EZjypY2MKAAAAQAAAAHQr9HqmMOESm/[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAARMPfbnbp50SwK3EZjypY2MKAAAAQAAAAHQr9HqmMOESm/[e-mail]>
User-Agent: Mutt/1.5.4i
X-Virus-Scanned: by amavisd-new-20030314-p2 (Debian) at example.com
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>

On Mon, Jun 30, 2003 at 03:40:01PM -0700, Blake Ramsdell wrote:
> 
> > -----Original Message-----
> > From: [e-mail] 
> > [mailto:[e-mail]] On Behalf Of Julien Stern
> > Sent: Monday, June 30, 2003 3:35 AM
> > To: Blake Ramsdell; [e-mail]; [e-mail]
> > Subject: Re: (Practical) S/MIME certificate chain handling
> > 
> > > I believe that most clients transmit the certificate chain (not
> > > including the root) today.
> > 
> > To the best of my knowledge, Outlook does not, and it has 
> > quite a large
> > market share ... (Although, I'd be happy to know how to make 
> > it do so if
> > there is a way ;) ).
> 
> Outlook 2002 sends all the certificates in the chain (I just verified
> this).  When Jim Schaad wrote the code way back in something like
> Outlook 97, I'm fairly certain that it sent all the certificates also.
> This could very well be a case of misconfiguration of some sort, and I'd
> be happy to work through it with you offline.  The early S/MIME
> implementations all understood the utility of this, and included the
> certificates for exactly the reasons that you cite.

We did a bit of research, and it seems that, for Outlook, if
intermediate certificates are stored in the local machine stores, they
are indeed sent. However, if these certificates are stored in the user
stores (the ones in the user profile) they are not sent, despite the
fact the chain is correctly reconstructed. This behavior is different
from the one in Outlook Express.

> [many things regarding automatic verification snipped]

Regarding the rest of this thread, thanks to all for your enlightening
replies. I guess I'll take the pragmatic approach and attempt to focus
on the settings that actually work ;) And hopefully, at some point, I
will have the insurance that, given the extensions in my chain of cert,
and the available servers, _any_ S/MIME compliant receiver will indeed
be able to verify everything automatically, including revocation...

--
Julien


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h62KXiFK082593 for <[e-mail]>; Wed, 2 Jul 2003 13:33:44 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h62KXiHH082592 for ietf-smime-bks; Wed, 2 Jul 2003 13:33:44 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h62KXgFK082587 for <[e-mail]>; Wed, 2 Jul 2003 13:33:43 -0700 (PDT) (envelope-from [e-mail])
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13167; Wed, 2 Jul 2003 16:33:41 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-smime-x400transport-08.txt
Date: Wed, 02 Jul 2003 16:33:41 -0400
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		: Transporting S/MIME Objects in X.400
	Author(s)	: P. Hoffman, C. Bonatti
	Filename	: draft-ietf-smime-x400transport-08.txt
	Pages		: 6
	Date		: 2003-7-2
	
This document describes protocol options for conveying CMS-protected
objects associated with S/MIME version 3 over an X.400 message transfer
system.

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-x400transport-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-x400transport-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-x400transport-08.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-smime-x400transport-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 above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h62KXgFK082585 for <[e-mail]>; Wed, 2 Jul 2003 13:33:42 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h62KXgpH082584 for ietf-smime-bks; Wed, 2 Jul 2003 13:33:42 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h62KXdFK082576 for <[e-mail]>; Wed, 2 Jul 2003 13:33:40 -0700 (PDT) (envelope-from [e-mail])
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13145; Wed, 2 Jul 2003 16:33:37 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-smime-x400wrap-07.txt
Date: Wed, 02 Jul 2003 16:33:37 -0400
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		: Securing X.400 Content with S/MIME
	Author(s)	: P. Hoffman, C. Bonatti, A. Eggen
	Filename	: draft-ietf-smime-x400wrap-07.txt
	Pages		: 11
	Date		: 2003-7-2
	
This document describes a protocol for adding cryptographic signature
and encryption services to X.400 content.

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-x400wrap-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-x400wrap-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-x400wrap-07.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-smime-x400wrap-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 above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h62KXaFK082571 for <[e-mail]>; Wed, 2 Jul 2003 13:33:36 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h62KXaqr082570 for ietf-smime-bks; Wed, 2 Jul 2003 13:33:36 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h62KXYFK082565 for <[e-mail]>; Wed, 2 Jul 2003 13:33:34 -0700 (PDT) (envelope-from [e-mail])
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13125; Wed, 2 Jul 2003 16:33:32 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-smime-rfc2633bis-05.txt
Date: Wed, 02 Jul 2003 16:33:32 -0400
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		: S/MIME Version 3.1 Message Specification
	Author(s)	: B. Ramsdell
	Filename	: draft-ietf-smime-rfc2633bis-05.txt
	Pages		: 0
	Date		: 2003-7-2
	
S/MIME (Secure/Multipurpose Internet Mail Extensions) provides a
consistent way to send and receive secure MIME data. Based on the
popular Internet MIME standard, S/MIME provides the following
cryptographic security services for electronic messaging applications:
authentication, message integrity and non-repudiation of origin (using
digital signatures) and data confidentiality (using encryption).

S/MIME can be used by traditional mail user agents (MUAs) to add
cryptographic security services to mail that is sent, and to interpret
cryptographic security services in mail that is received. However,
S/MIME is not restricted to mail; it can be used with any transport
mechanism that transports MIME data, such as HTTP. As such, S/MIME
takes advantage of the object-based features of MIME and allows secure
messages to be exchanged in mixed-transport systems.

Further, S/MIME can be used in automated message transfer agents that
use cryptographic security services that do not require any human
intervention, such as the signing of software-generated documents and
the encryption of FAX messages sent over the Internet.

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-rfc2633bis-05.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-rfc2633bis-05.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-rfc2633bis-05.txt

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

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

--OtherAccess--

--NextPart--




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h62FiXFK066678 for <[e-mail]>; Wed, 2 Jul 2003 08:44:33 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h62FiXJW066677 for ietf-smime-bks; Wed, 2 Jul 2003 08:44:33 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from [63.202.92.152] (adsl-63-202-92-152.dsl.snfc21.pacbell.net [63.202.92.152]) (authenticated bits=0) by above.proper.com (8.12.9/8.12.8) with ESMTP id h62FiSFN066656; Wed, 2 Jul 2003 08:44:30 -0700 (PDT) (envelope-from [e-mail])
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05210609bb28ab8d2f11@[63.202.92.152]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
X-Habeas-SWE-1: winter into spring
X-Habeas-SWE-2: brightly anticipated
X-Habeas-SWE-3: like Habeas SWE (tm)
X-Habeas-SWE-4: Copyright 2002 Habeas (tm)
X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this
X-Habeas-SWE-6: email in exchange for a license for this Habeas
X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant
X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this
X-Habeas-SWE-9: mark in spam to <http://www.habeas.com/report>.
Date: Wed, 2 Jul 2003 08:44:28 -0700
To: [e-mail], [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: Status of the examples draft
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>

Hi again. The -11 draft has the following changes:
5.1.bin
5.3.bin
5.4.bin
5.6.bin
5.7.bin
5.10.bin
8.2.bin
11.1.bin
11.2.bin

It would be great if everyone who has tested can re-test with these 
new examples.

BTW, I forgot to change the title of 6.3 to say RC2/128, and will do 
so in the -12 draft. (Just to be sure, I have already started the -12 
draft so I don't space out again...)

I would like to update the chart below for the -11 draft soon so we 
can move it to IETF last call.

======================================

Status of the examples in -10

4. Trivial Examples

4.1 ContentInfo with Data type, BER
   John Pawling: tested OK.
   Jim Schaad: tested OK.
   Jeff Jacoby: tested OK.
   Holger Ebel: tested OK.

4.2 ContentInfo with Data type, DER
   John Pawling: tested OK.
   Jim Schaad: tested OK.
   Jeff Jacoby: tested OK.
   Holger Ebel: tested OK.

5.  Signed-data
   Jim Schaad pointed out that many examples had the
     signatureAlgorithm of 1.2.840.10040.4.1 (dsa) but it should instead
     be 1.2.840.10040.4.3 (dsaWithSha1).
   The general decision was that the examples should have dsaWithSha1.
   John Pawling and Sue Beauchamp at DigitalNet agreed to re-generate
     the examples.

5.1 Basic signed content, DSS
   John Pawling: tested OK.
   Blake Ramsdell: tested OK.
   Jim Schaad: failed.
     signatureAlgorithm is dsa but should be dsaWithSha1
   Holger Ebel: tested OK.
   Sue Beauchamp sent new example file.

5.2 Basic signed content, RSA
   John Pawling: tested OK.
   Blake Ramsdell: tested OK.
   Jim Schaad: tested OK.
   Jeff Jacoby: tested OK.
   Holger Ebel: tested OK.

5.3 Basic signed content, detached content
   John Pawling: tested OK.
   Blake Ramsdell: tested OK.
   Jim Schaad: failed.
	Contains Alice's RSA certificate
	No content hint unsigned attribute
     signatureAlgorithm is dsa but should be dsaWithSha1
   Jeff Jacoby: tested OK.
   Holger Ebel: tested OK.
   Sue Beauchamp sent new example file.

5.4 Fancier signed content
   John Pawling: tested OK.
   Blake Ramsdell: tested OK.
   Jeff Jacoby: tested OK.
   Holger Ebel: tested OK.
     Countersigner is Alice, not Diane
     No content hint
   Sue Beauchamp sent new example file.

5.5 All RSA signed message
   John Pawling: tested OK.
   Blake Ramsdell: tested OK.
   Jim Schaad: tested OK.
   Jeff Jacoby: tested OK.
   Holger Ebel: tested OK.

5.6 Multiple signers
   John Pawling: tested OK.
   Blake Ramsdell: tested OK.
   Jim Schaad: failed.
     signatureAlgorithm is dsa but should be dsaWithSha1
   Holger Ebel: tested OK.
   Sue Beauchamp sent new example file.

5.7 Signing using SKI
   John Pawling: tested OK.
   Blake Ramsdell: tested OK.
   Jim Schaad: failed.
     signatureAlgorithm is dsa but should be dsaWithSha1
   Holger Ebel: tested OK.
   Sue Beauchamp sent new example file.

5.8 S/MIME multipart/signed message
   John Pawling: tested OK.
   Blake Ramsdell: tested OK.
   Holger Ebel: tested OK except that it has a CRLF prepended.

5.9 S/MIME application/pkcs7-mime signed message
   John Pawling: tested OK.
   Blake Ramsdell: tested OK.
   Jim Schaad: failed because signatureAlgorithm of dsa not dsaWithSha1
   Holger Ebel: tested OK except that it has a CRLF prepended.

5.10 SignedData With Attributes
   John Pawling: tested OK.
   Blake Ramsdell: tested OK.
   Jim Schaad: failed.
	Change "unknown OID" to "unknown OID (1.2.5555)"
	Content Hint should have an OID of 1.2.840.113549.1.7.1
	Content Identifier attribute absent
	Contains Security Label attribute
	Contains encrypt key preference attribute
	Contains ML Expansion History attribute
	Contains Equivalent Label attribute
   Jeff Jacoby: tested OK.
   Holger Ebel: failed (not signed by Alice).

5.11 SignedData with Certificates Only
   John Pawling: tested OK.
   Blake Ramsdell: tested OK.
   Jeff Jacoby: tested OK.
   Holger Ebel: tested OK.

6.  Enveloped-data

6.1 Basic encrypted content, TripleDES and DH
   John Pawling: tested OK.
   Holger Ebel: tested OK.

6.2 Basic encrypted content, TripleDES and RSA
   John Pawling: tested OK.
   Blake Ramsdell: tested OK.
   Jeff Jacoby: tested OK.
   Holger Ebel: tested OK.

6.3 Basic encrypted content, RC2/40 and RSA
   Blake Ramsdell: this is actually a 128-bit key.
   Jeff Jacoby: confirmed Blake's assertion.
   Paul Hoffman: thinks we could just change the title of the example.
   John Pawling: tested OK.
   Blake Ramsdell: tested OK.
   Jeff Jacoby: tested OK.
   Holger Ebel: tested OK.

6.4 Encrypted content, two recipients, no shared keying material
   John Pawling: tested OK but noted unsuccessful Invalid tag for
     privateKeyInfo for second login.
   Holger Ebel: tested OK.

6.5 Encrypted content, two recipients, shared keying material
   John Pawling: could not test due to bug in his code.
   Holger Ebel: tested OK.

6.6 Encrypted content, TripleDES and DH, previously-distributed keys
   John Pawling: tested OK.
   Holger Ebel: tested OK.

6.7 Encrypted content, RC2/40 and RSA, previously-distributed keys
   John Pawling: tested OK.
   Holger Ebel: tested OK.

6.8 S/MIME application/pkcs7-mime encrypted message
   John Pawling: tested OK.
   Holger Ebel: tested OK.

6.9 EnvelopedData with All Recipient Types
   John Pawling: tested OK.
   Holger Ebel: tested OK.

6.10 EnvelopedData with KARI RC2 Encryption
   John Pawling: tested OK.
   Holger Ebel: tested OK.

6.11 EnvelopedData with KEK 3DES Encryption
   John Pawling: tested OK.
   Holger Ebel: tested OK.

7. Digested-data
   Blake Ramsdell: tested OK.
   Jeff Jacoby: tested OK.

8. Encrypted-data

8.1 Simple EncryptedData
   Blake Ramsdell: tested OK.
   Jim Schaad: tested OK.
   Jeff Jacoby: tested OK.

8.2 EncryptedData with unprotected attributes
   Jim Schaad: failed badly.
     The key is not in the text and it is not the same as 8.1
	The encapsulated content type is EncryptedData not id-data
	The content hint content type does not match the encapsulated 
content type

9. Authenticated-data
   There are still no examples in this section.

10. Key Wrapping
   John Pawling: tested OK.

10.1 Wrapping RC2
   John Pawling: tested OK.

10.2 Wrapping TripleDES
   John Pawling: tested OK.
   Holger Ebel: tested OK.

11. ESS Examples

11.1 ReceiptRequest
   John Pawling: test failed, has sent new example file.
   Jeff Jacoby: tested OK.

11.2 Receipt
   John Pawling: test failed, has sent new example file.

11.3 eSSSecurityLabel
   John Pawling: tested OK.
   Jim Schaad: tested OK.
   Jeff Jacoby: tested OK.

11.4 EquivalentLabels
   John Pawling: tested OK.
   Jeff Jacoby: tested OK.

11.5 mlExpansionHistory
   John Pawling: tested OK.
   Jeff Jacoby: tested OK.

11.6 SigningCertificate
   John Pawling: tested OK.
   Jeff Jacoby: tested OK.

--Paul Hoffman, Director
--Internet Mail Consortium


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h62FFgFK062351 for <[e-mail]>; Wed, 2 Jul 2003 08:15:42 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h62FFgbh062350 for ietf-smime-bks; Wed, 2 Jul 2003 08:15:42 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from brutesquadlabs.com (gtec136-m.isomedia.com [207.115.67.136] (may be forged)) by above.proper.com (8.12.9/8.12.8) with ESMTP id h62FFaFK062339 for <[e-mail]>; Wed, 2 Jul 2003 08:15:36 -0700 (PDT) (envelope-from [e-mail])
Received: from DEXTER ([192.168.0.5]) by brutesquadlabs.com with ESMTP ; Wed, 2 Jul 2003 08:15:32 -0700
From: "Blake Ramsdell" <[e-mail]>
To: <[e-mail]>
Cc: "'Gregory S. Chudov'" <[e-mail]>
Subject: GOST with CMS
Date: Wed, 2 Jul 2003 08:15:32 -0700
Message-ID: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAARMPfbnbp50SwK3EZjypY2MKAAAAQAAAAbWMMVYx/[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
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 draft is available, profiling the use of the Russian national
cryptography standards (GOST) in CMS:

Title: Cryptographic Message Syntax (CMS) algorithms for GOST 28147-89,
GOST R 34.10-94, GOST R 34.10-2001, GOST R 34.11-94.

Authors: Serguei Leontiev, Vladimir Popov

Filename: draft-leontiev-cryptopro-cpcms-00.txt

http://www.ietf.org/internet-drafts/draft-leontiev-cryptopro-cpcms-00.tx
t

Gregory Chudov has asked to introduce this draft to the group at the
next working group meeting, and we will be providing him with some time
to do that.  I presume that this draft will become a draft of the
working group in the next revision.

Blake
--
Blake Ramsdell | Brute Squad Labs | http://www.brutesquadlabs.com 



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h62DwHFK057578 for <[e-mail]>; Wed, 2 Jul 2003 06:58:17 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h62DwH3b057577 for ietf-smime-bks; Wed, 2 Jul 2003 06:58:17 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from moorabbin.nexor.co.uk (moorabbin.nexor.co.uk [80.6.88.100]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h62DwAFK057564 for <[e-mail]>; Wed, 2 Jul 2003 06:58:16 -0700 (PDT) (envelope-from [e-mail])
Received: from typhoon (actually host 210.53.63.193.in-addr.arpa) by moorabbin.nexor.co.uk with ESMTP (Mailer) with ESMTP; Wed, 2 Jul 2003 14:55:15 +0100
Reply-To: "g.lunt" <[e-mail]>
From: Graeme Lunt <[e-mail]>
To: "'jimsch'" <[e-mail]>, "'Sean P. Turner'" <[e-mail]>
Cc: "'ietf-smime'" <[e-mail]>
Subject: RE: Signed Receipts and Mail Lists
Date: Wed, 2 Jul 2003 14:56:58 +0100
Organization: Nexor
Message-ID: <001f01c340a1$cf01f470$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
In-Reply-To: <009701c33ce3$a86b4170$[e-mail]>
X-Spam-Status: No, hits=-100.7 required=5.0 tests=IN_REP_TO,NOSPAM_INC,QUOTED_EMAIL_TEXT,SPAM_PHRASE_03_05, USER_IN_WHITELIST version=2.43
X-Spam-Level: 
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>

Jim,
 
> If we adopted the solution you gave, what limits me from making
> arbitrary statements about who I am in this field that then need to be

> independently verified by the receipt processing code?  (I.e. what if 
> I put the fact that I am [e-mail] in this field and sign with 
> my [e-mail] certificate).

First off, having looked in more detail at 2634 it implicitly requires
each mail list to have its own certificate. In particular, the
EntityIdentifier, used in MLExpansionHistory, refers only to a
certificate. So having a single certificate for an MLA supporting
multiple lists would cause the loop detection algorithm to fail.  

So what I was looking at (a single certificate for a mail list agent
supporting multiple lists) is a more fundamental change than I first
thought.

But back to your question. 

The basic answer is that nothing would limit you. Do you see this as a
major issue?

x400wrap has a similar case where the content being signed contains an
"originator" field. 

"Receiving agents SHOULD check that the originator address in the X.400
content matches an X.400 address in the signer's certificate, if X.400
addresses are present in the certificate and an originator address is
available in the content. A receiving agent SHOULD provide some explicit
alternate processing of the message if this comparison fails, which may
be to display a message that shows the recipient the addresses in the
certificate or other certificate details."

I think that similar wording to section 4.3 of this draft may be
acceptable?

This wording allows us to take our own action to correlate the x400
originator to the signer in the case that they don't match (we use
attribute certificates to do the signer to originator validation). 

So for your example, I may see something like:

"signed receipt from [e-mail] on behalf of [e-mail] at
<time>"

The receiptFrom field I proposed is primarily aimed at supporting the
correlation of the signed receipt to the original recipient by providing
original address the signed receipt was requested from. 

There are a number of reasons why I may not be able to match the
address[es] (subjectAltName) from the certificate to one of the
addresses I to:

a) Valid aliases not in the subjectAltNames of the certificate

b) Signed receipt from a recipient who received the message as a result
of ML expansion.  

c) Mail redirections - e.g. sent to "[e-mail]" which redirects to a
personal mailbox.
Similar to a). 


Graeme


> > -----Original Message-----
> > From: [e-mail] 
> > [mailto:[e-mail]] On Behalf Of Graeme Lunt
> > Sent: Wednesday, June 25, 2003 12:40 AM
> > To: 'Sean P. Turner'
> > Cc: 'ietf-smime'
> > Subject: RE: Signed Receipts and Mail Lists
> > 
> > 
> > 
> > Sean,
> >  
> > > I'm not sure that the MLA returns a receipt on behalf of the ML 
> > > members.
> > 
> > OK - if an MLA should not return signed receipts then there is not a

> > problem with my scenario.
> > 
> > > I looked through ESS again and I couldn't find anything
> > that said if a
> > > message enters an MLA with a signed receipt request that it
> > 
> > > shouldn't or should return a receipt.    
> > 
> > Is an MLA considered a "receiving agent"/"receiving 
> > software"/"processing software" in section 2.3 of ESS? I had assumed

> > that it was but agree it is unclear.
> > 
> > > Typically (I think), originators want to know that the
> > final recipient
> > got
> > > the message not whether the MLA got it.
> > 
> > I think there are arguments for both. If an originator
> sends a message
> > to:
> > 
> > [e-mail]
> > 
> > the originator probably only wants to know that it got to the 
> > complaints department at bigbank. The originator doesn't want to 
> > know (and bigbank doesn't want to let the originator know) which 
> > individuals within bigbank read the message.
> > 
> > > Then again maybe I didn't understand your scenario.
> > 
> > I don't think the originator needs to understand if the addresses 
> > they are requesting signed receipts from are address lists or not. 
> > If an originator sends a message to two recipients - one a mail 
> > list, one an individual - and requests first tier signed receipts, 
> > they will never receive a signed receipt from the mail list 
> > recipient. The user may find this unexpected. Correlation software
> > *may* be able to detect a mail list recipient and handle it
> > appropriately.
> > 
> > 
> > Graeme
> > 
> > 
> 
> 



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h62AuuFK051294 for <[e-mail]>; Wed, 2 Jul 2003 03:56:56 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h62AuuC7051292 for ietf-smime-bks; Wed, 2 Jul 2003 03:56:56 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h62AutFK051285 for <[e-mail]>; Wed, 2 Jul 2003 03:56:55 -0700 (PDT) (envelope-from [e-mail])
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03059; Wed, 2 Jul 2003 06:56:54 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-smime-examples-11.txt
Date: Wed, 02 Jul 2003 06:56:53 -0400
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		: Examples of S/MIME Messages
	Author(s)	: P. Hoffman
	Filename	: draft-ietf-smime-examples-11.txt
	Pages		: 8
	Date		: 2003-7-1
	
This document gives examples of message bodies formatted using S/MIME.
Specifically, it has examples of Cryptographic Message Syntax (CMS)
objects, S/MIME messages (including the MIME formatting), and Enhanced
Security Services for S/MIME (ESS). It includes examples of most or all
common CMS and ESS formats; in addition, it gives examples that show
common pitfalls in implementing CMS. The purpose of this document is to
help increase interoperability for S/MIME and other protocols that rely
on CMS.
This draft is being discussed on the 'ietf-smime' mailing list.  To
join the list, send a message to <[e-mail]> with the
single word 'subscribe' in the body of the message.  Also, there is a
Web site for the mailing list at <http://www.imc.org/ietf-smime/>.

This draft is being discussed on the 'ietf-smime' mailing list.  To
join the list, send a message to <[e-mail]> with the
single word 'subscribe' in the body of the message.  Also, 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-examples-11.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-examples-11.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-examples-11.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-examples-11.txt

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

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

--OtherAccess--

--NextPart--




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h62ApUFK050485 for <[e-mail]>; Wed, 2 Jul 2003 03:51:30 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h62ApUV0050484 for ietf-smime-bks; Wed, 2 Jul 2003 03:51:30 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h62ApTFK050473 for <[e-mail]>; Wed, 2 Jul 2003 03:51:30 -0700 (PDT) (envelope-from [e-mail])
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01615; Wed, 2 Jul 2003 06:51:26 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
CC: [e-mail], [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-mahy-sipping-smime-vs-digest-01.txt
Date: Wed, 02 Jul 2003 06:51:26 -0400
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.


	Title		: Discussion of suitability: S/MIME instead of Digest 
                          Authentication in the Session Initiation Protocol 
                         (SIP)
	Author(s)	: R. Mahy
	Filename	: draft-mahy-sipping-smime-vs-digest-01.txt
	Pages		: 11
	Date		: 2003-7-1
	
Digest authentication (as defined in RFC2617) is used in SIP
(RFC3261) for user authentication, and less frequently for message
integrity of MIME bodies carried in SIP.  Various members of the IETF
security community have periodically suggested that Digest should be
deprecated in favor of the SIP use of S/MIME (RFC2633), support for
which was recently introduced in RFC3261.  The author seeks clarity
from the IETF security community on behalf of the SIP community about
the feasibility and possible benefits of using S/MIME instead of
Digest in one or both of these applications.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-mahy-sipping-smime-vs-digest-01.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-mahy-sipping-smime-vs-digest-01.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-mahy-sipping-smime-vs-digest-01.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-mahy-sipping-smime-vs-digest-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-mahy-sipping-smime-vs-digest-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--NextPart--




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h61LodFK087936 for <[e-mail]>; Tue, 1 Jul 2003 14:50:39 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h61Lodk8087935 for ietf-smime-bks; Tue, 1 Jul 2003 14:50:39 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from brutesquadlabs.com (gtec136-m.isomedia.com [207.115.67.136] (may be forged)) by above.proper.com (8.12.9/8.12.8) with ESMTP id h61LocFK087918 for <[e-mail]>; Tue, 1 Jul 2003 14:50:39 -0700 (PDT) (envelope-from [e-mail])
Received: from DEXTER ([192.168.0.5]) by brutesquadlabs.com with ESMTP ; Tue, 1 Jul 2003 14:50:35 -0700
From: "Blake Ramsdell" <[e-mail]>
To: <[e-mail]>
Cc: "'Sean Turner'" <[e-mail]>
Subject: DRAFT S/MIME working group agenda
Date: Tue, 1 Jul 2003 14:50:35 -0700
Message-ID: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAARMPfbnbp50SwK3EZjypY2MKAAAAQAAAAH5/oOPiN10yLsjkx1W//[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
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>

Here is a draft agenda based on the response so far.  This will most
likely be the final agenda unless Sean or I hear something different.

Introductions (Sean Turner)
Working group status (Sean Turner)
CMS and ESS examples update (Paul Hoffman)
MSGbis and CERTbis update (Blake Ramsdell)
Interoperability matrix update (Jim Schaad)
KEM overview (Jim Schaad)
PSS status (Jim Schaad)
ESSbis overview (Jim Schaad)

Blake
--
Blake Ramsdell | Brute Squad Labs | http://www.brutesquadlabs.com 



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h619D0FK031127 for <[e-mail]>; Tue, 1 Jul 2003 02:13:00 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h619D0uv031126 for ietf-smime-bks; Tue, 1 Jul 2003 02:13:00 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from hermes.cs.auckland.ac.nz ([130.216.35.151]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h619CwFK030843 for <[e-mail]>; Tue, 1 Jul 2003 02:12:59 -0700 (PDT) (envelope-from [e-mail])
Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by hermes.cs.auckland.ac.nz (8.12.9/8.12.9) with ESMTP id h6198iXX012517; Tue, 1 Jul 2003 21:08:44 +1200
Received: (from pgut001@localhost) by medusa01.cs.auckland.ac.nz (8.11.6/8.11.6) id h6198gB18508; Tue, 1 Jul 2003 21:08:42 +1200
Date: Tue, 1 Jul 2003 21:08:42 +1200
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail], [e-mail], [e-mail]
Subject: RE: (Practical) S/MIME certificate chain handling
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>

"Blake Ramsdell" <[e-mail]> writes:

>I agree, and that's why they send all the certificates along with messages to
>this date.  By "they", I mean S/MIME-enabled versions of Netscape, Outlook
>Express, Outlook, and the S/MIME plugin for Eudora that I wrote.

Just as another data point, a small portion of my certificate zoo consists of
cert chains from S/MIME sigs, and every one of them is a full chain (or at
least some sort of chain), rather than a single cert.  I don't track where
they originally came from, but they cover (at least) Outlook (many versions),
Netscape, and a few S/MIME gateways that auto-sign everything passing through
them (most of the stuff I've seen in general mail in fact would be auto-
signed, either by a gateway or because the sender turned it on and forgot
about it).  I do have some single-cert chains, but they're from oddball
applications like EDI messaging (the certs have EDI altnames and whatnot)
which aren't representative of general usage.

Peter.