RE: Certs-only Mechanism for X.400 Transport

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

Section 3.6 currently reads (sorry if it wraps)

> 3.6 Creating a Certificates-only Message
> 
>    The certificates only message or MIME entity is used to transport
>    certificates, such as in response to a registration request. This
>    format can also be used to convey CRLs.
> 
>    Step 1. The certificates are made available to the CMS generating
>    process which creates a CMS object of type signedData. The signedData
>    encapContentInfo eContent field MUST be absent and signerInfos field
>    MUST be empty.
> 
>    Step 2. The CMS signedData object is enclosed in an
>    application/pkcs7-mime MIME entity
> 
>    The smime-type parameter for a certs-only message is "certs-only".
>    The file extension for this type of message is ".p7c".

These steps are valid for sending CRLs also, if that is ambiguous.  Step 1
can be modified to read "The certificates and/or CRLs".  Pushing CRLs
through a CMS message is a valid idea (at least I think so), and in fact we
do it for our own product (we chase down CRLs and package thm in CMS
messages).

Blake 

-----Original Message-----
From: Russ Housley [mailto:[e-mail]]
Sent: Wednesday, February 28, 2001 5:57 AM
To: William Ottaway
Cc: Bonatti, Chris; [e-mail]; [e-mail]
Subject: RE: Certs-only Mechanism for X.400 Transport


I was not part of the S/MIME v2 discussions that lead to the current 
format.  I have asked Blake to chime in, and I hope that he does.  The 
scenario of interest is a CA returning a certificate in response to the 
PKCS#10 request.  Here, the CA could choose to include the current CRLs in 
the "cert-only" message.  This would seed the newly-enrolled user's CRL
cache.

I am not aware of any CA pushing CRLs to their subscribers in an S/MIME 
message.  It could certainly be done....

Russ

At 04:30 PM 2/26/2001 +0000, William Ottaway wrote:
>Chris,
>
>I'm happy for the text to indicate that the format described for a certs
>only message could be used to transport CRLs or both, as long as the text
>also states that if CRLs or both are being transported the OID for certs
>only MUST not be used.
>
>Do we have consensus :-)
>
>Bill.
>
> > -----Original Message-----
> > From: Bonatti, Chris [mailto:[e-mail]]
> > Sent: 26 February 2001 16:10
> > To: William Ottaway
> > Cc: [e-mail]; [e-mail]
> > Subject: Re: Certs-only Mechanism for X.400 Transport
> >
> >
> > Bill,
> >
> >     Okay, how about option (3)  ;-)
> >
> >     (3) would be we clarify the text, but describe more clearly
> > what I think was
> > the intent of RFC 2633.  Namely, that the format described and
> > identified as
> > "certs-only" can be used to convey either certs, CRLs or both.
> >
> >     Btw, I would happily go along with either (1) or (2) if the
> > corresponding
> > change were made to the MSG spec.  I guess I still favor (3)
> > however, because I
> > perceive it to be the status quo, and because allowing CRLs to be
> > included here
> > doesn't seem to break anything for the PKCS #10 scenario.  I'd be
> > hard pressed
> > to cite the benefits, though.  Does anybody remember the logic
> > for why this was
> > done?
> >
> > Chris
> >
> >
> > _______________________
> >
> > William Ottaway wrote:
> >
> > > Jim,
> > >
> > > I think I'm inferring what is done. :-)
> > >
> > > My only gripe is I don't like the statement "This format can
> > also be used to
> > > convey CRLs." followed by a description of how to carry
> > certificates but no
> > > description of how to carry CRLs in a similar format.
> > >
> > > Its too late to change RFC 2633 but draft-ietf-smime-x400trans could
say
> > > something different.
> > >
> > > 1) Don't mention that CRLs can be carried in a similar way to a
> > certs only
> > > message
> > >
> > > or
> > >
> > > 2) Specify an OID for a CRL only message.
> > >
> > > Bill.
> > >
> >





Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id MAA26147 for ietf-smime-bks; Wed, 28 Feb 2001 12:36:51 -0800 (PST)
Received: from cane.deming.com (mail.deming.com [208.236.41.137]) by above.proper.com (8.9.3/8.9.3) with SMTP id MAA26141 for <[e-mail]>; Wed, 28 Feb 2001 12:36:49 -0800 (PST)
Received: from 208.236.41.137 by cane.deming.com with ESMTP (Tumbleweed MMS SMTP Relay (MMS v4.7)); Wed, 28 Feb 2001 12:36:21 -0800
X-Server-Uuid: 1a012586-24e9-11d1-adae-00a024bc53c5
Received: by cane.deming.com with Internet Mail Service (5.5.2650.21) id <CXGVMSZ1>; Wed, 28 Feb 2001 12:36:21 -0800
Message-ID: <[e-mail]>
From: "Blake Ramsdell" <[e-mail]>
To: "'Russ Housley'" <[e-mail]>, "William Ottaway" <[e-mail]>
cc: "Bonatti, Chris" <[e-mail]>, [e-mail], [e-mail]
Subject: RE: Certs-only Mechanism for X.400 Transport
Date: Wed, 28 Feb 2001 12:36:13 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
X-WSS-ID: 1683BECF46671-01-01
Content-Type: text/plain;  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>

Section 3.6 currently reads (sorry if it wraps)

> 3.6 Creating a Certificates-only Message
> 
>    The certificates only message or MIME entity is used to transport
>    certificates, such as in response to a registration request. This
>    format can also be used to convey CRLs.
> 
>    Step 1. The certificates are made available to the CMS generating
>    process which creates a CMS object of type signedData. The signedData
>    encapContentInfo eContent field MUST be absent and signerInfos field
>    MUST be empty.
> 
>    Step 2. The CMS signedData object is enclosed in an
>    application/pkcs7-mime MIME entity
> 
>    The smime-type parameter for a certs-only message is "certs-only".
>    The file extension for this type of message is ".p7c".

These steps are valid for sending CRLs also, if that is ambiguous.  Step 1
can be modified to read "The certificates and/or CRLs".  Pushing CRLs
through a CMS message is a valid idea (at least I think so), and in fact we
do it for our own product (we chase down CRLs and package thm in CMS
messages).

Blake 

-----Original Message-----
From: Russ Housley [mailto:[e-mail]]
Sent: Wednesday, February 28, 2001 5:57 AM
To: William Ottaway
Cc: Bonatti, Chris; [e-mail]; [e-mail]
Subject: RE: Certs-only Mechanism for X.400 Transport


I was not part of the S/MIME v2 discussions that lead to the current 
format.  I have asked Blake to chime in, and I hope that he does.  The 
scenario of interest is a CA returning a certificate in response to the 
PKCS#10 request.  Here, the CA could choose to include the current CRLs in 
the "cert-only" message.  This would seed the newly-enrolled user's CRL
cache.

I am not aware of any CA pushing CRLs to their subscribers in an S/MIME 
message.  It could certainly be done....

Russ

At 04:30 PM 2/26/2001 +0000, William Ottaway wrote:
>Chris,
>
>I'm happy for the text to indicate that the format described for a certs
>only message could be used to transport CRLs or both, as long as the text
>also states that if CRLs or both are being transported the OID for certs
>only MUST not be used.
>
>Do we have consensus :-)
>
>Bill.
>
> > -----Original Message-----
> > From: Bonatti, Chris [mailto:[e-mail]]
> > Sent: 26 February 2001 16:10
> > To: William Ottaway
> > Cc: [e-mail]; [e-mail]
> > Subject: Re: Certs-only Mechanism for X.400 Transport
> >
> >
> > Bill,
> >
> >     Okay, how about option (3)  ;-)
> >
> >     (3) would be we clarify the text, but describe more clearly
> > what I think was
> > the intent of RFC 2633.  Namely, that the format described and
> > identified as
> > "certs-only" can be used to convey either certs, CRLs or both.
> >
> >     Btw, I would happily go along with either (1) or (2) if the
> > corresponding
> > change were made to the MSG spec.  I guess I still favor (3)
> > however, because I
> > perceive it to be the status quo, and because allowing CRLs to be
> > included here
> > doesn't seem to break anything for the PKCS #10 scenario.  I'd be
> > hard pressed
> > to cite the benefits, though.  Does anybody remember the logic
> > for why this was
> > done?
> >
> > Chris
> >
> >
> > _______________________
> >
> > William Ottaway wrote:
> >
> > > Jim,
> > >
> > > I think I'm inferring what is done. :-)
> > >
> > > My only gripe is I don't like the statement "This format can
> > also be used to
> > > convey CRLs." followed by a description of how to carry
> > certificates but no
> > > description of how to carry CRLs in a similar format.
> > >
> > > Its too late to change RFC 2633 but draft-ietf-smime-x400trans could
say
> > > something different.
> > >
> > > 1) Don't mention that CRLs can be carried in a similar way to a
> > certs only
> > > message
> > >
> > > or
> > >
> > > 2) Specify an OID for a CRL only message.
> > >
> > > Bill.
> > >
> >




Received: by above.proper.com (8.9.3/8.9.3) id GAA00672 for ietf-smime-bks; Wed, 28 Feb 2001 06:02:21 -0800 (PST)
Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by above.proper.com (8.9.3/8.9.3) with ESMTP id GAA00665 for <[e-mail]>; Wed, 28 Feb 2001 06:02:20 -0800 (PST)
Received: from RHOUSLEY-PC.spyrus.com (dial08.spyrus.com [207.212.34.128]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id GAA19858; Wed, 28 Feb 2001 06:00:01 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.2
Date: Wed, 28 Feb 2001 08:57:10 -0500
To: "William Ottaway" <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: RE: Certs-only Mechanism for X.400 Transport
Cc: "Bonatti, Chris" <[e-mail]>, <[e-mail]>, <[e-mail]>
In-Reply-To: <[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>

I was not part of the S/MIME v2 discussions that lead to the current 
format.  I have asked Blake to chime in, and I hope that he does.  The 
scenario of interest is a CA returning a certificate in response to the 
PKCS#10 request.  Here, the CA could choose to include the current CRLs in 
the "cert-only" message.  This would seed the newly-enrolled user's CRL cache.

I am not aware of any CA pushing CRLs to their subscribers in an S/MIME 
message.  It could certainly be done....

Russ

At 04:30 PM 2/26/2001 +0000, William Ottaway wrote:
>Chris,
>
>I'm happy for the text to indicate that the format described for a certs
>only message could be used to transport CRLs or both, as long as the text
>also states that if CRLs or both are being transported the OID for certs
>only MUST not be used.
>
>Do we have consensus :-)
>
>Bill.
>
> > -----Original Message-----
> > From: Bonatti, Chris [mailto:[e-mail]]
> > Sent: 26 February 2001 16:10
> > To: William Ottaway
> > Cc: [e-mail]; [e-mail]
> > Subject: Re: Certs-only Mechanism for X.400 Transport
> >
> >
> > Bill,
> >
> >     Okay, how about option (3)  ;-)
> >
> >     (3) would be we clarify the text, but describe more clearly
> > what I think was
> > the intent of RFC 2633.  Namely, that the format described and
> > identified as
> > "certs-only" can be used to convey either certs, CRLs or both.
> >
> >     Btw, I would happily go along with either (1) or (2) if the
> > corresponding
> > change were made to the MSG spec.  I guess I still favor (3)
> > however, because I
> > perceive it to be the status quo, and because allowing CRLs to be
> > included here
> > doesn't seem to break anything for the PKCS #10 scenario.  I'd be
> > hard pressed
> > to cite the benefits, though.  Does anybody remember the logic
> > for why this was
> > done?
> >
> > Chris
> >
> >
> > _______________________
> >
> > William Ottaway wrote:
> >
> > > Jim,
> > >
> > > I think I'm inferring what is done. :-)
> > >
> > > My only gripe is I don't like the statement "This format can
> > also be used to
> > > convey CRLs." followed by a description of how to carry
> > certificates but no
> > > description of how to carry CRLs in a similar format.
> > >
> > > Its too late to change RFC 2633 but draft-ietf-smime-x400trans could say
> > > something different.
> > >
> > > 1) Don't mention that CRLs can be carried in a similar way to a
> > certs only
> > > message
> > >
> > > or
> > >
> > > 2) Specify an OID for a CRL only message.
> > >
> > > Bill.
> > >
> >



Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id DAA18096 for ietf-smime-bks; Tue, 27 Feb 2001 03:27:53 -0800 (PST)
Received: from balinese.baltimore.ie ([e-mail] [194.125.215.8]) by above.proper.com (8.9.3/8.9.3) with ESMTP id DAA18085 for <[e-mail]>; Tue, 27 Feb 2001 03:27:50 -0800 (PST)
Received: by balinese.baltimore.ie; id LAA07756; Tue, 27 Feb 2001 11:27:46 GMT
Received: from emeairlsw1.ie.baltimore.com(10.153.25.53) by balinese.baltimore.ie via smap (V4.2) id xma005370; Tue, 27 Feb 01 11:21:56 GMT
Received: from bobcat.baltimore.ie (bobcat.ie.baltimore.com) by emeairlsw1.baltimore.com (Content Technologies SMTPRS 4.2.1) with ESMTP id <[e-mail]>; Tue, 27 Feb 2001 11:21:23 +0000
Received: from baltimore.ie (ip187-24.ie.baltimore.com [10.153.24.187]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id LAA01901; Tue, 27 Feb 2001 11:21:55 GMT
Message-ID: <[e-mail]>
Date: Tue, 27 Feb 2001 11:21:54 +0000
From: Stephen Farrell <[e-mail]>
Reply-To: [e-mail]
Organization: Baltimore Technologies Ltd.
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail]
Subject: Re: WG Last Call:draft-ietf-smime-rcek-01.txt
References: <000401c0a04c$60c7f650$[e-mail]>
Content-Type: text/plain; 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>

Hi Jim,

[...]
> What I
> would like to see is a discussion of when a protocal should use the proposed
> method rather than one of the above suggested methods.

Ok - how about adding this to section 2: "There are other ways that could
be envisaged to establish the required symmetric keying material, e.g.
by leveraging a group keying scheme or by defining a content type
that contains a KEK value. Although this scheme is much simpler than generic 
group key management, if an implementation already supports group key 
management then this scheme doesn't add value. This scheme is also 
suitable for inclusion in CMS libraries (though the addition of new state
might be a problem for some implementations), which can offer some 
advantages over application layer (e.g. where the content includes the KEK)
schemes."

Definitely needs wordsmithing, but is that the type of thing you mean?

> > > 5.  Section 3.  What is the default value of CEKMaxDecrypts
> > if it is not
> > > present.

> The two values that I though of immeadately are either 1 or inifinite.  Of
> the two I would probably go with 1 and insist that you do continous
> chaining.

One is fine then. Will add.

> > > 6.  Section 4.  First, the CE algorithm and the KE
[...]
> 
> I would like to see the phrase "using the same underlying cryptographic
> operation" added somehow.  I could argue that MARS and AES use the same
> format and size of keying material and they are of similar strength.  Do you
> want to be using the byte swapping this case as well?

Fair point. Will add that.

> 
> > > 9.  Appendix A.  --<<IMPLICIT??>>-- should be removed or fixed
> >
> > Well, which do you prefer in this case? I'm not sure.
> 
> For your module it makes absolute no difference as there is no tagging
> contained in the module.

Phew! (I just hate tags:-)

> > > 12.  Please add comments to the effect of what goes into
> > each of the fields
> > > and that there is an association between the pairs as OID
> > attribute value.
[...]
> I don't expect that the ASN.1 module will stay with the i-d.  I often take
> out the modules and save them on their own.  It is useful to be able to scan
> the ASN when I am decoding messages without having to resort to reading the
> entire draft.

Well...I agree its somewhat useful, but I also think its marginal and in the 
worst case misleading (too abbreviated). However, since its not worth getting 
hung up about this, I'll add comments like those in CMS.

Stephen.

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) [phone]
39 Parkgate Street,                     fax: [phone]
Dublin 8.                mailto:[e-mail]
Ireland                             http://www.baltimore.com


Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id PAA11222 for ietf-smime-bks; Mon, 26 Feb 2001 15:30:35 -0800 (PST)
Received: from femail3.sdc1.sfba.home.com (femail3.sdc1.sfba.home.com [24.0.95.83]) by above.proper.com (8.9.3/8.9.3) with ESMTP id PAA11218 for <[e-mail]>; Mon, 26 Feb 2001 15:30:34 -0800 (PST)
Received: from revelation ([65.4.166.11]) by femail3.sdc1.sfba.home.com (InterMail vM.4.01.03.00 201-229-121) with SMTP id <20010226232831.XLEB11050.femail3.sdc1.sfba.home.com@revelation>; Mon, 26 Feb 2001 15:28:31 -0800
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Subject: RE: WG Last Call:draft-ietf-smime-rcek-01.txt
Date: Mon, 26 Feb 2001 15:32:24 -0800
Message-ID: <000401c0a04c$60c7f650$[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 CWS, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
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>

Stephen,

>
> Hi Jim,
>
> Thanks for reviewing this.
>
> > 1.  I would like to see a section added to section 2 to
> describe why this
> > "trick" is being used rather than just establishing a
> short-term kek value
> > which is used for a time period and then tossed.  I.e. When
> do you use this
> > trick and when do you establish a multi-use kek value.
>
> Not clear to me - "establishing a short-term kek value" how?
> If you mean
> I should say that you could do this trick or use out-of-band
> mechanisms to
> establish a kek, fine. Otherwise, I'm not sure what text you'd like.
>

One simple way to do this is to use the GLKey control from the symmetric key
distribution draft.  This allows for a standard way to distribute a KEK key
which could be used for a short time.  Alternatively the protocal that is
using this draft could in turn define a first message that distributes the
KEK value and then uses that for some set of subsequent messages.  What I
would like to see is a discussion of when a protocal should use the proposed
method rather than one of the above suggested methods.

> > 5.  Section 3.  What is the default value of CEKMaxDecrypts
> if it is not
> > present.
>
> Given that its a hint, that's implementation specific and so
> there's no
> generic default. If folks wanted one, I'd go with 10, but I
> think we can
> omit this.

The two values that I though of immeadately are either 1 or inifinite.  Of
the two I would probably go with 1 and insist that you do continous
chaining.

>
> > 6.  Section 4.  First, the CE algorithm and the KE
> algorithm are never "the
> > same" in some sense.  id-alg-CMS3DESwrap and des-ede3-cbc
> are different in a
> > number of significant ways.  Please change the text.  I
> would suggest
> > something along "If the CE algorithm and KE algorithm use
> the same key
> > material...".  I have problems with even this because of
> the question of a
> > CEK of 128-bit RC2 and a KEK of 40-bit RC2 in which case it
> is not clear
> > that this is the algorithm one should be using.
>
> No problem adding text clarifying what "same" means here. How about:
>
> "Note: In some sense, the CEK and KEK algorithms are never the "same",
> e.g. id-alg-CMS3DESwrap and des-ede3-cbc differ. However, for the
> purposes of this specification, all we care about is that the
> algorithms
> use the same format and size of keying material (see also security
> considerations) and that they do not differ significantly in terms
> of the resulting cryptographic "strength". In that sense the two
> algorithms in the example above are the "same.""
>
> > The best overall approach might be to say that if the KEK
> is A and the CEK
> > is B then you use the byte-reveral method and just the list
> ones that
> > "match" in impedance.
>
> I'd really rather not be listing pairs of algorithms in this document.
> Would the addition of the text above be sufficient?

I would like to see the phrase "using the same underlying cryptographic
operation" added somehow.  I could argue that MARS and AES use the same
format and size of keying material and they are of similar strength.  Do you
want to be using the byte swapping this case as well?

> > 9.  Appendix A.  --<<IMPLICIT??>>-- should be removed or fixed
>
> Well, which do you prefer in this case? I'm not sure.

For your module it makes absolute no difference as there is no tagging
contained in the module.

> >
> > 12.  Please add comments to the effect of what goes into
> each of the fields
> > and that there is an association between the pairs as OID
> attribute value.
>
> Huh? You mean in the ASN.1 module? I think in a 7 page i-d, the reader
> is expected to read more than just the ASN.1 module.

I don't expect that the ASN.1 module will stay with the i-d.  I often take
out the modules and save them on their own.  It is useful to be able to scan
the ASN when I am decoding messages without having to resort to reading the
entire draft.

>
> Stephen.
>
>

jim



Received: by above.proper.com (8.9.3/8.9.3) id IAA29467 for ietf-smime-bks; Mon, 26 Feb 2001 08:25:33 -0800 (PST)
Received: from mail.eris.dera.gov.uk (ns0.eris.dera.gov.uk [128.98.1.1]) by above.proper.com (8.9.3/8.9.3) with SMTP id IAA29456 for <[e-mail]>; Mon, 26 Feb 2001 08:25:31 -0800 (PST)
Received: (qmail 23167 invoked from network); 26 Feb 2001 16:25:33 -0000
Received: from cray.eris.dera.gov.uk (HELO mailhost.eris.dera.gov.uk) (128.98.2.7) by ens0.eris.dera.gov.uk with SMTP; 26 Feb 2001 16:25:33 -0000
Received: (qmail 5833 invoked from network); 26 Feb 2001 16:25:31 -0000
Received: from wottaway.eris.dera.gov.uk (HELO wottaway) (128.98.10.192) by mailhost.eris.dera.gov.uk with SMTP; 26 Feb 2001 16:25:31 -0000
From: "William Ottaway" <[e-mail]>
To: "Bonatti, Chris" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
Subject: RE: Certs-only Mechanism for X.400 Transport
Date: Mon, 26 Feb 2001 16:30:19 -0000
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
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>

Chris,

I'm happy for the text to indicate that the format described for a certs
only message could be used to transport CRLs or both, as long as the text
also states that if CRLs or both are being transported the OID for certs
only MUST not be used.

Do we have consensus :-)

Bill.

> -----Original Message-----
> From: Bonatti, Chris [mailto:[e-mail]]
> Sent: 26 February 2001 16:10
> To: William Ottaway
> Cc: [e-mail]; [e-mail]
> Subject: Re: Certs-only Mechanism for X.400 Transport
>
>
> Bill,
>
>     Okay, how about option (3)  ;-)
>
>     (3) would be we clarify the text, but describe more clearly
> what I think was
> the intent of RFC 2633.  Namely, that the format described and
> identified as
> "certs-only" can be used to convey either certs, CRLs or both.
>
>     Btw, I would happily go along with either (1) or (2) if the
> corresponding
> change were made to the MSG spec.  I guess I still favor (3)
> however, because I
> perceive it to be the status quo, and because allowing CRLs to be
> included here
> doesn't seem to break anything for the PKCS #10 scenario.  I'd be
> hard pressed
> to cite the benefits, though.  Does anybody remember the logic
> for why this was
> done?
>
> Chris
>
>
> _______________________
>
> William Ottaway wrote:
>
> > Jim,
> >
> > I think I'm inferring what is done. :-)
> >
> > My only gripe is I don't like the statement "This format can
> also be used to
> > convey CRLs." followed by a description of how to carry
> certificates but no
> > description of how to carry CRLs in a similar format.
> >
> > Its too late to change RFC 2633 but draft-ietf-smime-x400trans could say
> > something different.
> >
> > 1) Don't mention that CRLs can be carried in a similar way to a
> certs only
> > message
> >
> > or
> >
> > 2) Specify an OID for a CRL only message.
> >
> > Bill.
> >
>



Received: by above.proper.com (8.9.3/8.9.3) id IAA29044 for ietf-smime-bks; Mon, 26 Feb 2001 08:10:42 -0800 (PST)
Received: from smtp-a.capu.net (IDENT:0@[205.177.76.122]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA29037 for <[e-mail]>; Mon, 26 Feb 2001 08:10:39 -0800 (PST)
Received: from ieca.com (dial-216-33.capu.net [64.50.216.33]) by smtp-a.capu.net (8.9.3/8.9.3) with ESMTP id LAA19561; Mon, 26 Feb 2001 11:09:47 -0500
Message-ID: <[e-mail]>
Date: Mon, 26 Feb 2001 11:09:42 -0500
From: "Bonatti, Chris" <[e-mail]>
Organization: IECA, Inc.
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: William Ottaway <[e-mail]>
CC: [e-mail], [e-mail]
Subject: Re: Certs-only Mechanism for X.400 Transport
References: <[e-mail]>
Content-Type: text/plain; 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>

Bill,

    Okay, how about option (3)  ;-)

    (3) would be we clarify the text, but describe more clearly what I think was
the intent of RFC 2633.  Namely, that the format described and identified as
"certs-only" can be used to convey either certs, CRLs or both.

    Btw, I would happily go along with either (1) or (2) if the corresponding
change were made to the MSG spec.  I guess I still favor (3) however, because I
perceive it to be the status quo, and because allowing CRLs to be included here
doesn't seem to break anything for the PKCS #10 scenario.  I'd be hard pressed
to cite the benefits, though.  Does anybody remember the logic for why this was
done?

Chris


_______________________

William Ottaway wrote:

> Jim,
>
> I think I'm inferring what is done. :-)
>
> My only gripe is I don't like the statement "This format can also be used to
> convey CRLs." followed by a description of how to carry certificates but no
> description of how to carry CRLs in a similar format.
>
> Its too late to change RFC 2633 but draft-ietf-smime-x400trans could say
> something different.
>
> 1) Don't mention that CRLs can be carried in a similar way to a certs only
> message
>
> or
>
> 2) Specify an OID for a CRL only message.
>
> Bill.
>



Received: by above.proper.com (8.9.3/8.9.3) id EAA19123 for ietf-smime-bks; Mon, 26 Feb 2001 04:57:48 -0800 (PST)
Received: from smtp.netreach.net (fatuka.netreach.net [207.29.195.121]) by above.proper.com (8.9.3/8.9.3) with SMTP id EAA19107 for <[e-mail]>; Mon, 26 Feb 2001 04:57:46 -0800 (PST)
Received: (qmail 19566 invoked by uid 102); 26 Feb 2001 12:58:29 -0000
Received: from static-cc.netreach.net (HELO delbert) (207.29.201.235) by smtp.netreach.net with SMTP; 26 Feb 2001 12:58:29 -0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]@mail2.netreach.net
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Mon, 26 Feb 2001 07:57:10 -0500
To: [e-mail]
From: TISC Programs <[e-mail]>
Subject: The Internet Security Conference 2001
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 Fifth Internet Security Conference will be held June 4-8, 2001
at the Century Plaza Hotel and Tower, 2025 Avenue of the Stars,
Century City Los Angeles, CA 90067-4696. TISC is an educational
forum for security professionals and practitioners.

TISC Workshops on network security principles, Windows 2000 security,
firewall practices, incident response, security systems for the
Internet, attack trends and countermeasures, VPNs, and hacking are
presented by leading experts in the security community.

In addition, over 50 security experts will offer technical advice
and present invited papers during the TISC Security Symposium.
Topics include Anti-Hacking, IDS, VPNs, Authentication and PKI,
web security and privacy, network forensics, LINUX security,
wireless security, malware, web threats, and more.

View the complete agenda at http://www.tisc2001.com/agenda.html

We hope to see you in Los Angeles!
The TISC 2001 Program Committee
www.tisc2001.com




Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id BAA26540 for ietf-smime-bks; Mon, 26 Feb 2001 01:50:21 -0800 (PST)
Received: from balinese.baltimore.ie ([e-mail] [194.125.215.8]) by above.proper.com (8.9.3/8.9.3) with ESMTP id BAA26535 for <[e-mail]>; Mon, 26 Feb 2001 01:50:20 -0800 (PST)
Received: by balinese.baltimore.ie; id JAA05662; Mon, 26 Feb 2001 09:50:18 GMT
Received: from emeairlsw1.ie.baltimore.com(10.153.25.53) by balinese.baltimore.ie via smap (V4.2) id xma005552; Mon, 26 Feb 01 09:49:27 GMT
Received: from bobcat.baltimore.ie (bobcat.ie.baltimore.com) by emeairlsw1.baltimore.com (Content Technologies SMTPRS 4.2.1) with ESMTP id <[e-mail]>; Mon, 26 Feb 2001 09:48:55 +0000
Received: from baltimore.ie (ip187-24.ie.baltimore.com [10.153.24.187]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id JAA22303; Mon, 26 Feb 2001 09:48:55 GMT
Message-ID: <[e-mail]>
Date: Mon, 26 Feb 2001 09:48:59 +0000
From: Stephen Farrell <[e-mail]>
Reply-To: [e-mail]
Organization: Baltimore Technologies Ltd.
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail]
Subject: Re: WG Last Call:draft-ietf-smime-rcek-01.txt
References: <002301c09f80$f660e770$[e-mail]>
Content-Type: text/plain; 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>

Hi Jim,

Thanks for reviewing this.

> 1.  I would like to see a section added to section 2 to describe why this
> "trick" is being used rather than just establishing a short-term kek value
> which is used for a time period and then tossed.  I.e. When do you use this
> trick and when do you establish a multi-use kek value.

Not clear to me - "establishing a short-term kek value" how? If you mean
I should say that you could do this trick or use out-of-band mechanisms to
establish a kek, fine. Otherwise, I'm not sure what text you'd like.

> 2.  Please add a paragraph to the security section area about the fact that
> byte reversal may not be a good idea if the algorithm does a parity type
> check over a larger than byte block. I.e. describe why the bit-wise
> flip-flop was a "bad" idea.

Good idea.

> 3.  Section 3, Note 2.  Please change the text from "can occur in any of
> the" to "can occur with any of the".  The attribute cannot occur inside of
> any ReceipientInfo object as it is an unathenticated attribute.

Fine.

> 4.  Section 3.  id-reck-attrs has a TBD.

Yes. Russ?

> 5.  Section 3.  What is the default value of CEKMaxDecrypts if it is not
> present.

Given that its a hint, that's implementation specific and so there's no
generic default. If folks wanted one, I'd go with 10, but I think we can 
omit this.
 
> 6.  Section 4.  First, the CE algorithm and the KE algorithm are never "the
> same" in some sense.  id-alg-CMS3DESwrap and des-ede3-cbc are different in a
> number of significant ways.  Please change the text.  I would suggest
> something along "If the CE algorithm and KE algorithm use the same key
> material...".  I have problems with even this because of the question of a
> CEK of 128-bit RC2 and a KEK of 40-bit RC2 in which case it is not clear
> that this is the algorithm one should be using.

No problem adding text clarifying what "same" means here. How about:

"Note: In some sense, the CEK and KEK algorithms are never the "same",
e.g. id-alg-CMS3DESwrap and des-ede3-cbc differ. However, for the 
purposes of this specification, all we care about is that the algorithms
use the same format and size of keying material (see also security
considerations) and that they do not differ significantly in terms
of the resulting cryptographic "strength". In that sense the two 
algorithms in the example above are the "same.""

> The best overall approach might be to say that if the KEK is A and the CEK
> is B then you use the byte-reveral method and just the list ones that
> "match" in impedance.

I'd really rather not be listing pairs of algorithms in this document.
Would the addition of the text above be sufficient?

> 
> 7.  Remove appendix B.

Nope:-) Actually, I think these are very useful and the RFC editor seems 
happy to reomve 'em.

> 
> 8.  Appendix A. Missing module number

Yep. Russ?

> 9.  Appendix A.  --<<IMPLICIT??>>-- should be removed or fixed

Well, which do you prefer in this case? I'm not sure.

> 
> 10.  id-reck-attrs is TDB

Yep.

> 
> 12.  Please add comments to the effect of what goes into each of the fields
> and that there is an association between the pairs as OID attribute value.

Huh? You mean in the ASN.1 module? I think in a 7 page i-d, the reader
is expected to read more than just the ASN.1 module.

Stephen.


-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) [phone]
39 Parkgate Street,                     fax: [phone]
Dublin 8.                mailto:[e-mail]
Ireland                             http://www.baltimore.com


Received: by above.proper.com (8.9.3/8.9.3) id PAA11305 for ietf-smime-bks; Sun, 25 Feb 2001 15:14:29 -0800 (PST)
Received: from femail3.sdc1.sfba.home.com (femail3.sdc1.sfba.home.com [24.0.95.83]) by above.proper.com (8.9.3/8.9.3) with ESMTP id PAA11299 for <[e-mail]>; Sun, 25 Feb 2001 15:14:27 -0800 (PST)
Received: from revelation ([65.4.166.11]) by femail3.sdc1.sfba.home.com (InterMail vM.4.01.03.00 201-229-121) with SMTP id <20010225231225.PEBM11050.femail3.sdc1.sfba.home.com@revelation> for <[e-mail]>; Sun, 25 Feb 2001 15:12:25 -0800
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: <[e-mail]>
Subject: RE: WG Last Call:draft-ietf-smime-rcek-01.txt
Date: Sun, 25 Feb 2001 15:16:18 -0800
Message-ID: <002301c09f80$f660e770$[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 CWS, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
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>

First - I assume that the last call is not going to be closed on the 26th
because a new version of the document needs to be issued with some fixes in
it.

Changes that I think need to be addressed before advancement.

1.  I would like to see a section added to section 2 to describe why this
"trick" is being used rather than just establishing a short-term kek value
which is used for a time period and then tossed.  I.e. When do you use this
trick and when do you establish a multi-use kek value.

2.  Please add a paragraph to the security section area about the fact that
byte reversal may not be a good idea if the algorithm does a parity type
check over a larger than byte block. I.e. describe why the bit-wise
flip-flop was a "bad" idea.

3.  Section 3, Note 2.  Please change the text from "can occur in any of
the" to "can occur with any of the".  The attribute cannot occur inside of
any ReceipientInfo object as it is an unathenticated attribute.

4.  Section 3.  id-reck-attrs has a TBD.

5.  Section 3.  What is the default value of CEKMaxDecrypts if it is not
present.

6.  Section 4.  First, the CE algorithm and the KE algorithm are never "the
same" in some sense.  id-alg-CMS3DESwrap and des-ede3-cbc are different in a
number of significant ways.  Please change the text.  I would suggest
something along "If the CE algorithm and KE algorithm use the same key
material...".  I have problems with even this because of the question of a
CEK of 128-bit RC2 and a KEK of 40-bit RC2 in which case it is not clear
that this is the algorithm one should be using.

The best overall approach might be to say that if the KEK is A and the CEK
is B then you use the byte-reveral method and just the list ones that
"match" in impedance.

7.  Remove appendix B.

8.  Appendix A. Missing module number

9.  Appendix A.  --<<IMPLICIT??>>-- should be removed or fixed

10.  id-reck-attrs is TDB

12.  Please add comments to the effect of what goes into each of the fields
and that there is an association between the pairs as OID attribute value.

jim



Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id HAA24842 for ietf-smime-bks; Fri, 23 Feb 2001 07:58:49 -0800 (PST)
Received: from mail.eris.dera.gov.uk (ns0.eris.dera.gov.uk [128.98.1.1]) by above.proper.com (8.9.3/8.9.3) with SMTP id HAA24832 for <[e-mail]>; Fri, 23 Feb 2001 07:58:47 -0800 (PST)
Received: (qmail 18799 invoked from network); 23 Feb 2001 15:58:47 -0000
Received: from cray.eris.dera.gov.uk (HELO mailhost.eris.dera.gov.uk) (128.98.2.7) by ens0.eris.dera.gov.uk with SMTP; 23 Feb 2001 15:58:47 -0000
Received: (qmail 7161 invoked from network); 23 Feb 2001 15:58:46 -0000
Received: from wottaway.eris.dera.gov.uk (HELO wottaway) (128.98.10.192) by mailhost.eris.dera.gov.uk with SMTP; 23 Feb 2001 15:58:46 -0000
From: "William Ottaway" <[e-mail]>
To: <[e-mail]>, "'Bonatti, Chris'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Certs-only Mechanism for X.400 Transport
Date: Fri, 23 Feb 2001 16:03:26 -0000
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <001601c09daf$6c4cbd20$[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
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 think I'm inferring what is done. :-)

My only gripe is I don't like the statement "This format can also be used to
convey CRLs." followed by a description of how to carry certificates but no
description of how to carry CRLs in a similar format.

Its too late to change RFC 2633 but draft-ietf-smime-x400trans could say
something different.

1) Don't mention that CRLs can be carried in a similar way to a certs only
message

or

2) Specify an OID for a CRL only message.

Bill.

> -----Original Message-----
> From: Jim Schaad [mailto:[e-mail]]
> Sent: 23 February 2001 15:44
> To: 'William Ottaway'; 'Bonatti, Chris'
> Cc: [e-mail]
> Subject: RE: Certs-only Mechanism for X.400 Transport
>
>
> Bill,
>
> I think you are over infering what is done.  While it would be possible to
> define a CRLs only message nobody has done so todate.  At this
> point in time
> CRLs are distributed (for S/MIME) either in a signed/encrypted
> message (with
> content) or the client is responsable to finding the CRL by following CDPs
> and the like.
>
> jim
>
> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of William Ottaway
> Sent: Thursday, February 22, 2001 9:08 AM
> To: Bonatti, Chris
> Cc: [e-mail]
> Subject: RE: Certs-only Mechanism for X.400 Transport
>
>
> Chris,
>
> RFC 2633 hints that CRLs can be sent in a similar format to a cert only
> message. It then states that for a cert only message the smime type is
> "certs-only".
>
> I interpret the text in 3.6 of RFC 2633 as telling me that a CRL only
> message could be sent in a similar way as the cert only message but would
> have a "crl-only" smime type.
>
> I can't comment on how CRLs are commonly sent.
>
> If you don't believe that you will use the same mechanism to
> transport CRLs
> as certs I would suggest removing the text "This format can also
> be used to
> convey CRLs".
>
> Bill.
>
> > -----Original Message-----
> > From: Bonatti, Chris [mailto:[e-mail]]
> > Sent: 21 February 2001 17:26
> > To: William Ottaway
> > Cc: [e-mail]
> > Subject: Re: Certs-only Mechanism for X.400 Transport
> >
> >
> > Bill,
> >
> >     I would not object to this myself, but it differs from the
> > treatment in
> > RFC 2633.  Also, I don't think CRLs are commonly sent using this
> > mechanism, so
> > I wonder about whether it's a scenario worth optimizing for.
> >
> > Chris
> >
> >
> > ____________________
> >
> > William Ottaway wrote:
> >
> > > Chris,
> > >
> > > Rather than state "This format can also be used to convey CRLs
> > " how about
> > > specifying an OID for CRLs and describing how a CRL is
> transported, this
> > > could be in a separate section or you could describe CRL and
> certificate
> > > transport in the same section, as the only difference will be the OID.
> > >
> > > Bill.
> > >
> > > > -----Original Message-----
> > > > From: [e-mail]
> > > > [mailto:[e-mail]]On Behalf Of Bonatti, Chris
> > > > Sent: 20 February 2001 15:22
> > > > To: [e-mail]
> > > > Subject: Certs-only Mechanism for X.400 Transport
> > > >
> > > >
> > > >     Some discussion after the December meeting, suggested that we
> > > > revise the specification for transporting S/MIME objects in X.400
> > > > (draft-ietf-smime-x400trans) to enable certs-only messages to be
> > > > readily identified.  This responds to the assumption that the
> > > > PKCS #10 certificate request may be adapted to and used in the
> > > > X.400 environment.  I admittedly didn't go down this road in my
> > > > thinking, but it seems plausible enough.
> > > >
> > > >     After elaborating all the options (and doing some significant
> > > > consultation with X.400 wonks) I recommend that we use the
> > > > Encoded Information Types (EITs) facility of X.400 to distinguish
> > > > the certs-only messages.  This mechanism is non-invasive to the
> > > > security function, well-suited to the job at hand, and well
> > > > supported in the X.400 community.  The main impact to x400trans
> > > > spec is that we define a new OID value to represent the new
> > > > "certs-only" EIT.  To that end, I propose that the following new
> > > > section (see below) be inserted in the spec.
> > > >
> > > >     Discussion on this point is, of course, welcome.
> > > >
> > > > Chris
> > > >
> > > >
> > > > ____________________
> > > >
> > > > 2.5 Certificates-only Message
> > > >
> > > > The certificates-only message is used to transport certificates,
> > > > such as in response to a registration request.  This format can
> > > > also be used to convey CRLs.  The certificates-only message
> > > > consists of a single instance of CMS content of type
> > > > Signed-data.  The encapContentInfo eContent field MUST be absent
> > > > and signerInfos field MUST be empty.
> > > >
> > > > The resulting certificates-only CMS content is conveyed in
> > > > accordance with section 2.2.  The following OID value is defined
> > > > to identify certificates-only messages in the X.400 transport
> > > > environment.
> > > >
> > > >     id-eit-certsOnly  OBJECT IDENTIFIER ::=
> > > >         { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
> > > >         pkcs-9(9) smime(16) eits(***) certsOnly(1) }
> > > >
> > > > Sending agents SHOULD include this OID in the
> > > > original-encoded-information-types (EITs) field of the X.400
> > > > message envelope.  Receiving agents SHOULD recognize the this OID
> > > > value in the EITs field, and process the certificates-only
> > > > appropriately according to local procedures.
> > > >
> > > >
> > > >
> >
>
>



Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id HAA22562 for ietf-smime-bks; Fri, 23 Feb 2001 07:42:05 -0800 (PST)
Received: from femail3.sdc1.sfba.home.com (femail3.sdc1.sfba.home.com [24.0.95.83]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA22552 for <[e-mail]>; Fri, 23 Feb 2001 07:42:03 -0800 (PST)
Received: from revelation ([65.4.166.11]) by femail3.sdc1.sfba.home.com (InterMail vM.4.01.03.00 201-229-121) with SMTP id <20010223153959.ZKAT11050.femail3.sdc1.sfba.home.com@revelation>; Fri, 23 Feb 2001 07:39:59 -0800
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: "'William Ottaway'" <[e-mail]>, "'Bonatti, Chris'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Certs-only Mechanism for X.400 Transport
Date: Fri, 23 Feb 2001 07:43:50 -0800
Message-ID: <001601c09daf$6c4cbd20$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
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>

Bill,

I think you are over infering what is done.  While it would be possible to
define a CRLs only message nobody has done so todate.  At this point in time
CRLs are distributed (for S/MIME) either in a signed/encrypted message (with
content) or the client is responsable to finding the CRL by following CDPs
and the like.

jim

-----Original Message-----
From: [e-mail]
[mailto:[e-mail]]On Behalf Of William Ottaway
Sent: Thursday, February 22, 2001 9:08 AM
To: Bonatti, Chris
Cc: [e-mail]
Subject: RE: Certs-only Mechanism for X.400 Transport


Chris,

RFC 2633 hints that CRLs can be sent in a similar format to a cert only
message. It then states that for a cert only message the smime type is
"certs-only".

I interpret the text in 3.6 of RFC 2633 as telling me that a CRL only
message could be sent in a similar way as the cert only message but would
have a "crl-only" smime type.

I can't comment on how CRLs are commonly sent.

If you don't believe that you will use the same mechanism to transport CRLs
as certs I would suggest removing the text "This format can also be used to
convey CRLs".

Bill.

> -----Original Message-----
> From: Bonatti, Chris [mailto:[e-mail]]
> Sent: 21 February 2001 17:26
> To: William Ottaway
> Cc: [e-mail]
> Subject: Re: Certs-only Mechanism for X.400 Transport
>
>
> Bill,
>
>     I would not object to this myself, but it differs from the
> treatment in
> RFC 2633.  Also, I don't think CRLs are commonly sent using this
> mechanism, so
> I wonder about whether it's a scenario worth optimizing for.
>
> Chris
>
>
> ____________________
>
> William Ottaway wrote:
>
> > Chris,
> >
> > Rather than state "This format can also be used to convey CRLs
> " how about
> > specifying an OID for CRLs and describing how a CRL is transported, this
> > could be in a separate section or you could describe CRL and certificate
> > transport in the same section, as the only difference will be the OID.
> >
> > Bill.
> >
> > > -----Original Message-----
> > > From: [e-mail]
> > > [mailto:[e-mail]]On Behalf Of Bonatti, Chris
> > > Sent: 20 February 2001 15:22
> > > To: [e-mail]
> > > Subject: Certs-only Mechanism for X.400 Transport
> > >
> > >
> > >     Some discussion after the December meeting, suggested that we
> > > revise the specification for transporting S/MIME objects in X.400
> > > (draft-ietf-smime-x400trans) to enable certs-only messages to be
> > > readily identified.  This responds to the assumption that the
> > > PKCS #10 certificate request may be adapted to and used in the
> > > X.400 environment.  I admittedly didn't go down this road in my
> > > thinking, but it seems plausible enough.
> > >
> > >     After elaborating all the options (and doing some significant
> > > consultation with X.400 wonks) I recommend that we use the
> > > Encoded Information Types (EITs) facility of X.400 to distinguish
> > > the certs-only messages.  This mechanism is non-invasive to the
> > > security function, well-suited to the job at hand, and well
> > > supported in the X.400 community.  The main impact to x400trans
> > > spec is that we define a new OID value to represent the new
> > > "certs-only" EIT.  To that end, I propose that the following new
> > > section (see below) be inserted in the spec.
> > >
> > >     Discussion on this point is, of course, welcome.
> > >
> > > Chris
> > >
> > >
> > > ____________________
> > >
> > > 2.5 Certificates-only Message
> > >
> > > The certificates-only message is used to transport certificates,
> > > such as in response to a registration request.  This format can
> > > also be used to convey CRLs.  The certificates-only message
> > > consists of a single instance of CMS content of type
> > > Signed-data.  The encapContentInfo eContent field MUST be absent
> > > and signerInfos field MUST be empty.
> > >
> > > The resulting certificates-only CMS content is conveyed in
> > > accordance with section 2.2.  The following OID value is defined
> > > to identify certificates-only messages in the X.400 transport
> > > environment.
> > >
> > >     id-eit-certsOnly  OBJECT IDENTIFIER ::=
> > >         { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
> > >         pkcs-9(9) smime(16) eits(***) certsOnly(1) }
> > >
> > > Sending agents SHOULD include this OID in the
> > > original-encoded-information-types (EITs) field of the X.400
> > > message envelope.  Receiving agents SHOULD recognize the this OID
> > > value in the EITs field, and process the certificates-only
> > > appropriately according to local procedures.
> > >
> > >
> > >
>




Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id KAA26058 for ietf-smime-bks; Thu, 22 Feb 2001 10:25:51 -0800 (PST)
Received: from smtp-a.capu.net (IDENT:[e-mail] [205.177.76.122]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA26053 for <[e-mail]>; Thu, 22 Feb 2001 10:25:50 -0800 (PST)
Received: from ieca.com (dial-216-98.capu.net [64.50.216.98]) by smtp-a.capu.net (8.9.3/8.9.3) with ESMTP id NAA17234; Thu, 22 Feb 2001 13:25:46 -0500
Message-ID: <[e-mail]>
Date: Thu, 22 Feb 2001 13:25:42 -0500
From: "Bonatti, Chris" <[e-mail]>
Organization: IECA, Inc.
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: William Ottaway <[e-mail]>
CC: [e-mail]
Subject: Re: Certs-only Mechanism for X.400 Transport
References: <[e-mail]>
Content-Type: text/plain; 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>

Bill,

What 3.6 says seems pretty clear.  It says:

> The certificates only message or MIME entity is used to transport
> certificates, such as in response to a registration request. This
> format can also be used to convey CRLs.
>

This seems pretty clear that they are the same format.  It then goes on to say
that the certs-only format is an empty 'SignedData' structure.  So if this were
to be used for CRLs, I would make the inference that the 'certificates' and
'crls' fields of the 'signedData' should be used.

Chris



_____________________

William Ottaway wrote:

> Chris,
>
> RFC 2633 hints that CRLs can be sent in a similar format to a cert only
> message. It then states that for a cert only message the smime type is
> "certs-only".
>
> I interpret the text in 3.6 of RFC 2633 as telling me that a CRL only
> message could be sent in a similar way as the cert only message but would
> have a "crl-only" smime type.
>
> I can't comment on how CRLs are commonly sent.
>
> If you don't believe that you will use the same mechanism to transport CRLs
> as certs I would suggest removing the text "This format can also be used to
> convey CRLs".
>
> Bill.
>
> > -----Original Message-----
> > From: Bonatti, Chris [mailto:[e-mail]]
> > Sent: 21 February 2001 17:26
> > To: William Ottaway
> > Cc: [e-mail]
> > Subject: Re: Certs-only Mechanism for X.400 Transport
> >
> >
> > Bill,
> >
> >     I would not object to this myself, but it differs from the
> > treatment in
> > RFC 2633.  Also, I don't think CRLs are commonly sent using this
> > mechanism, so
> > I wonder about whether it's a scenario worth optimizing for.
> >
> > Chris
> >
> >
> > ____________________
> >
> > William Ottaway wrote:
> >
> > > Chris,
> > >
> > > Rather than state "This format can also be used to convey CRLs
> > " how about
> > > specifying an OID for CRLs and describing how a CRL is transported, this
> > > could be in a separate section or you could describe CRL and certificate
> > > transport in the same section, as the only difference will be the OID.
> > >
> > > Bill.
> > >
> > > > -----Original Message-----
> > > > From: [e-mail]
> > > > [mailto:[e-mail]]On Behalf Of Bonatti, Chris
> > > > Sent: 20 February 2001 15:22
> > > > To: [e-mail]
> > > > Subject: Certs-only Mechanism for X.400 Transport
> > > >
> > > >
> > > >     Some discussion after the December meeting, suggested that we
> > > > revise the specification for transporting S/MIME objects in X.400
> > > > (draft-ietf-smime-x400trans) to enable certs-only messages to be
> > > > readily identified.  This responds to the assumption that the
> > > > PKCS #10 certificate request may be adapted to and used in the
> > > > X.400 environment.  I admittedly didn't go down this road in my
> > > > thinking, but it seems plausible enough.
> > > >
> > > >     After elaborating all the options (and doing some significant
> > > > consultation with X.400 wonks) I recommend that we use the
> > > > Encoded Information Types (EITs) facility of X.400 to distinguish
> > > > the certs-only messages.  This mechanism is non-invasive to the
> > > > security function, well-suited to the job at hand, and well
> > > > supported in the X.400 community.  The main impact to x400trans
> > > > spec is that we define a new OID value to represent the new
> > > > "certs-only" EIT.  To that end, I propose that the following new
> > > > section (see below) be inserted in the spec.
> > > >
> > > >     Discussion on this point is, of course, welcome.
> > > >
> > > > Chris
> > > >
> > > >
> > > > ____________________
> > > >
> > > > 2.5 Certificates-only Message
> > > >
> > > > The certificates-only message is used to transport certificates,
> > > > such as in response to a registration request.  This format can
> > > > also be used to convey CRLs.  The certificates-only message
> > > > consists of a single instance of CMS content of type
> > > > Signed-data.  The encapContentInfo eContent field MUST be absent
> > > > and signerInfos field MUST be empty.
> > > >
> > > > The resulting certificates-only CMS content is conveyed in
> > > > accordance with section 2.2.  The following OID value is defined
> > > > to identify certificates-only messages in the X.400 transport
> > > > environment.
> > > >
> > > >     id-eit-certsOnly  OBJECT IDENTIFIER ::=
> > > >         { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
> > > >         pkcs-9(9) smime(16) eits(***) certsOnly(1) }
> > > >
> > > > Sending agents SHOULD include this OID in the
> > > > original-encoded-information-types (EITs) field of the X.400
> > > > message envelope.  Receiving agents SHOULD recognize the this OID
> > > > value in the EITs field, and process the certificates-only
> > > > appropriately according to local procedures.
> > > >
> > > >
> > > >
> >



Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id JAA22542 for ietf-smime-bks; Thu, 22 Feb 2001 09:03:16 -0800 (PST)
Received: from mail.eris.dera.gov.uk (ns0.eris.dera.gov.uk [128.98.1.1]) by above.proper.com (8.9.3/8.9.3) with SMTP id JAA22536 for <[e-mail]>; Thu, 22 Feb 2001 09:03:12 -0800 (PST)
Received: (qmail 19247 invoked from network); 22 Feb 2001 17:03:13 -0000
Received: from cray.eris.dera.gov.uk (HELO mailhost.eris.dera.gov.uk) (128.98.2.7) by ens0.eris.dera.gov.uk with SMTP; 22 Feb 2001 17:03:13 -0000
Received: (qmail 29512 invoked from network); 22 Feb 2001 17:03:06 -0000
Received: from wottaway.eris.dera.gov.uk (HELO wottaway) (128.98.10.192) by mailhost.eris.dera.gov.uk with SMTP; 22 Feb 2001 17:03:06 -0000
From: "William Ottaway" <[e-mail]>
To: "Bonatti, Chris" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Certs-only Mechanism for X.400 Transport
Date: Thu, 22 Feb 2001 17:07:43 -0000
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
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>

Chris,

RFC 2633 hints that CRLs can be sent in a similar format to a cert only
message. It then states that for a cert only message the smime type is
"certs-only".

I interpret the text in 3.6 of RFC 2633 as telling me that a CRL only
message could be sent in a similar way as the cert only message but would
have a "crl-only" smime type.

I can't comment on how CRLs are commonly sent.

If you don't believe that you will use the same mechanism to transport CRLs
as certs I would suggest removing the text "This format can also be used to
convey CRLs".

Bill.

> -----Original Message-----
> From: Bonatti, Chris [mailto:[e-mail]]
> Sent: 21 February 2001 17:26
> To: William Ottaway
> Cc: [e-mail]
> Subject: Re: Certs-only Mechanism for X.400 Transport
>
>
> Bill,
>
>     I would not object to this myself, but it differs from the
> treatment in
> RFC 2633.  Also, I don't think CRLs are commonly sent using this
> mechanism, so
> I wonder about whether it's a scenario worth optimizing for.
>
> Chris
>
>
> ____________________
>
> William Ottaway wrote:
>
> > Chris,
> >
> > Rather than state "This format can also be used to convey CRLs
> " how about
> > specifying an OID for CRLs and describing how a CRL is transported, this
> > could be in a separate section or you could describe CRL and certificate
> > transport in the same section, as the only difference will be the OID.
> >
> > Bill.
> >
> > > -----Original Message-----
> > > From: [e-mail]
> > > [mailto:[e-mail]]On Behalf Of Bonatti, Chris
> > > Sent: 20 February 2001 15:22
> > > To: [e-mail]
> > > Subject: Certs-only Mechanism for X.400 Transport
> > >
> > >
> > >     Some discussion after the December meeting, suggested that we
> > > revise the specification for transporting S/MIME objects in X.400
> > > (draft-ietf-smime-x400trans) to enable certs-only messages to be
> > > readily identified.  This responds to the assumption that the
> > > PKCS #10 certificate request may be adapted to and used in the
> > > X.400 environment.  I admittedly didn't go down this road in my
> > > thinking, but it seems plausible enough.
> > >
> > >     After elaborating all the options (and doing some significant
> > > consultation with X.400 wonks) I recommend that we use the
> > > Encoded Information Types (EITs) facility of X.400 to distinguish
> > > the certs-only messages.  This mechanism is non-invasive to the
> > > security function, well-suited to the job at hand, and well
> > > supported in the X.400 community.  The main impact to x400trans
> > > spec is that we define a new OID value to represent the new
> > > "certs-only" EIT.  To that end, I propose that the following new
> > > section (see below) be inserted in the spec.
> > >
> > >     Discussion on this point is, of course, welcome.
> > >
> > > Chris
> > >
> > >
> > > ____________________
> > >
> > > 2.5 Certificates-only Message
> > >
> > > The certificates-only message is used to transport certificates,
> > > such as in response to a registration request.  This format can
> > > also be used to convey CRLs.  The certificates-only message
> > > consists of a single instance of CMS content of type
> > > Signed-data.  The encapContentInfo eContent field MUST be absent
> > > and signerInfos field MUST be empty.
> > >
> > > The resulting certificates-only CMS content is conveyed in
> > > accordance with section 2.2.  The following OID value is defined
> > > to identify certificates-only messages in the X.400 transport
> > > environment.
> > >
> > >     id-eit-certsOnly  OBJECT IDENTIFIER ::=
> > >         { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
> > >         pkcs-9(9) smime(16) eits(***) certsOnly(1) }
> > >
> > > Sending agents SHOULD include this OID in the
> > > original-encoded-information-types (EITs) field of the X.400
> > > message envelope.  Receiving agents SHOULD recognize the this OID
> > > value in the EITs field, and process the certificates-only
> > > appropriately according to local procedures.
> > >
> > >
> > >
>



Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id JAA20635 for ietf-smime-bks; Wed, 21 Feb 2001 09:26:20 -0800 (PST)
Received: from smtp-a.capu.net (IDENT:[e-mail] [205.177.76.122]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA20630 for <[e-mail]>; Wed, 21 Feb 2001 09:26:19 -0800 (PST)
Received: from ieca.com (dial-216-83.capu.net [64.50.216.83]) by smtp-a.capu.net (8.9.3/8.9.3) with ESMTP id MAA01425; Wed, 21 Feb 2001 12:26:10 -0500
Message-ID: <[e-mail]>
Date: Wed, 21 Feb 2001 12:26:07 -0500
From: "Bonatti, Chris" <[e-mail]>
Organization: IECA, Inc.
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: William Ottaway <[e-mail]>
CC: [e-mail]
Subject: Re: Certs-only Mechanism for X.400 Transport
References: <[e-mail]>
Content-Type: text/plain; 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>

Bill,

    I would not object to this myself, but it differs from the treatment in
RFC 2633.  Also, I don't think CRLs are commonly sent using this mechanism, so
I wonder about whether it's a scenario worth optimizing for.

Chris


____________________

William Ottaway wrote:

> Chris,
>
> Rather than state "This format can also be used to convey CRLs " how about
> specifying an OID for CRLs and describing how a CRL is transported, this
> could be in a separate section or you could describe CRL and certificate
> transport in the same section, as the only difference will be the OID.
>
> Bill.
>
> > -----Original Message-----
> > From: [e-mail]
> > [mailto:[e-mail]]On Behalf Of Bonatti, Chris
> > Sent: 20 February 2001 15:22
> > To: [e-mail]
> > Subject: Certs-only Mechanism for X.400 Transport
> >
> >
> >     Some discussion after the December meeting, suggested that we
> > revise the specification for transporting S/MIME objects in X.400
> > (draft-ietf-smime-x400trans) to enable certs-only messages to be
> > readily identified.  This responds to the assumption that the
> > PKCS #10 certificate request may be adapted to and used in the
> > X.400 environment.  I admittedly didn't go down this road in my
> > thinking, but it seems plausible enough.
> >
> >     After elaborating all the options (and doing some significant
> > consultation with X.400 wonks) I recommend that we use the
> > Encoded Information Types (EITs) facility of X.400 to distinguish
> > the certs-only messages.  This mechanism is non-invasive to the
> > security function, well-suited to the job at hand, and well
> > supported in the X.400 community.  The main impact to x400trans
> > spec is that we define a new OID value to represent the new
> > "certs-only" EIT.  To that end, I propose that the following new
> > section (see below) be inserted in the spec.
> >
> >     Discussion on this point is, of course, welcome.
> >
> > Chris
> >
> >
> > ____________________
> >
> > 2.5 Certificates-only Message
> >
> > The certificates-only message is used to transport certificates,
> > such as in response to a registration request.  This format can
> > also be used to convey CRLs.  The certificates-only message
> > consists of a single instance of CMS content of type
> > Signed-data.  The encapContentInfo eContent field MUST be absent
> > and signerInfos field MUST be empty.
> >
> > The resulting certificates-only CMS content is conveyed in
> > accordance with section 2.2.  The following OID value is defined
> > to identify certificates-only messages in the X.400 transport
> > environment.
> >
> >     id-eit-certsOnly  OBJECT IDENTIFIER ::=
> >         { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
> >         pkcs-9(9) smime(16) eits(***) certsOnly(1) }
> >
> > Sending agents SHOULD include this OID in the
> > original-encoded-information-types (EITs) field of the X.400
> > message envelope.  Receiving agents SHOULD recognize the this OID
> > value in the EITs field, and process the certificates-only
> > appropriately according to local procedures.
> >
> >
> >



Received: by above.proper.com (8.9.3/8.9.3) id GAA08660 for ietf-smime-bks; Wed, 21 Feb 2001 06:38:50 -0800 (PST)
Received: from balinese.baltimore.ie ([e-mail] [194.125.215.8]) by above.proper.com (8.9.3/8.9.3) with ESMTP id GAA08656 for <[e-mail]>; Wed, 21 Feb 2001 06:38:48 -0800 (PST)
Received: by balinese.baltimore.ie; id OAA16142; Wed, 21 Feb 2001 14:38:49 GMT
Received: from emeairlsw1.ie.baltimore.com(10.153.25.53) by balinese.baltimore.ie via smap (V4.2) id xma015904; Wed, 21 Feb 01 14:37:49 GMT
Received: from bobcat.baltimore.ie (unverified) by emeairlsw1.baltimore.com (Content Technologies SMTPRS 4.2.1) with ESMTP id <[e-mail]>; Wed, 21 Feb 2001 14:37:17 +0000
Received: from baltimore.ie (ip187-24.ie.baltimore.com [10.153.24.187]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id OAA20856; Wed, 21 Feb 2001 14:37:44 GMT
Message-ID: <[e-mail]>
Date: Wed, 21 Feb 2001 14:37:45 +0000
From: Stephen Farrell <[e-mail]>
Reply-To: [e-mail]
Organization: Baltimore Technologies Ltd.
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Russ Housley <[e-mail]>
CC: [e-mail]
Subject: Re: WG Last Call:draft-ietf-smime-rcek-01.txt
References: <[e-mail]>
Content-Type: text/plain; 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>

Russ Housley wrote:
> 
> Byte reversal seems okay to me.

I agree. If there's a substantive reason to change, then ok,
but I don't believe there is.

Stephen.


-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) [phone]
39 Parkgate Street,                     fax: [phone]
Dublin 8.                mailto:[e-mail]
Ireland                             http://www.baltimore.com


Received: by above.proper.com (8.9.3/8.9.3) id PAA04306 for ietf-smime-bks; Tue, 20 Feb 2001 15:32:58 -0800 (PST)
Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by above.proper.com (8.9.3/8.9.3) with SMTP id PAA04302 for <[e-mail]>; Tue, 20 Feb 2001 15:32:57 -0800 (PST)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Tue, 20 Feb 2001 16:32:24 -0700
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.5.5
Date: Tue, 20 Feb 2001 16:32:18 -0700
From: "Tolga Acar" <[e-mail]>
To: <[e-mail]>, <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: Re: WG Last Call:draft-ietf-smime-rcek-01.txt
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=_A6FD0398.40211F7E"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=_A6FD0398.40211F7E
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

It may be prudent to use a FIPS 140-1/2 certifiable PRF, such as defined =
in FIPS 186-2 using SHA-1 in the core. I'm not sure if p1363a's KDF2 is =
the same as FIPS 186-2 G function-based PRF.

- Tolga

>>> [e-mail] 2/20/01 16:11:53 >>>
William Whyte <[e-mail]> writes:
> > >William suggests byte reversal instead, which seems ok from both
> perspectives.
> >=20
> > Okay.  So, since bitwise-NOT and bit-reversal both have shortcomings, =
what
>=20
> > are you going to use as the mandatory to implement transform?
>=20
> As Stephen says, I've suggested byte reversal. In fact, what I
> would most like to see as the mandatory to implement transform
> is X9.63 key derivation (the key derivation function referred
> to as KDF2 in IEEE P1363a), but to the best of my knowledge there's
> no stable, freely-available description of this that we could
> reference. If anyone fancied writing it up as an RFC that'd
> be very nice...
How about using the PRF from TLS? It's HMAC-based, widely viewed
as strong, and easily referenceable.

-Ekr

--=_A6FD0398.40211F7E
Content-Type: text/plain
Content-Disposition: attachment; filename="TEXT.htm"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 5.50.4611.1300" name=GENERATOR></HEAD>
<BODY style="MARGIN-TOP: 2px; FONT: 10pt Arial; MARGIN-LEFT: 2px">
<DIV>It may be prudent to use a FIPS 140-1/2 certifiable PRF, such as defined in 
FIPS 186-2 using SHA-1 in the core. I'm not sure if p1363a's KDF2 is the same as 
FIPS 186-2 G function-based PRF.</DIV>
<DIV>&nbsp;</DIV>
<DIV>- Tolga<BR><BR>&gt;&gt;&gt; [e-mail] 2/20/01 16:11:53 
&gt;&gt;&gt;<BR>William Whyte &lt;[e-mail]&gt; writes:<BR>&gt; &gt; 
&gt;William suggests byte reversal instead, which seems ok from both<BR>&gt; 
perspectives.<BR>&gt; &gt; <BR>&gt; &gt; Okay.&nbsp; So, since bitwise-NOT and 
bit-reversal both have shortcomings, what<BR>&gt; <BR>&gt; &gt; are you going to 
use as the mandatory to implement transform?<BR>&gt; <BR>&gt; As Stephen says, 
I've suggested byte reversal. In fact, what I<BR>&gt; would most like to see as 
the mandatory to implement transform<BR>&gt; is X9.63 key derivation (the key 
derivation function referred<BR>&gt; to as KDF2 in IEEE P1363a), but to the best 
of my knowledge there's<BR>&gt; no stable, freely-available description of this 
that we could<BR>&gt; reference. If anyone fancied writing it up as an RFC 
that'd<BR>&gt; be very nice...<BR>How about using the PRF from TLS? It's 
HMAC-based, widely viewed<BR>as strong, and easily 
referenceable.<BR><BR>-Ekr<BR></DIV></BODY></HTML>

--=_A6FD0398.40211F7E--


Received: by above.proper.com (8.9.3/8.9.3) id PAA03697 for ietf-smime-bks; Tue, 20 Feb 2001 15:07:21 -0800 (PST)
Received: from romeo.rtfm.com (m206-141.dsl.tsoft.com [198.144.206.141]) by above.proper.com (8.9.3/8.9.3) with ESMTP id PAA03693 for <[e-mail]>; Tue, 20 Feb 2001 15:07:20 -0800 (PST)
Received: (ekr@localhost) by romeo.rtfm.com (8.9.3/8.6.4) id PAA24482; Tue, 20 Feb 2001 15:11:53 -0800 (PST)
To: William Whyte <[e-mail]>
Cc: Russ Housley <[e-mail]>, [e-mail], [e-mail]
Subject: Re: WG Last Call:draft-ietf-smime-rcek-01.txt
References: <[e-mail]>
Reply-to: EKR <[e-mail]>
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
From: Eric Rescorla <[e-mail]>
Date: 20 Feb 2001 15:11:53 -0800
In-Reply-To: William Whyte's message of "Mon, 19 Feb 2001 09:58:08 -0000"
Message-ID: <[e-mail]>
Lines: 19
X-Mailer: Gnus v5.6.45/XEmacs 20.4 - "Emerald"
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>

William Whyte <[e-mail]> writes:
> > >William suggests byte reversal instead, which seems ok from both
> perspectives.
> > 
> > Okay.  So, since bitwise-NOT and bit-reversal both have shortcomings, what
> 
> > are you going to use as the mandatory to implement transform?
> 
> As Stephen says, I've suggested byte reversal. In fact, what I
> would most like to see as the mandatory to implement transform
> is X9.63 key derivation (the key derivation function referred
> to as KDF2 in IEEE P1363a), but to the best of my knowledge there's
> no stable, freely-available description of this that we could
> reference. If anyone fancied writing it up as an RFC that'd
> be very nice...
How about using the PRF from TLS? It's HMAC-based, widely viewed
as strong, and easily referenceable.

-Ekr


Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id OAA02841 for ietf-smime-bks; Tue, 20 Feb 2001 14:28:17 -0800 (PST)
Received: from exchsrv1.cosinecom.com (mail.cosinecom.com [63.88.104.16]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA02834 for <[e-mail]>; Tue, 20 Feb 2001 14:28:16 -0800 (PST)
Received: by exchsrv1.cosinecom.com with Internet Mail Service (5.5.2653.19) id <1XBP1GC7>; Tue, 20 Feb 2001 14:25:15 -0800
Message-ID: <[e-mail]>
From: Paul Lambert <[e-mail]>
To: "'William Whyte'" <[e-mail]>
Cc: [e-mail], Russ Housley <[e-mail]>, [e-mail]
Subject: RE: WG Last Call:draft-ietf-smime-rcek-01.txt
Date: Tue, 20 Feb 2001 14:25:14 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C09B8B.FEA59DC0"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C09B8B.FEA59DC0
Content-Type: text/plain;
	charset="iso-8859-1"


The ANSI documents are not on line, but there is a short description of the
KDF in section 3.8 of:

http://csrc.nist.gov/encryption/kms/summary-x9-63.pdf


Is this the one you're proposing?

Paul 

-----Original Message-----
From: William Whyte [mailto:[e-mail]]
Sent: Monday, February 19, 2001 1:58 AM
To: Russ Housley; [e-mail]
Cc: [e-mail]
Subject: RE: WG Last Call:draft-ietf-smime-rcek-01.txt


> >William suggests byte reversal instead, which seems ok from both
perspectives.
> 
> Okay.  So, since bitwise-NOT and bit-reversal both have shortcomings, what

> are you going to use as the mandatory to implement transform?

As Stephen says, I've suggested byte reversal. In fact, what I
would most like to see as the mandatory to implement transform
is X9.63 key derivation (the key derivation function referred
to as KDF2 in IEEE P1363a), but to the best of my knowledge there's
no stable, freely-available description of this that we could
reference. If anyone fancied writing it up as an RFC that'd
be very nice...

(I have to say I'm uncomfortable with the hacky use of PKCS#5
here. But at least PKCS#5 is referenceable).

Cheers,

William


----------------------------------------------------------------------------
-
Baltimore Technologies plc will not be liable for direct,  special,
indirect 
or consequential  damages  arising  from  alteration of  the contents of
this
message by a third party or as a result of any virus being passed on.

In addition, certain Marketing collateral may be added from time to time to
promote Baltimore Technologies products, services, Global e-Security or
appearance at trade shows and conferences.

This footnote confirms that this email message has been swept by
Baltimore MIMEsweeper for Content Security threats, including
computer viruses.
   http://www.baltimore.com

------_=_NextPart_001_01C09B8B.FEA59DC0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>RE: WG Last Call:draft-ietf-smime-rcek-01.txt</TITLE>
</HEAD>
<BODY>
<BR>

<P><FONT SIZE=3D2>The ANSI documents are not on line, but there is a =
short description of the KDF in section 3.8 of:</FONT>
</P>

<P><FONT SIZE=3D2><A =
HREF=3D"http://csrc.nist.gov/encryption/kms/summary-x9-63.pdf" =
TARGET=3D"_blank">http://csrc.nist.gov/encryption/kms/summary-x9-63.pdf<=
/A></FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Is this the one you're proposing?</FONT>
</P>

<P><FONT SIZE=3D2>Paul </FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: William Whyte [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>]</F=
ONT>
<BR><FONT SIZE=3D2>Sent: Monday, February 19, 2001 1:58 AM</FONT>
<BR><FONT SIZE=3D2>To: Russ Housley; =
[e-mail]</FONT>
<BR><FONT SIZE=3D2>Cc: [e-mail]</FONT>
<BR><FONT SIZE=3D2>Subject: RE: WG Last =
Call:draft-ietf-smime-rcek-01.txt</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>&gt; &gt;William suggests byte reversal instead, =
which seems ok from both</FONT>
<BR><FONT SIZE=3D2>perspectives.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Okay.&nbsp; So, since bitwise-NOT and =
bit-reversal both have shortcomings, what</FONT>
</P>

<P><FONT SIZE=3D2>&gt; are you going to use as the mandatory to =
implement transform?</FONT>
</P>

<P><FONT SIZE=3D2>As Stephen says, I've suggested byte reversal. In =
fact, what I</FONT>
<BR><FONT SIZE=3D2>would most like to see as the mandatory to implement =
transform</FONT>
<BR><FONT SIZE=3D2>is X9.63 key derivation (the key derivation function =
referred</FONT>
<BR><FONT SIZE=3D2>to as KDF2 in IEEE P1363a), but to the best of my =
knowledge there's</FONT>
<BR><FONT SIZE=3D2>no stable, freely-available description of this that =
we could</FONT>
<BR><FONT SIZE=3D2>reference. If anyone fancied writing it up as an RFC =
that'd</FONT>
<BR><FONT SIZE=3D2>be very nice...</FONT>
</P>

<P><FONT SIZE=3D2>(I have to say I'm uncomfortable with the hacky use =
of PKCS#5</FONT>
<BR><FONT SIZE=3D2>here. But at least PKCS#5 is referenceable).</FONT>
</P>

<P><FONT SIZE=3D2>Cheers,</FONT>
</P>

<P><FONT SIZE=3D2>William</FONT>
</P>
<BR>

<P><FONT =
SIZE=3D2>---------------------------------------------------------------=
--------------</FONT>
<BR><FONT SIZE=3D2>Baltimore Technologies plc will not be liable for =
direct,&nbsp; special,&nbsp; indirect </FONT>
<BR><FONT SIZE=3D2>or consequential&nbsp; damages&nbsp; arising&nbsp; =
from&nbsp; alteration of&nbsp; the contents of this</FONT>
<BR><FONT SIZE=3D2>message by a third party or as a result of any virus =
being passed on.</FONT>
</P>

<P><FONT SIZE=3D2>In addition, certain Marketing collateral may be =
added from time to time to</FONT>
<BR><FONT SIZE=3D2>promote Baltimore Technologies products, services, =
Global e-Security or</FONT>
<BR><FONT SIZE=3D2>appearance at trade shows and conferences.</FONT>
</P>

<P><FONT SIZE=3D2>This footnote confirms that this email message has =
been swept by</FONT>
<BR><FONT SIZE=3D2>Baltimore MIMEsweeper for Content Security threats, =
including</FONT>
<BR><FONT SIZE=3D2>computer viruses.</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; <A HREF=3D"http://www.baltimore.com" =
TARGET=3D"_blank">http://www.baltimore.com</A></FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C09B8B.FEA59DC0--


Received: by above.proper.com (8.9.3/8.9.3) id MAA29712 for ietf-smime-bks; Tue, 20 Feb 2001 12:13:48 -0800 (PST)
Received: from balinese.baltimore.ie ([e-mail] [194.125.215.8]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA29706 for <[e-mail]>; Tue, 20 Feb 2001 12:13:45 -0800 (PST)
Received: by balinese.baltimore.ie; id UAA24086; Tue, 20 Feb 2001 20:13:45 GMT
Received: from emeairlsw1.ie.baltimore.com(10.153.25.53) by balinese.baltimore.ie via smap (V4.2) id xma013935; Tue, 20 Feb 01 15:31:16 GMT
Received: from bobcat.baltimore.ie (unverified) by emeairlsw1.baltimore.com (Content Technologies SMTPRS 4.2.1) with ESMTP id <[e-mail]>; Tue, 20 Feb 2001 15:28:56 +0000
Received: from irlbdc.ie.baltimore.com (irlbdc.ie.baltimore.com [10.153.25.3]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id PAA19083; Tue, 20 Feb 2001 15:29:21 GMT
Received: by irlbdc.ie.baltimore.com with Internet Mail Service (5.5.2650.21) id <FKH6YAXL>; Tue, 20 Feb 2001 15:32:23 -0000
Message-ID: <[e-mail]>
From: William Whyte <[e-mail]>
To: Russ Housley <[e-mail]>, [e-mail]
Cc: [e-mail]
Subject: RE: WG Last Call:draft-ietf-smime-rcek-01.txt
Date: Mon, 19 Feb 2001 09:58:08 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
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>

> >William suggests byte reversal instead, which seems ok from both
perspectives.
> 
> Okay.  So, since bitwise-NOT and bit-reversal both have shortcomings, what

> are you going to use as the mandatory to implement transform?

As Stephen says, I've suggested byte reversal. In fact, what I
would most like to see as the mandatory to implement transform
is X9.63 key derivation (the key derivation function referred
to as KDF2 in IEEE P1363a), but to the best of my knowledge there's
no stable, freely-available description of this that we could
reference. If anyone fancied writing it up as an RFC that'd
be very nice...

(I have to say I'm uncomfortable with the hacky use of PKCS#5
here. But at least PKCS#5 is referenceable).

Cheers,

William


-----------------------------------------------------------------------------
Baltimore Technologies plc will not be liable for direct,  special,  indirect 
or consequential  damages  arising  from  alteration of  the contents of this
message by a third party or as a result of any virus being passed on.

In addition, certain Marketing collateral may be added from time to time to
promote Baltimore Technologies products, services, Global e-Security or
appearance at trade shows and conferences.

This footnote confirms that this email message has been swept by
Baltimore MIMEsweeper for Content Security threats, including
computer viruses.
   http://www.baltimore.com


Received: by above.proper.com (8.9.3/8.9.3) id LAA29207 for ietf-smime-bks; Tue, 20 Feb 2001 11:51:42 -0800 (PST)
Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA29203 for <[e-mail]>; Tue, 20 Feb 2001 11:51:41 -0800 (PST)
Received: from RHOUSLEY-PC.spyrus.com ([209.172.119.211]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id LAA13729; Tue, 20 Feb 2001 11:49:32 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.2
Date: Tue, 20 Feb 2001 14:39:11 -0500
To: William Whyte <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: RE: WG Last Call:draft-ietf-smime-rcek-01.txt
Cc: [e-mail]
In-Reply-To: <[e-mail] re.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>

Byte reversal seems okay to me.

Russ

At 09:58 AM 2/19/2001 +0000, William Whyte wrote:
> > >William suggests byte reversal instead, which seems ok from both
>perspectives.
> >
> > Okay.  So, since bitwise-NOT and bit-reversal both have shortcomings, what
>
> > are you going to use as the mandatory to implement transform?
>
>As Stephen says, I've suggested byte reversal. In fact, what I
>would most like to see as the mandatory to implement transform
>is X9.63 key derivation (the key derivation function referred
>to as KDF2 in IEEE P1363a), but to the best of my knowledge there's
>no stable, freely-available description of this that we could
>reference. If anyone fancied writing it up as an RFC that'd
>be very nice...
>
>(I have to say I'm uncomfortable with the hacky use of PKCS#5
>here. But at least PKCS#5 is referenceable).
>
>Cheers,
>
>William
>
>
>-----------------------------------------------------------------------------
>Baltimore Technologies plc will not be liable for direct,  special,  indirect
>or consequential  damages  arising  from  alteration of  the contents of this
>message by a third party or as a result of any virus being passed on.
>
>In addition, certain Marketing collateral may be added from time to time to
>promote Baltimore Technologies products, services, Global e-Security or
>appearance at trade shows and conferences.
>
>This footnote confirms that this email message has been swept by
>Baltimore MIMEsweeper for Content Security threats, including
>computer viruses.
>    http://www.baltimore.com



Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id IAA23525 for ietf-smime-bks; Tue, 20 Feb 2001 08:15:01 -0800 (PST)
Received: from mail.eris.dera.gov.uk (ns0.eris.dera.gov.uk [128.98.1.1]) by above.proper.com (8.9.3/8.9.3) with SMTP id IAA23514 for <[e-mail]>; Tue, 20 Feb 2001 08:14:59 -0800 (PST)
Received: (qmail 10871 invoked from network); 20 Feb 2001 16:14:55 -0000
Received: from cray.eris.dera.gov.uk (HELO mailhost.eris.dera.gov.uk) (128.98.2.7) by ens0.eris.dera.gov.uk with SMTP; 20 Feb 2001 16:14:55 -0000
Received: (qmail 1505 invoked from network); 20 Feb 2001 16:14:54 -0000
Received: from wottaway.eris.dera.gov.uk (HELO wottaway) (128.98.10.192) by mailhost.eris.dera.gov.uk with SMTP; 20 Feb 2001 16:14:54 -0000
From: "William Ottaway" <[e-mail]>
To: "Bonatti, Chris" <[e-mail]>, <[e-mail]>
Subject: RE: Certs-only Mechanism for X.400 Transport
Date: Tue, 20 Feb 2001 16:19:25 -0000
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
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>

Chris,

Rather than state "This format can also be used to convey CRLs " how about
specifying an OID for CRLs and describing how a CRL is transported, this
could be in a separate section or you could describe CRL and certificate
transport in the same section, as the only difference will be the OID.

Bill.


> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Bonatti, Chris
> Sent: 20 February 2001 15:22
> To: [e-mail]
> Subject: Certs-only Mechanism for X.400 Transport
>
>
>     Some discussion after the December meeting, suggested that we
> revise the specification for transporting S/MIME objects in X.400
> (draft-ietf-smime-x400trans) to enable certs-only messages to be
> readily identified.  This responds to the assumption that the
> PKCS #10 certificate request may be adapted to and used in the
> X.400 environment.  I admittedly didn't go down this road in my
> thinking, but it seems plausible enough.
>
>     After elaborating all the options (and doing some significant
> consultation with X.400 wonks) I recommend that we use the
> Encoded Information Types (EITs) facility of X.400 to distinguish
> the certs-only messages.  This mechanism is non-invasive to the
> security function, well-suited to the job at hand, and well
> supported in the X.400 community.  The main impact to x400trans
> spec is that we define a new OID value to represent the new
> "certs-only" EIT.  To that end, I propose that the following new
> section (see below) be inserted in the spec.
>
>     Discussion on this point is, of course, welcome.
>
> Chris
>
>
> ____________________
>
> 2.5 Certificates-only Message
>
> The certificates-only message is used to transport certificates,
> such as in response to a registration request.  This format can
> also be used to convey CRLs.  The certificates-only message
> consists of a single instance of CMS content of type
> Signed-data.  The encapContentInfo eContent field MUST be absent
> and signerInfos field MUST be empty.
>
> The resulting certificates-only CMS content is conveyed in
> accordance with section 2.2.  The following OID value is defined
> to identify certificates-only messages in the X.400 transport
> environment.
>
>     id-eit-certsOnly  OBJECT IDENTIFIER ::=
>         { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
>         pkcs-9(9) smime(16) eits(***) certsOnly(1) }
>
> Sending agents SHOULD include this OID in the
> original-encoded-information-types (EITs) field of the X.400
> message envelope.  Receiving agents SHOULD recognize the this OID
> value in the EITs field, and process the certificates-only
> appropriately according to local procedures.
>
>
>



Received: by above.proper.com (8.9.3/8.9.3) id HAA17418 for ietf-smime-bks; Tue, 20 Feb 2001 07:22:04 -0800 (PST)
Received: from smtp-a.capu.net (IDENT:[e-mail] [205.177.76.122]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA17414 for <[e-mail]>; Tue, 20 Feb 2001 07:22:01 -0800 (PST)
Received: from ieca.com (dial-216-28.capu.net [64.50.216.28]) by smtp-a.capu.net (8.9.3/8.9.3) with ESMTP id KAA04428 for <[e-mail]>; Tue, 20 Feb 2001 10:22:01 -0500
Message-ID: <[e-mail]>
Date: Tue, 20 Feb 2001 10:21:55 -0500
From: "Bonatti, Chris" <[e-mail]>
Organization: IECA, Inc.
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Certs-only Mechanism for X.400 Transport
Content-Type: text/plain; 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>

    Some discussion after the December meeting, suggested that we
revise the specification for transporting S/MIME objects in X.400
(draft-ietf-smime-x400trans) to enable certs-only messages to be
readily identified.  This responds to the assumption that the
PKCS #10 certificate request may be adapted to and used in the
X.400 environment.  I admittedly didn't go down this road in my
thinking, but it seems plausible enough.

    After elaborating all the options (and doing some significant
consultation with X.400 wonks) I recommend that we use the
Encoded Information Types (EITs) facility of X.400 to distinguish
the certs-only messages.  This mechanism is non-invasive to the
security function, well-suited to the job at hand, and well
supported in the X.400 community.  The main impact to x400trans
spec is that we define a new OID value to represent the new
"certs-only" EIT.  To that end, I propose that the following new
section (see below) be inserted in the spec.

    Discussion on this point is, of course, welcome.

Chris


____________________

2.5 Certificates-only Message

The certificates-only message is used to transport certificates,
such as in response to a registration request.  This format can
also be used to convey CRLs.  The certificates-only message
consists of a single instance of CMS content of type
Signed-data.  The encapContentInfo eContent field MUST be absent
and signerInfos field MUST be empty.

The resulting certificates-only CMS content is conveyed in
accordance with section 2.2.  The following OID value is defined
to identify certificates-only messages in the X.400 transport
environment.

    id-eit-certsOnly  OBJECT IDENTIFIER ::=
        { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
        pkcs-9(9) smime(16) eits(***) certsOnly(1) }

Sending agents SHOULD include this OID in the
original-encoded-information-types (EITs) field of the X.400
message envelope.  Receiving agents SHOULD recognize the this OID
value in the EITs field, and process the certificates-only
appropriately according to local procedures.





Received: by above.proper.com (8.9.3/8.9.3) id CAA24747 for ietf-smime-bks; Mon, 19 Feb 2001 02:11:52 -0800 (PST)
Received: from balinese.baltimore.ie ([e-mail] [194.125.215.8]) by above.proper.com (8.9.3/8.9.3) with ESMTP id CAA24742 for <[e-mail]>; Mon, 19 Feb 2001 02:11:49 -0800 (PST)
Received: by balinese.baltimore.ie; id KAA15539; Mon, 19 Feb 2001 10:11:48 GMT
Received: from emeairlsw1.ie.baltimore.com(10.153.25.53) by balinese.baltimore.ie via smap (V4.2) id xma015004; Mon, 19 Feb 01 10:10:58 GMT
Received: from bobcat.baltimore.ie (unverified) by emeairlsw1.baltimore.com (Content Technologies SMTPRS 4.2.1) with ESMTP id <[e-mail]>; Mon, 19 Feb 2001 10:10:31 +0000
Received: from baltimore.ie (ip187-24.ie.baltimore.com [10.153.24.187]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id KAA25015; Mon, 19 Feb 2001 10:10:57 GMT
Message-ID: <[e-mail]>
Date: Mon, 19 Feb 2001 10:11:02 +0000
From: Stephen Farrell <[e-mail]>
Reply-To: [e-mail]
Organization: Baltimore Technologies Ltd.
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Russ Housley <[e-mail]>
CC: [e-mail]
Subject: Re: WG Last Call:draft-ietf-smime-rcek-01.txt
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; 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>

Hi Russ,

> >William suggests byte reversal instead, which seems ok from both perspectives.
> 
> Okay.  So, since bitwise-NOT and bit-reversal both have shortcomings, what
> are you going to use as the mandatory to implement transform?

Byte reversal, i.e. MSG2.KEK=byte-reverse(MSG1.CEK). If MSG1.CEK has N
bytes, then treated as 'C' arrays, MSG2.KEK[i] = MSG1.CEK[N-i].

> > > 2.  The document defines three related attributes.  It does not tell the
> > > implementor how to deal with the situation where some (but not all) of the
> > > attributes are implemented.
[...]
> >All in all, I disagreee that the implementer is left in limbo, but can add
> >text like the above if that helps.
> 
> I would like to see the text.

How about a new section 5:

"5. Conformance.

This specification only applies to messages where the CEKReference
attribute is present. All attributes specified here SHOULD be ignored unless 
they are present in a message containing a valid, new or recognised, existing 
value of CEKReference. The CEKMaxDecrypts attribute is to be treated by the 
recipient as a hint, but MUST be honored by the originator. 

The optional to implement KEKDerivationAlgorithm attribute MUST only be present 
when MSG1.content-encryption-algorithm differs from MSG2.key-encryption-algorithm, 
in which case it MUST be present. Implementations which recognize this
attribute, but do not support the functionality SHOULD ignore the attribute.

Ignoring attributes as discussed above, will lead to decryption failures.
CMS implementations SHOULD be able to signal the particular reason for this
failure to the calling application."

> I agree that this is a matter of taste.  I guess that I would like to hear
> from implementors to resolve this one.

Agreed. I think its fair to assume that silence here is concensus not to
change the text? 

Cheers,
Stephen.

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) [phone]
39 Parkgate Street,                     fax: [phone]
Dublin 8.                mailto:[e-mail]
Ireland                             http://www.baltimore.com


Received: by above.proper.com (8.9.3/8.9.3) id BAA24134 for ietf-smime-bks; Mon, 19 Feb 2001 01:52:52 -0800 (PST)
Received: from balinese.baltimore.ie ([e-mail] [194.125.215.8]) by above.proper.com (8.9.3/8.9.3) with ESMTP id BAA24129 for <[e-mail]>; Mon, 19 Feb 2001 01:52:51 -0800 (PST)
Received: by balinese.baltimore.ie; id JAA05261; Mon, 19 Feb 2001 09:52:49 GMT
Received: from emeairlsw1.ie.baltimore.com(10.153.25.53) by balinese.baltimore.ie via smap (V4.2) id xma004911; Mon, 19 Feb 01 09:52:12 GMT
Received: from bobcat.baltimore.ie (unverified) by emeairlsw1.baltimore.com (Content Technologies SMTPRS 4.2.1) with ESMTP id <[e-mail]>; Mon, 19 Feb 2001 09:51:44 +0000
Received: from irlbdc.ie.baltimore.com (irlbdc.ie.baltimore.com [10.153.25.3]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id JAA24223; Mon, 19 Feb 2001 09:52:10 GMT
Received: by irlbdc.ie.baltimore.com with Internet Mail Service (5.5.2650.21) id <1ZWFNBY9>; Mon, 19 Feb 2001 09:59:53 -0000
Message-ID: <[e-mail]>
From: William Whyte <[e-mail]>
To: Russ Housley <[e-mail]>, [e-mail]
Cc: [e-mail]
Subject: RE: WG Last Call:draft-ietf-smime-rcek-01.txt
Date: Mon, 19 Feb 2001 09:58:08 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
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>

> >William suggests byte reversal instead, which seems ok from both
perspectives.
> 
> Okay.  So, since bitwise-NOT and bit-reversal both have shortcomings, what

> are you going to use as the mandatory to implement transform?

As Stephen says, I've suggested byte reversal. In fact, what I
would most like to see as the mandatory to implement transform
is X9.63 key derivation (the key derivation function referred
to as KDF2 in IEEE P1363a), but to the best of my knowledge there's
no stable, freely-available description of this that we could
reference. If anyone fancied writing it up as an RFC that'd
be very nice...

(I have to say I'm uncomfortable with the hacky use of PKCS#5
here. But at least PKCS#5 is referenceable).

Cheers,

William


-----------------------------------------------------------------------------
Baltimore Technologies plc will not be liable for direct,  special,  indirect 
or consequential  damages  arising  from  alteration of  the contents of this
message by a third party or as a result of any virus being passed on.

In addition, certain Marketing collateral may be added from time to time to
promote Baltimore Technologies products, services, Global e-Security or
appearance at trade shows and conferences.

This footnote confirms that this email message has been swept by
Baltimore MIMEsweeper for Content Security threats, including
computer viruses.
   http://www.baltimore.com


Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id QAA29191 for ietf-smime-bks; Sun, 18 Feb 2001 16:49:25 -0800 (PST)
Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by above.proper.com (8.9.3/8.9.3) with ESMTP id QAA29183 for <[e-mail]>; Sun, 18 Feb 2001 16:49:24 -0800 (PST)
Received: from RHOUSLEY-PC.spyrus.com (dial03.spyrus.com [207.212.34.123]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id QAA11052; Sun, 18 Feb 2001 16:48:34 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.2
Date: Thu, 15 Feb 2001 15:13:32 -0500
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: Re: WG Last Call:draft-ietf-smime-rcek-01.txt
Cc: [e-mail]
In-Reply-To: <[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>

Steve:

> > 1.  The default transformation from a CEK to a KEK is reversing the order
> > of the bits.  For a DES or 3DES key, this will cause parity bits to become
> > keying material.  I would prefer a default transformation that did not mix
> > parity and keying material since 3DES in the S/MIME mandatory to implement
> > cipher.  I propose a bitwise NOT.
>
>Good catch. However, you're caught yourself too!
>
>The original reason to include bit reversal was: (raised by James Manger)
>
>"One attack against this proposal springs to mind.  An attacker knowing some
>of the plaintext (a prefix in a field for instance) can use the
>corresponding ciphertext block as the next encrypted CEK, i.e. as
>KEKRecipientInfo.encryptedKey.  Now the attacker know the next CEK.  [note.
>this attacks may be unfair - by attacking something the proposal was not
>claiming to protect - but I am unsure what others believe the proposal does
>protect]"
>
>And I'm afraid that with bitwise-NOT and the DES complementarity property
>(thanks to William Whyte for spotting this), the original bad feature raises
>its head again (isn't key management fun:-).
>
>William suggests byte reversal instead, which seems ok from both perspectives.

Okay.  So, since bitwise-NOT and bit-reversal both have shortcomings, what 
are you going to use as the mandatory to implement transform?

> > 2.  The document defines three related attributes.  It does not tell the
> > implementor how to deal with the situation where some (but not all) of the
> > attributes are implemented.
>
>Disagree. You MUST support CEKReference and CEKMaxDecrypts, and MAY support
>KEKDerivationAlgorithm. (If that's not clear I will make it more so.)
>
>CEKReference clearly has to be present or everything else is to be ignored.
>
>CEKMaxDecrypts is only really a hint in any case, so if its not present the
>recipient just keeps the CEKReference for a locally configured period (in
>reality this'd be specified in some specification for the use case of this
>trick).
>
>KEKDerivationAlgorithm clearly has to be present if algorithms will change
>for MSG2, otherwise not.
>
>All in all, I disagreee that the implementer is left in limbo, but can add
>text like the above if that helps.

I would like to see the text.

> > I suggest that a single attribute that
> > includes some OPTIONAL fields might be preferable.
>
>I think this is a matter of taste - you prefer a single "structured" 
>attribute,
>my preference is for a set of "flat" attributes (I think its easier to 
>code for
>most ASN.1 handlers). 'Course, I'll switch if that's the concensus (i.e. if a
>few other folks chip in on the subject).

I agree that this is a matter of taste.  I guess that I would like to hear 
from implementors to resolve this one.

> > Perhaps:
> >
> >     CEKReference ::= SEQUENCE {
> >        ref                              OCTET STRING,
> >        maxDecrypts              INTEGER OPTIONAL,
> >        kekDerivationAlg         OBJECT IDENTIFIER DEFAULT 
> id-alg-bitwise-not,
> >        kekDerivationParam       ANY DEFINED BY kekDerivationAlg OPTIONAL  }
>
> > In addition to making it straightforward to discuss the interactions
> > between the fields, this approach allows other KEK Derivation algorithms to
> > be specified in the future without any modification to the
> > specification.  If the bit order reversal algorithm is needed, a simple OID
> > assignment and statement that parameters are not needed completes the
> > task.  The PKCS#5 KEK derivation is an OID assignment where parameters are
> > required.
>
>That last point is fair enough. OTOH, the current syntax also has the
>required extensibility via the attribute OID for KEKDerivationAlgorithm
>(which maybe should therefore be called PKCS5KEKDerivationAlgorithm?).

In general, I prefer to distribute keys with an algorithm identifier that 
tells the recipient how to use the key.  In this case, the CEK and the CEK 
algorithm are handled by CMS.  By default, the CEK and KEK will employ the 
same algorithm.  If not, then the transformation and the KEK algorithm 
should be part of the management information.

Russ



Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id NAA25181 for ietf-smime-bks; Fri, 16 Feb 2001 13:20:41 -0800 (PST)
Received: from wfhqex05.gfgsi.com (netva01.wangfed.com [206.137.100.2]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA25173; Fri, 16 Feb 2001 13:20:40 -0800 (PST)
Received: by wfhqex05.gfgsi.com with Internet Mail Service (5.5.2650.21) id <Z2A4YA6A>; Fri, 16 Feb 2001 16:23:58 -0500
Message-ID: <[e-mail]>
From: "Pawling, John" <[e-mail]>
To: "Pawling, John" <[e-mail]>
Subject: v1.9 S/MIME Freeware Library Now Available
Date: Fri, 16 Feb 2001 16:23:46 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
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>

All,

Getronics Government Solutions has delivered Version 1.9 of the 
S/MIME Freeware Library (SFL) source code.  The SFL source code files 
are freely available to everyone from the Getronics Government 
Solutions web site at <http://www.getronicsgov.com/hot/sfl_home.htm>.    

The SFL implements the IETF S/MIME v3 RFC 2630 Cryptographic Message 
Syntax (CMS) and RFC 2634 Enhanced Security Services (ESS) specifications. 
It also implements portions of the RFC 2633 Message Specification and 
RFC 2632 Certificate Handling document.  When used in conjunction with
the Crypto++ v4.1 freeware library, the SFL implements the RFC 2631 
Diffie-Hellman (D-H) Key Agreement Method specification.  It has been 
successfully tested using the MS Windows NT/95/98/2000, Linux and Solaris 
2.7 operating systems.  Further enhancements, ports and testing of the SFL
are 
still in process.  Further releases of the SFL will be provided as
significant 
capabilities are added. 

The SFL has been successfully used to sign, verify, encrypt and decrypt 
CMS/ESS objects using: S/MIME v3 mandatory-to-implement algorithms (DSA, E-S
D-
H, 3DES) provided by the Crypto++ v4.1 library; RSA suite of algorithms
provided 
by the RSA BSAFE v4.2 and Crypto++ v4.1 libraries; and Fortezza suite of 
algorithms provided by the Fortezza Crypto Card.  The v1.9 SFL uses the v1.3
R5 
Enhanced SNACC ASN.1 Library to encode/decode objects. The v1.9 SFL release 
includes: SFL High-level library; Free (a.k.a. Crypto++) Crypto Token
Interface 
Library (CTIL); BSAFE CTIL; Fortezza CTIL; SPEX/ CTIL; PKCS #11 CTIL; v1.3
R5
Enhanced SNACC ASN.1 Compiler and Library; test utilities; test drivers; and

test data.  All CTILs were tested as Dynamically Linked Libraries (DLL)
using
MS Windows.  The Fortezza, BSAFE and Crypto++ CTILs were tested with the 
respective security libraries as shared objects using Linux and Solaris 2.7.


The SFL has been successfully used to exchange signedData and envelopedData 
messages with the Microsoft (MS) Internet Explorer Outlook Express v4.01, 
Netscape Communicator 4.X and Entrust S/MIME v2 products.  Signed messages 
have been exchanged with the RSA S/MAIL and WorldTalk S/MIME v2 products. 

The SFL has also been used to perform S/MIME v3 interoperability testing
with 
Microsoft that exercised the majority of the features specified by RFCs 
2630, 2631 and 2634.  This testing included the RSA, mandatory S/MIME V3 and

Fortezza suites of algorithms.  We used the SFL to successfully process all
of 
the SFL-supported sample data included in the S/MIME WG "Examples of S/MIME 
Messages" document.  We also used the SFL to generate S/MIME v3 sample 
messages that were included in the "Examples" document.
We have also performed limited S/MIME v3 testing with Baltimore.  

The following enhancements are included in the v1.9 SFL and CTIL releases
(compared with the v1.8 releases):

1) Tested using common v1.3 R5 Enhanced SNACC ASN.1 Library, v1.9 CTILs 
and LIBCERT libraries shared with the v1.5 Access Control Library (ACL) 
and v1.9 Certificate Management Library (CML).

2) Added freeware implementation of the Advanced Encryption Standard (AES)
algorithm (in addition to SHA-1) to the Common Class inherited by all CTILs.


3) Enhanced PKCS #11 CTIL so that it can be used with any PKCS #11-compliant

DLL/shared library. 

4) Successfully tested PKCS #11 CTIL with Litronic Maestro v1.0 library
(using 
Fortezza Card).  Successfully performed interop testing between Fortezza
CTIL 
and PKCS #11 CTIL.

5) Successfully tested PKCS #11 CTIL with the GemPlus PKCS #11 library (DLL)

using a GemPlus Smart Card (to provide RSA); and Free3 CTIL with the
Crypto++ 
library (to provide 3DES). Successfully performed interop testing between
this 
configuration and Free3 CTIL.   

6) We developed and tested a hybrid CTIL that inherits the PKCS #11 and
Free3 
CTILs.  This allows the application to access both CTILs using a single
login.  
We tested the hybrid CTIL to use: PKCS #11 CTIL with the GemPlus DLL using a

GemPlus Smart Card (to provide RSA); and Free3 CTIL with the Crypto++
library 
(to provide 3DES).  Note that we did not modify the PKCS #11 and Free3 CTILs
to 
support this work.  

7) Successfully tested PKCS #11 CTIL with the DataKey PKCS #11 library (DLL)

using a DataKey Smart Card (to provide RSA); and Free3 CTIL with the
Crypto++ 
library (to provide 3DES).   Successfully performed interop testing between
this 
configuration and Free3 CTIL.  

8) Successfully tested SFL with SPEX/ CTIL, Spyrus SPEX/ 2 Library, and
Lynks 
Cards, including using RSA and Triple-DES. 

9) Enhanced common CTIL functionality to accept no parameters and to provide

hash, content, encrypt/decrypt, signature verification services.

10) Tested Free3 CTIL with Crypto++ v4.1.

11) Enhanced SFL test utilities to create/process MIME headings using
Mozilla 
MIME library. 

12) Enhanced ReportTool to completely process PKCS #12 file and provide
decrypted 
contents. 

13) Developed code to generate RSA key material using the Crypto++ library. 

14) Enhanced CertificateBuilder to create PKCS #12 files including DSA
private 
keys and related data. 

15) Converted all source code to use CVS configuration management system.

16) Corrected bugs in SFL: incorrect E-S D-H object identifier (OID); 
ESSSecurityLabel build/process code; Party A information field used 
with D-H; envelopedData keyTransportRecipientInfo version; and NULL
parameter 
incorrectly omitted when RSA OID is present. 

17) Corrected bugs in Fortezza and SPEX/ CTILs (3DES initialization vector
ASN.1 
encoded improperly).  

18) Resolved compiler warnings in SFL and CTILs.

19) Performed regression testing to ensure that aforementioned enhancements
did 
not break existing SFL functionality.

20) Successfully linked (using Windows) the v1.9 SFL, v1.3 R5 SNACC and v1.9

CML.

We also delivered the v1.9 SFL Application Programming Interface (API) 
and v1.9 SDD API documents.  We also delivered the v1.0 SMP Components Setup

Manual that describes the component installation procedures for the v1.9
SFL, 
v1.9 CML, and v1.3 R5 Enhanced SNACC libraries.

We are still in the process of enhancing and testing the SFL.  Future 
releases will include: additional PKCS #11 CTIL testing; finish 
CertificateBuilder command line utility; enhancing 
CertificateBuilder to support creation of Attribute Certificates; 
add "Certificate Management Messages over CMS" ASN.1 encode/decode 
functions; add enhanced test routines; bug fixes; support for other 
crypto APIs (possible); and support for other operating systems. 

The SFL is developed to maximize portability to 32-bit operating 
systems.  In addition to testing on MS Windows, Linux and Solaris 2.7, 
we plan to port the SFL to the following operating systems: HP/UX 11, IBM
AIX 
3.2 (possibly), SCO 5.0 (possibly) and Macintosh (possibly).

The following SFL files are available from <http://www.GetronicsGov.com/>:

1) SFL Documents: Fact Sheet, Software Design Description, API, CTIL 
API, Software Test Description, Implementers Guide, Overview Briefing and 
Public License.     

2) smimeR1.9.tar.gz:  Source code, MS Windows NT/95/98/2000 project files
and 
Unix makefiles for SFL Hi-Level library.

3) snacc13r5rn.tar.gz (source code and binaries available from Getronics 
Enhanced SNACC web page: <http://www.getronicsgov.com/hot/snacc_home.htm>): 
Source code, MS Windows NT/95/98/2000 project files and Unix makefiles for
v1.3 R5 Enhanced SNACC ASN.1 Compiler and Library.  Source code is
compilable for Linux, Solaris 2.7 and MS Windows NT/95/98/2000 that has 
been enhanced by GGS to implement the Distinguished Encoding Rules.  This
file includes a sample test project demonstrating the use of the SNACC
classes.  

4) smCTIR1.9.tar.gz:  Source code, MS Windows NT/95/98/2000 project files
and 
Unix makefiles for the following CTILs: Test (no crypto), Crypto++, BSAFE, 
Fortezza, SPEX/ and PKCS #11. 

5) smLibCR1.9.tar.gz: Source code, MS Windows NT/95/98/2000 project files
and 
Unix makefiles for the LIBCERT library that provides ASN.1 and certificate 
processing services used by the SFL, ACL and CML.

6) smTest1.9.tar.gz: Source code, MS Windows NT/95/98/2000 project files and

Unix makefiles for test drivers used to test the SFL.  This file also
includes 
sample CMS/ESS test data and test X.509 Certificates.  This file also
includes 
test utilities to create X.509 Certificates that each include 
a D-H, DSA or RSA public key.  

7) csmime.mdl contains SFL Class diagrams created using Microsoft 
Visual Modeler (comes with MS Visual Studio 6.0, Enterprise Tools).
The file can also be viewed using Rational Rose C++ Demo 4.0
45 day evaluation copy which can be obtained from
<http://www.rational.com/uml/resources/practice_uml/index.jtmpl>.
Not all classes are documented in the MDL file at this time.

All source code for the SFL is being provided at no cost and with no 
financial limitations regarding its use and distribution. 
Organizations can use the SFL without paying any royalties or 
licensing fees.  Getronics is developing the SFL under contract to the U.S. 
Government.  The U.S. Government is furnishing the SFL source code at 
no cost to the vendor subject to the conditions of the "SFL Public 
License".

On 14 January 2000, the U.S. Department of Commerce, Bureau of 
Export Administration published a new regulation implementing an update 
to the U.S. Government's encryption export policy 
<http://www.bxa.doc.gov/Encryption/Default.htm>.  In accordance with 
the revisions to the Export Administration Regulations (EAR) of 14 Jan 
2000, the downloading of the SFL source code is not password controlled.

The SFL is composed of a high-level library that performs generic CMS 
and ESS processing independent of the crypto algorithms used to 
protect a specific object.  The SFL high-level library makes calls to 
an algorithm-independent CTIL API.  The underlying, external crypto
token libraries are not distributed as part of the SFL 
source code. The application developer must independently obtain these 
libraries and then link them with the SFL.  For example, the SFL can be 
used with the freeware Crypto++ library to obtain 3DES, D-H, RSA and 
DSA. To use the SFL with Crypto++ the vendor must download the Crypto++ 
freeware library from the Crypto++ Web Page 
<http://www.eskimo.com/~weidai/cryptlib.html>
and then compile it with the GGS-developed Crypto++ CTIL source code.  
 
The National Institute of Standards and Technology (NIST) is providing 
test S/MIME messages (created by Getronics) at 
<http://csrc.nist.gov/pki/testing/x509paths.html>.  
Getronics used the SFL to successfully process the NIST test data.

The Internet Mail Consortium (IMC) has established an SFL web page
<http://www.imc.org/imc-sfl>.  The IMC has also established an SFL
mail list which is used to: distribute information regarding SFL
releases; discuss SFL-related issues; and provide a means for SFL
users to provide feedback, comments, bug reports, etc.  Subscription
information for the imc-sfl mailing list is at the IMC web site
listed above.

All comments regarding the SFL source code and documents are welcome.  
This SFL release announcement was sent to several mail lists, but 
please send all messages regarding the SFL to the imc-sfl mail list 
ONLY.  Please do not send messages regarding the SFL to any of the IETF 
mail lists.  We will respond to all messages sent to the imc-sfl mail 
list.

============================================
John Pawling, [e-mail]
Getronics Government Solutions, LLC
============================================ 



Received: by above.proper.com (8.9.3/8.9.3) id KAA05746 for ietf-smime-bks; Wed, 14 Feb 2001 10:12:45 -0800 (PST)
Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA05741 for <[e-mail]>; Wed, 14 Feb 2001 10:12:44 -0800 (PST)
Received: from RHOUSLEY-PC.spyrus.com ([209.172.119.211]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id JAA29915; Wed, 14 Feb 2001 09:49:39 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.2
Date: Wed, 14 Feb 2001 12:50:30 -0500
To: [e-mail], [e-mail]
From: Russ Housley <[e-mail]>
Subject: I-D ACTION:draft-ietf-smime-domsec-08.txt
Cc: [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>

Jeff & Marcus:

The S/MIME WG is done with the DOMSEC document.  The document is ready for 
IETF Last Call.  We expect the document to become an Experimental RFC.

	Title		: Domain Security Services using S/MIME
	Author(s)	: T. Dean, W. Ottaway
	Filename	: draft-ietf-smime-domsec-08.txt
	Pages		: 8
	Date		: 01-Feb-01

Russ



Received: by above.proper.com (8.9.3/8.9.3) id CAA28978 for ietf-smime-bks; Wed, 14 Feb 2001 02:32:14 -0800 (PST)
Received: from balinese.baltimore.ie ([e-mail] [194.125.215.8]) by above.proper.com (8.9.3/8.9.3) with ESMTP id CAA28969 for <[e-mail]>; Wed, 14 Feb 2001 02:32:12 -0800 (PST)
Received: by balinese.baltimore.ie; id KAA20481; Wed, 14 Feb 2001 10:32:05 GMT
Received: from emeairlsw1.ie.baltimore.com(10.153.25.53) by balinese.baltimore.ie via smap (V4.2) id xma020086; Wed, 14 Feb 01 10:31:06 GMT
Received: from bobcat.baltimore.ie (unverified) by emeairlsw1.baltimore.com (Content Technologies SMTPRS 4.2.1) with ESMTP id <[e-mail]>; Wed, 14 Feb 2001 10:30:42 +0000
Received: from baltimore.ie (ip187-24.ie.baltimore.com [10.153.24.187]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id KAA21255; Wed, 14 Feb 2001 10:31:03 GMT
Message-ID: <[e-mail]>
Date: Wed, 14 Feb 2001 10:31:03 +0000
From: Stephen Farrell <[e-mail]>
Reply-To: [e-mail]
Organization: Baltimore Technologies Ltd.
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Mike Just <[e-mail]>
CC: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-smime-rcek-01.txt
References: <C69F91F7FDEEC74F8BF6BF9861B2F61303441A@sottmxs07>
Content-Type: text/plain; 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>

Thanks Mike,

Will add words to that effect.

Stephen.

> Mike Just wrote:
> 
> Hi Stephen, Sean,
> 
> Possibly another item worth including in the Security Considerations section. Suppose MSG1 is sent
> to a set S1 of users. In the case where MSG2 is sent to only a subset of users in S1, all users
> from S1 will still be able to decrypt MSG2 (since MSG2.KEK is computed only from MSG1.CEK).  I
> don't think you intended for your solution to be used for such dynamic recipient sets, but it
> might be worth explicitly mentioning this unfortunate side-effect of key re-use in any case.
> (Might be enough to mention that the recipient lists must be the same for each message.)
> 
> Mike J.
> 
-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) [phone]
39 Parkgate Street,                     fax: [phone]
Dublin 8.                mailto:[e-mail]
Ireland                             http://www.baltimore.com


Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id OAA08925 for ietf-smime-bks; Tue, 13 Feb 2001 14:45:51 -0800 (PST)
Received: from sottmxs02.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA08919 for <[e-mail]>; Tue, 13 Feb 2001 14:45:50 -0800 (PST)
Received: by sottmxs02.entrust.com with Internet Mail Service (5.5.2650.21) id <1RVQGWYX>; Tue, 13 Feb 2001 17:45:22 -0500
Message-ID: <C69F91F7FDEEC74F8BF6BF9861B2F61303441A@sottmxs07>
From: Mike Just <[e-mail]>
To: [e-mail]
Cc: "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: I-D ACTION:draft-ietf-smime-rcek-01.txt
Date: Tue, 13 Feb 2001 17:45:19 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0960E.A462A290"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0960E.A462A290
Content-Type: text/plain;
	charset="iso-8859-1"

Hi Stephen, Sean,

Possibly another item worth including in the Security Considerations
section. Suppose MSG1 is sent to a set S1 of users. In the case where MSG2
is sent to only a subset of users in S1, all users from S1 will still be
able to decrypt MSG2 (since MSG2.KEK is computed only from MSG1.CEK).  I
don't think you intended for your solution to be used for such dynamic
recipient sets, but it might be worth explicitly mentioning this unfortunate
side-effect of key re-use in any case. (Might be enough to mention that the
recipient lists must be the same for each message.)

Mike J.  

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> Sent: Friday, February 09, 2001 7:27 AM
> Cc: [e-mail]
> Subject: I-D ACTION:draft-ietf-smime-rcek-01.txt
> 
> 
> 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		: Reuse of CMS Content Encryption Keys
> 	Author(s)	: S. Farrell, S. Turner
> 	Filename	: draft-ietf-smime-rcek-01.txt
> 	Pages		: 7
> 	Date		: 08-Feb-01
> 	
> This note describes a way to include a key identifier in a CMS
> enveloped data structure, so that the content encryption key can be
> re-used for further enveloped data packets.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-smime-rcek-01.txt
> 
> 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-rcek-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-ietf-smime-rcek-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_001_01C0960E.A462A290
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>RE: I-D ACTION:draft-ietf-smime-rcek-01.txt</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Hi Stephen, Sean,</FONT>
</P>

<P><FONT SIZE=3D2>Possibly another item worth including in the Security =
Considerations section. Suppose MSG1 is sent to a set S1 of users. In =
the case where MSG2 is sent to only a subset of users in S1, all users =
from S1 will still be able to decrypt MSG2 (since MSG2.KEK is computed =
only from MSG1.CEK).&nbsp; I don't think you intended for your solution =
to be used for such dynamic recipient sets, but it might be worth =
explicitly mentioning this unfortunate side-effect of key re-use in any =
case. (Might be enough to mention that the recipient lists must be the =
same for each message.)</FONT></P>

<P><FONT SIZE=3D2>Mike J.&nbsp; </FONT>
</P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: [e-mail] [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]=
</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Friday, February 09, 2001 7:27 AM</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: [e-mail]</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: I-D =
ACTION:draft-ietf-smime-rcek-01.txt</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; A New Internet-Draft is available from the =
on-line </FONT>
<BR><FONT SIZE=3D2>&gt; Internet-Drafts directories.</FONT>
<BR><FONT SIZE=3D2>&gt; This draft is a work item of the S/MIME Mail =
Security Working </FONT>
<BR><FONT SIZE=3D2>&gt; Group of the IETF.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Title&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : Reuse of =
CMS Content Encryption Keys</FONT>
<BR><FONT SIZE=3D2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Author(s)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : S. Farrell, S. =
Turner</FONT>
<BR><FONT SIZE=3D2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Filename&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : =
draft-ietf-smime-rcek-01.txt</FONT>
<BR><FONT SIZE=3D2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Pages&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : 7</FONT>
<BR><FONT SIZE=3D2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Date&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : =
08-Feb-01</FONT>
<BR><FONT SIZE=3D2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; This note describes a way to include a key =
identifier in a CMS</FONT>
<BR><FONT SIZE=3D2>&gt; enveloped data structure, so that the content =
encryption key can be</FONT>
<BR><FONT SIZE=3D2>&gt; re-used for further enveloped data =
packets.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; A URL for this Internet-Draft is:</FONT>
<BR><FONT SIZE=3D2>&gt; <A =
HREF=3D"http://www.ietf.org/internet-drafts/draft-ietf-smime-rcek-01.txt=
" =
TARGET=3D"_blank">http://www.ietf.org/internet-drafts/draft-ietf-smime-r=
cek-01.txt</A></FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Internet-Drafts are also available by anonymous =
FTP. Login </FONT>
<BR><FONT SIZE=3D2>&gt; with the username</FONT>
<BR><FONT SIZE=3D2>&gt; &quot;anonymous&quot; and a password of your =
e-mail address. After logging in,</FONT>
<BR><FONT SIZE=3D2>&gt; type &quot;cd internet-drafts&quot; and =
then</FONT>
<BR><FONT SIZE=3D2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &quot;get =
draft-ietf-smime-rcek-01.txt&quot;.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; A list of Internet-Drafts directories can be =
found in</FONT>
<BR><FONT SIZE=3D2>&gt; <A HREF=3D"http://www.ietf.org/shadow.html" =
TARGET=3D"_blank">http://www.ietf.org/shadow.html</A> </FONT>
<BR><FONT SIZE=3D2>&gt; or <A =
HREF=3D"ftp://ftp.ietf.org/ietf/1shadow-sites.txt" =
TARGET=3D"_blank">ftp://ftp.ietf.org/ietf/1shadow-sites.txt</A></FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Internet-Drafts can also be obtained by =
e-mail.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Send a message to:</FONT>
<BR><FONT SIZE=3D2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
[e-mail].</FONT>
<BR><FONT SIZE=3D2>&gt; In the body type:</FONT>
<BR><FONT SIZE=3D2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &quot;FILE =
/internet-drafts/draft-ietf-smime-rcek-01.txt&quot;.</FONT>
<BR><FONT SIZE=3D2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; NOTE: The mail server at ietf.org can return =
the document in</FONT>
<BR><FONT SIZE=3D2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; MIME-encoded =
form by using the &quot;mpack&quot; utility.&nbsp; To use this</FONT>
<BR><FONT SIZE=3D2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; feature, insert =
the command &quot;ENCODING mime&quot; before the =
&quot;FILE&quot;</FONT>
<BR><FONT SIZE=3D2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; command.&nbsp; =
To decode the response(s), you will need &quot;munpack&quot; or</FONT>
<BR><FONT SIZE=3D2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; a MIME-compliant =
mail reader.&nbsp; Different MIME-compliant </FONT>
<BR><FONT SIZE=3D2>&gt; mail readers</FONT>
<BR><FONT SIZE=3D2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; exhibit =
different behavior, especially when dealing with</FONT>
<BR><FONT SIZE=3D2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&quot;multipart&quot; MIME messages (i.e. documents which have been =
split</FONT>
<BR><FONT SIZE=3D2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; up into multiple =
messages), so check your local documentation on</FONT>
<BR><FONT SIZE=3D2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; how to =
manipulate these messages.</FONT>
<BR><FONT SIZE=3D2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; Below is the data which will enable a MIME =
compliant mail reader</FONT>
<BR><FONT SIZE=3D2>&gt; implementation to automatically retrieve the =
ASCII version of the</FONT>
<BR><FONT SIZE=3D2>&gt; Internet-Draft.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0960E.A462A290--


Received: by above.proper.com (8.9.3/8.9.3) id NAA03622 for ietf-smime-bks; Tue, 13 Feb 2001 13:28:19 -0800 (PST)
Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA03617 for <[e-mail]>; Tue, 13 Feb 2001 13:28:17 -0800 (PST)
Received: from RHOUSLEY-PC.spyrus.com ([209.172.119.211]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id NAA13633 for <[e-mail]>; Tue, 13 Feb 2001 13:27:47 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.2
Date: Tue, 13 Feb 2001 16:23:48 -0500
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: S/MIME WG meeting at 50th IETF
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 S/MIME WG meeting has been tentatively scheduled for one two-hour 
session.  The DRAFT agenda is available at : 
http://www.ietf.org/meetings/agenda_50.txt

Please send me S/MIME WG agenda topics.  I will post a DRAFT S/MIME WG 
session agenda in a few weeks.

As usual, overhead and data projectors will be provided in the meeting room.

Russ



Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id CAA18064 for ietf-smime-bks; Tue, 13 Feb 2001 02:57:56 -0800 (PST)
Received: from balinese.baltimore.ie ([e-mail] [194.125.215.8]) by above.proper.com (8.9.3/8.9.3) with ESMTP id CAA18058 for <[e-mail]>; Tue, 13 Feb 2001 02:57:54 -0800 (PST)
Received: by balinese.baltimore.ie; id KAA27670; Tue, 13 Feb 2001 10:57:53 GMT
Received: from emeairlsw1.ie.baltimore.com(10.153.25.53) by balinese.baltimore.ie via smap (V4.2) id xma027542; Tue, 13 Feb 01 10:57:22 GMT
Received: from bobcat.baltimore.ie (unverified) by emeairlsw1.baltimore.com (Content Technologies SMTPRS 4.2.1) with ESMTP id <[e-mail]>; Tue, 13 Feb 2001 10:57:00 +0000
Received: from baltimore.ie (ip187-24.ie.baltimore.com [10.153.24.187]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id KAA20257; Tue, 13 Feb 2001 10:57:21 GMT
Message-ID: <[e-mail]>
Date: Tue, 13 Feb 2001 10:57:32 +0000
From: Stephen Farrell <[e-mail]>
Reply-To: [e-mail]
Organization: Baltimore Technologies Ltd.
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Russ Housley <[e-mail]>
CC: [e-mail], xme <[e-mail]>
Subject: Re: WG Last Call:draft-ietf-smime-rcek-01.txt
References: <[e-mail]>
Content-Type: text/plain; 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>

Hi Russ,

> 1.  The default transformation from a CEK to a KEK is reversing the order
> of the bits.  For a DES or 3DES key, this will cause parity bits to become
> keying material.  I would prefer a default transformation that did not mix
> parity and keying material since 3DES in the S/MIME mandatory to implement
> cipher.  I propose a bitwise NOT.

Good catch. However, you're caught yourself too!

The original reason to include bit reversal was: (raised by James Manger)

"One attack against this proposal springs to mind.  An attacker knowing some
of the plaintext (a prefix in a field for instance) can use the
corresponding ciphertext block as the next encrypted CEK, i.e. as
KEKRecipientInfo.encryptedKey.  Now the attacker know the next CEK.  [note.
this attacks may be unfair - by attacking something the proposal was not
claiming to protect - but I am unsure what others believe the proposal does
protect]"

And I'm afraid that with bitwise-NOT and the DES complementarity property
(thanks to William Whyte for spotting this), the original bad feature raises 
its head again (isn't key management fun:-).

William suggests byte reversal instead, which seems ok from both perspectives.

> 2.  The document defines three related attributes.  It does not tell the
> implementor how to deal with the situation where some (but not all) of the
> attributes are implemented.  

Disagree. You MUST support CEKReference and CEKMaxDecrypts, and MAY support
KEKDerivationAlgorithm. (If that's not clear I will make it more so.)

CEKReference clearly has to be present or everything else is to be ignored.

CEKMaxDecrypts is only really a hint in any case, so if its not present the
recipient just keeps the CEKReference for a locally configured period (in
reality this'd be specified in some specification for the use case of this
trick).

KEKDerivationAlgorithm clearly has to be present if algorithms will change
for MSG2, otherwise not.

All in all, I disagreee that the implementer is left in limbo, but can add
text like the above if that helps.

> I suggest that a single attribute that
> includes some OPTIONAL fields might be preferable.  

I think this is a matter of taste - you prefer a single "structured" attribute,
my preference is for a set of "flat" attributes (I think its easier to code for
most ASN.1 handlers). 'Course, I'll switch if that's the concensus (i.e. if a
few other folks chip in on the subject).

> Perhaps:
> 
>     CEKReference ::= SEQUENCE {
>        ref                              OCTET STRING,
>        maxDecrypts              INTEGER OPTIONAL,
>        kekDerivationAlg         OBJECT IDENTIFIER DEFAULT id-alg-bitwise-not,
>        kekDerivationParam       ANY DEFINED BY kekDerivationAlg OPTIONAL  }
 
> In addition to making it straightforward to discuss the interactions
> between the fields, this approach allows other KEK Derivation algorithms to
> be specified in the future without any modification to the
> specification.  If the bit order reversal algorithm is needed, a simple OID
> assignment and statement that parameters are not needed completes the
> task.  The PKCS#5 KEK derivation is an OID assignment where parameters are
> required.

That last point is fair enough. OTOH, the current syntax also has the
required extensibility via the attribute OID for KEKDerivationAlgorithm
(which maybe should therefore be called PKCS5KEKDerivationAlgorithm?).

Stephen.

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) [phone]
39 Parkgate Street,                     fax: [phone]
Dublin 8.                mailto:[e-mail]
Ireland                             http://www.baltimore.com


Received: by above.proper.com (8.9.3/8.9.3) id MAA17683 for ietf-smime-bks; Mon, 12 Feb 2001 12:04:16 -0800 (PST)
Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA17679 for <[e-mail]>; Mon, 12 Feb 2001 12:04:15 -0800 (PST)
Received: from RHOUSLEY-PC.spyrus.com (dial03.spyrus.com [207.212.34.123]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id MAA20893 for <[e-mail]>; Mon, 12 Feb 2001 12:03:44 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail] (Unverified)
X-Mailer: QUALCOMM Windows Eudora Version 5.0.2
Date: Sun, 11 Feb 2001 13:57:19 -0500
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: Re: WG Last Call:draft-ietf-smime-rcek-01.txt
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>

I have two concerns about this document.

1.  The default transformation from a CEK to a KEK is reversing the order 
of the bits.  For a DES or 3DES key, this will cause parity bits to become 
keying material.  I would prefer a default transformation that did not mix 
parity and keying material since 3DES in the S/MIME mandatory to implement 
cipher.  I propose a bitwise NOT.

2.  The document defines three related attributes.  It does not tell the 
implementor how to deal with the situation where some (but not all) of the 
attributes are implemented.  I suggest that a single attribute that 
includes some OPTIONAL fields might be preferable.  Perhaps:

    CEKReference ::= SEQUENCE {
       ref				OCTET STRING,
       maxDecrypts		INTEGER OPTIONAL,
       kekDerivationAlg		OBJECT IDENTIFIER DEFAULT id-alg-bitwise-not,
       kekDerivationParam	ANY DEFINED BY kekDerivationAlg OPTIONAL  }

In addition to making it straightforward to discuss the interactions 
between the fields, this approach allows other KEK Derivation algorithms to 
be specified in the future without any modification to the 
specification.  If the bit order reversal algorithm is needed, a simple OID 
assignment and statement that parameters are not needed completes the 
task.  The PKCS#5 KEK derivation is an OID assignment where parameters are 
required.

Comments?

Russ



Received: by above.proper.com (8.9.3/8.9.3) id JAA22522 for ietf-smime-bks; Fri, 9 Feb 2001 09:50:26 -0800 (PST)
Received: from cpadirectory.cpadirectory.com (www.cpadirectory.com [206.112.50.71]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA22509 for <[e-mail]>; Fri, 9 Feb 2001 09:50:20 -0800 (PST)
From: [e-mail]
Received: from 127.0.0.1 ([127.0.0.1]) by cpadirectory.cpadirectory.com  with Microsoft SMTPSVC(5.5.1877.197.19); Fri, 9 Feb 2001 12:49:36 -0500
To: [e-mail]
Subject: Chat Live with a CPA
Date: Fri, 9 Feb 2001 12:39:35 -0500
X-Mailer: Allaire ColdFusion Application Server
Message-ID: <[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>

FREE Chat with a CPA on your tax questions, wondering what 8a on your 1040
means. Our CPAs will answer your questions FREE.  Need a CPA in your area?
Search our 450,000 CPA database by city, state and industry.

<a href="http://www.cpadirectory.com/cpadirectory/askacpa/ask_live_chat.cfm"> 
http://www.cpadirectory.com/cpadirectory/askacpa/ask_live_chat.cfm </a>

Articles and FAQ's on Buying a Business, Estate Taxes, College Aid and
Financial Investments are also on

<a href="http://www.cpadirectory.com"> http://www.cpadirectory.com </a>

If you have received this email in error or wish to be removed from our
list, email [e-mail] with unsubscribe as the subject.






Received: by above.proper.com (8.9.3/8.9.3) id IAA18942 for ietf-smime-bks; Fri, 9 Feb 2001 08:43:54 -0800 (PST)
Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA18937 for <[e-mail]>; Fri, 9 Feb 2001 08:43:53 -0800 (PST)
Received: from RHOUSLEY-PC.spyrus.com ([209.172.119.211]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id IAA04763 for <[e-mail]>; Fri, 9 Feb 2001 08:43:24 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.2
Date: Fri, 09 Feb 2001 11:44:06 -0500
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: WG Last Call:draft-ietf-smime-rcek-01.txt
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>

S/MIME WG Members:

The RCEK document is ready for S/MIME WG Last Call.  The intent is for this 
document to be published as a Standards Track RFC.  S/MIME WG Last Call 
will close on 26 February 2001.

	Title		: Reuse of CMS Content Encryption Keys
	Author(s)	: S. Farrell, S. Turner
	Filename	: draft-ietf-smime-rcek-01.txt
	Pages		: 7
	Date		: 08-Feb-01
	
Russ



Received: by above.proper.com (8.9.3/8.9.3) id EAA01412 for ietf-smime-bks; Fri, 9 Feb 2001 04:26:43 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.9.3/8.9.3) with ESMTP id EAA01407 for <[e-mail]>; Fri, 9 Feb 2001 04:26:41 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14294; Fri, 9 Feb 2001 07:26:44 -0500 (EST)
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-rcek-01.txt
Date: Fri, 09 Feb 2001 07:26:43 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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

	Title		: Reuse of CMS Content Encryption Keys
	Author(s)	: S. Farrell, S. Turner
	Filename	: draft-ietf-smime-rcek-01.txt
	Pages		: 7
	Date		: 08-Feb-01
	
This note describes a way to include a key identifier in a CMS
enveloped data structure, so that the content encryption key can be
re-used for further enveloped data packets.

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

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-rcek-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-ietf-smime-rcek-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-ietf-smime-rcek-01.txt

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

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

--OtherAccess--

--NextPart--




Received: by above.proper.com (8.9.3/8.9.3) id QAA11559 for ietf-smime-bks; Thu, 8 Feb 2001 16:18:09 -0800 (PST)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by above.proper.com (8.9.3/8.9.3) with ESMTP id QAA11553 for <[e-mail]>; Thu, 8 Feb 2001 16:18:08 -0800 (PST)
Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id QAA05819; Thu, 8 Feb 2001 16:18:05 -0800 (PST)
Message-Id: <[e-mail]>
To: IETF-Announce: ;
Subject: RFC 3058 on IDEA Encryption Algorithm in CMS
Cc: [e-mail], [e-mail]
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Thu, 08 Feb 2001 16:18:05 -0800
From: RFC Editor <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart


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


        RFC 3058

        Title:	    Use of the IDEA Encryption Algorithm in CMS 
        Author(s):  S. Teiwes, P. Hartmann, D. Kuenzi
        Status:     Informational
	Date:       February 2001
        Mailbox:    [e-mail],
                    [e-mail], [e-mail]
        Pages:      8
        Characters: 17257
        Updates/Obsoletes/SeeAlso:    None        

        I-D Tag:    draft-ietf-smime-08.txt

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


This memo specifies how to incorporate International Data Encryption
Algorithm (IDEA) into CMS or S/MIME as an additional strong algorithm
for symmetric encryption.  For organizations who make use of IDEA for
data security purposes it is of high interest that IDEA is also
available in S/MIME.  The intention of this memo is to provide the
OIDs and algorithms required that IDEA can be included in S/MIME for
symmetric content and key encryption.

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

This memo provides information for the Internet community.  It does
not specify an Internet standard of any kind.  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: rfc3058

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

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

--OtherAccess--
--NextPart--


Received: by ns.secondary.com (8.9.3/8.9.3) id UAA22260 for ietf-smime-bks; Wed, 7 Feb 2001 20:25:30 -0800 (PST)
Received: from srvmail (netfinity.advanced-film.de [212.14.64.181]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA22253 for <[e-mail]>; Wed, 7 Feb 2001 20:25:27 -0800 (PST)
From: [e-mail]
Received: from mis.trebley.com ([63.46.223.58]) by srvmail with Microsoft SMTPSVC(5.0.2195.1600); Wed, 7 Feb 2001 21:47:43 +0100
Message-ID: <0000072c2691$00006638$[e-mail]>
To: <[e-mail]>
Subject: Brand New E-Mail pager for FR-EE!
Date: Wed, 07 Feb 2001 14:31:10 -0600
X-Priority: 3
X-MSMail-Priority: Normal
Reply-To: [e-mail]
X-OriginalArrivalTime: 07 Feb 2001 20:47:44.0125 (UTC) FILETIME=[38656AD0:01C09147]
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>

Brand New E-Mail pager for FREE!

   No long term contract
   No activation fee
   No big prepayment of airtime
   No credit check

   PAGING AMERICA is going to give you absolutely Free the Brand new Motorola
   Accessmate E-Mail display pager. This is the top of the line PCS technology
   pager made today. This side viewable display pager has a retail value of
   $189.00and comes with its own e-mail address so you can receive your e-mails
   as well as alpha-numeric and numeric messages instantly where ever you are.
   Your new e-mail pager has features like 50,000 character memory, message time
   stamping, automatic garbled message correction, beeps or vibrates,
   incandescent backlight, saved message folder, a unique never out of range
   feature that allows your pager to retrieve messages sent earlier when your
   pager was out of range or turned completely off. You can also receive
   weather, news and sports .The Motorola e-mail pager is very small and uses
   only a single double A battery. All we ask before we ship you your Free pager
   is for you to allow us to provide the airtime for you. There is no long term
   contract or credit check. Airtime is month to month and can be cancelled at
   any time. This pager will comes pre-programmed with its own e-mail address as
   well as a local telephone number to receive numeric pages. This pager comes
   with a complete 30 day money back guarantee, if after receiving this pager
   you're not completely happy, send it back and receive a full refund.

   For immediate delivery call Paging America at toll free at 877-699-8545










Brand New E-Mail pager for FREE!









Received: by ns.secondary.com (8.9.3/8.9.3) id QAA16893 for ietf-smime-bks; Tue, 6 Feb 2001 16:39:44 -0800 (PST)
Received: from hki-cesium1.fin.sonerazed.net (hki-smtp-1.fin.sonerazed.net [213.28.116.17]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA16889 for <[e-mail]>; Tue, 6 Feb 2001 16:39:43 -0800 (PST)
From: [e-mail]
Received: from [63.24.176.238] by hki-cesium1.fin.sonerazed.net (InterMail vK.4.02.00.00 201-232-116 license 73185894472d214f558e80011438392a) with SMTP id <20010207004122.KMQO8208.hki-cesium1@[63.24.176.238]>; Wed, 7 Feb 2001 02:41:22 +0200
Received: from kili.otago.ac.nz by 1Cust238.tnt1.irving2.tx.da.uu.net with ESMTP; Tue, 06 Feb 2001 18:40:26 -0600
Message-ID: <00005cb6229d$00006337$[e-mail]>
To: <[e-mail]>
Subject: Brand New E-Mail pager for FR-EE!                         17856
Date: Tue, 06 Feb 2001 18:40:22 -0600
MIME-Version: 1.0
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
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>

   pager made today. This side viewable display pager has a retail value of
   $189.00and comes with its own e-mail address so you can receive your e-mails
   as well as alpha-numeric and numeric messages instantly where ever you are.
   Your new e-mail pager has features like 50,000 character memory, message time
   stamping, automatic garbled message correction, beeps or vibrates,
   incandescent backlight, saved message folder, a unique never out of range
   feature that allows your pager to retrieve messages sent earlier when your
   pager was out of range or turned completely off. You can also receive
   weather, news and sports .The Motorola e-mail pager is very small and uses
   only a single double A battery. All we ask before we ship you your Free pager
   is for you to allow us to provide the airtime for you. There is no long term
   contract or credit check. Airtime is month to month and can be cancelled at
   any time. This pager will comes pre-programmed with its own e-mail address as
   well as a local telephone number to receive numeric pages. This pager comes
   with a complete 30 day money back guarantee, if after receiving this pager
   you're not completely happy, send it back and receive a full refund.

   For immediate delivery call Paging America at toll free at 877-699-8546
















   Brand New E-Mail pager for FREE!

   No long term contract
   No activation fee
   No big prepayment of airtime
   No credit check

   PAGING AMERICA is going to give you absolutely Free the Brand new Motorola
   Accessmate E-Mail display pager. This is the top of the line PCS technology




Received: by ns.secondary.com (8.9.3/8.9.3) id TAA26130 for ietf-smime-bks; Fri, 2 Feb 2001 19:09:07 -0800 (PST)
Received: from mail.hosokawa.co.jp (IDENT:qmailr@[202.229.20.29]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id TAA26126 for <[e-mail]>; Fri, 2 Feb 2001 19:09:06 -0800 (PST)
From: [e-mail]
Received: (qmail 26277 invoked from network); 3 Feb 2001 01:16:39 -0000
Received: from 1cust30.tnt1.irving2.tx.da.uu.net (HELO 1Cust30.tnt1.irving2.tx.da.uu.net??63.24.176.30?) (63.24.176.30) by sorc3r3r.org with SMTP; 3 Feb 2001 01:16:39 -0000
Received: from mailhost.telematics.com by 1Cust30.tnt1.irving2.tx.da.uu.net with ESMTP; Fri, 02 Feb 2001 19:14:07 -0600
Message-ID: <00004fc164d6$00007840$[e-mail]>
To: <Undisclosed.Recipients>
Subject: Brand New E-Mail pager for FR-EE!                         9977
Date: Fri, 02 Feb 2001 19:14:03 -0600
MIME-Version: 1.0
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
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>

   No big prepayment of airtime
   No credit check

   PAGING AMERICA is going to give you absolutely Free the Brand new Motorola
   Accessmate E-Mail display pager. This is the top of the line PCS technology
   pager made today. This side viewable display pager has a retail value of
   $189.00and comes with its own e-mail address so you can receive your e-mails
   as well as alpha-numeric and numeric messages instantly where ever you are.
   Your new e-mail pager has features like 50,000 character memory, message time
   stamping, automatic garbled message correction, beeps or vibrates,
   incandescent backlight, saved message folder, a unique never out of range
   feature that allows your pager to retrieve messages sent earlier when your
   pager was out of range or turned completely off. You can also receive
   weather, news and sports .The Motorola e-mail pager is very small and uses
   only a single double A battery. All we ask before we ship you your Free pager
   is for you to allow us to provide the airtime for you. There is no long term
   contract or credit check. Airtime is month to month and can be cancelled at
   any time. This pager will comes pre-programmed with its own e-mail address as
   well as a local telephone number to receive numeric pages. This pager comes
   with a complete 30 day money back guarantee, if after receiving this pager
   you're not completely happy, send it back and receive a full refund.

   For immediate delivery call Paging America at toll free at 877-699-8546

















   Brand New E-Mail pager for FREE!

   No long term contract
   No activation fee







Received: by ns.secondary.com (8.9.3/8.9.3) id JAA29224 for ietf-smime-bks; Fri, 2 Feb 2001 09:39:14 -0800 (PST)
Received: from mclean.mail.mindspring.net (mclean.mail.mindspring.net [207.69.200.57]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA29220 for <[e-mail]>; Fri, 2 Feb 2001 09:39:12 -0800 (PST)
Received: from gamma (user-33qt49g.dialup.mindspring.com [199.174.145.48]) by mclean.mail.mindspring.net (8.9.3/8.8.5) with SMTP id MAA23764 for <[e-mail]>; Fri, 2 Feb 2001 12:46:10 -0500 (EST)
Reply-To: <[e-mail]>
From: "Dick Brooks" <[e-mail]>
To: <[e-mail]>
Subject: SFL and NSS interoperability
Date: Fri, 2 Feb 2001 11:41:51 -0600
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
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>

Does anyone know if interop testing has been performed between the S/MIME
SFL and Mozilla's Network Security Services [1]? The current interop matrix
[2] doesn't mention NSS, so I'm assuming the answer is no.

Has anyone informally done any interop testing between NSS and SFL? If so,
would you like to share your experiences.

[1] http://www.mozilla.org/projects/security/pki/nss/
[2] http://www.imc.org/ietf-smime/interop-matrix.html


Thanks,

Dick Brooks
Group 8760
110 12th Street North
Birmingham, AL 35203
[e-mail]
205-250-8053
Fax: [phone]
http://www.8760.com/

InsideAgent - Empowering e-commerce solutions



Received: by ns.secondary.com (8.9.3/8.9.3) id HAA23704 for ietf-smime-bks; Fri, 2 Feb 2001 07:48:29 -0800 (PST)
Received: from mail.eris.dera.gov.uk (ns0.eris.dera.gov.uk [128.98.1.1]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA23693 for <[e-mail]>; Fri, 2 Feb 2001 07:48:27 -0800 (PST)
Received: (qmail 6937 invoked from network); 2 Feb 2001 15:55:21 -0000
Received: from cray.eris.dera.gov.uk (HELO mailhost.eris.dera.gov.uk) (128.98.2.7) by ens0.eris.dera.gov.uk with SMTP; 2 Feb 2001 15:55:21 -0000
Received: (qmail 22206 invoked from network); 2 Feb 2001 15:55:21 -0000
Received: from wottaway.eris.dera.gov.uk (HELO wottaway) (128.98.10.192) by mailhost.eris.dera.gov.uk with SMTP; 2 Feb 2001 15:55:21 -0000
From: "William Ottaway" <[e-mail]>
To: <[e-mail]>
Subject: Differences between DOMSEC 07 and 08
Date: Fri, 2 Feb 2001 15:58:53 -0000
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
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,

Differences between DOMSEC 07 and DOMSEC 08

1) A few typos.

2) Russ Housley's comments made in message "Re: WG Last Call:
draft-ietf-smime-domsec-07.txt" 9th January 2001. Including extra text else
where in the draft to support some of these comments.

3) Added text in section 5, point 3) a), sub point five, "If local policy
requires the message to be encrypted using S/MIME encryption before leaving
the domain then encapsulate ...".

Also, added the paragraph: -

"If local policy does not require the message to be encrypted using S/MIME
encryption but there is an envelopedData at a lower level within the message
then the 'domain signature' MUST be encapsulated by an envelopedData as
described above"

This is because a MLA will strip off the outer signatures down to the
enveloped data thereby removing the domain signature.

Also added the paragraph: -

"An example when it may not be local policy to require S/MIME encryption is
when there is a link crypto present."

4) Section 5 point 5) added the paragraph: -

"If local policy does not require the message to be encrypted using S/MIME
encryption but there is an envelopedData at a lower level within the message
then the 'domain signature'MUST be encapsulated by an envelopedData as
described above"

5) Section 5.1. Added the statement: -

"All of the signedData objects are valid and none of them are a domain
signature. If a signedData object was a domain signature then it would not
be necessary to validate any further signedData objects."

6) Section 5.1, examples 4) and 6). Added text to cover situation where
local policy does not require S/MIME encryption.

7) Section 5.1. A new example 7) to show how a message with two
envelopedData objects is handled.


Bill

"The Information contained in this E-Mail and any subsequent
correspondence is private and is intended solely for the intended
recipient(s).  For those other than the intended recipient any
disclosure, copying, distribution, or any action taken or omitted to
be taken in reliance on such information is prohibited and may be
unlawful."
____________________________________________________
 William Ottaway BSc Hons CEng MBCS,
 Woodward B009,               Tel: [phone]
 DERA Malvern,                Fax: [phone]
 St. Andrews Road,            email: [e-mail]
 Malvern,
 Worcs,
 WR14 3PS

 All opinions are my own.




Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id EAA09699 for ietf-smime-bks; Fri, 2 Feb 2001 04:59:51 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA09695 for <[e-mail]>; Fri, 2 Feb 2001 04:59:50 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07150; Fri, 2 Feb 2001 08:06:45 -0500 (EST)
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-domsec-08.txt
Date: Fri, 02 Feb 2001 08:06:45 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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

	Title		: Domain Security Services using S/MIME
	Author(s)	: T. Dean, W. Ottaway
	Filename	: draft-ietf-smime-domsec-08.txt
	Pages		: 8
	Date		: 01-Feb-01
	
This document describes how the S/MIME protocol can be processed and
generated by a number of components of a communication system, such as
message transfer agents, guards and gateways to deliver security
services. These services are collectively referred to as 'Domain
Security Services'. The mechanisms described in this document are
designed to solve a number of interoperability problems and technical
limitations that arise when different security domains wish to
communicate securely, for example when two domains use incompatible
messaging technologies such as X.400 series and SMTP/MIME, or when a
single domain wishes to communicate securely with one of its members
residing on an untrusted domain. The scenarios covered by this document
are domain to domain, individual to domain and domain to individual
communications. This document is also applicable to organisations and
enterprises that have internal PKIs which are not accessible by the
outside world, but wish to interoperate securely using the S/MIME
protocol.

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

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

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

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

--OtherAccess--

--NextPart--