[[893412646]] Subscription to ietf-smime for [e-mail]

[[e-mail]]

Greetings. This message is a periodic reminder that
     [e-mail]
is subscribed to the
     ietf-smime
mailing list.

There are two purposes for this message:
- If this message is bounced by your mail server, I can remove you from
  the mailing list and reduce waste of bandwidth and resources. (If you
  are reading this message, it clearly didn't get bounced!)
- Some people stay subscribed to mailing lists even though they do not
  want to because they do not know how to unsubscribe. 

If you want to stay subscribed to the ietf-smime mailing list,
you do not need to do anything. Feel free to delete this message.

On the other hand, if you want to unsubscribe from this list, simply go
to the following link:
     <http://www.imc.org/Unsubs/893412646>

If for some reason you cannot go to that web site, you can also
unsubscribe by email; however, doing so is not as likely to get you
unsubscribed as the web site is. To unsubscribe using email, you can
respond to this message and I will unsubscribe you by hand in the next
few days. Again, this is not assured to work because your mail system
may make it impossible for me to determine who you are or what you want
to unsubscribe to.

Alternatively, you can send a plain-text message to:
     [e-mail]
with the single word
     unsubscribe
in the body of the message. This last method assumes that the "From:"
address in your mail is "[e-mail]". Again, using the
web site above is more likely to work than this method (due to limitations
in Majordomo, the mailing list software we currently use).

If you have any questions, feel free to contact me.

--Paul Hoffman, list administrator



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g7UKULK26142 for ietf-smime-bks; Fri, 30 Aug 2002 13:30:21 -0700 (PDT)
Received: from vulcan.rsasecurity.com (mail.rsasecurity.com [204.167.114.123]) by above.proper.com (8.11.6/8.11.3) with SMTP id g7UKUJ226138 for <[e-mail]>; Fri, 30 Aug 2002 13:30:19 -0700 (PDT)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 30 Aug 2002 20:30:22 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id QAA15953; Fri, 30 Aug 2002 16:30:15 -0400 (EDT)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.10.2) with ESMTP id g7UKRwv22524; Fri, 30 Aug 2002 16:27:59 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <3TPV33D2>; Fri, 30 Aug 2002 16:30:12 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.9.13]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3TPV33DA; Fri, 30 Aug 2002 16:30:05 -0400
From: "Housley, Russ" <[e-mail]>
To: Tony Capel <[e-mail]>
Cc: [e-mail], [e-mail], "'Peter Gutmann'" <[e-mail]>, [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Fri, 30 Aug 2002 16:24:17 -0400
Subject: RE: I-D ACTION:draft-ietf-smime-rfc2633bis-01.txt:    CompressedData
In-Reply-To: <000a01c2503c$535b2fe0$01b5a8c0@tony>
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>

Tony:

On the receive side, we say that the S/MIME agent must be capable of 
handling either order.

On the sending side, we say that the S/MIME agent can include a default 
method for handling this (either way), and they may optionally provide a 
setting for the user to change the ordering.

Russ

At 11:45 AM 8/30/2002 -0400, Tony Capel wrote:
>Russ:
>
>Sorry, I have misled you with my message.
>
>I agree with Peter and with your "I can live with it" conclusion.  The
>problem I see is that although we must allow the user to be able to
>select either method; we have the problem of telling the software
>implementer what to do today in the absence of a decision (which will be
>made by users in the future).  Do we have implementers/vendors flipping
>a coin or making value judgements themselves on the pros and cons?
>Rather than that, we say: 1. "the order should be capable of being
>specified by the local user" and (really optionally) 2. "the default
>behaviour is as follows". If we fail to do this, we will have
>implementations with one or the other order decision embedded (and
>potentially unalterable) in the implementation. Also there are some alg
>types where compression first is mandatory for technical reasons.
>
>tony
>
> > -----Original Message-----
> > From: Housley, Russ [mailto:[e-mail]]
> > Sent: August 30, 2002 10:56 AM
> > To: Tony Capel
> > Cc: [e-mail]; [e-mail]; 'Peter Gutmann';
> > [e-mail]
> > Subject: RE: I-D ACTION:draft-ietf-smime-rfc2633bis-01.txt:
>CompressedData
> >
> > Tony:
> >
> > I recall a discussion of this on the list quite some time ago; there
>are
> > tradeoffs.  One size does not fit all.  One application could
> > appropriately
> > select one ordering, and another application could appropriately
>select
> > the
> > opposite.  For this reason, we do not want to mandate any particular
> > ordering for CMS.
> >
> > Perhaps the user community of S/MIME is diverse enough that we should
>not
> > pick a single ordering for this context.  This is the position
>expressed
> > by
> > Peter Gutmann, and I can live with it.  However, the text needs to
>provide
> > a discussion of the pros and cons for the supported orderings.
> >
> > Someone writing a general purpose library should support arbitrary
> > ordering
> > of CMS protection content types (at least on the receive side).
> >
> > Russ
> >
> > At 10:32 AM 8/30/2002 -0400, Tony Capel wrote:
> > >Russ:
> > >
> > >I understand your concern.  I had hoped to dodge this by recognizing
> > >that this decision is very instance-specific, i.e. dependant upon
>what
> > >the end user is using the signed message for.  But from the poor
> > >programmer-of-messaging-software perspective she needs to know NOW
>what
> > >to do for all future end user applications.
> > >
> > >So maybe some guidance along the following line might be what is
>needed
> > >(the first two of which are obvious):
> > >
> > >1. Always compress before encrypt.
> > >2. Always compress before sign if using a lossy or other non-fully
> > >reversible algorithm.
> > >3. In all other cases sign before compress if not instructed
>otherwise,
> > >and provide a local (implementation specific) means for the user to
> > >specify the other order.
> > >
> > >The rationale for selecting signing first if the user does not
>specify
> > >otherwise is based on the assumption that this will most often
>satisfy
> > >the most stringent user signing policy (it will be wrong least
>often!).
> > >However, implementations should permit the local configuration of
>this
> > >based on user operational or other policies.
> > >
> > >As far as getting into a discussion of why one way or another is
> > >"better", it is not clear to me that s/mime is the right place for
>that.
> > >This might be better treated in signature policy or other such
> > >documents.
> > >
> > >tony
> > >
> > > > -----Original Message-----
> > > > From: [e-mail]
> > >[mailto:[e-mail]]
> > > > On Behalf Of Housley, Russ
> > > > Sent: August 29, 2002 10:21 AM
> > > > To: Tony Capel
> > > > Cc: [e-mail]; [e-mail]; 'Peter Gutmann';
> > > > [e-mail]
> > > > Subject: RE: I-D ACTION:draft-ietf-smime-rfc2633bis-01.txt:
> > >CompressedData
> > > >
> > > >
> > > > Tony:
> > > >
> > > > I agree that the use of the compression algorithm identifier in
>S/MIME
> > > > Capabilities is the right approach.
> > > >
> > > > I think that we need to offer guidance in MSGbis for S/MIME
> > >applications
> > > > on
> > > > the order of operations.  Other applications that make use of CMS
> > >could
> > > > make different decisions, but MSGbis should set the conventions
>for
> > > > S/MIME.
> > > >
> > > > RFC 2634 describes the triple wrapper:
> > > >          sign-encrypt-sign.
> > > >
> > > > To maintain maximum capability with this specification, we have
>two
> > > > choices:
> > > >          sign-compress-encrypt-sign; or
> > > >          compress-sign-encrypt-sign
> > > >
> > > > In support of the sign-what-you-say concept, I prefer
> > > > sign-compress-encrypt-sign.
> > > >
> > > > Russ
> > > >
> > > >
> > > > At 10:30 AM 8/28/2002 -0400, Tony Capel wrote:
> > > > >Blake:
> > > > >
> > > > >I wonder if we could not close off the "CompressedData"
>discussion
> > > > >simply by adding a few word (e.g. "...and compression, see
>RFC3274" )
> > > > >reference to RFC3274, Peter's compression rfc, to Section 2.5.2
>of
> > >MSG
> > > > >(and adding RFC3274 to the list of references)?
> > > > >
> > > > >If 2.5.2 is updated to address the preferBinaryInside issue maybe
>now
> > >is
> > > > >the time to do both (especially since both are aimed at reducing
> > > > >messaging overhead).
> > > > >
> > > > >CompressedData use is listed as an outstanding issue for MSG in
>the
> > > > >recent IETF WG meeting minutes:
> > > > >http://www.imc.org/ietf-smime/mail-archive/msg01339.html
> > > > >
> > > > >It has also been raised in three threads on this list:
> > > > >http://www.imc.org/ietf-smime/mail-archive/msg01295.html
> > > > >http://www.imc.org/ietf-smime/mail-archive/msg01172.html
> > > > >http://www.imc.org/ietf-smime/mail-archive/msg01241.html
> > > > >
> > > > >With respect to the order of compression and signing:  For
>receivers
> > >it
> > > > >has been pointed out that the encoding unambiguously indicates
>the
> > >order
> > > > >upon receipt.  Thus it would appear that no new mechanism is
>required
> > >to
> > > > >ensure interoperability (providing the receiver can process the
> > >entities
> > > > >in either order, and I THINK this what is implied by the current
> > >text).
> > > > >
> > > > >With respect to whether the sender should sign or compress first:
> > >Some
> > > > >applications will prefer signing first (sign-what-you-say, e.g.
>to
> > >meet
> > > > >EU or other "directives" interpreted to require signing before
> > > > >compression) and others will prefer compression first (signing
>the
> > > > >compressed version, e.g. for processing efficiency or as would be
> > > > >required if lossy compression were to be used). I suggest we
>dodge
> > >this
> > > > >bullet by arguing that this is an application issue best left to
> > > > >mechanisms (if needed) outside s/mime.
> > > > >
> > > > >Adding a reference to RFC3274 would emphasize RFC3274's use of
> > > > >corresponding compression algorithm OID(s) as an sMIMECapability
>to
> > > > >specify receiver compression capabilities.  Hopefully this will
> > >promote
> > > > >the implementation of compression which will reduce message
>overheads
> > > > >benefiting mail system operators and users accessing e-mail over
>low
> > > > >bandwidth channels.
> > > > >
> > > > >tony
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: [e-mail]
> > > > >[mailto:[e-mail]]
> > > > > > On Behalf Of Tony Capel
> > > > > > Sent: July 9, 2002 10:24 AM
> > > > > > To: 'Peter Gutmann'; [e-mail];
> > > > > > [e-mail]; [e-mail];
> > >[e-mail]
> > > > > > Subject: RE: I-D ACTION:draft-ietf-smime-rfc2633bis-01.txt
> > > > > >
> > > > > >
> > > > > > Peter,
> > > > > >
> > > > > > many of us like your compression addition and would like it
>widely
> > >(if
> > > > > > not ubiquitously!) implemented.
> > > > > >
> > > > > > One perceived barrier to the adoption of s/mime is the
>expansion
> > >of
> > > > > > message size due to the repeated application of transfer
>(base64)
> > > > > > encoding at each wrap.  Messaging system operators become
>alarmed
> > >when
> > > > > > told message sizes may more than double as a result.  (Indeed
>the
> > >NIST
> > > > > > draft profile depreciates such coding of inner wraps to
>address
> > >this
> > > > > > issue.)
> > > > > >
> > > > > > The ability to offer compression also addresses overall
>message
> > > > > > expansion and will be an important capability to offer in
> > >compensation
> > > > > > when "marketing" the adoption of s/mime by large
>organizations.
> > > > > >
> > > > > >
> > > > > > Tony Capel
> > > > > >
> > > > > >
> > > > > > -----Original Message-----
> > > > > > From: [e-mail]
> > > > > > [mailto:[e-mail]] On Behalf Of Peter
>Gutmann
> > > > > > Sent: July 9, 2002 4:49 AM
> > > > > > To: [e-mail]; [e-mail];
> > > > > > [e-mail]; [e-mail]
> > > > > > Subject: Re: I-D ACTION:draft-ietf-smime-rfc2633bis-01.txt
> > > > > >
> > > > > >
> > > > > > "Blake Ramsdell" <[e-mail]> writes:
> > > > > >
> > > > > > >I didn't see much uptake on this besides Russ saying "MAY",
>and
> > >I'm
> > > > > > worried
> > > > > > >about compatibility.  I will put a slide in my presentation
>about
> > > > >this
> > > > > > for
> > > > > > >Yokohama.
> > > > > >
> > > > > > AFAIK the major use at the moment is in EDI environments
>(large,
> > > > >highly-
> > > > > > compressible messages, and everything is "by prior
>arrangement"
> > > > >anyway).
> > > > > > There
> > > > > > are a couple of apps which support it out there though, so
>having
> > >it
> > > > > > mentioned
> > > > > > would be nice just to let implementers know it's there.
> > > > > >
> > > > > > Peter.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g7UFjZ812418 for ietf-smime-bks; Fri, 30 Aug 2002 08:45:35 -0700 (PDT)
Received: from mx1.magmacom.com (mx1.magmacom.com [206.191.0.217]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7UFjY212413 for <[e-mail]>; Fri, 30 Aug 2002 08:45:34 -0700 (PDT)
Received: from mail3.magma.ca (mail3.magma.ca [206.191.0.221]) by mx1.magmacom.com (Magma's Mail Server) with ESMTP id g7UFjX4w027709; Fri, 30 Aug 2002 11:45:33 -0400 (EDT)
Received: from tony (ottawa-hs-209-217-122-183.s-ip.magma.ca [209.217.122.183]) by mail3.magma.ca (Magma's Mail Server) with ESMTP id g7UFjJcI018867; Fri, 30 Aug 2002 11:45:33 -0400 (EDT)
From: "Tony Capel" <[e-mail]>
To: "'Housley, Russ'" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, "'Peter Gutmann'" <[e-mail]>, <[e-mail]>
Subject: RE: I-D ACTION:draft-ietf-smime-rfc2633bis-01.txt:    CompressedData
Date: Fri, 30 Aug 2002 11:45:43 -0400
Message-ID: <000a01c2503c$535b2fe0$01b5a8c0@tony>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
In-Reply-To: <[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
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:

Sorry, I have misled you with my message.

I agree with Peter and with your "I can live with it" conclusion.  The
problem I see is that although we must allow the user to be able to
select either method; we have the problem of telling the software
implementer what to do today in the absence of a decision (which will be
made by users in the future).  Do we have implementers/vendors flipping
a coin or making value judgements themselves on the pros and cons?
Rather than that, we say: 1. "the order should be capable of being
specified by the local user" and (really optionally) 2. "the default
behaviour is as follows". If we fail to do this, we will have
implementations with one or the other order decision embedded (and
potentially unalterable) in the implementation. Also there are some alg
types where compression first is mandatory for technical reasons.

tony

> -----Original Message-----
> From: Housley, Russ [mailto:[e-mail]]
> Sent: August 30, 2002 10:56 AM
> To: Tony Capel
> Cc: [e-mail]; [e-mail]; 'Peter Gutmann';
> [e-mail]
> Subject: RE: I-D ACTION:draft-ietf-smime-rfc2633bis-01.txt:
CompressedData
> 
> Tony:
> 
> I recall a discussion of this on the list quite some time ago; there
are
> tradeoffs.  One size does not fit all.  One application could
> appropriately
> select one ordering, and another application could appropriately
select
> the
> opposite.  For this reason, we do not want to mandate any particular
> ordering for CMS.
> 
> Perhaps the user community of S/MIME is diverse enough that we should
not
> pick a single ordering for this context.  This is the position
expressed
> by
> Peter Gutmann, and I can live with it.  However, the text needs to
provide
> a discussion of the pros and cons for the supported orderings.
> 
> Someone writing a general purpose library should support arbitrary
> ordering
> of CMS protection content types (at least on the receive side).
> 
> Russ
> 
> At 10:32 AM 8/30/2002 -0400, Tony Capel wrote:
> >Russ:
> >
> >I understand your concern.  I had hoped to dodge this by recognizing
> >that this decision is very instance-specific, i.e. dependant upon
what
> >the end user is using the signed message for.  But from the poor
> >programmer-of-messaging-software perspective she needs to know NOW
what
> >to do for all future end user applications.
> >
> >So maybe some guidance along the following line might be what is
needed
> >(the first two of which are obvious):
> >
> >1. Always compress before encrypt.
> >2. Always compress before sign if using a lossy or other non-fully
> >reversible algorithm.
> >3. In all other cases sign before compress if not instructed
otherwise,
> >and provide a local (implementation specific) means for the user to
> >specify the other order.
> >
> >The rationale for selecting signing first if the user does not
specify
> >otherwise is based on the assumption that this will most often
satisfy
> >the most stringent user signing policy (it will be wrong least
often!).
> >However, implementations should permit the local configuration of
this
> >based on user operational or other policies.
> >
> >As far as getting into a discussion of why one way or another is
> >"better", it is not clear to me that s/mime is the right place for
that.
> >This might be better treated in signature policy or other such
> >documents.
> >
> >tony
> >
> > > -----Original Message-----
> > > From: [e-mail]
> >[mailto:[e-mail]]
> > > On Behalf Of Housley, Russ
> > > Sent: August 29, 2002 10:21 AM
> > > To: Tony Capel
> > > Cc: [e-mail]; [e-mail]; 'Peter Gutmann';
> > > [e-mail]
> > > Subject: RE: I-D ACTION:draft-ietf-smime-rfc2633bis-01.txt:
> >CompressedData
> > >
> > >
> > > Tony:
> > >
> > > I agree that the use of the compression algorithm identifier in
S/MIME
> > > Capabilities is the right approach.
> > >
> > > I think that we need to offer guidance in MSGbis for S/MIME
> >applications
> > > on
> > > the order of operations.  Other applications that make use of CMS
> >could
> > > make different decisions, but MSGbis should set the conventions
for
> > > S/MIME.
> > >
> > > RFC 2634 describes the triple wrapper:
> > >          sign-encrypt-sign.
> > >
> > > To maintain maximum capability with this specification, we have
two
> > > choices:
> > >          sign-compress-encrypt-sign; or
> > >          compress-sign-encrypt-sign
> > >
> > > In support of the sign-what-you-say concept, I prefer
> > > sign-compress-encrypt-sign.
> > >
> > > Russ
> > >
> > >
> > > At 10:30 AM 8/28/2002 -0400, Tony Capel wrote:
> > > >Blake:
> > > >
> > > >I wonder if we could not close off the "CompressedData"
discussion
> > > >simply by adding a few word (e.g. "...and compression, see
RFC3274" )
> > > >reference to RFC3274, Peter's compression rfc, to Section 2.5.2
of
> >MSG
> > > >(and adding RFC3274 to the list of references)?
> > > >
> > > >If 2.5.2 is updated to address the preferBinaryInside issue maybe
now
> >is
> > > >the time to do both (especially since both are aimed at reducing
> > > >messaging overhead).
> > > >
> > > >CompressedData use is listed as an outstanding issue for MSG in
the
> > > >recent IETF WG meeting minutes:
> > > >http://www.imc.org/ietf-smime/mail-archive/msg01339.html
> > > >
> > > >It has also been raised in three threads on this list:
> > > >http://www.imc.org/ietf-smime/mail-archive/msg01295.html
> > > >http://www.imc.org/ietf-smime/mail-archive/msg01172.html
> > > >http://www.imc.org/ietf-smime/mail-archive/msg01241.html
> > > >
> > > >With respect to the order of compression and signing:  For
receivers
> >it
> > > >has been pointed out that the encoding unambiguously indicates
the
> >order
> > > >upon receipt.  Thus it would appear that no new mechanism is
required
> >to
> > > >ensure interoperability (providing the receiver can process the
> >entities
> > > >in either order, and I THINK this what is implied by the current
> >text).
> > > >
> > > >With respect to whether the sender should sign or compress first:
> >Some
> > > >applications will prefer signing first (sign-what-you-say, e.g.
to
> >meet
> > > >EU or other "directives" interpreted to require signing before
> > > >compression) and others will prefer compression first (signing
the
> > > >compressed version, e.g. for processing efficiency or as would be
> > > >required if lossy compression were to be used). I suggest we
dodge
> >this
> > > >bullet by arguing that this is an application issue best left to
> > > >mechanisms (if needed) outside s/mime.
> > > >
> > > >Adding a reference to RFC3274 would emphasize RFC3274's use of
> > > >corresponding compression algorithm OID(s) as an sMIMECapability
to
> > > >specify receiver compression capabilities.  Hopefully this will
> >promote
> > > >the implementation of compression which will reduce message
overheads
> > > >benefiting mail system operators and users accessing e-mail over
low
> > > >bandwidth channels.
> > > >
> > > >tony
> > > >
> > > > > -----Original Message-----
> > > > > From: [e-mail]
> > > >[mailto:[e-mail]]
> > > > > On Behalf Of Tony Capel
> > > > > Sent: July 9, 2002 10:24 AM
> > > > > To: 'Peter Gutmann'; [e-mail];
> > > > > [e-mail]; [e-mail];
> >[e-mail]
> > > > > Subject: RE: I-D ACTION:draft-ietf-smime-rfc2633bis-01.txt
> > > > >
> > > > >
> > > > > Peter,
> > > > >
> > > > > many of us like your compression addition and would like it
widely
> >(if
> > > > > not ubiquitously!) implemented.
> > > > >
> > > > > One perceived barrier to the adoption of s/mime is the
expansion
> >of
> > > > > message size due to the repeated application of transfer
(base64)
> > > > > encoding at each wrap.  Messaging system operators become
alarmed
> >when
> > > > > told message sizes may more than double as a result.  (Indeed
the
> >NIST
> > > > > draft profile depreciates such coding of inner wraps to
address
> >this
> > > > > issue.)
> > > > >
> > > > > The ability to offer compression also addresses overall
message
> > > > > expansion and will be an important capability to offer in
> >compensation
> > > > > when "marketing" the adoption of s/mime by large
organizations.
> > > > >
> > > > >
> > > > > Tony Capel
> > > > >
> > > > >
> > > > > -----Original Message-----
> > > > > From: [e-mail]
> > > > > [mailto:[e-mail]] On Behalf Of Peter
Gutmann
> > > > > Sent: July 9, 2002 4:49 AM
> > > > > To: [e-mail]; [e-mail];
> > > > > [e-mail]; [e-mail]
> > > > > Subject: Re: I-D ACTION:draft-ietf-smime-rfc2633bis-01.txt
> > > > >
> > > > >
> > > > > "Blake Ramsdell" <[e-mail]> writes:
> > > > >
> > > > > >I didn't see much uptake on this besides Russ saying "MAY",
and
> >I'm
> > > > > worried
> > > > > >about compatibility.  I will put a slide in my presentation
about
> > > >this
> > > > > for
> > > > > >Yokohama.
> > > > >
> > > > > AFAIK the major use at the moment is in EDI environments
(large,
> > > >highly-
> > > > > compressible messages, and everything is "by prior
arrangement"
> > > >anyway).
> > > > > There
> > > > > are a couple of apps which support it out there though, so
having
> >it
> > > > > mentioned
> > > > > would be nice just to let implementers know it's there.
> > > > >
> > > > > Peter.




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g7UF7Gi10387 for ietf-smime-bks; Fri, 30 Aug 2002 08:07:16 -0700 (PDT)
Received: from vulcan.rsasecurity.com (mail.rsasecurity.com [204.167.114.123]) by above.proper.com (8.11.6/8.11.3) with SMTP id g7UF7E210383 for <[e-mail]>; Fri, 30 Aug 2002 08:07:14 -0700 (PDT)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 30 Aug 2002 15:07:16 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id LAA15393; Fri, 30 Aug 2002 11:07:05 -0400 (EDT)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.10.2) with ESMTP id g7UF4ox15452; Fri, 30 Aug 2002 11:04:51 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <3TPV320R>; Fri, 30 Aug 2002 11:07:04 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.9.20]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3TPV3203; Fri, 30 Aug 2002 11:06:57 -0400
From: "Housley, Russ" <[e-mail]>
To: Tony Capel <[e-mail]>
Cc: [e-mail], [e-mail], "'Peter Gutmann'" <[e-mail]>, [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Fri, 30 Aug 2002 10:55:40 -0400
Subject: RE: I-D ACTION:draft-ietf-smime-rfc2633bis-01.txt:   CompressedData
In-Reply-To: <000601c25032$20bd50e0$01b5a8c0@tony>
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>

Tony:

I recall a discussion of this on the list quite some time ago; there are 
tradeoffs.  One size does not fit all.  One application could appropriately 
select one ordering, and another application could appropriately select the 
opposite.  For this reason, we do not want to mandate any particular 
ordering for CMS.

Perhaps the user community of S/MIME is diverse enough that we should not 
pick a single ordering for this context.  This is the position expressed by 
Peter Gutmann, and I can live with it.  However, the text needs to provide 
a discussion of the pros and cons for the supported orderings.

Someone writing a general purpose library should support arbitrary ordering 
of CMS protection content types (at least on the receive side).

Russ

At 10:32 AM 8/30/2002 -0400, Tony Capel wrote:
>Russ:
>
>I understand your concern.  I had hoped to dodge this by recognizing
>that this decision is very instance-specific, i.e. dependant upon what
>the end user is using the signed message for.  But from the poor
>programmer-of-messaging-software perspective she needs to know NOW what
>to do for all future end user applications.
>
>So maybe some guidance along the following line might be what is needed
>(the first two of which are obvious):
>
>1. Always compress before encrypt.
>2. Always compress before sign if using a lossy or other non-fully
>reversible algorithm.
>3. In all other cases sign before compress if not instructed otherwise,
>and provide a local (implementation specific) means for the user to
>specify the other order.
>
>The rationale for selecting signing first if the user does not specify
>otherwise is based on the assumption that this will most often satisfy
>the most stringent user signing policy (it will be wrong least often!).
>However, implementations should permit the local configuration of this
>based on user operational or other policies.
>
>As far as getting into a discussion of why one way or another is
>"better", it is not clear to me that s/mime is the right place for that.
>This might be better treated in signature policy or other such
>documents.
>
>tony
>
> > -----Original Message-----
> > From: [e-mail]
>[mailto:[e-mail]]
> > On Behalf Of Housley, Russ
> > Sent: August 29, 2002 10:21 AM
> > To: Tony Capel
> > Cc: [e-mail]; [e-mail]; 'Peter Gutmann';
> > [e-mail]
> > Subject: RE: I-D ACTION:draft-ietf-smime-rfc2633bis-01.txt:
>CompressedData
> >
> >
> > Tony:
> >
> > I agree that the use of the compression algorithm identifier in S/MIME
> > Capabilities is the right approach.
> >
> > I think that we need to offer guidance in MSGbis for S/MIME
>applications
> > on
> > the order of operations.  Other applications that make use of CMS
>could
> > make different decisions, but MSGbis should set the conventions for
> > S/MIME.
> >
> > RFC 2634 describes the triple wrapper:
> >          sign-encrypt-sign.
> >
> > To maintain maximum capability with this specification, we have two
> > choices:
> >          sign-compress-encrypt-sign; or
> >          compress-sign-encrypt-sign
> >
> > In support of the sign-what-you-say concept, I prefer
> > sign-compress-encrypt-sign.
> >
> > Russ
> >
> >
> > At 10:30 AM 8/28/2002 -0400, Tony Capel wrote:
> > >Blake:
> > >
> > >I wonder if we could not close off the "CompressedData" discussion
> > >simply by adding a few word (e.g. "...and compression, see RFC3274" )
> > >reference to RFC3274, Peter's compression rfc, to Section 2.5.2 of
>MSG
> > >(and adding RFC3274 to the list of references)?
> > >
> > >If 2.5.2 is updated to address the preferBinaryInside issue maybe now
>is
> > >the time to do both (especially since both are aimed at reducing
> > >messaging overhead).
> > >
> > >CompressedData use is listed as an outstanding issue for MSG in the
> > >recent IETF WG meeting minutes:
> > >http://www.imc.org/ietf-smime/mail-archive/msg01339.html
> > >
> > >It has also been raised in three threads on this list:
> > >http://www.imc.org/ietf-smime/mail-archive/msg01295.html
> > >http://www.imc.org/ietf-smime/mail-archive/msg01172.html
> > >http://www.imc.org/ietf-smime/mail-archive/msg01241.html
> > >
> > >With respect to the order of compression and signing:  For receivers
>it
> > >has been pointed out that the encoding unambiguously indicates the
>order
> > >upon receipt.  Thus it would appear that no new mechanism is required
>to
> > >ensure interoperability (providing the receiver can process the
>entities
> > >in either order, and I THINK this what is implied by the current
>text).
> > >
> > >With respect to whether the sender should sign or compress first:
>Some
> > >applications will prefer signing first (sign-what-you-say, e.g. to
>meet
> > >EU or other "directives" interpreted to require signing before
> > >compression) and others will prefer compression first (signing the
> > >compressed version, e.g. for processing efficiency or as would be
> > >required if lossy compression were to be used). I suggest we dodge
>this
> > >bullet by arguing that this is an application issue best left to
> > >mechanisms (if needed) outside s/mime.
> > >
> > >Adding a reference to RFC3274 would emphasize RFC3274's use of
> > >corresponding compression algorithm OID(s) as an sMIMECapability to
> > >specify receiver compression capabilities.  Hopefully this will
>promote
> > >the implementation of compression which will reduce message overheads
> > >benefiting mail system operators and users accessing e-mail over low
> > >bandwidth channels.
> > >
> > >tony
> > >
> > > > -----Original Message-----
> > > > From: [e-mail]
> > >[mailto:[e-mail]]
> > > > On Behalf Of Tony Capel
> > > > Sent: July 9, 2002 10:24 AM
> > > > To: 'Peter Gutmann'; [e-mail];
> > > > [e-mail]; [e-mail];
>[e-mail]
> > > > Subject: RE: I-D ACTION:draft-ietf-smime-rfc2633bis-01.txt
> > > >
> > > >
> > > > Peter,
> > > >
> > > > many of us like your compression addition and would like it widely
>(if
> > > > not ubiquitously!) implemented.
> > > >
> > > > One perceived barrier to the adoption of s/mime is the expansion
>of
> > > > message size due to the repeated application of transfer (base64)
> > > > encoding at each wrap.  Messaging system operators become alarmed
>when
> > > > told message sizes may more than double as a result.  (Indeed the
>NIST
> > > > draft profile depreciates such coding of inner wraps to address
>this
> > > > issue.)
> > > >
> > > > The ability to offer compression also addresses overall message
> > > > expansion and will be an important capability to offer in
>compensation
> > > > when "marketing" the adoption of s/mime by large organizations.
> > > >
> > > >
> > > > Tony Capel
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: [e-mail]
> > > > [mailto:[e-mail]] On Behalf Of Peter Gutmann
> > > > Sent: July 9, 2002 4:49 AM
> > > > To: [e-mail]; [e-mail];
> > > > [e-mail]; [e-mail]
> > > > Subject: Re: I-D ACTION:draft-ietf-smime-rfc2633bis-01.txt
> > > >
> > > >
> > > > "Blake Ramsdell" <[e-mail]> writes:
> > > >
> > > > >I didn't see much uptake on this besides Russ saying "MAY", and
>I'm
> > > > worried
> > > > >about compatibility.  I will put a slide in my presentation about
> > >this
> > > > for
> > > > >Yokohama.
> > > >
> > > > AFAIK the major use at the moment is in EDI environments (large,
> > >highly-
> > > > compressible messages, and everything is "by prior arrangement"
> > >anyway).
> > > > There
> > > > are a couple of apps which support it out there though, so having
>it
> > > > mentioned
> > > > would be nice just to let implementers know it's there.
> > > >
> > > > Peter.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g7UEWdk07169 for ietf-smime-bks; Fri, 30 Aug 2002 07:32:39 -0700 (PDT)
Received: from mx2.magma.ca (mx2.magma.ca [206.191.0.250]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7UEWb207165 for <[e-mail]>; Fri, 30 Aug 2002 07:32:38 -0700 (PDT)
Received: from mail6.magma.ca (mail6.magma.ca [206.191.0.248]) by mx2.magma.ca (Magma Relay Server) with ESMTP id g7UEWYq9014447;  Fri, 30 Aug 2002 10:32:34 -0400
Received: from tony (ottawa-hs-209-217-122-183.s-ip.magma.ca [209.217.122.183]) by mail6.magma.ca (Magma's Mail Server) with ESMTP id g7UEWORb021101; Fri, 30 Aug 2002 10:32:33 -0400 (EDT)
From: "Tony Capel" <[e-mail]>
To: "'Housley, Russ'" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, "'Peter Gutmann'" <[e-mail]>, <[e-mail]>
Subject: RE: I-D ACTION:draft-ietf-smime-rfc2633bis-01.txt:   CompressedData
Date: Fri, 30 Aug 2002 10:32:48 -0400
Message-ID: <000601c25032$20bd50e0$01b5a8c0@tony>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
In-Reply-To: <[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Russ:

I understand your concern.  I had hoped to dodge this by recognizing
that this decision is very instance-specific, i.e. dependant upon what
the end user is using the signed message for.  But from the poor
programmer-of-messaging-software perspective she needs to know NOW what
to do for all future end user applications. 

So maybe some guidance along the following line might be what is needed
(the first two of which are obvious):

1. Always compress before encrypt.
2. Always compress before sign if using a lossy or other non-fully
reversible algorithm.
3. In all other cases sign before compress if not instructed otherwise,
and provide a local (implementation specific) means for the user to
specify the other order.

The rationale for selecting signing first if the user does not specify
otherwise is based on the assumption that this will most often satisfy
the most stringent user signing policy (it will be wrong least often!).
However, implementations should permit the local configuration of this
based on user operational or other policies.

As far as getting into a discussion of why one way or another is
"better", it is not clear to me that s/mime is the right place for that.
This might be better treated in signature policy or other such
documents.

tony

> -----Original Message-----
> From: [e-mail]
[mailto:[e-mail]]
> On Behalf Of Housley, Russ
> Sent: August 29, 2002 10:21 AM
> To: Tony Capel
> Cc: [e-mail]; [e-mail]; 'Peter Gutmann';
> [e-mail]
> Subject: RE: I-D ACTION:draft-ietf-smime-rfc2633bis-01.txt:
CompressedData
> 
> 
> Tony:
> 
> I agree that the use of the compression algorithm identifier in S/MIME
> Capabilities is the right approach.
> 
> I think that we need to offer guidance in MSGbis for S/MIME
applications
> on
> the order of operations.  Other applications that make use of CMS
could
> make different decisions, but MSGbis should set the conventions for
> S/MIME.
> 
> RFC 2634 describes the triple wrapper:
>          sign-encrypt-sign.
> 
> To maintain maximum capability with this specification, we have two
> choices:
>          sign-compress-encrypt-sign; or
>          compress-sign-encrypt-sign
> 
> In support of the sign-what-you-say concept, I prefer
> sign-compress-encrypt-sign.
> 
> Russ
> 
> 
> At 10:30 AM 8/28/2002 -0400, Tony Capel wrote:
> >Blake:
> >
> >I wonder if we could not close off the "CompressedData" discussion
> >simply by adding a few word (e.g. "...and compression, see RFC3274" )
> >reference to RFC3274, Peter's compression rfc, to Section 2.5.2 of
MSG
> >(and adding RFC3274 to the list of references)?
> >
> >If 2.5.2 is updated to address the preferBinaryInside issue maybe now
is
> >the time to do both (especially since both are aimed at reducing
> >messaging overhead).
> >
> >CompressedData use is listed as an outstanding issue for MSG in the
> >recent IETF WG meeting minutes:
> >http://www.imc.org/ietf-smime/mail-archive/msg01339.html
> >
> >It has also been raised in three threads on this list:
> >http://www.imc.org/ietf-smime/mail-archive/msg01295.html
> >http://www.imc.org/ietf-smime/mail-archive/msg01172.html
> >http://www.imc.org/ietf-smime/mail-archive/msg01241.html
> >
> >With respect to the order of compression and signing:  For receivers
it
> >has been pointed out that the encoding unambiguously indicates the
order
> >upon receipt.  Thus it would appear that no new mechanism is required
to
> >ensure interoperability (providing the receiver can process the
entities
> >in either order, and I THINK this what is implied by the current
text).
> >
> >With respect to whether the sender should sign or compress first:
Some
> >applications will prefer signing first (sign-what-you-say, e.g. to
meet
> >EU or other "directives" interpreted to require signing before
> >compression) and others will prefer compression first (signing the
> >compressed version, e.g. for processing efficiency or as would be
> >required if lossy compression were to be used). I suggest we dodge
this
> >bullet by arguing that this is an application issue best left to
> >mechanisms (if needed) outside s/mime.
> >
> >Adding a reference to RFC3274 would emphasize RFC3274's use of
> >corresponding compression algorithm OID(s) as an sMIMECapability to
> >specify receiver compression capabilities.  Hopefully this will
promote
> >the implementation of compression which will reduce message overheads
> >benefiting mail system operators and users accessing e-mail over low
> >bandwidth channels.
> >
> >tony
> >
> > > -----Original Message-----
> > > From: [e-mail]
> >[mailto:[e-mail]]
> > > On Behalf Of Tony Capel
> > > Sent: July 9, 2002 10:24 AM
> > > To: 'Peter Gutmann'; [e-mail];
> > > [e-mail]; [e-mail];
[e-mail]
> > > Subject: RE: I-D ACTION:draft-ietf-smime-rfc2633bis-01.txt
> > >
> > >
> > > Peter,
> > >
> > > many of us like your compression addition and would like it widely
(if
> > > not ubiquitously!) implemented.
> > >
> > > One perceived barrier to the adoption of s/mime is the expansion
of
> > > message size due to the repeated application of transfer (base64)
> > > encoding at each wrap.  Messaging system operators become alarmed
when
> > > told message sizes may more than double as a result.  (Indeed the
NIST
> > > draft profile depreciates such coding of inner wraps to address
this
> > > issue.)
> > >
> > > The ability to offer compression also addresses overall message
> > > expansion and will be an important capability to offer in
compensation
> > > when "marketing" the adoption of s/mime by large organizations.
> > >
> > >
> > > Tony Capel
> > >
> > >
> > > -----Original Message-----
> > > From: [e-mail]
> > > [mailto:[e-mail]] On Behalf Of Peter Gutmann
> > > Sent: July 9, 2002 4:49 AM
> > > To: [e-mail]; [e-mail];
> > > [e-mail]; [e-mail]
> > > Subject: Re: I-D ACTION:draft-ietf-smime-rfc2633bis-01.txt
> > >
> > >
> > > "Blake Ramsdell" <[e-mail]> writes:
> > >
> > > >I didn't see much uptake on this besides Russ saying "MAY", and
I'm
> > > worried
> > > >about compatibility.  I will put a slide in my presentation about
> >this
> > > for
> > > >Yokohama.
> > >
> > > AFAIK the major use at the moment is in EDI environments (large,
> >highly-
> > > compressible messages, and everything is "by prior arrangement"
> >anyway).
> > > There
> > > are a couple of apps which support it out there though, so having
it
> > > mentioned
> > > would be nice just to let implementers know it's there.
> > >
> > > Peter.




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g7U2htO29241 for ietf-smime-bks; Thu, 29 Aug 2002 19:43:55 -0700 (PDT)
Received: from brutesquadlabs.com (gtec136-m.isomedia.com [207.115.67.136] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7U2hs229237 for <[e-mail]>; Thu, 29 Aug 2002 19:43:55 -0700 (PDT)
Received: from DEXTER ([192.168.0.7]) by brutesquadlabs.com with SMTP ; Thu, 29 Aug 2002 19:43:45 -0700
Message-ID: <01c001c24fcf$0fa0b490$[e-mail]>
From: "Blake Ramsdell" <[e-mail]>
To: "David P. Kemp" <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: RFC 2632bis: Using Distinguished Names for Internet Mail
Date: Thu, 29 Aug 2002 19:43:45 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g7U2ht229238
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

----- Original Message ----- 
From: "David P. Kemp" <[e-mail]>
To: <[e-mail]>
Sent: Wednesday, August 28, 2002 3:25 PM
Subject: RFC 2632bis: Using Distinguished Names for Internet Mail


> However, in communications with our PKI development organization,
> one large user agent developer has quoted other sentences from
> RFC 2632 out of context to claim that V3 user agents must refuse
> to accept certificates that do not contain rfc822 addresses.
> In order to avoid such misinterpretation,  RFC 2632bis could use
> a little explicit, though perhaps redundant, clarification.

I will review these changes.  Since I am firmly of the belief that there exist useful certificates in the universe without an email address in them, I'm all for it ;).

Blake



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g7TMJ1K14642 for ietf-smime-bks; Thu, 29 Aug 2002 15:19:01 -0700 (PDT)
Received: from vulcan.rsasecurity.com (mail.rsasecurity.com [204.167.114.123]) by above.proper.com (8.11.6/8.11.3) with SMTP id g7TMIx214633 for <[e-mail]>; Thu, 29 Aug 2002 15:18:59 -0700 (PDT)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 29 Aug 2002 22:19:02 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id SAA29530; Thu, 29 Aug 2002 18:18:57 -0400 (EDT)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.10.2) with ESMTP id g7TMGcL08893; Thu, 29 Aug 2002 18:16:38 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <3TPVN078>; Thu, 29 Aug 2002 18:18:46 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.9.10]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3TPVN07Z; Thu, 29 Aug 2002 18:18:44 -0400
From: "Housley, Russ" <[e-mail]>
To: Tony Capel <[e-mail]>
Cc: [e-mail], [e-mail], "'Peter Gutmann'" <[e-mail]>, [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 29 Aug 2002 10:21:22 -0400
Subject: RE: I-D ACTION:draft-ietf-smime-rfc2633bis-01.txt:  CompressedData
In-Reply-To: <001601c24e9f$785d9240$01b5a8c0@tony>
References: <002101c22754$361d6f30$01b5a8c0@tony>
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>

Tony:

I agree that the use of the compression algorithm identifier in S/MIME 
Capabilities is the right approach.

I think that we need to offer guidance in MSGbis for S/MIME applications on 
the order of operations.  Other applications that make use of CMS could 
make different decisions, but MSGbis should set the conventions for S/MIME.

RFC 2634 describes the triple wrapper:
         sign-encrypt-sign.

To maintain maximum capability with this specification, we have two choices:
         sign-compress-encrypt-sign; or
         compress-sign-encrypt-sign

In support of the sign-what-you-say concept, I prefer 
sign-compress-encrypt-sign.

Russ


At 10:30 AM 8/28/2002 -0400, Tony Capel wrote:
>Blake:
>
>I wonder if we could not close off the "CompressedData" discussion
>simply by adding a few word (e.g. "...and compression, see RFC3274" )
>reference to RFC3274, Peter's compression rfc, to Section 2.5.2 of MSG
>(and adding RFC3274 to the list of references)?
>
>If 2.5.2 is updated to address the preferBinaryInside issue maybe now is
>the time to do both (especially since both are aimed at reducing
>messaging overhead).
>
>CompressedData use is listed as an outstanding issue for MSG in the
>recent IETF WG meeting minutes:
>http://www.imc.org/ietf-smime/mail-archive/msg01339.html
>
>It has also been raised in three threads on this list:
>http://www.imc.org/ietf-smime/mail-archive/msg01295.html
>http://www.imc.org/ietf-smime/mail-archive/msg01172.html
>http://www.imc.org/ietf-smime/mail-archive/msg01241.html
>
>With respect to the order of compression and signing:  For receivers it
>has been pointed out that the encoding unambiguously indicates the order
>upon receipt.  Thus it would appear that no new mechanism is required to
>ensure interoperability (providing the receiver can process the entities
>in either order, and I THINK this what is implied by the current text).
>
>With respect to whether the sender should sign or compress first:  Some
>applications will prefer signing first (sign-what-you-say, e.g. to meet
>EU or other "directives" interpreted to require signing before
>compression) and others will prefer compression first (signing the
>compressed version, e.g. for processing efficiency or as would be
>required if lossy compression were to be used). I suggest we dodge this
>bullet by arguing that this is an application issue best left to
>mechanisms (if needed) outside s/mime.
>
>Adding a reference to RFC3274 would emphasize RFC3274's use of
>corresponding compression algorithm OID(s) as an sMIMECapability to
>specify receiver compression capabilities.  Hopefully this will promote
>the implementation of compression which will reduce message overheads
>benefiting mail system operators and users accessing e-mail over low
>bandwidth channels.
>
>tony
>
> > -----Original Message-----
> > From: [e-mail]
>[mailto:[e-mail]]
> > On Behalf Of Tony Capel
> > Sent: July 9, 2002 10:24 AM
> > To: 'Peter Gutmann'; [e-mail];
> > [e-mail]; [e-mail]; [e-mail]
> > Subject: RE: I-D ACTION:draft-ietf-smime-rfc2633bis-01.txt
> >
> >
> > Peter,
> >
> > many of us like your compression addition and would like it widely (if
> > not ubiquitously!) implemented.
> >
> > One perceived barrier to the adoption of s/mime is the expansion of
> > message size due to the repeated application of transfer (base64)
> > encoding at each wrap.  Messaging system operators become alarmed when
> > told message sizes may more than double as a result.  (Indeed the NIST
> > draft profile depreciates such coding of inner wraps to address this
> > issue.)
> >
> > The ability to offer compression also addresses overall message
> > expansion and will be an important capability to offer in compensation
> > when "marketing" the adoption of s/mime by large organizations.
> >
> >
> > Tony Capel
> >
> >
> > -----Original Message-----
> > From: [e-mail]
> > [mailto:[e-mail]] On Behalf Of Peter Gutmann
> > Sent: July 9, 2002 4:49 AM
> > To: [e-mail]; [e-mail];
> > [e-mail]; [e-mail]
> > Subject: Re: I-D ACTION:draft-ietf-smime-rfc2633bis-01.txt
> >
> >
> > "Blake Ramsdell" <[e-mail]> writes:
> >
> > >I didn't see much uptake on this besides Russ saying "MAY", and I'm
> > worried
> > >about compatibility.  I will put a slide in my presentation about
>this
> > for
> > >Yokohama.
> >
> > AFAIK the major use at the moment is in EDI environments (large,
>highly-
> > compressible messages, and everything is "by prior arrangement"
>anyway).
> > There
> > are a couple of apps which support it out there though, so having it
> > mentioned
> > would be nice just to let implementers know it's there.
> >
> > Peter.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g7SMT7D09739 for ietf-smime-bks; Wed, 28 Aug 2002 15:29:07 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7SMT6209734 for <[e-mail]>; Wed, 28 Aug 2002 15:29:06 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id g7SMTXT23125 for <[e-mail]>; Wed, 28 Aug 2002 18:29:33 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Wed, 28 Aug 2002 18:25:09 -0400
From: "David P. Kemp" <[e-mail]>
X-Mailer: Mozilla 4.79 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: RFC 2632bis: Using Distinguished Names for Internet Mail
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-H-S-Loop-Check-Ejzfr: 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Blake,

Section 3 ("Using Distinguished Names for Internet Mail") of the
Certificate Handling I-D (2632bis draft -01) is unchanged from RFC2632
(except for inclusion of the PKCS #9 email attribute).

It should be obvious that the WG made a conscious and deliberate
decision to change the handling of rfc822 email addresses between
S/MIME V2 and V3:

    RFC 2312 (S/MIME V2) says: "End-entity certificates MUST
    contain an Internet mail address ..."

    RFC 2632 (S/MIME V3) says: "End-entity certificates MAY
    contain an Internet mail address ..." and "Receiving agents
    MUST check that the address ... matches ... if mail addresses
    are present in the certificate."

However, in communications with our PKI development organization,
one large user agent developer has quoted other sentences from
RFC 2632 out of context to claim that V3 user agents must refuse
to accept certificates that do not contain rfc822 addresses.
In order to avoid such misinterpretation,  RFC 2632bis could use
a little explicit, though perhaps redundant, clarification.

Four suggested additions to sections 3 and 5 are shown below,
highlighted *** thus ***:


---------------------------------------------------------------------

3. Using Distinguished Names for Internet Mail

End-entity certificates MAY contain an Internet mail address as
described in [RFC-2822]. The address must be an "addr-spec" as defined
in Section 3.4.1 of that specification. The email address SHOULD be in
the subjectAltName extension, and SHOULD NOT be in the subject
distinguished name.

*** Receiving agents MUST recognize and accept certificates that
contain no email address. ***
Receiving agents MUST recognize email addresses in the subjectAltName
field. Receiving agents MUST recognize email addresses in the
Distinguished Name field in the PKCS #9 [PKCS9] emailAddress
attribute:

pkcs-9-at-emailAddress OBJECT IDENTIFIER ::=
  {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 1 }

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


---------------------------------------------------------------------


5. Security Considerations

All of the security issues faced by any cryptographic application must
be faced by a S/MIME agent. Among these issues are protecting the
user's private key, preventing various attacks, and helping the user
avoid mistakes such as inadvertently encrypting a message for the
wrong recipient. The entire list of security considerations is beyond
the scope of this document, but some significant concerns are listed
here.

When processing certificates, there are many situations where the
processing might fail. Because the processing may be done by a user
agent, a security gateway, or other program, there is no single way to
handle such failures. Just because the methods to handle the failures
has not been listed, however, the reader should not assume that they
are not important. The opposite is true: if a certificate is not
provably valid and associated with the message, the processing
software should take immediate and noticable steps to inform the end
user about it.

Some of the many places where signature and certificate checking might
fail include:

- no Internet mail addresses in a certificate matches the sender of a
  message *** ,if the certificate contains at least one mail address ***
- no certificate chain leads to a trusted CA
- no ability to check the CRL for a certificate
- an invalid CRL was received
- the CRL being checked is expired
- the certificate is expired
- the certificate has been revoked

There are certainly other instances where a certificate may be
invalid, and it is the responsibility of the processing software to
check them all thoroughly, and to decide what to do if the check
fails.

---------------------------------------------------------------------


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g7SEUQR09094 for ietf-smime-bks; Wed, 28 Aug 2002 07:30:26 -0700 (PDT)
Received: from mx1.magmacom.com (mx1.magmacom.com [206.191.0.217]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7SEUP209088 for <[e-mail]>; Wed, 28 Aug 2002 07:30:25 -0700 (PDT)
Received: from mail5.magma.ca (mail5.magma.ca [206.191.0.225]) by mx1.magmacom.com (Magma's Mail Server) with ESMTP id g7SEUErK016675; Wed, 28 Aug 2002 10:30:14 -0400 (EDT)
Received: from tony (ottawa-hs-209-217-122-183.s-ip.magma.ca [209.217.122.183]) by mail5.magma.ca (Magma's Mail Server) with ESMTP id g7SEU461019092; Wed, 28 Aug 2002 10:30:13 -0400 (EDT)
From: "Tony Capel" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Cc: "'Peter Gutmann'" <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: RE: I-D ACTION:draft-ietf-smime-rfc2633bis-01.txt:  CompressedData
Date: Wed, 28 Aug 2002 10:30:28 -0400
Message-ID: <001601c24e9f$785d9240$01b5a8c0@tony>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
In-Reply-To: <002101c22754$361d6f30$01b5a8c0@tony>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Blake:

I wonder if we could not close off the "CompressedData" discussion
simply by adding a few word (e.g. "...and compression, see RFC3274" )
reference to RFC3274, Peter's compression rfc, to Section 2.5.2 of MSG
(and adding RFC3274 to the list of references)?

If 2.5.2 is updated to address the preferBinaryInside issue maybe now is
the time to do both (especially since both are aimed at reducing
messaging overhead).

CompressedData use is listed as an outstanding issue for MSG in the
recent IETF WG meeting minutes:
http://www.imc.org/ietf-smime/mail-archive/msg01339.html

It has also been raised in three threads on this list:
http://www.imc.org/ietf-smime/mail-archive/msg01295.html
http://www.imc.org/ietf-smime/mail-archive/msg01172.html
http://www.imc.org/ietf-smime/mail-archive/msg01241.html

With respect to the order of compression and signing:  For receivers it
has been pointed out that the encoding unambiguously indicates the order
upon receipt.  Thus it would appear that no new mechanism is required to
ensure interoperability (providing the receiver can process the entities
in either order, and I THINK this what is implied by the current text).

With respect to whether the sender should sign or compress first:  Some
applications will prefer signing first (sign-what-you-say, e.g. to meet
EU or other "directives" interpreted to require signing before
compression) and others will prefer compression first (signing the
compressed version, e.g. for processing efficiency or as would be
required if lossy compression were to be used). I suggest we dodge this
bullet by arguing that this is an application issue best left to
mechanisms (if needed) outside s/mime.
  
Adding a reference to RFC3274 would emphasize RFC3274's use of
corresponding compression algorithm OID(s) as an sMIMECapability to
specify receiver compression capabilities.  Hopefully this will promote
the implementation of compression which will reduce message overheads
benefiting mail system operators and users accessing e-mail over low
bandwidth channels.

tony

> -----Original Message-----
> From: [e-mail]
[mailto:[e-mail]]
> On Behalf Of Tony Capel
> Sent: July 9, 2002 10:24 AM
> To: 'Peter Gutmann'; [e-mail];
> [e-mail]; [e-mail]; [e-mail]
> Subject: RE: I-D ACTION:draft-ietf-smime-rfc2633bis-01.txt
> 
> 
> Peter,
> 
> many of us like your compression addition and would like it widely (if
> not ubiquitously!) implemented.
> 
> One perceived barrier to the adoption of s/mime is the expansion of
> message size due to the repeated application of transfer (base64)
> encoding at each wrap.  Messaging system operators become alarmed when
> told message sizes may more than double as a result.  (Indeed the NIST
> draft profile depreciates such coding of inner wraps to address this
> issue.)
> 
> The ability to offer compression also addresses overall message
> expansion and will be an important capability to offer in compensation
> when "marketing" the adoption of s/mime by large organizations.
> 
> 
> Tony Capel
> 
> 
> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]] On Behalf Of Peter Gutmann
> Sent: July 9, 2002 4:49 AM
> To: [e-mail]; [e-mail];
> [e-mail]; [e-mail]
> Subject: Re: I-D ACTION:draft-ietf-smime-rfc2633bis-01.txt
> 
> 
> "Blake Ramsdell" <[e-mail]> writes:
> 
> >I didn't see much uptake on this besides Russ saying "MAY", and I'm
> worried
> >about compatibility.  I will put a slide in my presentation about
this
> for
> >Yokohama.
> 
> AFAIK the major use at the moment is in EDI environments (large,
highly-
> compressible messages, and everything is "by prior arrangement"
anyway).
> There
> are a couple of apps which support it out there though, so having it
> mentioned
> would be nice just to let implementers know it's there.
> 
> Peter.





Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g7SDWHP04505 for ietf-smime-bks; Wed, 28 Aug 2002 06:32:17 -0700 (PDT)
Received: from tube.clearswift.com (tube.clearswift.com [195.153.60.158]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7SDWF204500; Wed, 28 Aug 2002 06:32:16 -0700 (PDT)
Received: from orange.net-tel.co.uk (orange.net-tel.co.uk [193.122.171.1]) by tube.clearswift.com (4.8.0.147) with ESMTP id ; Wed, 28 Aug 2002 14:26:30 +0100
Received: from "/PRMD=NET-TEL/ADMD=Gold 400/C=GB/" by orange.net-tel.co.uk (Route400-RFCGate); Wed, 28 Aug 2002 14:38:56 +0100
X400-Received: by mta "net-tel" in "/PRMD=net-tel/ADMD=gold 400/C=gb/";  Relayed; Wed, 28 Aug 2002 14:38:56 +0100
X400-Received: by "/PRMD=NET-TEL/ADMD=Gold 400/C=GB/"; Relayed;  Wed, 28 Aug 2002 14:38:56 +0100
X400-MTS-Identifier:  ["/PRMD=NET-TEL/ADMD=Gold 400/C=GB/";ORANGE:0054-020828143856-09af]
X400-Content-Type: P2-1988 (22)
X400-Originator: [e-mail]
Original-Encoded-Information-Types:  IA5-Text, (2)(6)(1)(12)(0), (1)(2)(840)(113556)(3)(10)(1)
X400-Recipients: non-disclosure:;
Date: Wed, 28 Aug 2002 14:38:56 +0100
X400-Content-Identifier: Re(2): CMS-X.400
Message-Id: <"CASQUETS:0e2c-020828142828-0002*/G=Jim/S=Craigie/O=Net-Tel Computer Systems Ltd/PRMD=Net-Tel/ADMD=Gold 400/C=GB/"@MHS>
From: [e-mail]
To: [e-mail]
Cc: "'SMIME, IETF'" <[e-mail]>
In-Reply-To: <[e-mail]>
Subject: Re(2): CMS-X.400: [application/x400-content] versus [application/x40 0-bp]
MIME-Version: 1.0 (Generated by Clearswift ES version 4.8.0.147)
Content-Type: Multipart/Mixed;         boundary="ECASQUETS:0e2c-020828142828-0002s/G=Jim.b0ndr1y.nested_0"
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>

--ECASQUETS:0e2c-020828142828-0002s/G=Jim.b0ndr1y.nested_0
Content-Type: text/plain;charset=us-ascii
Content-Transfer-Encoding: 7bit

> Did you mean to say "bodypart" rather than "content" at the end of 
> your sentence:
> > Conveying a content within a ForwardedContent body-part clearly 
> > has a different semantic to conveying a content.

No, I meant content. The purpose of application/x400-content is to convey the complete content as extracted from an X.400 envelope.

Jim




-----------------------------------------------------------------------

Clearswift monitors, controls and protects all its messaging traffic in compliance with its 
corporate email policy using Clearswift products. Find out more about Clearswift, its 
solutions and services at http://www.clearswift.com

********************************************************************************************************
This communication is confidential and may contain privileged information intended solely 
for the named addressee(s). It may not be used or disclosed except for the purpose for 
which it has been sent. If you are not the intended recipient, you must not copy, distribute 
or take any action in reliance on it. Unless expressly stated, opinions in this message are 
those of the individual sender and not of Clearswift. If you have received this communication
in error, please notify Clearswift by emailing [e-mail] quoting the sender and
delete the message and any attached documents. Clearswift accepts no liability or 
responsibility for any onward transmission or use of emails and attachments having left the 
Clearswift domain.

--ECASQUETS:0e2c-020828142828-0002s/G=Jim.b0ndr1y.nested_0
Content-type: application/ms-tnef
Content-Description: MAPI 1.0 TNEF
Content-Disposition: attachment;filename="WINMAIL.DAT";
        modification-date="Wed, 28 Aug 2002 14:28:28 +0100";size=1102
Content-Transfer-Encoding: base64

eJ8+Inb3AQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy
b3NvZnQgTWFpbC5Ob3RlADEIASCAAwAOAAAA0gcIABwADgAKABoAAwAyAQEAgAAAcAAAAAQAcAAM
AFQASmltIENyYWlnaWUAWDQwMDpHPUppbTsgUz1DcmFpZ2llOyBPPU5ldC1UZWwgQ29tcHV0ZXIg
U3lzdGVtcyBMdGQ7IFA9TmV0LVRlbDsgQT1Hb2xkIDQwMDsgQz1HQjsAAAAAAAAAAABvHgEDkAYA
ZAMAABAAAABAAAgwMMdrRpROwgECAQkQAQAAAJwBAACYAQAAPAIAAExaRnWG/uAdAwAKAHJjcGcx
MjUWMgD4C2BuDhAwMzOPAfcCpAPjAgBwcnEOUAhmY2gKwHNldDDnBdAN4ANgc28BgAYJAoCmfQqA
CMggOwlvMAKAJQqBdgiQd2sLgGQ0bQxgYwBQCwNjAEELtSCAPiBEaWQgeQhgBiAHgAORdG8gc2FI
eSAiBuBkeQqxdMAiIHJhdGgEkBhg+xFQA6AiBaACMAnwGWEZoPkZ8WUgCfAXwBIwCuMKgB8XgBfh
BcARgBqCY2U6hxvWF4AIUG52ZXkLgOpnGuAgGmUgA/AZsAuA9R5hRgWwdwsRCYAd0R7DLRjyLRky
HoBsGDBybF8YwB04EVAEIB5wZAaQZu8EkB7SEYADgXQN4BhiGmENHg4uG9Qb1E5vLCBOSRgTITEl
BSBUGzFwnQhwcBIQG0AboWFwC1ALDeAZoGkCIC94NDB8MC0elgQAI/gbEwWgbR8LUBGQKvIetCKB
ZXh0fRmQYxqQF8ADUhrgA6BYni4pQRtRHgAJAHBlJWteSgdwJXob1BMxADCwHgBwAAEAAABLAAAA
UmUoMik6IENNUy1YLjQwMDogW2FwcGxpY2F0aW9uL3g0MDAtY29udGVudF0gdmVyc3VzIFthcHBs
aWNhdGlvbi94NDAgMC1icF0AAAIBcQABAAAAFgAAAAHCTpbKQedfjYlIXEGTs1D4V1WOYPAAAAsA
KQAAAAAAAwCkUQAAAAADAPB7AAAAAAsACAwBAAAACwA1AAAAAAALAAYMAAAAEAsAIwAAAAAAHgA9
AAEAAAABAAAAAAAAAB4AGgwBAAAADAAAAEppbSBDcmFpZ2llAAIBHQwBAAAAVAAAAFg0MDA6Rz1K
SU07IFM9Q1JBSUdJRTsgTz1ORVQtVEVMIENPTVBVVEVSIFNZU1RFTVMgTFREOyBQPU5FVC1URUw7
IEE9R09MRCA0MDA7IEM9R0I7AB4AHgwBAAAABQAAAFg0MDAAAAAAHgAfDAEAAABPAAAARz1KaW07
IFM9Q3JhaWdpZTsgTz1OZXQtVGVsIENvbXB1dGVyIFN5c3RlbXMgTHRkOyBQPU5ldC1UZWw7IEE9
R29sZCA0MDA7IEM9R0I7AABb4A==

--ECASQUETS:0e2c-020828142828-0002s/G=Jim.b0ndr1y.nested_0--



Received: by above.proper.com (8.11.6/8.11.3) id g7SD5sj01580 for ietf-smime-bks; Wed, 28 Aug 2002 06:05:54 -0700 (PDT)
Received: from ztxmail05.ztx.compaq.com (ztxmail05.ztx.compaq.com [161.114.1.209]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7SD5q201575 for <[e-mail]>; Wed, 28 Aug 2002 06:05:53 -0700 (PDT)
Received: from taynzmail03.nz-tay.cpqcorp.net (taynzmail03.nz-tay.cpqcorp.net [16.47.4.103]) by ztxmail05.ztx.compaq.com (Postfix) with ESMTP id F0BC43554 for <[e-mail]>; Wed, 28 Aug 2002 08:05:44 -0500 (CDT)
Received: from diexch01.xko.dec.com (diexch01.xko.dec.com [16.138.244.57]) by taynzmail03.nz-tay.cpqcorp.net (Postfix) with ESMTP id 7BBFD1914 for <[e-mail]>; Wed, 28 Aug 2002 09:05:42 -0400 (EDT)
Received: by diexch01.xko.dec.com with Internet Mail Service (5.5.2650.21) id <RSW25Q5P>; Wed, 28 Aug 2002 18:39:58 +0530
Message-ID: <[e-mail]>
From: "Muzumdar, Hari" <[e-mail]>
To: "'SMIME, IETF'" <[e-mail]>
Subject: RE: CMS-X.400: [application/x400-content] versus [application/x40 0-bp]
Date: Wed, 28 Aug 2002 18:39:56 +0530
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>

Many thanks for replying, Jim.

Did you mean to say "bodypart" rather than "content" at the end of 
your sentence:
> Conveying a content within a ForwardedContent body-part clearly 
> has a different semantic to conveying a content.


I thought the application/x400-bp had adequate MIME parameters and 
other framework to encapsulate any Basic or Extended X.400 bodypart. 
And a ForwardedContent is an Extended bodypart too.

o  The "x400-bp" subtype would not have lost any information and 
   would have preserved the ForwardedContent. 
o  The x400-bp's parameter would tell the receiving agent that an 
   Extended bodypart of type ForwardedContent had been encapsulated.
o  The receiving agent could then base64-decode this and invoke an
   X.400 content-identification routine, which would render the 
   Content if it could.

Or is there more to it all? Are there things I haven't considered? 

Best Regards,
		Hari.


-----Original Message-----
From: Jim Craigie On Behalf Of [e-mail]
Sent: Wednesday, August 28, 2002 5:45 PM
To: Muzumdar, Hari
Cc: 'SMIME, IETF'
Subject: Re: CMS-X.400: [application/x400-content] versus
  [application/x400-bp ]


> Hello,
> 
> There was some discussion early this year about the proposed new MIME 
> subtype "application/x400-content".
> 
> Have there been any further discussions and/or decisions on this topic? 
> 
> The mailing list contains only the initial few exchanges.
> 
> Was the application/x400-bp type (IANA-registered by RFC 1494) not 
> considered? At first glance, this does look like it could encapsulate 
> ForwardedContent. What were the reasons for proposing a new MIME type?

Conveying a content within a ForwardedContent body-part clearly has a
different semantic to conveying a content. Preserving that semantic is
usually important to both originator and recipients.

Jim



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g7SC8mu27027 for ietf-smime-bks; Wed, 28 Aug 2002 05:08:48 -0700 (PDT)
Received: from tube.clearswift.com (tube.clearswift.com [195.153.60.158]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7SC8k227023 for <[e-mail]>; Wed, 28 Aug 2002 05:08:47 -0700 (PDT)
Received: from orange.net-tel.co.uk (orange.net-tel.co.uk [193.122.171.1]) by tube.clearswift.com (4.8.0.147) with ESMTP id ; Wed, 28 Aug 2002 13:02:56 +0100
Received: from "/PRMD=NET-TEL/ADMD=Gold 400/C=GB/" by orange.net-tel.co.uk (Route400-RFCGate); Wed, 28 Aug 2002 13:15:20 +0100
X400-Received: by mta "net-tel" in "/PRMD=net-tel/ADMD=gold 400/C=gb/";  Relayed; Wed, 28 Aug 2002 13:15:20 +0100
X400-Received: by "/PRMD=NET-TEL/ADMD=Gold 400/C=GB/"; Relayed;  Wed, 28 Aug 2002 13:15:20 +0100
X400-MTS-Identifier:  ["/PRMD=NET-TEL/ADMD=Gold 400/C=GB/";ORANGE:0054-020828131520-09ac]
X400-Content-Type: P2-1988 (22)
X400-Originator: [e-mail]
Original-Encoded-Information-Types:  IA5-Text, (2)(6)(1)(12)(0), (1)(2)(840)(113556)(3)(10)(1)
X400-Recipients: non-disclosure:;
Date: Wed, 28 Aug 2002 13:15:20 +0100
X400-Content-Identifier: Re: CMS-X.400: a
Message-Id: <"CASQUETS:0e2c-020828130452-0001*/G=Jim/S=Craigie/O=Net-Tel Computer Systems Ltd/PRMD=Net-Tel/ADMD=Gold 400/C=GB/"@MHS>
From: [e-mail]
To: "Muzumdar, Hari" <[e-mail]>
Cc: "'SMIME, IETF'" <[e-mail]>
In-Reply-To: <[e-mail]>
Subject: Re: CMS-X.400: [application/x400-content] versus [application/x400-bp ]
MIME-Version: 1.0 (Generated by Clearswift ES version 4.8.0.147)
Content-Type: Multipart/Mixed;         boundary="ECASQUETS:0e2c-020828130452-0001s/G=Jim.b0ndr1y.nested_0"
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>

--ECASQUETS:0e2c-020828130452-0001s/G=Jim.b0ndr1y.nested_0
Content-Type: text/plain;charset=us-ascii
Content-Transfer-Encoding: 7bit

> Hello,
> 
> There was some discussion early this year about the proposed new MIME 
> subtype "application/x400-content".
> 
> Have there been any further discussions and/or decisions on this topic? 
> 
> The mailing list contains only the initial few exchanges.
> 
> Was the application/x400-bp type (IANA-registered by RFC 1494) not 
> considered? At first glance, this does look like it could encapsulate 
> ForwardedContent. What were the reasons for proposing a new MIME type?

Conveying a content within a ForwardedContent body-part clearly has a different semantic to conveying a content. Preserving that semantic is usually important to both originator and recipients.

Jim




-----------------------------------------------------------------------

Clearswift monitors, controls and protects all its messaging traffic in compliance with its 
corporate email policy using Clearswift products. Find out more about Clearswift, its 
solutions and services at http://www.clearswift.com

********************************************************************************************************
This communication is confidential and may contain privileged information intended solely 
for the named addressee(s). It may not be used or disclosed except for the purpose for 
which it has been sent. If you are not the intended recipient, you must not copy, distribute 
or take any action in reliance on it. Unless expressly stated, opinions in this message are 
those of the individual sender and not of Clearswift. If you have received this communication
in error, please notify Clearswift by emailing [e-mail] quoting the sender and
delete the message and any attached documents. Clearswift accepts no liability or 
responsibility for any onward transmission or use of emails and attachments having left the 
Clearswift domain.

--ECASQUETS:0e2c-020828130452-0001s/G=Jim.b0ndr1y.nested_0
Content-type: application/ms-tnef
Content-Description: MAPI 1.0 TNEF
Content-Disposition: attachment;filename="WINMAIL.DAT";
        modification-date="Wed, 28 Aug 2002 13:04:52 +0100";size=1358
Content-Transfer-Encoding: base64

eJ8+IlVsAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy
b3NvZnQgTWFpbC5Ob3RlADEIASCAAwAOAAAA0gcIABwADAA0ACYAAwBmAQEAgAAAcAAAAAQAcAAM
AFQASmltIENyYWlnaWUAWDQwMDpHPUppbTsgUz1DcmFpZ2llOyBPPU5ldC1UZWwgQ29tcHV0ZXIg
U3lzdGVtcyBMdGQ7IFA9TmV0LVRlbDsgQT1Hb2xkIDQwMDsgQz1HQjsAAAAAAAAAAABvHgEDkAYA
ZAQAABAAAABAAAgwUKouaIlOwgECAQkQAQAAAJkCAACVAgAAtAMAAExaRnUOz2SLAwAKAHJjcGcx
MjUWMgD4C2BuDhAwMzOPAfcCpAPjAgBwcnEOUAhmY2gKwHNldDDnBdAN4ANgc28BgAYJAoCmfQqA
CMggOwlvMAKAJQqBdgiQd2sLgGQ0bQxgYwBQCwNjAEELtSCgPiBIZWwJACwKoicKgBeAGAZUaASQ
ZSCcd2EEIBIgB4AgZAQAlGN1BBBpAiAgZQrAIGx5IHRoBAAgef0aoSABoAhgBUAbABlAEOBMb3AS
EAmAIG4H0U0ISU1FGHdzdWJ0xHlwGUAiYXALUA3gBGF0GmEveDQwMI4tBaACMAnwdCIuGA64SGF2
GUAcARkxYgnh9RuQbhrgZghwIWIZ6QQg+QBwZC8FsQWBBAAjQxpxbRsDdBxgDeA/GHcYiSCnAMAD
EAuAZyAeoHMFQL8fggtxJIIa0xlAC4BpHuDnB0AiQAfRZXgRQQ8gB5CdIA9XGXEcAh5/YnAa8IEe
IihJQU5BLRQwLmcnYRkhHLBiGuBSRoBDIDE0OTQpHMD+bwVBJaUfgQCQBIEJgCVwskEFQGZpEXAF
QGcPAchjZSwa9GRvB5EJADRvaydBayihJ4J1bPccsAnwHsBwHeALYB+wGHd+RgWwGWALIAmACFAf
oy73KxARUAVAdxkiHAIUMBlw3yNSAhAFwBxEJxJhHMgeEt4/JZQllDVBITB5N9QfhX8ZUCjgGxAh
8TSvIbAEcHn2LQqxJ4FsGqQRUCNxGeG/ASAZITrhEYADgR7gYyURtyeSOg41sFAUMBGAchWQvych
GwA18T7XGyEaMHUHQP8a0QdwHHAAID8BP1IG4BsA9ySQBRAtsG4e0AWxI5E2od8kICVAH8EqBiWU
SgdwORoLJZQTMQBIMAAAAB4AcAABAAAASAAAAFJlOiBDTVMtWC40MDA6IFthcHBsaWNhdGlvbi94
NDAwLWNvbnRlbnRdIHZlcnN1cyBbYXBwbGljYXRpb24veDQwMC1icCBdAAIBcQABAAAAFgAAAAHC
ToscE4fNGWrbY0+9s+zks9wByWgAAAsAKQAAAAAAAwCkUQAAAAADAPB7AAAAAAsACAwBAAAACwA1
AAAAAAALAAYMAAAAEAsAIwAAAAAAHgA9AAEAAAAFAAAAUmU6IAAAAAAeABoMAQAAAAwAAABKaW0g
Q3JhaWdpZQACAR0MAQAAAFQAAABYNDAwOkc9SklNOyBTPUNSQUlHSUU7IE89TkVULVRFTCBDT01Q
VVRFUiBTWVNURU1TIExURDsgUD1ORVQtVEVMOyBBPUdPTEQgNDAwOyBDPUdCOwAeAB4MAQAAAAUA
AABYNDAwAAAAAB4AHwwBAAAATwAAAEc9SmltOyBTPUNyYWlnaWU7IE89TmV0LVRlbCBDb21wdXRl
ciBTeXN0ZW1zIEx0ZDsgUD1OZXQtVGVsOyBBPUdvbGQgNDAwOyBDPUdCOwAATik=

--ECASQUETS:0e2c-020828130452-0001s/G=Jim.b0ndr1y.nested_0--



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g7S9bJJ13682 for ietf-smime-bks; Wed, 28 Aug 2002 02:37:19 -0700 (PDT)
Received: from zcamail05.zca.compaq.com (zcamail05.zca.compaq.com [161.114.32.105]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7S9bH213677 for <[e-mail]>; Wed, 28 Aug 2002 02:37:18 -0700 (PDT)
Received: from taynzmail03.nz-tay.cpqcorp.net (taynzmail03.nz-tay.cpqcorp.net [16.47.4.103]) by zcamail05.zca.compaq.com (Postfix) with ESMTP id 502624402 for <[e-mail]>; Wed, 28 Aug 2002 02:37:10 -0700 (PDT)
Received: from diexch01.xko.dec.com (diexch01.xko.dec.com [16.138.244.57]) by taynzmail03.nz-tay.cpqcorp.net (Postfix) with ESMTP id 20A581A96 for <[e-mail]>; Wed, 28 Aug 2002 05:37:07 -0400 (EDT)
Received: by diexch01.xko.dec.com with Internet Mail Service (5.5.2650.21) id <RSW25LCM>; Wed, 28 Aug 2002 15:11:23 +0530
Message-ID: <[e-mail]>
From: "Muzumdar, Hari" <[e-mail]>
To: "'SMIME, IETF'" <[e-mail]>
Subject: CMS-X.400: [application/x400-content] versus [application/x400-bp ]
Date: Wed, 28 Aug 2002 15:11:22 +0530
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>

Hello,

There was some discussion early this year about the proposed new MIME 
subtype "application/x400-content".

Have there been any further discussions and/or decisions on this topic? 
The mailing list contains only the initial few exchanges.

Was the application/x400-bp type (IANA-registered by RFC 1494) not 
considered? At first glance, this does look like it could encapsulate 
ForwardedContent. What were the reasons for proposing a new MIME type?

Best Regards,
		Hari.



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g7RNnHc06136 for ietf-smime-bks; Tue, 27 Aug 2002 16:49:17 -0700 (PDT)
Received: from [165.227.249.18] (165-227-249-20.client.dsl.net [165.227.249.20]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7RNcH205470; Tue, 27 Aug 2002 16:38:17 -0700 (PDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05111a48b991bcfec5f8@[165.227.249.18]>
Date: Tue, 27 Aug 2002 16:38:17 -0700
To: (many IETF mailing lists)
From: Paul Hoffman / IMC <[e-mail]>
Subject: Nomcom call for volunteers
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>

Forwarded for Phil Roberts <[e-mail]>:

The members of the IESG and IAB and the IETF chair are selected
by a nominations committee made up of volunteers from the
IETF community.  The nominations committee is now in the process
of being formed and volunteers are being accepted until Sep 6.
Please see (http://www.ietf.org/nomcom/msg19765.html)
for information if you are interested in volunteering
to be on the nominations committee.


Received: by above.proper.com (8.11.6/8.11.3) id g7RLWnT28903 for ietf-smime-bks; Tue, 27 Aug 2002 14:32:49 -0700 (PDT)
Received: from gonzo.aus.rsa.com (mail.rsasecurity.com.au [203.46.112.10]) by above.proper.com (8.11.6/8.11.3) with SMTP id g7RLWk228898 for <[e-mail]>; Tue, 27 Aug 2002 14:32:47 -0700 (PDT)
Received: from grover by gonzo.aus.rsa.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 27 Aug 2002 21:33:35 UT
Received: from exaus01.local.aus.rsa.com (exaus01.local.aus.rsa.com [10.177.1.15]) by grover.local.aus.rsa.com (8.10.2/8.10.2) with ESMTP id g7RLc5q21089 for <[e-mail]>; Wed, 28 Aug 2002 07:38:05 +1000 (EST)
Received: by exaus01.local.aus.rsa.com with Internet Mail Service (5.5.2653.19) id <QPRAFRCA>; Wed, 28 Aug 2002 07:32:53 +1000
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.9.25]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3TPVMYRP; Tue, 27 Aug 2002 17:32:24 -0400
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Tue, 27 Aug 2002 17:32:22 -0400
To: [e-mail]
From: "Housley, Russ" <[e-mail]>
Subject: Nomcom call for volunteers
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 members of the IESG and IAB and the IETF chair are selected
by a nominations committee made up of volunteers from the
IETF community.  The nominations committee is now in the process
of being formed and volunteers are being accepted until Sep 6.
Please see (http://www.ietf.org/nomcom/msg19765.html)
for information if you are interested in volunteering
to be on the nominations committee. 


Received: by above.proper.com (8.11.6/8.11.3) id g7L2a7U07778 for ietf-smime-bks; Tue, 20 Aug 2002 19:36:07 -0700 (PDT)
Received: from Obsidian (pcp01965971pcs.nrockv01.md.comcast.net [68.48.109.11]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7L2a5207774 for <[e-mail]>; Tue, 20 Aug 2002 19:36:05 -0700 (PDT)
Received: from [192.168.0.4] by Obsidian (ArGoSoft Mail Server, Version 1.61 (1.6.1.9)); Tue, 20 Aug 2002 22:36:07 -0400
From: "Bonatti, Chris" <[e-mail]>
To: "Sreeramulu, Diguvapalem" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Doubt in IETF draft, "Securing X.400 Content".
Date: Tue, 20 Aug 2002 22:36:05 -0400
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>

Sreeramulu.D,

  I don't think I am familiar with the class hierarchy to which you are
referring.  However, if I'm guessing correctly based on the names (always a
haphazard way to do business) it sounds like the OMP_O_MH_C_GENERAL_CONTENT
class would be appropriate.  I assume that OMP_O_IM_C_INTERPERSONAL_MSG and
OMP_O_MH_C_GENERAL_CONTENT are polymorphic class definitions that be used
interchangably when submitting a message to the MTS.

  Am I on the right track here?

Regards,
Chris B.


-----Original Message-----
From: [e-mail] [mailto:[e-mail]]On
Behalf Of Sreeramulu, Diguvapalem
Sent: Monday, August 12, 2002 01:22
To: '[e-mail]'
Subject: Doubt in IETF draft, "Securing X.400 Content".


Hi,
  This is Sreeramulu.D. working for Digital GlobalSoft Ltd, a subsidiary of
Hewlette-Packard co.,U.S.A. Currently we are working on sending s/mime
mssages in b/n Internet and X.400. This mail is regarding the IETF draft,
"Securing X.400 content". I have a scenario in which I have to send a
secured X.400 content to an internet user.  What is an OM_class (like
OMP_O_IM_C_INTERPERSONAL_MSG),to create a content object from? Or otherwise
can we put the protected X.400 content in an oject of an OM_class,
OMP_O_MH_C_GENERAL_CONTENT and send it across?

Hope you could understand my problem. Hoping an elaborated reply from you as
soon as possible.

Thanks&Regards,
  Sreeramulu.D
   Mailbus Engineering,
   Digital GlobalSoft Ltd.,
   INDIA.






Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g7JIr6x17238 for ietf-smime-bks; Mon, 19 Aug 2002 11:53:06 -0700 (PDT)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7JIr5n17234 for <[e-mail]>; Mon, 19 Aug 2002 11:53:05 -0700 (PDT)
Received: (from bcn@localhost) by boreas.isi.edu (8.11.6/8.11.2) id g7JIr7r25399; Mon, 19 Aug 2002 11:53:07 -0700 (PDT)
Date: Mon, 19 Aug 2002 11:53:07 -0700 (PDT)
Message-Id: <[e-mail]>
From: Clifford Neuman <[e-mail]>
To: [e-mail]
Subject: CFP - Symposium on Network & Distributed Systems Security
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 Internet Society's (ISOC) annual Symposium on Network and Distributed
System Security (NDSS) brings together innovative and forward thinking
members of the Internet community including leading-edge security
researchers and implementers, globally-recognized security-technology
experts, and users from both the private and public sectors who design,
develop, exploit, and deploy the technologies that define network and
distributed system security.

If you are working on new and practical approaches to security problems
that are endemic to network and distributed systems, we invite you to
participate in NDSS'03 by submitting one or more technical papers and/or
panel proposals.  Submission details may be found at:

  http://www.isoc.org/isoc/conferences/ndss/03/cfp.shtml

NDSS'03 will again be held for three days in San Diego, California in
February, 2003.  One day of tutorials will be followed by two days of
technical sessions including refereed papers, invited talks, and panel
discussions and debates.

Please be aware that the NDSS'03 cut off date for paper and panel
submission is August 30, 2002.

All accepted papers will be published in The NDSS Proceedings by the
Internet Society.  There will also be an Outstanding Paper Award presented
at the Symposium to the author(s).  Submitted papers should not have been
previously published or be submitted simultaneously to a journal or to
another symposium or workshop with a published proceedings.

Please consider joining us at NDSS'03.  We look forward to hearing from you!

Clifford Neuman, 
Information Sciences Institute, University of Southern California
General Chair, NDSS'03 

Virgil Gligor, University of Maryland
Michael Reiter, Carnegie Mellon University
Program Chairs,  NDSS'03 


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g7GD3RS12734 for ietf-smime-bks; Fri, 16 Aug 2002 06:03:27 -0700 (PDT)
Received: from vulcan.rsasecurity.com (mail.rsasecurity.com [204.167.114.123]) by above.proper.com (8.11.6/8.11.3) with SMTP id g7GD3Pw12730 for <[e-mail]>; Fri, 16 Aug 2002 06:03:26 -0700 (PDT)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 16 Aug 2002 13:03:27 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id JAA10299; Fri, 16 Aug 2002 09:03:24 -0400 (EDT)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.10.2) with ESMTP id g7GD1EC22921; Fri, 16 Aug 2002 09:01:14 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <3TPV2NTY>; Fri, 16 Aug 2002 09:03:23 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.9.18]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3TPV2NT4; Fri, 16 Aug 2002 09:03:17 -0400
From: "Housley, Russ" <[e-mail]>
To: Tony Capel <[e-mail]>
Cc: [e-mail], "'Blake Ramsdell'" <[e-mail]>
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Fri, 16 Aug 2002 09:03:03 -0400
Subject: Re: Inner Binary Encoding in MSG, RFC2633-bis-01
In-Reply-To: <000301c23e0f$784d7950$01b5a8c0@tony>
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 expected there to be more discussion of this proposal.  I hesitate to 
consider the lack of discussion to indicate agreement.  However, this looks 
like a very reasonable approach.  Therefore, I have assigned the necessary 
object identifier:

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

    id-cap  OBJECT IDENTIFIER ::= { id-smime 11 }

    id-cap-preferBinaryInside  OBJECT IDENTIFIER ::= { id-cap 1 }

Blake, please make the necessary changes to RFC2633bis.

Russ


At 08:39 AM 8/7/2002 -0400, Tony Capel wrote:

>Blake:
>
>This e-mail proposes to conclude a short off-list discussion (and
>discussion during recent S/MIME WG meeting) by proposing an approach
>whereby senders are able to avoid 7-bit transfer encoding inner binary
>MIME entities if they know that all intended receivers for the message
>are able to process binary entities.
>
>Without this change, unnecessary overheads will be introduced for many
>s/mime messages and this is a concern of mail system operators and
>persons downloading mail over limited bandwidth channels.
>
>Currently, in [MSG] section 3.1.2 it states that inner MIME entities
>SHOULD always be transfer encoded in case intermediate processing
>exposes the inner content to non-8-bit clean transport.  This is clearly
>a safe approach, however in very many common cases where messages are
>fully decoded at the "desktop" - or within client/server environments
>with 8-bit transport (also common) - it leads to unnecessary message
>expansion.
>
>Blake, you have emphasized that there may be problems with some gateways
>where inner content may be exposed to non-8-bit safe environments (e.g.
>such as DOMSEC in some multipart inner-content situations).  Jim Schaad
>pointed out at the recent WG meeting that rfc2633 currently requires
>support for binary encoding.  Also a recent survey of messaging system
>implementers indicated that their code could handle binary encoding
>(please refer to the WG minutes for further info and where
>interoperability concerns are also raised).  So clearly we cannot make a
>wholesale change; we must retain the ability to accommodate
>non-8-bit-safe intermediate environments.
>
>In a previous discussion in 1997 a "preferBinaryInside" sMIMECapability
>attribute was suggested, see:
>
>http://www.imc.org/ietf-smime/archive1/msg00249.html
>
>The use of an sMIMECapability OID would provide a means by which
>receivers can signal to senders that senders need not 7-bit transfer
>encode inner entities.  Receivers would only publish this OID if they
>are "binary safe".
>
>Since interoperability is not impacted if senders 7-bit transfer encode
>anyway, senders should only avoid such transfer encoding if they "know"
>(either by receiving this OID or by other means) that the receiver is
>binary safe - if the sender does not know, it should 7-bit transfer
>encode.
>
>To do this we would need an OID, and a slight change to 2633bis-01:
>
>1.  An OID added to http://www.imc.org/ietf-smime/other-smime-oids.asn
>
>For example:
>
>preferBinaryInside OBJECT IDENTIFIER ::=
>     {sMIMECapabilities xx}
>--        (No parameters. In the event that this OID is present,
>--         then the receiver is capable of processing binary inner
>--         MIME entities and every effort should be made by senders
>--         to avoid unnecessary transfer encoding of these entities.
>--         Receivers should only publish this capability if they
>--         can guarantee that all MIME processing, other than that
>--         of the outermost MIME entity, is fully binary capable.)
>
>2.  In section 2.5.2, suggest expanding the sentence:
>
>  "It also includes a non-algorithm capability which is the preference
>for signedData."
>
>To:
>
>"It MAY also be used to indicate additional preferences or capabilities,
>for example preference to always receive signed messages or never
>receive encrypted messages and the capability to process binary inner
>MIME content (see section 3.1.2).  Refer to the list of SMIMECapability
>OIDs for further information."
>
>3.  In section 3.1.2 addition of text something like:
>
>"S/MIME implementations which "know" that all intended recipient(s) are
>capable of handling inner (all but the outermost) binary MIME objects
>SHOULD NOT use 7-bit transfer encoding for the inner entities since this
>would unnecessarily expand the message size.  Implementations MAY "know"
>that recipient implementations are capable of handling inner binary MIME
>entities either by interpreting a corresponding sMIMECapabilities
>attribute (see section 2.5.2), by prior agreement, or by other means.
>
>"If one or more intended recipients are unable to handle inner binary
>MIME objects, or if this capability in unknown for any of the intended
>recipients, S/MIME implementations SHOULD use transfer encoding
>described in section 3.1.3 for all MIME entities they secure."
>
>
>I hope this addresses the issue with minimum fallout!
>
>
>Regards,
>
>tony


Received: by above.proper.com (8.11.6/8.11.3) id g7FD78x25561 for ietf-smime-bks; Thu, 15 Aug 2002 06:07:08 -0700 (PDT)
Received: from nebula.x509.com (nebula.x509.com [199.175.150.19]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7FD77w25557 for <[e-mail]>; Thu, 15 Aug 2002 06:07:07 -0700 (PDT)
Received: from crack.x509.com (mail.x509.com [199.175.150.1]) by nebula.x509.com (8.11.6/XCERT) with ESMTP id g7FD6xF07573 for <[e-mail]>; Thu, 15 Aug 2002 06:06:59 -0700 (PDT)
Received: from exvan01.x509.com (exvan01.x509.com [10.9.22.50]) by crack.x509.com (8.11.6/XCERT) with ESMTP id g7FD6xt04848 for <[e-mail]>; Thu, 15 Aug 2002 06:06:59 -0700 (PDT)
Received: by exvan01.x509.com with Internet Mail Service (5.5.2653.19) id <NK3HTN0J>; Thu, 15 Aug 2002 06:11:28 -0700
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.9.11]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3TPVH9GF; Thu, 15 Aug 2002 09:06:18 -0400
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 15 Aug 2002 09:05:23 -0400
To: [e-mail]
From: "Housley, Russ" <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-smime-cms-rsaes-oaep-06.txt
In-Reply-To: <[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>

Dear S/MIME WG:

This update to the RSAES-OAEP document addresses the issues raised during 
working group last call.  Major changes include a new section on 
certificate conventions and revisions in the security considerations.

I plan to forward this document to the IESG on Friday for IETF-wide Last 
Call.  Post a message to the WG mail list if you have concerns.

Russ

>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           : Use of the RSAES-OAEP Transport Algorithm in CMS
>         Author(s)       : R. Housley
>         Filename        : draft-ietf-smime-cms-rsaes-oaep-06.txt
>         Pages           : 15
>         Date            : 14-Aug-02
>
>This document describes the use of the RSAES-OAEP key transport
>method of key management within the Cryptographic Message Syntax
>(CMS).
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-ietf-smime-cms-rsaes-oaep-06.txt


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g7FCHVe21837 for ietf-smime-bks; Thu, 15 Aug 2002 05:17:31 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7FCHTw21832 for <[e-mail]>; Thu, 15 Aug 2002 05:17:30 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22069; Thu, 15 Aug 2002 08:16:10 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-smime-cms-rsaes-oaep-06.txt
Date: Thu, 15 Aug 2002 08:16:10 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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

	Title		: Use of the RSAES-OAEP Transport Algorithm in CMS
	Author(s)	: R. Housley
	Filename	: draft-ietf-smime-cms-rsaes-oaep-06.txt
	Pages		: 15
	Date		: 14-Aug-02
	
This document describes the use of the RSAES-OAEP key transport
method of key management within the Cryptographic Message Syntax
(CMS).

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

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

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

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


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

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-smime-cms-rsaes-oaep-06.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-smime-cms-rsaes-oaep-06.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-smime-cms-rsaes-oaep-06.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.11.6/8.11.3) id g7CFDsd11121 for ietf-smime-bks; Mon, 12 Aug 2002 08:13:54 -0700 (PDT)
Received: from vulcan.rsasecurity.com (mail.rsasecurity.com [204.167.114.123]) by above.proper.com (8.11.6/8.11.3) with SMTP id g7CFDmw11110 for <[e-mail]>; Mon, 12 Aug 2002 08:13:48 -0700 (PDT)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 12 Aug 2002 15:13:50 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id LAA18720 for <[e-mail]>; Mon, 12 Aug 2002 11:13:49 -0400 (EDT)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.10.2) with ESMTP id g7CFBbv24663 for <[e-mail]>; Mon, 12 Aug 2002 11:11:37 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <3TPVGSGK>; Mon, 12 Aug 2002 11:13:46 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.9.10]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3TPVGSG2; Mon, 12 Aug 2002 11:13:42 -0400
From: "Housley, Russ" <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Mon, 12 Aug 2002 11:13:37 -0400
Subject: Re: S/MIME v3.1 vs SMIME v3
In-Reply-To: <[e-mail] m>
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 biggest difference is the algorithms that have been chosen as mandatory 
to implement.  The mail list archive contains an extensive discussion of 
this topic.

Russ


At 02:59 PM 8/8/2002 +0100, [e-mail] wrote:


>In what way does S/MIME v3.1 improve/extend SMIME v3 ?
>I've been looking for information on the differences (aside from the
>message specifications themselves).


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g7C5Ha406217 for ietf-smime-bks; Sun, 11 Aug 2002 22:17:36 -0700 (PDT)
Received: from ztxmail04.ztx.compaq.com (ztxmail04.ztx.compaq.com [161.114.1.208]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7C5HYw06213 for <[e-mail]>; Sun, 11 Aug 2002 22:17:35 -0700 (PDT)
Received: from mailrelay01.cce.cpqcorp.net (mailrelay01.cce.cpqcorp.net [16.47.68.171]) by ztxmail04.ztx.compaq.com (Postfix) with ESMTP id 159A1330 for <[e-mail]>; Mon, 12 Aug 2002 00:17:34 -0500 (CDT)
Received: from diexch01.xko.dec.com (diexch01.xko.dec.com [16.138.244.57]) by mailrelay01.cce.cpqcorp.net (Postfix) with ESMTP id 64FBAD07 for <[e-mail]>; Mon, 12 Aug 2002 00:17:28 -0500 (CDT)
Received: by diexch01.xko.dec.com with Internet Mail Service (5.5.2650.21) id <QMD995YN>; Mon, 12 Aug 2002 10:52:26 +0530
Message-ID: <[e-mail]>
From: "Sreeramulu, Diguvapalem" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject:  Doubt in IETF draft, "Securing X.400 Content".
Date: Mon, 12 Aug 2002 10:52:25 +0530
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C241C0.3E72C852"
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_01C241C0.3E72C852
Content-Type: text/plain;
	charset="iso-8859-1"

Hi,
  This is Sreeramulu.D. working for Digital GlobalSoft Ltd, a subsidiary of
Hewlette-Packard co.,U.S.A. Currently we are working on sending s/mime
mssages in b/n Internet and X.400. This mail is regarding the IETF draft,
"Securing X.400 content". I have a scenario in which I have to send a
secured X.400 content to an internet user.  What is an OM_class (like
OMP_O_IM_C_INTERPERSONAL_MSG),to create a content object from? Or otherwise
can we put the protected X.400 content in an oject of an OM_class,
OMP_O_MH_C_GENERAL_CONTENT and send it across? 
 
Hope you could understand my problem. Hoping an elaborated reply from you as
soon as possible.
 
Thanks&Regards, 
  Sreeramulu.D
   Mailbus Engineering,
   Digital GlobalSoft Ltd.,
   INDIA.


   

 

------_=_NextPart_001_01C241C0.3E72C852
Content-Type: text/html;
	charset="iso-8859-1"

<!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 6.00.2600.0" name=GENERATOR></HEAD>
<BODY>
<DIV>
<DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
size=2></FONT></DIV><FONT face="Courier New" color=#0000ff size=2><SPAN 
class=109320012-05082002>Hi,<BR>&nbsp; This is Sreeramulu.D. working for Digital 
GlobalSoft Ltd, a subsidiary of Hewlette-Packard co.,U.S.A. Currently we are 
working on sending s/mime mssages in b/n Internet and X.400. This mail is 
regarding the IETF draft, "Securing X.400 content". I have a scenario in which I 
have to send a secured X.400 content to an internet user.&nbsp; What is an 
OM_class (like OMP_O_IM_C_INTERPERSONAL_MSG),to create a content object from? Or 
otherwise can we put the protected X.400 content in an oject of an OM_class, 
OMP_O_MH_C_GENERAL_CONTENT and send it across? </SPAN></FONT></DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2><SPAN 
class=109320012-05082002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face="Courier New" color=#0000ff size=2><SPAN 
class=109320012-05082002>Hope you could understand my problem. Hoping an 
elaborated<SPAN class=000012105-12082002>&nbsp;</SPAN><SPAN 
class=000012105-12082002>reply&nbsp;</SPAN>from you as soon as 
possible.</SPAN></FONT></DIV>
<DIV><FONT face="Courier New"><FONT size=2><FONT color=#0000ff><SPAN 
class=109320012-05082002></SPAN></FONT></FONT></FONT>&nbsp;</DIV>
<DIV><FONT size=+0><FONT size=+0><FONT face="Courier New"><FONT 
color=#0000ff><FONT size=2><SPAN 
class=109320012-05082002>Thanks&amp;</SPAN>Regards,&nbsp;<BR><SPAN 
class=109320012-05082002>&nbsp; 
</SPAN>Sreeramulu.D</FONT></FONT></FONT></FONT></FONT></DIV>
<DIV><SPAN class=109320012-05082002><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; Mailbus Engineering,</FONT></SPAN></DIV>
<DIV><SPAN class=109320012-05082002><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; Digital GlobalSoft Ltd.,</FONT></SPAN></DIV>
<DIV><SPAN class=109320012-05082002><FONT face="Courier New" color=#0000ff 
size=2>&nbsp;&nbsp; INDIA.</FONT></SPAN></DIV>
<P><FONT color=#800080><BR></FONT><FONT face=Garamond 
color=#008000>&nbsp;&nbsp;</FONT> </P>
<DIV><FONT face="Courier New" color=#0000ff 
size=2></FONT>&nbsp;</DIV></BODY></HTML>

------_=_NextPart_001_01C241C0.3E72C852--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g79K34x08412 for ietf-smime-bks; Fri, 9 Aug 2002 13:03:04 -0700 (PDT)
Received: from vulcan.rsasecurity.com (mail.rsasecurity.com [204.167.114.123]) by above.proper.com (8.11.6/8.11.3) with SMTP id g79K32w08408 for <[e-mail]>; Fri, 9 Aug 2002 13:03:03 -0700 (PDT)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 9 Aug 2002 20:03:05 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id QAA25932 for <[e-mail]>; Fri, 9 Aug 2002 16:03:04 -0400 (EDT)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.10.2) with ESMTP id g79K0s913487 for <[e-mail]>; Fri, 9 Aug 2002 16:00:54 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <3TPVGAHN>; Fri, 9 Aug 2002 16:03:03 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.9.31]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3TPVGAHJ; Fri, 9 Aug 2002 16:02:58 -0400
From: "Housley, Russ" <[e-mail]>
To: Robert Zuccherato <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 07 Aug 2002 17:55:30 -0400
Subject: RE: RSA OAEP Public Key Identification
In-Reply-To: <[e-mail] .com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Robert:

Your suggestion is consistent with RFC 3279, and I support it.

Russ

At 10:41 AM 8/2/2002 -0400, Robert Zuccherato wrote:

>Russ;
>
>I think that including the id-RSAES-OAEP be used in the certificate 
>subject public key info field is the right way to go.  The only other 
>option that I see is Extended Key Usage, but I don't think that EKU was 
>meant to deal with algorithm usages.
>
>I do have one question though.  If we go with your proposal, how would 
>certificates with rsaEncryption in the SubjectPublicKeyInfo 
>AlgorithmIdentifier be treated?  My suggestion would be that any key 
>transport method (PKCS #1, OAEP, etc) could be used with these 
>keys.  Anything else would be a redefinition of what that OID 
>meant.  Also, this would allow people who want to use both algorithms with 
>one key to continue to do so.  This would mean that id-RSAES-OAEP need 
>only be included in the subject public key info of certificates whose key 
>is to be used solely with OAEP, for everyone else nothing changes.
>
>         Robert.
>
> > -----Original Message-----
> > From: Housley, Russ 
> [<mailto:[e-mail]>mailto:[e-mail]]
> > Sent: Thursday, August 01, 2002 5:01 PM
> > To: [e-mail]
> > Subject: RSA OAEP Public Key Identification
> >
> >
> >
> > At the meeting in Yokohama, we discussed the RSA OAEP draft.
> > One of the
> > areas that was discussed was the security considerations
> > section, where the
> > document recommends that a key pair only be used for one
> > purpose.  Presently, we do not have a mechanism for
> > identifying how a key
> > holder would like to have their public key used.
> >
> > The certificate currently tells the message originator that
> > the public key
> > is an RSA key, and the key usage extension tells that the
> > public key can be
> > used for key transport.  There is nothing to tell the message
> > originator
> > whether RSA PKCS #1 v1.5 or RSA OAEP ought to be used with a
> > particular
> > key.  So, there is no indication to the message originator
> > that will allow
> > the security consideration to be implemented.
> >
> > Here is my proposed solution: use a different algorithm
> > identifier in the
> > certificate.
> >
> > I suggest that the id-RSAES-OAEP be used in the certificate
> > subject public
> > key info field to indicate that the public key should ONLY be
> > used with RSA
> > OAEP.
> >
> > This proposal may make transition from RSA PKCS #1 v1.5 to
> > RSA OAEP a bit
> > more difficult, since it would not allow one key pair to be
> > used with both
> > algorithms.  However, this is exactly what the security
> > considerations
> > recommend.
> >
> > Does anyone have concerns with this approach?
> >
> > If this approach is adopted, then a companion document in the
> > PKIX working
> > group for the proper handling of RSA OAEP (and probably RSA
> > PSS) public
> > keys will likely be needed.
> >
> > Russ
> >


Received: by above.proper.com (8.11.6/8.11.3) id g78E1Dp16649 for ietf-smime-bks; Thu, 8 Aug 2002 07:01:13 -0700 (PDT)
Received: from emampx001.pwcglobal.com (emampx001.pwcglobal.com [164.143.240.132]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g78E1Cw16641 for <[e-mail]>; Thu, 8 Aug 2002 07:01:12 -0700 (PDT)
Received: from uk-emamta003.ema.pwcinternal.com (uk-emamta003.ema.pwcinternal.com [10.250.44.242]) by emampx001.pwcglobal.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g78E17Y26695 for <[e-mail]>; Thu, 8 Aug 2002 15:01:08 +0100 (BST)
Sensitivity: 
Subject: S/MIME v3.1 vs SMIME v3
To: [e-mail]
From: [e-mail]
Date: Thu, 8 Aug 2002 14:59:21 +0100
Message-ID: <[e-mail]>
X-MIMETrack: Serialize by Router on UK-EMAMTA003/UK/INTL(Release 5.0.9 |November 16, 2001) at 08/08/2002 02:55:04 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

In what way does S/MIME v3.1 improve/extend SMIME v3 ?
I've been looking for information on the differences (aside from the
message specifications themselves).

_________________________________________________________________
The information transmitted is intended only for the person or entity to
which it is addressed and may contain confidential and/or privileged
material.  Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by persons or
entities other than the intended recipient is prohibited.   If you received
this in error, please contact the sender and delete the material from any
computer.



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g77CdKc10530 for ietf-smime-bks; Wed, 7 Aug 2002 05:39:20 -0700 (PDT)
Received: from mx4.magma.ca (mx4.magma.ca [206.191.0.253]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g77CdJw10525 for <[e-mail]>; Wed, 7 Aug 2002 05:39:19 -0700 (PDT)
Received: from mail6.magma.ca (mail6 [206.191.0.248]) by mx4.magma.ca (Magma's Mail Server) with ESMTP id g77CdIrs018779; Wed, 7 Aug 2002 08:39:18 -0400
Received: from tony (ottawa-hs-209-217-122-183.s-ip.magma.ca [209.217.122.183]) by mail6.magma.ca (Magma's Mail Server) with ESMTP id g77Cd9Rb012994; Wed, 7 Aug 2002 08:39:18 -0400 (EDT)
From: "Tony Capel" <[e-mail]>
To: <[e-mail]>, "'Blake Ramsdell'" <[e-mail]>
Subject: Inner Binary Encoding in MSG, RFC2633-bis-01
Date: Wed, 7 Aug 2002 08:39:22 -0400
Message-ID: <000301c23e0f$784d7950$01b5a8c0@tony>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Blake:

This e-mail proposes to conclude a short off-list discussion (and
discussion during recent S/MIME WG meeting) by proposing an approach
whereby senders are able to avoid 7-bit transfer encoding inner binary
MIME entities if they know that all intended receivers for the message
are able to process binary entities.

Without this change, unnecessary overheads will be introduced for many
s/mime messages and this is a concern of mail system operators and
persons downloading mail over limited bandwidth channels.

Currently, in [MSG] section 3.1.2 it states that inner MIME entities
SHOULD always be transfer encoded in case intermediate processing
exposes the inner content to non-8-bit clean transport.  This is clearly
a safe approach, however in very many common cases where messages are
fully decoded at the "desktop" - or within client/server environments
with 8-bit transport (also common) - it leads to unnecessary message
expansion.

Blake, you have emphasized that there may be problems with some gateways
where inner content may be exposed to non-8-bit safe environments (e.g.
such as DOMSEC in some multipart inner-content situations).  Jim Schaad
pointed out at the recent WG meeting that rfc2633 currently requires
support for binary encoding.  Also a recent survey of messaging system
implementers indicated that their code could handle binary encoding
(please refer to the WG minutes for further info and where
interoperability concerns are also raised).  So clearly we cannot make a
wholesale change; we must retain the ability to accommodate
non-8-bit-safe intermediate environments.

In a previous discussion in 1997 a "preferBinaryInside" sMIMECapability
attribute was suggested, see:

http://www.imc.org/ietf-smime/archive1/msg00249.html

The use of an sMIMECapability OID would provide a means by which
receivers can signal to senders that senders need not 7-bit transfer
encode inner entities.  Receivers would only publish this OID if they
are "binary safe".

Since interoperability is not impacted if senders 7-bit transfer encode
anyway, senders should only avoid such transfer encoding if they "know"
(either by receiving this OID or by other means) that the receiver is
binary safe - if the sender does not know, it should 7-bit transfer
encode.  

To do this we would need an OID, and a slight change to 2633bis-01:

1.  An OID added to http://www.imc.org/ietf-smime/other-smime-oids.asn

For example:

preferBinaryInside OBJECT IDENTIFIER ::=
    {sMIMECapabilities xx}
--        (No parameters. In the event that this OID is present,
--         then the receiver is capable of processing binary inner
--         MIME entities and every effort should be made by senders
--         to avoid unnecessary transfer encoding of these entities.
--         Receivers should only publish this capability if they
--         can guarantee that all MIME processing, other than that
--         of the outermost MIME entity, is fully binary capable.)

2.  In section 2.5.2, suggest expanding the sentence:

 "It also includes a non-algorithm capability which is the preference
for signedData."

To:

"It MAY also be used to indicate additional preferences or capabilities,
for example preference to always receive signed messages or never
receive encrypted messages and the capability to process binary inner
MIME content (see section 3.1.2).  Refer to the list of SMIMECapability
OIDs for further information."

3.  In section 3.1.2 addition of text something like:

"S/MIME implementations which "know" that all intended recipient(s) are
capable of handling inner (all but the outermost) binary MIME objects
SHOULD NOT use 7-bit transfer encoding for the inner entities since this
would unnecessarily expand the message size.  Implementations MAY "know"
that recipient implementations are capable of handling inner binary MIME
entities either by interpreting a corresponding sMIMECapabilities
attribute (see section 2.5.2), by prior agreement, or by other means.

"If one or more intended recipients are unable to handle inner binary
MIME objects, or if this capability in unknown for any of the intended
recipients, S/MIME implementations SHOULD use transfer encoding
described in section 3.1.3 for all MIME entities they secure."


I hope this addresses the issue with minimum fallout!


Regards,

tony




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g76Lets06111 for ietf-smime-bks; Tue, 6 Aug 2002 14:40:55 -0700 (PDT)
Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g76Lenw06093 for <[e-mail]>; Tue, 6 Aug 2002 14:40:53 -0700 (PDT)
Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.157]) by mail5.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 6 Aug 2002 14:40:41 -0700
Received: from 157.54.6.150 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 06 Aug 2002 14:40:43 -0700
Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 6 Aug 2002 14:40:41 -0700
Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 6 Aug 2002 14:40:42 -0700
Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3604.0); Tue, 6 Aug 2002 14:40:01 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary"
Subject: RE: RSA OAEP Public Key Identification
Date: Tue, 6 Aug 2002 14:41:19 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: RSA OAEP Public Key Identification
thread-index: AcI9h/8fC4JLJk6pTyOuqS04PGKvvAABjTSQ
From: "Trevor Freeman" <[e-mail]>
To: "Robert Zuccherato" <[e-mail]>, "Simon Blake-Wilson" <[e-mail]>, "Housley, Russ" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 06 Aug 2002 21:40:01.0849 (UTC) FILETIME=[D1C1DA90:01C23D91]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

--------------InterScan_NT_MIME_Boundary
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C23D91.FFF17362"

------_=_NextPart_001_01C23D91.FFF17362
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Robert,

This is about defining policy on how the RSA key is used. Since there is
no scope for this kind of policy in the key usage extension, then EKU is
the intended mechanism. There is nothing in 3280 which restricts the
scope of the kinds usages in EKU to just application policy. The
complication here is that we have a deployed base of applications which
understand one or more existing RSA key OIDs and PKCS#1.5. I agree with
Simon, we should use a new OID for the RSA keys which indicates that if
you use this key with this OID you must understand the range of possible
policies that may be expressed in the EKU extension. If you are OK with
the key being used for both PKCS#1.5 and OAEP the use the existing key
OID with no EKU. We don't have to mark anything critical which is always
a loose cannon, we can just do this by mandate.

Trevor

-----Original Message-----
From: Robert Zuccherato [mailto:[e-mail]]=20
Sent: Tuesday, August 06, 2002 1:16 PM
To: 'Simon Blake-Wilson'; 'Housley, Russ'; [e-mail]
Subject: RE: RSA OAEP Public Key Identification

=20

I have two reasons for saying "not EKU".

=20

1.  The PKIX Certificate and CRL profile (RFC 3280) has the following
text describing EKU:

	If the extension is present, then the certificate MUST only be
used for one of the purposes indicated.  If multiple purposes are
indicated the application need not recognize all purposes indicated, as
long as the intended purpose is present. =20

Thus, for example, if the certificate had both id-RSAES-OAEP and
id-kp-emailProtection, then the key could legally be used for protecting
email, without regard for whether or not OAEP or PKCS #1 v1.5 should be
used.  Now, S/MIME could make a requirement that when encrypting for a
recipient and using OAEP then the id-RSAES-OAEP OID must be present, but
then that requirement wouldn't be necessarily binding on all other
applications that may process that certificate.

=20

2.  In my opinion EKU was meant to identify application-level purposes
for which the key may be used, not algorithm-level purposes.  Looking at
the purposes defined in RFC3280 confirms this (server auth., client
auth., code signing, email protection, time stamping, OCSP signing).
Algorithm usages belong in the subjectPublicKeyInfo and placing them in
EKU just unnecessarily complicates things.

	-----Original Message-----
	From: Simon Blake-Wilson [mailto:[e-mail]]
	Sent: Tuesday, August 06, 2002 9:31 AM
	To: 'Robert Zuccherato'; 'Housley, Russ'; [e-mail]
	Subject: RE: RSA OAEP Public Key Identification

	Can one of you please expand on "Why not EKU?" (Since I included
it in all the ECC stuff, if there's a good reason why not, maybe we can
change things.) Naively it seems like EKU has a bunch of nice properties
... for example you can use it to place the policy decision on the
private key holder or the public key holder with the criticality flag,
you can acknowledge that using keys with multiple algs happens and at
least make you the keys are only used with the OIDs listed, you have a
reasonable migration path by making the extension non-critical
initially, etc. Is it just lack of support for EKU in PKI products that
makes introducing a new OID in subjectPublicKeyInfo desirable?

	=20

	Best regards. simon

	=20

	-----Original Message-----
	From: [e-mail]
[mailto:[e-mail]] On Behalf Of Robert Zuccherato
	Sent: Friday, August 02, 2002 9:41 AM
	To: 'Housley, Russ'; [e-mail]
	Subject: RE: RSA OAEP Public Key Identification

	=20

	Russ;=20

	I think that including the id-RSAES-OAEP be used in the
certificate subject public key info field is the right way to go.  The
only other option that I see is Extended Key Usage, but I don't think
that EKU was meant to deal with algorithm usages.

	I do have one question though.  If we go with your proposal, how
would certificates with rsaEncryption in the SubjectPublicKeyInfo
AlgorithmIdentifier be treated?  My suggestion would be that any key
transport method (PKCS #1, OAEP, etc) could be used with these keys.
Anything else would be a redefinition of what that OID meant.  Also,
this would allow people who want to use both algorithms with one key to
continue to do so.  This would mean that id-RSAES-OAEP need only be
included in the subject public key info of certificates whose key is to
be used solely with OAEP, for everyone else nothing changes.

	        Robert.=20

	> -----Original Message-----=20
	> From: Housley, Russ [mailto:[e-mail]]=20
	> Sent: Thursday, August 01, 2002 5:01 PM=20
	> To: [e-mail]=20
	> Subject: RSA OAEP Public Key Identification=20
	>=20
	>=20
	>=20
	> At the meeting in Yokohama, we discussed the RSA OAEP draft. =20
	> One of the=20
	> areas that was discussed was the security considerations=20
	> section, where the=20
	> document recommends that a key pair only be used for one=20
	> purpose.  Presently, we do not have a mechanism for=20
	> identifying how a key=20
	> holder would like to have their public key used.=20
	>=20
	> The certificate currently tells the message originator that=20
	> the public key=20
	> is an RSA key, and the key usage extension tells that the=20
	> public key can be=20
	> used for key transport.  There is nothing to tell the message=20
	> originator=20
	> whether RSA PKCS #1 v1.5 or RSA OAEP ought to be used with a=20
	> particular=20
	> key.  So, there is no indication to the message originator=20
	> that will allow=20
	> the security consideration to be implemented.=20
	>=20
	> Here is my proposed solution: use a different algorithm=20
	> identifier in the=20
	> certificate.=20
	>=20
	> I suggest that the id-RSAES-OAEP be used in the certificate=20
	> subject public=20
	> key info field to indicate that the public key should ONLY be=20
	> used with RSA=20
	> OAEP.=20
	>=20
	> This proposal may make transition from RSA PKCS #1 v1.5 to=20
	> RSA OAEP a bit=20
	> more difficult, since it would not allow one key pair to be=20
	> used with both=20
	> algorithms.  However, this is exactly what the security=20
	> considerations=20
	> recommend.=20
	>=20
	> Does anyone have concerns with this approach?=20
	>=20
	> If this approach is adopted, then a companion document in the=20
	> PKIX working=20
	> group for the proper handling of RSA OAEP (and probably RSA=20
	> PSS) public=20
	> keys will likely be needed.=20
	>=20
	> Russ=20
	>=20


------_=_NextPart_001_01C23D91.FFF17362
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html>

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 10 (filtered)">
<title>RE: RSA OAEP Public Key Identification</title>

<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:blue;
	text-decoration:underline;}
p
	{margin-right:0in;
	margin-left:0in;
	font-size:12.0pt;
	font-family:"Times New Roman";}
span.emailstyle18
	{font-family:Arial;
	color:navy;}
span.EmailStyle19
	{font-family:Arial;
	color:navy;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=3DEN-US link=3Dblue vlink=3Dblue>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Hi Robert,</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>This is about defining policy on =
how the
RSA key is used. Since there is no scope for this kind of policy in the =
key
usage extension, then EKU is the intended mechanism. There is nothing in =
3280
which restricts the scope of the kinds usages in EKU to just application
policy. The complication here is that we have a deployed base of =
applications which
understand one or more existing RSA key OIDs and PKCS#1.5. I agree with =
Simon,
we should use a new OID for the RSA keys which indicates that if you use =
this
key with this OID you must understand the range of possible policies =
that may
be expressed in the EKU extension. If you are OK with the key being used =
for both
PKCS#1.5 and OAEP the use the existing key OID with no EKU. We =
don&#8217;t have
to mark anything critical which is always a loose cannon, we can just do =
this
by mandate.</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Trevor</span></font></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D2 =
face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma'>-----Original =
Message-----<br>
<b><span style=3D'font-weight:bold'>From:</span></b> Robert Zuccherato
[mailto:[e-mail]] <br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> </span></font><font =
size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;font-family:Tahoma'>Tuesday, August
 06, 2002</span></font><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
font-family:Tahoma'> </span></font><font size=3D2 face=3DTahoma><span
 style=3D'font-size:10.0pt;font-family:Tahoma'>1:16 =
PM</span></font><font size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'><br>
<b><span style=3D'font-weight:bold'>To:</span></b> 'Simon Blake-Wilson';
'Housley, Russ'; [e-mail]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: RSA OAEP =
Public Key
Identification</span></font></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D3 =
face=3D"Times New Roman"><span
style=3D'font-size:12.0pt'>&nbsp;</span></font></p>

<div>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D2 =
color=3Dmaroon
face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;color:maroon'>I have
two reasons for saying &quot;not EKU&quot;.</span></font></p>

</div>

<div>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D3 =
face=3D"Times New Roman"><span
style=3D'font-size:12.0pt'>&nbsp;</span></font></p>

</div>

<div>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D2 =
color=3Dmaroon
face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;color:maroon'>1.&nbsp;
The PKIX Certificate and CRL profile (RFC 3280) has the following text
describing EKU:</span></font></p>

</div>

<blockquote =
style=3D'margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt'>

<div>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D3 =
face=3DArial><span
style=3D'font-size:12.0pt;font-family:Arial'>If the extension is =
present, then
the certificate MUST only be used for one of the purposes =
indicated.&nbsp; If
multiple purposes are indicated the application need not recognize all =
purposes
indicated, as long as the intended purpose is present.&nbsp; =
</span></font></p>

</div>

</blockquote>

<div>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D2 =
color=3Dmaroon
face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;color:maroon'>Thus,
for example, if the certificate had both id-RSAES-OAEP and
id-kp-emailProtection, then the key could legally be used for protecting =
email,
without regard for whether or not OAEP or PKCS #1 v1.5 should be =
used.&nbsp;
Now, S/MIME could make a requirement that when encrypting for a =
recipient and
using OAEP then the id-RSAES-OAEP OID must be present, but then that
requirement wouldn't be necessarily binding on all other applications =
that may
process that certificate.</span></font></p>

</div>

<div>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D3 =
face=3D"Times New Roman"><span
style=3D'font-size:12.0pt'>&nbsp;</span></font></p>

</div>

<div>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D2 =
color=3Dmaroon
face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;color:maroon'>2.&nbsp;
In my opinion EKU was meant to identify application-level purposes for =
which
the key may be used, not algorithm-level purposes.&nbsp; Looking at the
purposes defined in RFC3280 confirms this (server auth., client auth., =
code
signing, email protection, time stamping, OCSP signing).&nbsp; Algorithm =
usages
belong in the subjectPublicKeyInfo and placing them in EKU just =
unnecessarily
complicates things.</span></font></p>

</div>

<blockquote style=3D'border:none;border-left:solid maroon =
1.5pt;padding:0in 0in 0in 4.0pt;
margin-left:3.75pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt'=
>

<p class=3DMsoNormal =
style=3D'margin-right:0in;margin-bottom:12.0pt;margin-left:
.5in'><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;font-family:Tahoma'>-----Original
Message-----<br>
<b><span style=3D'font-weight:bold'>From:</span></b> Simon Blake-Wilson
[mailto:[e-mail]]<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Tuesday, August 06, =
2002
9:31 AM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> 'Robert Zuccherato'; =
'Housley,
Russ'; [e-mail]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: RSA OAEP =
Public Key
Identification</span></font></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D2 =
color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>Can one of you =
please
expand on &#8220;Why not EKU?&#8221; (Since I included it in all the ECC =
stuff,
if there&#8217;s a good reason why not, maybe we can change things.) =
Naively it
seems like EKU has a bunch of nice properties &#8230; for example you =
can use
it to place the policy decision on the private key holder or the public =
key
holder with the criticality flag, you can acknowledge that using keys =
with
multiple algs happens and at least make you the keys are only used with =
the
OIDs listed, you have a reasonable migration path by making the =
extension
non-critical initially, etc. Is it just lack of support for EKU in PKI =
products
that makes introducing a new OID in subjectPublicKeyInfo =
desirable?</span></font></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D3 =
face=3D"Times New Roman"><span
style=3D'font-size:12.0pt'>&nbsp;</span></font></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D2 =
color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>Best regards. =
simon</span></font></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D3 =
face=3D"Times New Roman"><span
style=3D'font-size:12.0pt'>&nbsp;</span></font></p>

<p class=3DMsoNormal style=3D'margin-left:1.0in'><font size=3D2 =
face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma'>-----Original =
Message-----<br>
<b><span style=3D'font-weight:bold'>From:</span></b>
[e-mail] [mailto:[e-mail]] =
<b><span
style=3D'font-weight:bold'>On Behalf Of </span></b>Robert Zuccherato<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Friday, August 02, =
2002 9:41
AM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> 'Housley, Russ';
[e-mail]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: RSA OAEP =
Public Key
Identification</span></font></p>

<p class=3DMsoNormal style=3D'margin-left:1.0in'><font size=3D3 =
face=3D"Times New Roman"><span
style=3D'font-size:12.0pt'>&nbsp;</span></font></p>

<p style=3D'margin-left:1.0in'><font size=3D2 face=3D"Times New =
Roman"><span
style=3D'font-size:10.0pt'>Russ;</span></font> </p>

<p style=3D'margin-left:1.0in'><font size=3D2 face=3D"Times New =
Roman"><span
style=3D'font-size:10.0pt'>I think that including the id-RSAES-OAEP be =
used in
the certificate subject public key info field is the right way to =
go.&nbsp; The
only other option that I see is Extended Key Usage, but I don't think =
that EKU
was meant to deal with algorithm usages.</span></font></p>

<p style=3D'margin-left:1.0in'><font size=3D2 face=3D"Times New =
Roman"><span
style=3D'font-size:10.0pt'>I do have one question though.&nbsp; If we go =
with
your proposal, how would certificates with rsaEncryption in the
SubjectPublicKeyInfo AlgorithmIdentifier be treated?&nbsp; My suggestion =
would
be that any key transport method (PKCS #1, OAEP, etc) could be used with =
these
keys.&nbsp; Anything else would be a redefinition of what that OID =
meant.&nbsp;
Also, this would allow people who want to use both algorithms with one =
key to
continue to do so.&nbsp; This would mean that id-RSAES-OAEP need only be
included in the subject public key info of certificates whose key is to =
be used
solely with OAEP, for everyone else nothing changes.</span></font></p>

<p style=3D'margin-left:1.0in'><font size=3D3 face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</span></font><font
size=3D2><span style=3D'font-size:10.0pt'>Robert.</span></font> </p>

<p style=3D'margin-left:1.0in'><font size=3D2 face=3D"Times New =
Roman"><span
style=3D'font-size:10.0pt'>&gt; -----Original Message-----</span></font> =
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; From: Housley, Russ =
[<a
href=3D"mailto:[e-mail]">mailto:[e-mail]<=
/a>]</span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; Sent: Thursday, =
August 01,
2002 5:01 PM</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; To: =
[e-mail]</span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; Subject: RSA OAEP =
Public Key
Identification</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; At the meeting in =
Yokohama, we
discussed the RSA OAEP draft.&nbsp; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; One of the =
</span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; areas that was =
discussed was
the security considerations </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; section, where the =
</span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; document recommends =
that a key
pair only be used for one </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; purpose.&nbsp; =
Presently, we
do not have a mechanism for </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; identifying how a =
key </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; holder would like =
to have
their public key used.</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; The certificate =
currently
tells the message originator that </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; the public key =
</span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; is an RSA key, and =
the key
usage extension tells that the </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; public key can be =
</span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; used for key =
transport.&nbsp;
There is nothing to tell the message </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; originator =
</span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; whether RSA PKCS #1 =
v1.5 or
RSA OAEP ought to be used with a </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; particular =
</span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; key.&nbsp; So, =
there is no
indication to the message originator </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; that will allow =
</span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; the security =
consideration to
be implemented.</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; Here is my proposed =
solution:
use a different algorithm </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; identifier in the =
</span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; =
certificate.</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; I suggest that the
id-RSAES-OAEP be used in the certificate </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; subject public =
</span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; key info field to =
indicate
that the public key should ONLY be </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; used with RSA =
</span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; OAEP.</span></font> =
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; This proposal may =
make
transition from RSA PKCS #1 v1.5 to </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; RSA OAEP a bit =
</span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; more difficult, =
since it would
not allow one key pair to be </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; used with both =
</span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; algorithms.&nbsp; =
However,
this is exactly what the security </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; considerations =
</span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; =
recommend.</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; Does anyone have =
concerns with
this approach?</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; If this approach is =
adopted,
then a companion document in the </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; PKIX working =
</span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; group for the =
proper handling
of RSA OAEP (and probably RSA </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; PSS) public =
</span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; keys will likely be =
needed.</span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; Russ</span></font> =
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font></p>

</blockquote>

</div>

</body>

</html>
=00
------_=_NextPart_001_01C23D91.FFF17362--

--------------InterScan_NT_MIME_Boundary--



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g76KFua00770 for ietf-smime-bks; Tue, 6 Aug 2002 13:15:56 -0700 (PDT)
Received: from SOTTMXS01.entrust.com (mail.entrust.com [216.191.251.35]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g76KFtw00766 for <[e-mail]>; Tue, 6 Aug 2002 13:15:55 -0700 (PDT)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2653.19) id <38JSS7VV>; Tue, 6 Aug 2002 16:15:47 -0400
Message-ID: <[e-mail]>
From: Robert Zuccherato <[e-mail]>
To: "'Simon Blake-Wilson'" <[e-mail]>, "'Housley, Russ'" <[e-mail]>, [e-mail]
Subject: RE: RSA OAEP Public Key Identification
Date: Tue, 6 Aug 2002 16:15:46 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C23D86.0C9664D0"
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_01C23D86.0C9664D0
Content-Type: text/plain

I have two reasons for saying "not EKU".
 
1.  The PKIX Certificate and CRL profile (RFC 3280) has the following text
describing EKU:

If the extension is present, then the certificate MUST only be used for one
of the purposes indicated.  If multiple purposes are indicated the
application need not recognize all purposes indicated, as long as the
intended purpose is present.  

Thus, for example, if the certificate had both id-RSAES-OAEP and
id-kp-emailProtection, then the key could legally be used for protecting
email, without regard for whether or not OAEP or PKCS #1 v1.5 should be
used.  Now, S/MIME could make a requirement that when encrypting for a
recipient and using OAEP then the id-RSAES-OAEP OID must be present, but
then that requirement wouldn't be necessarily binding on all other
applications that may process that certificate.
 
2.  In my opinion EKU was meant to identify application-level purposes for
which the key may be used, not algorithm-level purposes.  Looking at the
purposes defined in RFC3280 confirms this (server auth., client auth., code
signing, email protection, time stamping, OCSP signing).  Algorithm usages
belong in the subjectPublicKeyInfo and placing them in EKU just
unnecessarily complicates things.

-----Original Message-----
From: Simon Blake-Wilson [mailto:[e-mail]]
Sent: Tuesday, August 06, 2002 9:31 AM
To: 'Robert Zuccherato'; 'Housley, Russ'; [e-mail]
Subject: RE: RSA OAEP Public Key Identification



Can one of you please expand on "Why not EKU?" (Since I included it in all
the ECC stuff, if there's a good reason why not, maybe we can change
things.) Naively it seems like EKU has a bunch of nice properties ... for
example you can use it to place the policy decision on the private key
holder or the public key holder with the criticality flag, you can
acknowledge that using keys with multiple algs happens and at least make you
the keys are only used with the OIDs listed, you have a reasonable migration
path by making the extension non-critical initially, etc. Is it just lack of
support for EKU in PKI products that makes introducing a new OID in
subjectPublicKeyInfo desirable?

 

Best regards. simon

 

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Robert Zuccherato
Sent: Friday, August 02, 2002 9:41 AM
To: 'Housley, Russ'; [e-mail]
Subject: RE: RSA OAEP Public Key Identification

 

Russ; 

I think that including the id-RSAES-OAEP be used in the certificate subject
public key info field is the right way to go.  The only other option that I
see is Extended Key Usage, but I don't think that EKU was meant to deal with
algorithm usages.

I do have one question though.  If we go with your proposal, how would
certificates with rsaEncryption in the SubjectPublicKeyInfo
AlgorithmIdentifier be treated?  My suggestion would be that any key
transport method (PKCS #1, OAEP, etc) could be used with these keys.
Anything else would be a redefinition of what that OID meant.  Also, this
would allow people who want to use both algorithms with one key to continue
to do so.  This would mean that id-RSAES-OAEP need only be included in the
subject public key info of certificates whose key is to be used solely with
OAEP, for everyone else nothing changes.

        Robert. 

> -----Original Message----- 
> From: Housley, Russ [ mailto:[e-mail]
<mailto:[e-mail]> ] 
> Sent: Thursday, August 01, 2002 5:01 PM 
> To: [e-mail] 
> Subject: RSA OAEP Public Key Identification 
> 
> 
> 
> At the meeting in Yokohama, we discussed the RSA OAEP draft.  
> One of the 
> areas that was discussed was the security considerations 
> section, where the 
> document recommends that a key pair only be used for one 
> purpose.  Presently, we do not have a mechanism for 
> identifying how a key 
> holder would like to have their public key used. 
> 
> The certificate currently tells the message originator that 
> the public key 
> is an RSA key, and the key usage extension tells that the 
> public key can be 
> used for key transport.  There is nothing to tell the message 
> originator 
> whether RSA PKCS #1 v1.5 or RSA OAEP ought to be used with a 
> particular 
> key.  So, there is no indication to the message originator 
> that will allow 
> the security consideration to be implemented. 
> 
> Here is my proposed solution: use a different algorithm 
> identifier in the 
> certificate. 
> 
> I suggest that the id-RSAES-OAEP be used in the certificate 
> subject public 
> key info field to indicate that the public key should ONLY be 
> used with RSA 
> OAEP. 
> 
> This proposal may make transition from RSA PKCS #1 v1.5 to 
> RSA OAEP a bit 
> more difficult, since it would not allow one key pair to be 
> used with both 
> algorithms.  However, this is exactly what the security 
> considerations 
> recommend. 
> 
> Does anyone have concerns with this approach? 
> 
> If this approach is adopted, then a companion document in the 
> PKIX working 
> group for the proper handling of RSA OAEP (and probably RSA 
> PSS) public 
> keys will likely be needed. 
> 
> Russ 
> 


------_=_NextPart_001_01C23D86.0C9664D0
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=US-ASCII">
<TITLE>RE: RSA OAEP Public Key Identification</TITLE>

<META content="MSHTML 6.00.2716.2200" name=GENERATOR>
<STYLE>@font-face {
	font-family: Tahoma;
}
@page Section1 {size: 8.5in 11.0in; margin: 1.0in 1.25in 1.0in 1.25in; }
P.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
LI.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
DIV.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
A:link {
	COLOR: blue; TEXT-DECORATION: underline
}
SPAN.MsoHyperlink {
	COLOR: blue; TEXT-DECORATION: underline
}
A:visited {
	COLOR: blue; TEXT-DECORATION: underline
}
SPAN.MsoHyperlinkFollowed {
	COLOR: blue; TEXT-DECORATION: underline
}
P {
	FONT-SIZE: 12pt; MARGIN-LEFT: 0in; MARGIN-RIGHT: 0in; FONT-FAMILY: "Times New Roman"
}
SPAN.EmailStyle18 {
	COLOR: navy; FONT-FAMILY: Arial
}
DIV.Section1 {
	page: Section1
}
</STYLE>
</HEAD>
<BODY lang=EN-US vLink=blue link=blue>
<DIV><FONT face=Arial color=#800000 size=2><SPAN class=285590120-06082002>I have 
two reasons for saying "not EKU".</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#800000 size=2><SPAN 
class=285590120-06082002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial color=#800000 size=2><SPAN 
class=285590120-06082002>1.&nbsp; The PKIX Certificate and CRL profile (RFC 
3280) has the following text describing EKU:</SPAN></FONT></DIV>
<BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
  <DIV dir=ltr style="MARGIN-RIGHT: 0px"><FONT face=Arial><SPAN 
  class=285590120-06082002>If the extension is present, then the certificate 
  MUST only be used for one of the purposes indicated.&nbsp; If multiple 
  purposes are indicated the application need not recognize all purposes 
  indicated, as long as the intended purpose is present.&nbsp; 
  </SPAN></FONT></DIV></BLOCKQUOTE>
<DIV dir=ltr style="MARGIN-RIGHT: 0px"><FONT face=Arial><SPAN 
class=285590120-06082002><FONT color=#800000 size=2>Thus, for example, if the 
certificate had both id-RSAES-OAEP and id-kp-emailProtection, then the key could 
legally be used for protecting email, without regard for whether or not OAEP or 
PKCS #1 v1.5 should be used.&nbsp; Now, S/MIME could make a requirement that 
when encrypting for a recipient and using OAEP then the id-RSAES-OAEP OID must 
be present, but then that requirement wouldn't be necessarily binding on all 
other applications that may process that certificate.</FONT></SPAN></FONT></DIV>
<DIV dir=ltr style="MARGIN-RIGHT: 0px"><FONT face=Arial color=#800000 
size=2><SPAN class=285590120-06082002></SPAN></FONT>&nbsp;</DIV>
<DIV dir=ltr style="MARGIN-RIGHT: 0px"><FONT face=Arial color=#800000 
size=2><SPAN class=285590120-06082002>2.&nbsp; In my opinion EKU was meant to 
identify application-level purposes for which the key may be used, not 
algorithm-level purposes.&nbsp; Looking at the purposes defined in RFC3280 
confirms this (server auth., client auth., code signing, email protection, time 
stamping, OCSP signing).&nbsp; Algorithm usages belong in the 
subjectPublicKeyInfo and placing them in EKU just unnecessarily complicates 
things.</SPAN></FONT></DIV>
<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #800000 2px solid; MARGIN-RIGHT: 0px">
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Simon Blake-Wilson 
  [mailto:[e-mail]]<BR><B>Sent:</B> Tuesday, August 06, 2002 9:31 
  AM<BR><B>To:</B> 'Robert Zuccherato'; 'Housley, Russ'; 
  [e-mail]<BR><B>Subject:</B> RE: RSA OAEP Public Key 
  Identification<BR><BR></DIV></FONT>
  <DIV class=Section1>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Can one of you please 
  expand on &#8220;Why not EKU?&#8221; (Since I included it in all the ECC stuff, if there&#8217;s 
  a good reason why not, maybe we can change things.) Naively it seems like EKU 
  has a bunch of nice properties &#8230; for example you can use it to place the 
  policy decision on the private key holder or the public key holder with the 
  criticality flag, you can acknowledge that using keys with multiple algs 
  happens and at least make you the keys are only used with the OIDs listed, you 
  have a reasonable migration path by making the extension non-critical 
  initially, etc. Is it just lack of support for EKU in PKI products that makes 
  introducing a new OID in subjectPublicKeyInfo desirable?</SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"></SPAN></FONT>&nbsp;</P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Best regards. 
  simon</SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"></SPAN></FONT>&nbsp;</P>
  <P class=MsoNormal style="MARGIN-LEFT: 0.5in"><FONT face=Tahoma size=2><SPAN 
  style="FONT-SIZE: 10pt; FONT-FAMILY: Tahoma">-----Original 
  Message-----<BR><B><SPAN style="FONT-WEIGHT: bold">From:</SPAN></B> 
  [e-mail] [mailto:[e-mail]] <B><SPAN 
  style="FONT-WEIGHT: bold">On Behalf Of </SPAN></B>Robert 
  Zuccherato<BR><B><SPAN style="FONT-WEIGHT: bold">Sent:</SPAN></B> Friday, 
  August 02, 2002 9:41 AM<BR><B><SPAN style="FONT-WEIGHT: bold">To:</SPAN></B> 
  'Housley, Russ'; [e-mail]<BR><B><SPAN 
  style="FONT-WEIGHT: bold">Subject:</SPAN></B> RE: RSA OAEP Public Key 
  Identification</SPAN></FONT></P>
  <P class=MsoNormal style="MARGIN-LEFT: 0.5in"><FONT face="Times New Roman" 
  size=3><SPAN style="FONT-SIZE: 12pt"></SPAN></FONT>&nbsp;</P>
  <P style="MARGIN-LEFT: 0.5in"><FONT face="Times New Roman" size=2><SPAN 
  style="FONT-SIZE: 10pt">Russ;</SPAN></FONT> </P>
  <P style="MARGIN-LEFT: 0.5in"><FONT face="Times New Roman" size=2><SPAN 
  style="FONT-SIZE: 10pt">I think that including the id-RSAES-OAEP be used in 
  the certificate subject public key info field is the right way to go.&nbsp; 
  The only other option that I see is Extended Key Usage, but I don't think that 
  EKU was meant to deal with algorithm usages.</SPAN></FONT></P>
  <P style="MARGIN-LEFT: 0.5in"><FONT face="Times New Roman" size=2><SPAN 
  style="FONT-SIZE: 10pt">I do have one question though.&nbsp; If we go with 
  your proposal, how would certificates with rsaEncryption in the 
  SubjectPublicKeyInfo AlgorithmIdentifier be treated?&nbsp; My suggestion would 
  be that any key transport method (PKCS #1, OAEP, etc) could be used with these 
  keys.&nbsp; Anything else would be a redefinition of what that OID 
  meant.&nbsp; Also, this would allow people who want to use both algorithms 
  with one key to continue to do so.&nbsp; This would mean that id-RSAES-OAEP 
  need only be included in the subject public key info of certificates whose key 
  is to be used solely with OAEP, for everyone else nothing 
  changes.</SPAN></FONT></P>
  <P style="MARGIN-LEFT: 0.5in"><FONT face="Times New Roman" size=3><SPAN 
  style="FONT-SIZE: 12pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  </SPAN></FONT><FONT size=2><SPAN style="FONT-SIZE: 10pt">Robert.</SPAN></FONT> 
  </P>
  <P style="MARGIN-LEFT: 0.5in"><FONT face="Times New Roman" size=2><SPAN 
  style="FONT-SIZE: 10pt">&gt; -----Original Message-----</SPAN></FONT> 
  <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">&gt; From: Housley, Russ [<A 
  href="mailto:[e-mail]">mailto:[e-mail]</A>]</SPAN></FONT> 
  <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">&gt; Sent: Thursday, August 01, 
  2002 5:01 PM</SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">&gt; 
  To: [e-mail]</SPAN></FONT> <BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">&gt; Subject: RSA OAEP Public Key 
  Identification</SPAN></FONT> <BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">&gt; </SPAN></FONT><BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">&gt; </SPAN></FONT><BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">&gt; </SPAN></FONT><BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">&gt; At the meeting in Yokohama, we discussed the RSA 
  OAEP draft.&nbsp; </SPAN></FONT><BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">&gt; One of the </SPAN></FONT><BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">&gt; areas that was discussed was the security 
  considerations </SPAN></FONT><BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">&gt; section, where the </SPAN></FONT><BR><FONT 
  size=2><SPAN style="FONT-SIZE: 10pt">&gt; document recommends that a key pair 
  only be used for one </SPAN></FONT><BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">&gt; purpose.&nbsp; Presently, we do not have a 
  mechanism for </SPAN></FONT><BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">&gt; identifying how a key </SPAN></FONT><BR><FONT 
  size=2><SPAN style="FONT-SIZE: 10pt">&gt; holder would like to have their 
  public key used.</SPAN></FONT> <BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">&gt; </SPAN></FONT><BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">&gt; The certificate currently tells the message 
  originator that </SPAN></FONT><BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">&gt; the public key </SPAN></FONT><BR><FONT 
  size=2><SPAN style="FONT-SIZE: 10pt">&gt; is an RSA key, and the key usage 
  extension tells that the </SPAN></FONT><BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">&gt; public key can be </SPAN></FONT><BR><FONT 
  size=2><SPAN style="FONT-SIZE: 10pt">&gt; used for key transport.&nbsp; There 
  is nothing to tell the message </SPAN></FONT><BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">&gt; originator </SPAN></FONT><BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">&gt; whether RSA PKCS #1 v1.5 or RSA OAEP ought to be 
  used with a </SPAN></FONT><BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">&gt; 
  particular </SPAN></FONT><BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">&gt; 
  key.&nbsp; So, there is no indication to the message originator 
  </SPAN></FONT><BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">&gt; that will 
  allow </SPAN></FONT><BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">&gt; the 
  security consideration to be implemented.</SPAN></FONT> <BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">&gt; </SPAN></FONT><BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">&gt; Here is my proposed solution: use a different 
  algorithm </SPAN></FONT><BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">&gt; 
  identifier in the </SPAN></FONT><BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">&gt; certificate.</SPAN></FONT> <BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">&gt; </SPAN></FONT><BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">&gt; I suggest that the id-RSAES-OAEP be used in the 
  certificate </SPAN></FONT><BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">&gt; 
  subject public </SPAN></FONT><BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">&gt; key info field to indicate that the public key 
  should ONLY be </SPAN></FONT><BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">&gt; used with RSA </SPAN></FONT><BR><FONT 
  size=2><SPAN style="FONT-SIZE: 10pt">&gt; OAEP.</SPAN></FONT> <BR><FONT 
  size=2><SPAN style="FONT-SIZE: 10pt">&gt; </SPAN></FONT><BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">&gt; This proposal may make transition from RSA PKCS 
  #1 v1.5 to </SPAN></FONT><BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">&gt; 
  RSA OAEP a bit </SPAN></FONT><BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">&gt; more difficult, since it would not allow one key 
  pair to be </SPAN></FONT><BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">&gt; 
  used with both </SPAN></FONT><BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">&gt; algorithms.&nbsp; However, this is exactly what 
  the security </SPAN></FONT><BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">&gt; 
  considerations </SPAN></FONT><BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">&gt; recommend.</SPAN></FONT> <BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">&gt; </SPAN></FONT><BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">&gt; Does anyone have concerns with this 
  approach?</SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">&gt; 
  </SPAN></FONT><BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">&gt; If this 
  approach is adopted, then a companion document in the </SPAN></FONT><BR><FONT 
  size=2><SPAN style="FONT-SIZE: 10pt">&gt; PKIX working </SPAN></FONT><BR><FONT 
  size=2><SPAN style="FONT-SIZE: 10pt">&gt; group for the proper handling of RSA 
  OAEP (and probably RSA </SPAN></FONT><BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">&gt; PSS) public </SPAN></FONT><BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">&gt; keys will likely be needed.</SPAN></FONT> 
  <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">&gt; </SPAN></FONT><BR><FONT 
  size=2><SPAN style="FONT-SIZE: 10pt">&gt; Russ</SPAN></FONT> <BR><FONT 
  size=2><SPAN style="FONT-SIZE: 10pt">&gt; 
</SPAN></FONT></P></DIV></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C23D86.0C9664D0--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g76IV4X24912 for ietf-smime-bks; Tue, 6 Aug 2002 11:31:04 -0700 (PDT)
Received: from vulcan.rsasecurity.com (mail.rsasecurity.com [204.167.114.123]) by above.proper.com (8.11.6/8.11.3) with SMTP id g76IV3w24908 for <[e-mail]>; Tue, 6 Aug 2002 11:31:03 -0700 (PDT)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 6 Aug 2002 18:31:05 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id OAA28993 for <[e-mail]>; Tue, 6 Aug 2002 14:31:04 -0400 (EDT)
Received: from exrsa01.rsa.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.10.2) with ESMTP id g76ISsH25215 for <[e-mail]>; Tue, 6 Aug 2002 14:28:54 -0400 (EDT)
Received: by exrsa01.rsa.com with Internet Mail Service (5.5.2653.19) id <NGM1GBTC>; Tue, 6 Aug 2002 11:31:01 -0700
Message-ID: <[e-mail]>
From: "Yee, Peter" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: S/MIME WG Minutes from the 54th IETF
Date: Tue, 6 Aug 2002 11:30:51 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
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>

The minutes for the S/MIME Working Group meeting at the Yokohama
IETF follow.  If you find any egregious mistakes, please let me
know.  None of the presenters have complained yet. :-)

Thanks.
						-Peter Yee
						[e-mail]


This message includes the official minutes of the IETF S/MIME Working
Group (WG) meeting held at the 54th IETF in July 2002 in 
Yokohama, Japan.  Briefing slides will be available from 
<ftp://ftp.ietf.org/ietf/smime/>.  Reported by Peter Yee.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Introductions:  Russ Housley covered the agenda for the meeting.
No changes from the floor were offered or made.

  Introductions                        Russ Housley
  Working Group Status                 Russ Housley
  CMSbis Status                        Russ Housley
  MSGbis Update                        Russ Housley for Blake Ramsdell
  CERTbis Update                       Russ Housley for Blake Ramsdell
  X400wrap and X400transport Update    Sean Turner for Chris Bonatti
  CMS and ESS Examples Update          Russ Housley for Paul Hoffman
  Interoperability Matrix Update       Jim Schaad
  AES Update                           Jim Schaad
  RSA-OAEP Update                      Russ Housley
  PGP Certificate Support              Derek Atkins
  Wrap up                              Russ Housley

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Working Group Status:  Russ covered the current status of the active
documents in the working group.  Changes in status since the last
meeting are as follows.

Published as an RFC:
  - 3278 April 2002.  Use of Elliptic Curve Cryptography (ECC) Algorithms
         in Cryptographic Message Syntax (CMS).  S. Blake-Wilson,
         D. Brown, and P. Lambert.
  - 3114 May 2002.  Implementing Company Classification Policy with the
         S/MIME Security Label.  W. Nicholls.
  - 3274 June 2002.  Compressed Data Content Type for Cryptographic
         Message Syntax (CMS).  P. Gutmann.

RFC Editors Queue:
  - rfc2630bis  Cryptographic Message Syntax.  R. Housley
  - cmsalg      Cryptographic Message Syantx (CMS) Algorithms.
                    R. Housley
  - aes-keywrap AES Key Wrap Algorithm.  J. Schaad and R. Housley.

With the IESG for consideration:
  - x400wrap       Securing X.400 Content with S.MIME.  P. Hoffman,
                       C. Bonatti, and A. Eggen.
  - x400transport  Transporting S/MIME Objects in X.400.  P. Hoffman
                       and C. Bonnati.
  - symkeydist     CMS Symmetric Key Management and Distribution.
                       S. Turner.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

CMSbis Status:  About to be published as a Proposed Standard.  Blocked
  from going to Draft Standard until RFC 3280 progresses to Draft
  Standard.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

MSGbis Update:  Changes from -00:
  o Minor editorial work
  o Clarified "certificate managment" vs. "certs-only" (message
      content has not changed, only clarified).

Outstanding issues:
  o CompressedData use.  Which comes first sign or compress?  Should
      we expand SMIMECapabilities to indicate the compression algorithms
      that a recipient supports?  Current thinking is to add compression
      as a MAY.  Could be supported as a further profile of S/MIME or 
      could use the SMIMECapabilities (which many implementations only
      handle process in conjunction with encrypted messages).  Jim
      Schaad (Soaring Hawk) does not want compression for signed-only
      messages.  Further, Jim believes that compression should be applied
      after signing.  That is, the SignedData should be compressed.
  o Header field protection.  Would like to protect the RFC 2822 headers.
      To do so, the full 822 messsage is wrapped and protected in S/MIME.
      Then, outer headers for the S/MIME message are added that suffice
      for message delivery.
  o Inner binary encoding?  Triple-wrapped messages have considerable
     expansion due to Base-64 encoding for each layer of encapsulation.
     Is it acceptable only to Base-64 encode the outermost wrapper?
     S/MIME v2 used Base-64 encoding at each encapsulation because some
     older clients could not handle a binary transfer encoding type.  If
     we use binary encoding for inner wrappers, there is a problem with
     some gateways that remove security layers, exposing the contents 
     (such as DOMSEC).  If the exposed MIME type is multipart, then the
     re-encoding could impact signature validation.  The use of binary
     encoding is simply to reduce message expansion.  How the inner
     binary encoding is used can be done by two ways, it can be done as
     a profile, or it can be communicated through SMIMEcapabilities.
     Jim Schaad pointed out that RFC 2633 currently requires support for
     binary encoding.  Tim Polk (NIST) argued that it might cause
     interoperability problems, regardless of what the RFC decrees.  Many
     implementations handle inner binary encoding.  All implementers that
     responded to a S/MIME working group mailing list survey that was 
     conducted several months ago indicated that their code could handle
     binary encoding.  Further, no one expressed concerns in this area.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

CERTbis Update:
  o  Must not used v1 Attribute Certificates -- PKIX already mandates v2.
  o  MD2 security warning -- should not be used, but there are a few roots
       that use RSA-MD2
  o  Minor editorial work

Close to last call, so please get your inputs to Blake Ramsdell (Brute Squad
Labs) or Russ Housley (RSA Labs), via the mailing list.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

X400wrap & X400transport Update: X.400 Wrap is analgous to the MSG document,
and X.400 transport tells how to carry CMS objects via X.400 MTAs.

The documents are with the IESG, and the IETF Chair has raised a few
questions.  These questions are answered in new versions that are out to
the co-authors.  They should be posted soon.

One major issue:
  o  Header field protection
     Solutions:
     -  Encapsulate the message (including headers) in message/rfc822 and
        protect that
     -  Agree upon rules for merging inner/outer headers (inner protected
        and 822 headers must match!)
     -  Indicator to signal header merging needed

Documents are moving down the Standards Track, not Informational.  The -05
drafts will be released by the authors, hopefully getting these documents
closer to moving on.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

CMS and ESS Examples Update: New examples for inclusion in the document
have been sent to Paul Hoffman.  As soon as they are incorporated, a new
version of the document will be posted.  All implementers are asked to 
confirm that the examples produce the expected output.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Interoperability Matrix Update: Needs to be updated for rfc2630bis
and cmsalg (which are in the RFC Editor's Queue).

No recent implementer updates to the CMS information.  The CMS 
Algorithms portion of the matrix is very close (HMAC/SHA-1 is 
outstanding).

The SignedData portion has 6 items to go, and the EnvelopedData
portion has 10 items to go.

Paul Hoffman (IMC) has offered to coordinate interoperability testing

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

AES Update: Separated the AES and OAEP drafts.  The AES Keywrap is in
the RFC Editor's Queue.  One open issue remains in the AES for CMS
draft.  The mailing list constituency seems to want to allow RSA PKCS#1
v1.5 to wrap an AES key.  Jim Schaad does not want to allow this pairing.
Options:
 o  Keep MUST NOT (disallow this pairing)
 o  Change MUST NOT to MAY (with author's comment against doing the MAY)
 o  CHANGE to MAY and update SMIMECapabilities to allow for pairing
    information

Those present felt that MUST NOT was preferred, but the mailing list will
be polled again for a final input.  The draft will be posted at the end
of the week, and once this one decision is made, the document will be
ready for working group last call.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

RSAES-OAEP Update: Separated from the merged AES-OAEP document.  Other
separate but somewhat related documents are AES for CMS, RSA-KEM key
transport, and RSA-PSS digital signature.  The current (-03) draft of
RSAES-OAEP was posted June 2002.  Russ went over the structure of the
new draft.  A couple of questions were raised:

 o Is it okay to use the same RSA public/private key for RSAES-OAEP
   and other things.
   -- Not suggested.
 o Is RSAES-OAEP with SHA-1 secure for key transport of AES keys?
   -- SHA-1 used with 1024-bit RSA public key provides the equivalent of
      80-bit symmetric key, with respect to signatures.  This comparison
      is not so straightforward for key transport.  However, Burt Kaliski
      and others feel that the signature relationship is a low watermark
      for key transport, so for AES key transport, SHA-1 is not suggested.
      Thus, SHA-256, SHA-384, and SHA-512 will be added to ASN.1 module
      and suggested for use, but leave SHA-1 as the MUST implement.  Also,
      the updated draft will require RSA keys to be at least 1024 bits.

Working group last call, with the additions suggested above, would come
in August 2002.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

PGP Certificate Support: Derek Atkins (IHTFP Labs) suggested that with
many PGP Certificates out there and many S/MIME clients, the combination
of the two might be useful.  Essentially, this would be a binding of
PGP keys to be used in S/MIME messages (the converse is being worked in
the PGP working group).

In a straw poll, only one person thought that the support for PGP
certificates should not be investigated.  Many others thought that
an internet-draft should be developed.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g76DVej02845 for ietf-smime-bks; Tue, 6 Aug 2002 06:31:40 -0700 (PDT)
Received: from tomts22-srv.bellnexxia.net (tomts22.bellnexxia.net [209.226.175.184]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g76DVcw02838 for <[e-mail]>; Tue, 6 Aug 2002 06:31:38 -0700 (PDT)
Received: from Simon ([64.231.125.145]) by tomts22-srv.bellnexxia.net (InterMail vM.5.01.04.19 201-253-122-122-119-20020516) with ESMTP id <20020806133135.WLSG16788.tomts22-srv.bellnexxia.net@Simon>; Tue, 6 Aug 2002 09:31:35 -0400
From: "Simon Blake-Wilson" <[e-mail]>
To: "'Robert Zuccherato'" <[e-mail]>, "'Housley, Russ'" <[e-mail]>, <[e-mail]>
Subject: RE: RSA OAEP Public Key Identification
Date: Tue, 6 Aug 2002 09:31:26 -0400
Message-ID: <00ad01c23d4d$93fca760$c100a8c0@Simon>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_00AE_01C23D2C.0CEC8E00"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-Reply-To: <[e-mail]>
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_00AE_01C23D2C.0CEC8E00
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit

Can one of you please expand on "Why not EKU?" (Since I included it in
all the ECC stuff, if there's a good reason why not, maybe we can change
things.) Naively it seems like EKU has a bunch of nice properties . for
example you can use it to place the policy decision on the private key
holder or the public key holder with the criticality flag, you can
acknowledge that using keys with multiple algs happens and at least make
you the keys are only used with the OIDs listed, you have a reasonable
migration path by making the extension non-critical initially, etc. Is
it just lack of support for EKU in PKI products that makes introducing a
new OID in subjectPublicKeyInfo desirable?

 

Best regards. simon

 

-----Original Message-----
From: [e-mail]
[mailto:[e-mail]] On Behalf Of Robert Zuccherato
Sent: Friday, August 02, 2002 9:41 AM
To: 'Housley, Russ'; [e-mail]
Subject: RE: RSA OAEP Public Key Identification

 

Russ; 

I think that including the id-RSAES-OAEP be used in the certificate
subject public key info field is the right way to go.  The only other
option that I see is Extended Key Usage, but I don't think that EKU was
meant to deal with algorithm usages.

I do have one question though.  If we go with your proposal, how would
certificates with rsaEncryption in the SubjectPublicKeyInfo
AlgorithmIdentifier be treated?  My suggestion would be that any key
transport method (PKCS #1, OAEP, etc) could be used with these keys.
Anything else would be a redefinition of what that OID meant.  Also,
this would allow people who want to use both algorithms with one key to
continue to do so.  This would mean that id-RSAES-OAEP need only be
included in the subject public key info of certificates whose key is to
be used solely with OAEP, for everyone else nothing changes.

        Robert. 

> -----Original Message----- 
> From: Housley, Russ [mailto:[e-mail]] 
> Sent: Thursday, August 01, 2002 5:01 PM 
> To: [e-mail] 
> Subject: RSA OAEP Public Key Identification 
> 
> 
> 
> At the meeting in Yokohama, we discussed the RSA OAEP draft.  
> One of the 
> areas that was discussed was the security considerations 
> section, where the 
> document recommends that a key pair only be used for one 
> purpose.  Presently, we do not have a mechanism for 
> identifying how a key 
> holder would like to have their public key used. 
> 
> The certificate currently tells the message originator that 
> the public key 
> is an RSA key, and the key usage extension tells that the 
> public key can be 
> used for key transport.  There is nothing to tell the message 
> originator 
> whether RSA PKCS #1 v1.5 or RSA OAEP ought to be used with a 
> particular 
> key.  So, there is no indication to the message originator 
> that will allow 
> the security consideration to be implemented. 
> 
> Here is my proposed solution: use a different algorithm 
> identifier in the 
> certificate. 
> 
> I suggest that the id-RSAES-OAEP be used in the certificate 
> subject public 
> key info field to indicate that the public key should ONLY be 
> used with RSA 
> OAEP. 
> 
> This proposal may make transition from RSA PKCS #1 v1.5 to 
> RSA OAEP a bit 
> more difficult, since it would not allow one key pair to be 
> used with both 
> algorithms.  However, this is exactly what the security 
> considerations 
> recommend. 
> 
> Does anyone have concerns with this approach? 
> 
> If this approach is adopted, then a companion document in the 
> PKIX working 
> group for the proper handling of RSA OAEP (and probably RSA 
> PSS) public 
> keys will likely be needed. 
> 
> Russ 
> 


------=_NextPart_000_00AE_01C23D2C.0CEC8E00
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<html>

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">


<meta name=3DGenerator content=3D"Microsoft Word 10 (filtered)">
<title>RE: RSA OAEP Public Key Identification</title>

<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:blue;
	text-decoration:underline;}
p
	{margin-right:0in;
	margin-left:0in;
	font-size:12.0pt;
	font-family:"Times New Roman";}
span.EmailStyle18
	{font-family:Arial;
	color:navy;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=3DEN-US link=3Dblue vlink=3Dblue>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Can one of you please expand on =
&#8220;Why
not EKU?&#8221; (Since I included it in all the ECC stuff, if =
there&#8217;s a
good reason why not, maybe we can change things.) Naively it seems like =
EKU has
a bunch of nice properties &#8230; for example you can use it to place =
the policy
decision on the private key holder or the public key holder with the
criticality flag, you can acknowledge that using keys with multiple algs
happens and at least make you the keys are only used with the OIDs =
listed, you
have a reasonable migration path by making the extension non-critical
initially, etc. Is it just lack of support for EKU in PKI products that =
makes
introducing a new OID in subjectPublicKeyInfo =
desirable?</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Best regards. =
simon</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&nbsp;</span></font></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D2 =
face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma'>-----Original =
Message-----<br>
<b><span style=3D'font-weight:bold'>From:</span></b> =
[e-mail]
[mailto:[e-mail]] <b><span =
style=3D'font-weight:bold'>On
Behalf Of </span></b>Robert Zuccherato<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Friday, August 02, =
2002 9:41
AM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> 'Housley, Russ';
[e-mail]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: RSA OAEP =
Public Key
Identification</span></font></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D3 =
face=3D"Times New Roman"><span
style=3D'font-size:12.0pt'>&nbsp;</span></font></p>

<p style=3D'margin-left:.5in'><font size=3D2 face=3D"Times New =
Roman"><span
style=3D'font-size:10.0pt'>Russ;</span></font> </p>

<p style=3D'margin-left:.5in'><font size=3D2 face=3D"Times New =
Roman"><span
style=3D'font-size:10.0pt'>I think that including the id-RSAES-OAEP be =
used in
the certificate subject public key info field is the right way to =
go.&nbsp; The
only other option that I see is Extended Key Usage, but I don't think =
that EKU
was meant to deal with algorithm usages.</span></font></p>

<p style=3D'margin-left:.5in'><font size=3D2 face=3D"Times New =
Roman"><span
style=3D'font-size:10.0pt'>I do have one question though.&nbsp; If we go =
with
your proposal, how would certificates with rsaEncryption in the
SubjectPublicKeyInfo AlgorithmIdentifier be treated?&nbsp; My suggestion =
would
be that any key transport method (PKCS #1, OAEP, etc) could be used with =
these
keys.&nbsp; Anything else would be a redefinition of what that OID =
meant.&nbsp;
Also, this would allow people who want to use both algorithms with one =
key to
continue to do so.&nbsp; This would mean that id-RSAES-OAEP need only be
included in the subject public key info of certificates whose key is to =
be used
solely with OAEP, for everyone else nothing changes.</span></font></p>

<p style=3D'margin-left:.5in'><font size=3D3 face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</span></font><font
size=3D2><span style=3D'font-size:10.0pt'>Robert.</span></font> </p>

<p style=3D'margin-left:.5in'><font size=3D2 face=3D"Times New =
Roman"><span
style=3D'font-size:10.0pt'>&gt; -----Original Message-----</span></font> =
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; From: Housley, Russ =
[<a
href=3D"mailto:[e-mail]">mailto:[e-mail]<=
/a>]</span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; Sent: Thursday, =
August 01,
2002 5:01 PM</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; To: =
[e-mail]</span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; Subject: RSA OAEP =
Public Key
Identification</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; At the meeting in =
Yokohama, we
discussed the RSA OAEP draft.&nbsp; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; One of the =
</span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; areas that was =
discussed was
the security considerations </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; section, where the =
</span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; document recommends =
that a key
pair only be used for one </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; purpose.&nbsp; =
Presently, we
do not have a mechanism for </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; identifying how a =
key </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; holder would like =
to have
their public key used.</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; The certificate =
currently
tells the message originator that </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; the public key =
</span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; is an RSA key, and =
the key
usage extension tells that the </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; public key can be =
</span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; used for key =
transport.&nbsp;
There is nothing to tell the message </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; originator =
</span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; whether RSA PKCS #1 =
v1.5 or
RSA OAEP ought to be used with a </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; particular =
</span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; key.&nbsp; So, =
there is no
indication to the message originator </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; that will allow =
</span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; the security =
consideration to
be implemented.</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; Here is my proposed =
solution:
use a different algorithm </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; identifier in the =
</span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; =
certificate.</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; I suggest that the
id-RSAES-OAEP be used in the certificate </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; subject public =
</span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; key info field to =
indicate
that the public key should ONLY be </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; used with RSA =
</span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; OAEP.</span></font> =
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; This proposal may =
make
transition from RSA PKCS #1 v1.5 to </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; RSA OAEP a bit =
</span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; more difficult, =
since it would
not allow one key pair to be </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; used with both =
</span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; algorithms.&nbsp; =
However,
this is exactly what the security </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; considerations =
</span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; =
recommend.</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; Does anyone have =
concerns with
this approach?</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; If this approach is =
adopted,
then a companion document in the </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; PKIX working =
</span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; group for the =
proper handling
of RSA OAEP (and probably RSA </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; PSS) public =
</span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; keys will likely be =
needed.</span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; Russ</span></font> =
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font></p>

</div>

</body>

</html>

------=_NextPart_000_00AE_01C23D2C.0CEC8E00--




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g7388g513480 for ietf-smime-bks; Sat, 3 Aug 2002 01:08:42 -0700 (PDT)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7388ew13470 for <[e-mail]>; Sat, 3 Aug 2002 01:08:40 -0700 (PDT)
Received: from ruru.cs.auckland.ac.nz (ruru-nfs.cs.auckland.ac.nz [130.216.35.12]) by hermes.cs.auckland.ac.nz (8.12.4/8.12.4) with ESMTP id g7388Yq9004191; Sat, 3 Aug 2002 20:08:34 +1200
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id UAA174061; Sat, 3 Aug 2002 20:08:34 +1200 (NZST) (sender [e-mail])
Date: Sat, 3 Aug 2002 20:08:34 +1200 (NZST)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re:  RSA OAEP Public Key Identification
Cc: [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>

"Housley, Russ" <[e-mail]> writes:

>SMIMECapabilities cannot solve this problem.
>
>Suppose that I have two certificates, each with an RSA public key.  I want to
>use one of the public keys with PKCS #1 v1.5 and the other with OAEP.  In the
>current approach, both certificates have a key usage of keyEncipherment, and
>both certificates have a SubjectPublicKeyInfo AlgorithmIdentifier of
>rsaEncryption.  Also, SMIMECapabilities indicates both PKCS #1 v1.5 and OAEP.
>Therefore, a message originator has no idea which public key to use with PKCS
>#1 v1.5 and vice versa.

Fair enough.  However, I still can't see this flying... there's a Far Side
cartoon which shows two points of view of someone talking to a dog, the human
side is something like "This is my dog Fido, who's friendly with strangers,
doesn't chew the furniture, and doesn't get into fights with other dogs", and
the dog's side is "blah blah blah blah *Fido* blah blah blah blah blah blah
blah blah".  Getting this change across to end users will be similar, the
techies side will be "There's some obscure problem with existing RSA keys which
is too technical to explain and probably won't affect anyone, but just to be
safe we're making a switch to something else.  A slight downside is that
nothing will work any more with the new keys" and the masses will get "blah
blah blah blah blah blah *nothing will work any more with the new keys*".  You
may as well have the certificates made out of asbestos using child labour for
all the user buy-in they're going to get.

I don't think this is a solveable problem.  To kill PKCS #1, you need to make
sure the keys can only be used with OAEP.  By making sure they're only usable
with OAEP, they won't work when users try and do anything with them.  The
outcome is a foregone conclusion - it's X9.42 certs all over again.

I guess I've said my bit on this topic.  I certainly won't object if people
want to create OAEP OIDs and mechanisms and whatnot, but I'll stick with PKCS
#1 v1.5.

Peter.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g72Efib17061 for ietf-smime-bks; Fri, 2 Aug 2002 07:41:44 -0700 (PDT)
Received: from SOTTMXS01.entrust.com (mail.entrust.com [216.191.251.35]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g72Efgw17055 for <[e-mail]>; Fri, 2 Aug 2002 07:41:42 -0700 (PDT)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2653.19) id <38JSR4FZ>; Fri, 2 Aug 2002 10:41:28 -0400
Message-ID: <[e-mail]>
From: Robert Zuccherato <[e-mail]>
To: "'Housley, Russ'" <[e-mail]>, [e-mail]
Subject: RE: RSA OAEP Public Key Identification
Date: Fri, 2 Aug 2002 10:41:27 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C23A32.AEEEDA20"
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_01C23A32.AEEEDA20
Content-Type: text/plain

Russ;

I think that including the id-RSAES-OAEP be used in the certificate subject
public key info field is the right way to go.  The only other option that I
see is Extended Key Usage, but I don't think that EKU was meant to deal with
algorithm usages.

I do have one question though.  If we go with your proposal, how would
certificates with rsaEncryption in the SubjectPublicKeyInfo
AlgorithmIdentifier be treated?  My suggestion would be that any key
transport method (PKCS #1, OAEP, etc) could be used with these keys.
Anything else would be a redefinition of what that OID meant.  Also, this
would allow people who want to use both algorithms with one key to continue
to do so.  This would mean that id-RSAES-OAEP need only be included in the
subject public key info of certificates whose key is to be used solely with
OAEP, for everyone else nothing changes.

	Robert.

> -----Original Message-----
> From: Housley, Russ [mailto:[e-mail]]
> Sent: Thursday, August 01, 2002 5:01 PM
> To: [e-mail]
> Subject: RSA OAEP Public Key Identification
> 
> 
> 
> At the meeting in Yokohama, we discussed the RSA OAEP draft.  
> One of the 
> areas that was discussed was the security considerations 
> section, where the 
> document recommends that a key pair only be used for one 
> purpose.  Presently, we do not have a mechanism for 
> identifying how a key 
> holder would like to have their public key used.
> 
> The certificate currently tells the message originator that 
> the public key 
> is an RSA key, and the key usage extension tells that the 
> public key can be 
> used for key transport.  There is nothing to tell the message 
> originator 
> whether RSA PKCS #1 v1.5 or RSA OAEP ought to be used with a 
> particular 
> key.  So, there is no indication to the message originator 
> that will allow 
> the security consideration to be implemented.
> 
> Here is my proposed solution: use a different algorithm 
> identifier in the 
> certificate.
> 
> I suggest that the id-RSAES-OAEP be used in the certificate 
> subject public 
> key info field to indicate that the public key should ONLY be 
> used with RSA 
> OAEP.
> 
> This proposal may make transition from RSA PKCS #1 v1.5 to 
> RSA OAEP a bit 
> more difficult, since it would not allow one key pair to be 
> used with both 
> algorithms.  However, this is exactly what the security 
> considerations 
> recommend.
> 
> Does anyone have concerns with this approach?
> 
> If this approach is adopted, then a companion document in the 
> PKIX working 
> group for the proper handling of RSA OAEP (and probably RSA 
> PSS) public 
> keys will likely be needed.
> 
> Russ
> 

------_=_NextPart_001_01C23A32.AEEEDA20
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DUS-ASCII">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>RE: RSA OAEP Public Key Identification</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Russ;</FONT>
</P>

<P><FONT SIZE=3D2>I think that including the id-RSAES-OAEP be used in =
the certificate subject public key info field is the right way to =
go.&nbsp; The only other option that I see is Extended Key Usage, but I =
don't think that EKU was meant to deal with algorithm =
usages.</FONT></P>

<P><FONT SIZE=3D2>I do have one question though.&nbsp; If we go with =
your proposal, how would certificates with rsaEncryption in the =
SubjectPublicKeyInfo AlgorithmIdentifier be treated?&nbsp; My =
suggestion would be that any key transport method (PKCS #1, OAEP, etc) =
could be used with these keys.&nbsp; Anything else would be a =
redefinition of what that OID meant.&nbsp; Also, this would allow =
people who want to use both algorithms with one key to continue to do =
so.&nbsp; This would mean that id-RSAES-OAEP need only be included in =
the subject public key info of certificates whose key is to be used =
solely with OAEP, for everyone else nothing changes.</FONT></P>

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

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Housley, Russ [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]=
</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Thursday, August 01, 2002 5:01 PM</FONT>
<BR><FONT SIZE=3D2>&gt; To: [e-mail]</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: RSA OAEP Public Key =
Identification</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; At the meeting in Yokohama, we discussed the =
RSA OAEP draft.&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; One of the </FONT>
<BR><FONT SIZE=3D2>&gt; areas that was discussed was the security =
considerations </FONT>
<BR><FONT SIZE=3D2>&gt; section, where the </FONT>
<BR><FONT SIZE=3D2>&gt; document recommends that a key pair only be =
used for one </FONT>
<BR><FONT SIZE=3D2>&gt; purpose.&nbsp; Presently, we do not have a =
mechanism for </FONT>
<BR><FONT SIZE=3D2>&gt; identifying how a key </FONT>
<BR><FONT SIZE=3D2>&gt; holder would like to have their public key =
used.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; The certificate currently tells the message =
originator that </FONT>
<BR><FONT SIZE=3D2>&gt; the public key </FONT>
<BR><FONT SIZE=3D2>&gt; is an RSA key, and the key usage extension =
tells that the </FONT>
<BR><FONT SIZE=3D2>&gt; public key can be </FONT>
<BR><FONT SIZE=3D2>&gt; used for key transport.&nbsp; There is nothing =
to tell the message </FONT>
<BR><FONT SIZE=3D2>&gt; originator </FONT>
<BR><FONT SIZE=3D2>&gt; whether RSA PKCS #1 v1.5 or RSA OAEP ought to =
be used with a </FONT>
<BR><FONT SIZE=3D2>&gt; particular </FONT>
<BR><FONT SIZE=3D2>&gt; key.&nbsp; So, there is no indication to the =
message originator </FONT>
<BR><FONT SIZE=3D2>&gt; that will allow </FONT>
<BR><FONT SIZE=3D2>&gt; the security consideration to be =
implemented.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Here is my proposed solution: use a different =
algorithm </FONT>
<BR><FONT SIZE=3D2>&gt; identifier in the </FONT>
<BR><FONT SIZE=3D2>&gt; certificate.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I suggest that the id-RSAES-OAEP be used in the =
certificate </FONT>
<BR><FONT SIZE=3D2>&gt; subject public </FONT>
<BR><FONT SIZE=3D2>&gt; key info field to indicate that the public key =
should ONLY be </FONT>
<BR><FONT SIZE=3D2>&gt; used with RSA </FONT>
<BR><FONT SIZE=3D2>&gt; OAEP.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; This proposal may make transition from RSA PKCS =
#1 v1.5 to </FONT>
<BR><FONT SIZE=3D2>&gt; RSA OAEP a bit </FONT>
<BR><FONT SIZE=3D2>&gt; more difficult, since it would not allow one =
key pair to be </FONT>
<BR><FONT SIZE=3D2>&gt; used with both </FONT>
<BR><FONT SIZE=3D2>&gt; algorithms.&nbsp; However, this is exactly what =
the security </FONT>
<BR><FONT SIZE=3D2>&gt; considerations </FONT>
<BR><FONT SIZE=3D2>&gt; recommend.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Does anyone have concerns with this =
approach?</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; If this approach is adopted, then a companion =
document in the </FONT>
<BR><FONT SIZE=3D2>&gt; PKIX working </FONT>
<BR><FONT SIZE=3D2>&gt; group for the proper handling of RSA OAEP (and =
probably RSA </FONT>
<BR><FONT SIZE=3D2>&gt; PSS) public </FONT>
<BR><FONT SIZE=3D2>&gt; keys will likely be needed.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Russ</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C23A32.AEEEDA20--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g72DalU13706 for ietf-smime-bks; Fri, 2 Aug 2002 06:36:47 -0700 (PDT)
Received: from vulcan.rsasecurity.com (mail.rsasecurity.com [204.167.114.123]) by above.proper.com (8.11.6/8.11.3) with SMTP id g72Dafw13697 for <[e-mail]>; Fri, 2 Aug 2002 06:36:41 -0700 (PDT)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 2 Aug 2002 13:36:42 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id JAA27674 for <[e-mail]>; Fri, 2 Aug 2002 09:36:41 -0400 (EDT)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.10.2) with ESMTP id g72DYY401900 for <[e-mail]>; Fri, 2 Aug 2002 09:34:34 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <3TPVDB2Z>; Fri, 2 Aug 2002 09:36:39 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.9.7]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3TPVDB2W; Fri, 2 Aug 2002 09:36:33 -0400
From: "Housley, Russ" <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Fri, 02 Aug 2002 09:34:42 -0400
Subject: Re:  RSA OAEP Public Key Identification
In-Reply-To: <[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>

Peter:

SMIMECapabilities cannot solve this problem.

Suppose that I have two certificates, each with an RSA public key.  I want 
to use one of the public keys with PKCS #1 v1.5 and the other with 
OAEP.  In the current approach, both certificates have a key usage of 
keyEncipherment, and both certificates have a SubjectPublicKeyInfo 
AlgorithmIdentifier of rsaEncryption.  Also, SMIMECapabilities indicates 
both PKCS #1 v1.5 and OAEP.  Therefore, a message originator has no idea 
which public key to use with PKCS #1 v1.5 and vice versa.

The security considerations section is prudent; it recommends that just one 
content-encryption key scheme be used with a particular key pair.  The 
current approach does not give the message originator sufficient 
information to implement it.

Russ


At 08:49 PM 8/2/2002 +1200, Peter Gutmann wrote:
>"Housley, Russ" <[e-mail]> writes:
>
> >Here is my proposed solution: use a different algorithm identifier in the
> >certificate.  I suggest that the id-RSAES-OAEP be used in the certificate
> >subject public key info field to indicate that the public key should ONLY be
> >used with RSA OAEP.
>
>Hmm, I can see some problems with this.  From the technical point of view it's
>probably the easiest way to do it, but I can see horrible deployment problems.
>What you're doing is creating something which quacks like an RSA key but which
>will fail to work with anything which normally uses RSA keys.  I think I'd
>have quite some problems laying this out for developers, let alone end users -
>all they'd see is an RSA key which doesn't work properly.
>
>I'm also not sure that this is an algorithm issue.  An RSA key is an RSA key,
>whether you use it for PKCS #1, 9796, X9.31, or OAEP.  We don't ship them with
>OIDs saying they can't be used to wrap RC4/40 keys, or used on public internet
>terminals, or fed to your parrot.
>
>I'd prefer to delegate this to the application (via SMIMECapabilities) like
>most other stuff of this nature.  Alternatively, create an extKeyUsage or
>something, but creating a cert which (deliberately) doesn't work properly when
>you try and use it really seems to be asking for trouble.
>
>Peter.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g72DahA13701 for ietf-smime-bks; Fri, 2 Aug 2002 06:36:43 -0700 (PDT)
Received: from vulcan.rsasecurity.com (mail.rsasecurity.com [204.167.114.123]) by above.proper.com (8.11.6/8.11.3) with SMTP id g72Dafw13696 for <[e-mail]>; Fri, 2 Aug 2002 06:36:41 -0700 (PDT)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 2 Aug 2002 13:36:42 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id JAA27676 for <[e-mail]>; Fri, 2 Aug 2002 09:36:41 -0400 (EDT)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.10.2) with ESMTP id g72DYYb01901 for <[e-mail]>; Fri, 2 Aug 2002 09:34:34 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <3TPVDB2Y>; Fri, 2 Aug 2002 09:36:39 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.9.7]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3TPVDB2V; Fri, 2 Aug 2002 09:36:33 -0400
From: "Housley, Russ" <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Fri, 02 Aug 2002 09:26:03 -0400
Subject: RE: RSA OAEP Public Key Identification
In-Reply-To: <004201c239f6$76782ac0$[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Jim:

Yes, it could all be in one document.  At some point, when RFC 3279 is 
updated, the certificate-relevant information should go there.

Russ

At 12:30 AM 8/2/2002 -0700, Jim Schaad wrote:
>Russ,
>
>I do like the idea of specifying a different key identificater OID for
>RSA OAEP.  I don't like the idea of spreading this information over
>multiple documents. (How do to the Certificate in one draft, how to use
>in CMS in a second draft, possiblibly a third thing in a third draft.)
>Can we combine together some of the specification?
>
>jim
>
> > -----Original Message-----
> > From: [e-mail]
> > [mailto:[e-mail]] On Behalf Of Housley, Russ
> > Sent: Thursday, August 01, 2002 2:01 PM
> > To: [e-mail]
> > Subject: RSA OAEP Public Key Identification
> >
> >
> >
> > At the meeting in Yokohama, we discussed the RSA OAEP draft.
> > One of the
> > areas that was discussed was the security considerations
> > section, where the
> > document recommends that a key pair only be used for one
> > purpose.  Presently, we do not have a mechanism for
> > identifying how a key
> > holder would like to have their public key used.
> >
> > The certificate currently tells the message originator that
> > the public key
> > is an RSA key, and the key usage extension tells that the
> > public key can be
> > used for key transport.  There is nothing to tell the message
> > originator
> > whether RSA PKCS #1 v1.5 or RSA OAEP ought to be used with a
> > particular
> > key.  So, there is no indication to the message originator
> > that will allow
> > the security consideration to be implemented.
> >
> > Here is my proposed solution: use a different algorithm
> > identifier in the
> > certificate.
> >
> > I suggest that the id-RSAES-OAEP be used in the certificate
> > subject public
> > key info field to indicate that the public key should ONLY be
> > used with RSA
> > OAEP.
> >
> > This proposal may make transition from RSA PKCS #1 v1.5 to
> > RSA OAEP a bit
> > more difficult, since it would not allow one key pair to be
> > used with both
> > algorithms.  However, this is exactly what the security
> > considerations
> > recommend.
> >
> > Does anyone have concerns with this approach?
> >
> > If this approach is adopted, then a companion document in the
> > PKIX working
> > group for the proper handling of RSA OAEP (and probably RSA
> > PSS) public
> > keys will likely be needed.
> >
> > Russ
> >


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g72C7nX09340 for ietf-smime-bks; Fri, 2 Aug 2002 05:07:49 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g72C7mw09334 for <[e-mail]>; Fri, 2 Aug 2002 05:07:48 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15766; Fri, 2 Aug 2002 08:06:37 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-smime-cms-rsaes-oaep-05.txt
Date: Fri, 02 Aug 2002 08:06:37 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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

	Title		: Use of the RSAES-OAEP Transport Algorithm in CMS
	Author(s)	: R. Housley
	Filename	: draft-ietf-smime-cms-rsaes-oaep-05.txt
	Pages		: 13
	Date		: 01-Aug-02
	
This document describes the use of the RSAES-OAEP key transport
method of key management within the Cryptographic Message Syntax
(CMS).

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

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

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

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


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

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-smime-cms-rsaes-oaep-05.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-smime-cms-rsaes-oaep-05.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-smime-cms-rsaes-oaep-05.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.11.6/8.11.3) id g728nTg24579 for ietf-smime-bks; Fri, 2 Aug 2002 01:49:29 -0700 (PDT)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g728nRw24569 for <[e-mail]>; Fri, 2 Aug 2002 01:49:27 -0700 (PDT)
Received: from ruru.cs.auckland.ac.nz (ruru-nfs.cs.auckland.ac.nz [130.216.35.12]) by hermes.cs.auckland.ac.nz (8.12.4/8.12.4) with ESMTP id g728nLq9015419; Fri, 2 Aug 2002 20:49:21 +1200
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id UAA63374; Fri, 2 Aug 2002 20:49:18 +1200 (NZST) (sender [e-mail])
Date: Fri, 2 Aug 2002 20:49:18 +1200 (NZST)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re:  RSA OAEP Public Key Identification
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>

"Housley, Russ" <[e-mail]> writes:

>Here is my proposed solution: use a different algorithm identifier in the
>certificate.  I suggest that the id-RSAES-OAEP be used in the certificate
>subject public key info field to indicate that the public key should ONLY be
>used with RSA OAEP.

Hmm, I can see some problems with this.  From the technical point of view it's
probably the easiest way to do it, but I can see horrible deployment problems.
What you're doing is creating something which quacks like an RSA key but which
will fail to work with anything which normally uses RSA keys.  I think I'd
have quite some problems laying this out for developers, let alone end users -
all they'd see is an RSA key which doesn't work properly.

I'm also not sure that this is an algorithm issue.  An RSA key is an RSA key,
whether you use it for PKCS #1, 9796, X9.31, or OAEP.  We don't ship them with
OIDs saying they can't be used to wrap RC4/40 keys, or used on public internet
terminals, or fed to your parrot.

I'd prefer to delegate this to the application (via SMIMECapabilities) like
most other stuff of this nature.  Alternatively, create an extKeyUsage or
something, but creating a cert which (deliberately) doesn't work properly when
you try and use it really seems to be asking for trouble.

Peter.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g727VcL11844 for ietf-smime-bks; Fri, 2 Aug 2002 00:31:38 -0700 (PDT)
Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g727Vbw11840 for <[e-mail]>; Fri, 2 Aug 2002 00:31:37 -0700 (PDT)
Received: from revelation ([12.230.156.246]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020802073132.DPIE19356.rwcrmhc51.attbi.com@revelation>; Fri, 2 Aug 2002 07:31:32 +0000
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: "'Housley, Russ'" <[e-mail]>, <[e-mail]>
Subject: RE: RSA OAEP Public Key Identification
Date: Fri, 2 Aug 2002 00:30:22 -0700
Message-ID: <004201c239f6$76782ac0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
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>

Russ,

I do like the idea of specifying a different key identificater OID for
RSA OAEP.  I don't like the idea of spreading this information over
multiple documents. (How do to the Certificate in one draft, how to use
in CMS in a second draft, possiblibly a third thing in a third draft.)
Can we combine together some of the specification?

jim

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Housley, Russ
> Sent: Thursday, August 01, 2002 2:01 PM
> To: [e-mail]
> Subject: RSA OAEP Public Key Identification
> 
> 
> 
> At the meeting in Yokohama, we discussed the RSA OAEP draft.  
> One of the 
> areas that was discussed was the security considerations 
> section, where the 
> document recommends that a key pair only be used for one 
> purpose.  Presently, we do not have a mechanism for 
> identifying how a key 
> holder would like to have their public key used.
> 
> The certificate currently tells the message originator that 
> the public key 
> is an RSA key, and the key usage extension tells that the 
> public key can be 
> used for key transport.  There is nothing to tell the message 
> originator 
> whether RSA PKCS #1 v1.5 or RSA OAEP ought to be used with a 
> particular 
> key.  So, there is no indication to the message originator 
> that will allow 
> the security consideration to be implemented.
> 
> Here is my proposed solution: use a different algorithm 
> identifier in the 
> certificate.
> 
> I suggest that the id-RSAES-OAEP be used in the certificate 
> subject public 
> key info field to indicate that the public key should ONLY be 
> used with RSA 
> OAEP.
> 
> This proposal may make transition from RSA PKCS #1 v1.5 to 
> RSA OAEP a bit 
> more difficult, since it would not allow one key pair to be 
> used with both 
> algorithms.  However, this is exactly what the security 
> considerations 
> recommend.
> 
> Does anyone have concerns with this approach?
> 
> If this approach is adopted, then a companion document in the 
> PKIX working 
> group for the proper handling of RSA OAEP (and probably RSA 
> PSS) public 
> keys will likely be needed.
> 
> Russ
> 



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g727TTr11337 for ietf-smime-bks; Fri, 2 Aug 2002 00:29:29 -0700 (PDT)
Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g727TSw11330 for <[e-mail]>; Fri, 2 Aug 2002 00:29:28 -0700 (PDT)
Received: from revelation ([12.230.156.246]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020802072922.DOGU19356.rwcrmhc51.attbi.com@revelation>; Fri, 2 Aug 2002 07:29:22 +0000
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: "'Blake Ramsdell'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: AES and PKCS #1 v1.5 Issue
Date: Fri, 2 Aug 2002 00:28:12 -0700
Message-ID: <004101c239f6$29459800$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
In-Reply-To: <006001c2386d$682856a0$[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Blake,



> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Blake Ramsdell
> Sent: Wednesday, July 31, 2002 1:37 AM
> To: [e-mail]; 'Peter Gutmann'
> Cc: [e-mail]
> Subject: Re: AES and PKCS #1 v1.5 Issue
> 
> 
> 
> ----- Original Message ----- 
> From: "Jim Schaad" <[e-mail]>
> To: "'Blake Ramsdell'" <[e-mail]>; "'Peter 
> Gutmann'" <[e-mail]>
> Cc: <[e-mail]>
> Sent: Tuesday, July 30, 2002 7:49 PM
> Subject: RE: AES and PKCS #1 v1.5 Issue
> 
> 
> > 4. [Blake] Specification purity says that key management and content
> > encryption documents should not restrict each other.
> > - Blake - I just completely disagree on this issue.  I 
> think that each
> > type of algorithm can put restrictions and updates on usage for the
> > other type.  I believe that it is perfectly reasonable for a content
> > encryption algorithm to impose limitations on what key management
> > algorithms are allowed.  It could also modify the algorithms as
> > necessary (for example the original drafts change the key derivation
> > algorithm used with AES and D-H).  I can get behind the 
> purity of one
> > algorithm-one document, but not that they cannot put restrictions on
> > each other.
> 
> I did not say that an algorithm profile could not put a 
> restriction its use with another algorithm.  I said that if 
> the reason for the restriction is not specific to the 
> algorithm (in this case, the problems with PKCS #1 v1.5 are 
> not specific to its use with AES), then it doesn't make sense 
> to single it out in the algorithm profile.
> 
> Once again, the problem is not specific to the exact 
> combination of AES and PKCS #1 v1.5, and so we are not doing 
> the right thing if we have not covered it adequately in 
> either the CMS or MSG specification.  If we're going to 
> preclude the use of PKCS #1 v1.5, we should do it completely 
> or not at all.  It is unreasonable, redundant and wasteful to 
> mandate that all future symmetric algorithm profiles include 
> information about just how bad PKCS #1 v1.5 is, when we can 
> just provide guidance for the use / nonuse of PKCS #1 v1.5 in 
> CMS or MSG or some other general specification.
> 
> The point is not that AES should not use PKCS #1 v1.5, the 
> point is that if AES should not use PKCS #1 v1.5, then no 
> future symmetric algorithm should use PKCS #1 v1.5.  Existing 
> algorithms can be grandfathered, and we progress using new 
> guidelines for key wrapping.  For each draft author to take 
> their own individual stand on this issue and put their own 
> take on this into their draft doesn't seem productive.
> 
> In my mind, we are in one of two states at this point:
> 
> 1. CMS and MSG are completely reasonable in their treatment 
> of PKCS #1 v1.5, and no language with respect to this is 
> required in the AES draft.  If this is the case, I recommend 
> that we remove the PKCS #1 v1.5 specific language from the AES draft.
> 
> 2. CMS and MSG are incomplete in their treatment of PKCS #1 
> v1.5, and the language in the AES specification is attempting 
> to remedy this.  If this is the case, I recommend that we 
> remove the PKCS #1 v1.5 specific language from the AES draft, 
> and clarify the language accordingly in CMS and MSG.
> 
> Blake
> 

First, I would argue that the language to deal with this in MSG must be
considered to be extranious and could be removed altogether as far as I
am concerned.  Any argument based on it's presense in MSG is S/MIME
based on CMS based.

Second, CMS currently does not have any restrictions in RFC 2630 or its
follow on about algorithms.  This is by design and I still feel is
proper.

Third, we cannot suddenly outlaw PKCS #1 v1.5 without doing great harm
to the current community.  [Side note, I think that outlawing MD2 would
not cause great harm but that is a different problem.]  I don't have any
reason to believe that 3DES, RC2 and other algorithms of the same
general strength need to have a prohibition on v1.5 as they are the
current set of standards and we don't have an easy attack based on the
current uses.

Fourth, with the introduction of AES we are, in theory, bumping up the
level of difficulty in dealing with content encryption algorithms and
should fix any known key transport problems at the same time.  This is
what I have attempted to do.

Last,  I would be happy to move this language to CMSALG, but am unclear
as to how it should be phrased.  You MUST only use with the following
content encryption algoriths?  This would mean that either the list
would need to be exhaustive (3DES, RC2, CAST-128, IDEA,...) and these
standards would all need to be either informational or moved up the
standards track.  Or it would be small (3DES and RC2) and all of the
other algorithms would need to be re-issued saying, and me too.  But
this also violates your sense of purity.   I am unable to come up with a
good way to specify this without putting it into the AES draft and I
feel strongly that this needs to be specified.

Jim



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g71L0rq10251 for ietf-smime-bks; Thu, 1 Aug 2002 14:00:53 -0700 (PDT)
Received: from vulcan.rsasecurity.com (mail.rsasecurity.com [204.167.114.123]) by above.proper.com (8.11.6/8.11.3) with SMTP id g71L0pw10245 for <[e-mail]>; Thu, 1 Aug 2002 14:00:52 -0700 (PDT)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 1 Aug 2002 21:00:54 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id RAA23163 for <[e-mail]>; Thu, 1 Aug 2002 17:00:54 -0400 (EDT)
Received: from exeu00.securid.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.10.2) with ESMTP id g71KwjN12567 for <[e-mail]>; Thu, 1 Aug 2002 16:58:46 -0400 (EDT)
Received: by exeu00.eu.rsa.net with Internet Mail Service (5.5.2653.19) id <P68R531S>; Thu, 1 Aug 2002 22:04:05 +0100
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.9.27]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3TPVCZ4F; Thu, 1 Aug 2002 17:00:46 -0400
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 01 Aug 2002 17:00:42 -0400
To: [e-mail]
From: "Housley, Russ" <[e-mail]>
Subject: RSA OAEP Public Key Identification
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>

At the meeting in Yokohama, we discussed the RSA OAEP draft.  One of the 
areas that was discussed was the security considerations section, where the 
document recommends that a key pair only be used for one 
purpose.  Presently, we do not have a mechanism for identifying how a key 
holder would like to have their public key used.

The certificate currently tells the message originator that the public key 
is an RSA key, and the key usage extension tells that the public key can be 
used for key transport.  There is nothing to tell the message originator 
whether RSA PKCS #1 v1.5 or RSA OAEP ought to be used with a particular 
key.  So, there is no indication to the message originator that will allow 
the security consideration to be implemented.

Here is my proposed solution: use a different algorithm identifier in the 
certificate.

I suggest that the id-RSAES-OAEP be used in the certificate subject public 
key info field to indicate that the public key should ONLY be used with RSA 
OAEP.

This proposal may make transition from RSA PKCS #1 v1.5 to RSA OAEP a bit 
more difficult, since it would not allow one key pair to be used with both 
algorithms.  However, this is exactly what the security considerations 
recommend.

Does anyone have concerns with this approach?

If this approach is adopted, then a companion document in the PKIX working 
group for the proper handling of RSA OAEP (and probably RSA PSS) public 
keys will likely be needed.

Russ


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g71I6Bm02061 for ietf-smime-bks; Thu, 1 Aug 2002 11:06:11 -0700 (PDT)
Received: from wfhqex05.gfgsi.com (netva01.getronicsgov.com [67.105.229.98]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g71I6Bw02056 for <[e-mail]>; Thu, 1 Aug 2002 11:06:11 -0700 (PDT)
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: v2.1 S/MIME Freeware Library (SFL) Now Available
Date: Thu, 1 Aug 2002 14:06:07 -0400
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: v2.1 S/MIME Freeware Library (SFL) Now Available
Thread-Index: AcI5hhsP6XOt1UY5R2CHe/iQEv/4vw==
From: "Pawling, John" <[e-mail]>
To: "SMIME WG (SMIME WG)" <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g71I6Bw02057
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 the Version 2.1 
S/MIME Freeware Library (SFL) source code.  The SFL source code files
and documents are freely available 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++ freeware library, the SFL implements the 
RFC 2631 Diffie-Hellman (D-H) Key Agreement Method specification.  It 
has been successfully tested using the Microsoft (MS) Windows 
NT/98/2000/XP, Linux and Sun Solaris 2.8 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: DSA, E-S D-H, 3DES algorithms provided by the 
Crypto++ library; RSA suite of algorithms provided by the RSA BSAFE 6.0
Crypto-C and Crypto++ libraries; and Fortezza suite of algorithms 
provided by the Fortezza Crypto Card.  The v2.1 SFL uses the v2.1 
Certificate Management Library (CML) and v1.4 Enhanced SNACC (eSNACC) 
ASN.1 C++ Library to encode/decode objects.  The v2.1 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; Microsoft CAPI v2.0 CTIL; 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.8.  

The SFL has been successfully used to exchange signedData and 
envelopedData messages with the MS Internet Explorer Outlook Express 
v4.01, Netscape Communicator 4.X, Entrust and Baltimore S/MIME 
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,
DSA, E-S D-H, 3DES, SHA and Fortezza algorithms.  We used the SFL to 
successfully process 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.

The use of the v2.1 SFL is described in the v2.1 SFL Application
Programming Interface (API) and v2.1 SFL Software Design Description
documents.  The use of the v2.1 CTIL API is described in the v2.1
CTIL API document. 


v2.1 SFL includes the following enhancements (compared to v2.0.1 
(Patch A) SFL and CTIL releases):

1) To make it easier for integrators to retrieve and compile the
source code for the ACL, SFL and CML libraries, we delivered a
consolidated release zip file including the source code, 
project files, make files, and readme files for
the SFL, CML, Storage Retrieval Library (SRL), ACL, CTIL, and
CTILManager libraries.  

2) Eliminated SFL dependency on the LibCert dynamic library to
reduce the complexity of integrating the SFL into applications.

3) Enhanced SFL to provide the signer's certificate that matches
the Issuer/Serial (or keyId) of an application-designated 
SignerInfo in a signedData object.  We also enhanced the SFL to
provide the encrypter's certificate that matches the 
Issuer/Serial (or keyId) of an application-designated 
originatorInfo in an envelopedData object.  This included
enhancing the SFL to use the SRL to store all certificates 
and CRLs extracted from the signedData or envelopedData objects 
into the SRL database.  

4) Enhanced SFL to optionally use the CML to build and validate:
recipients' certification paths as part of encrypting S/MIME 
messages; signer's certification path as part of verifying 
signed messages; and encrypter's certification path (if 
required for pairwise key generation) as part of decrypting 
a message.  This included enhancing the SFL to use the SRL to
retrieve certificates and CRLs from the SRL database.  These 
enhancements will significantly reduce the amount of time 
required by vendors to integrate the CML and SFL into their 
applications.

5) Enhanced SFL to use a standard Exception class that will
enable applications to catch all exceptions using the standard
class.  This enhancement will reduce the amount of time 
required to integrate the SFL, CML, ACL, and eSNACC libraries
into applications.  

6) SFL was updated to fix minor memory leaks and bugs.


v2.1 CTILs include the following enhancements (compared to
v2.0.1 release):

1) Eliminated the CTIL Manager Library dependency on the 
LibCert dynamic library to reduce the complexity of 
integrating the CTILs into applications.

2) Enhanced CTILs to decode and decrypt PKCS #12 files.
This eliminates the dependency on the OpenSSL library and
significantly reduces the size of the CTILs that used OpenSSL.  

3) Enhanced the CTIL API to allow all relevant crypto 
algorithm(s) (i.e. hash, signature, encryption, decryption, 
key management) to be specified per crypto operation.

4) Changed to use standard SMP Exception class derived 
from C++ std::exception class.  

5) MS CAPI CTIL was updated to fix minor memory leaks and bugs.


v2.1 CertificateBuilder utility includes the following enhancements
(compared to v2.0.1 release):

1) Added capability to generate X.509 (2000) Attribute Certificates
including X.501 Clearance attributes including user-selected values 
extracted from Security Policy Information File (SPIF) for the
security policy.  

2) Added capability to generate ESSSecurityLabels.  

3) Enhanced to use the standard Exception class.


We are still in the process of enhancing and testing the SFL.  Future 
releases may include: additional PKCS #11 CTIL testing;  
add "Certificate Management Messages over CMS" ASN.1 encode/decode 
functions; add enhanced test routines; bug fixes; 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.8, 
we may port the SFL to other operating systems.

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.  
 
The SFL uses the CML and eSNACC ASN.1 Library to encode/decode
certificates, ACs, CRLs and components thereof.  The CML is freely
available at: <http://www.getronicsgov.com/hot/cml_home.htm>.

The SFL has been successfully tested in conjunction with the Access
Control Library (ACL) that is freely available to everyone from: 
<http://www.getronicsgov.com/hot/acl_home.htm>.

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.

NIST is using the SFL and CML as part of the NIST S/MIME Test 
Facility (NSMTF) that they are planning to host (see 
<http://csrc.ncsl.nist.gov/pki/smime/>).  Vendors will be able to use
the NSMTF to help determine if their products comply with the
IETF S/MIME v3 specifications and the Federal S/MIME v3 Client Profile. 

The SFL has been integrated into many applications to provide CMS/ESS
security services.  For example, the SFL was integrated into a security
plug-in for a commercial e-mail application that enabled the 
application to meet the Bridge Certification Authority Demonstration 
Phase II requirements including implementing ESS features such as
security labels.

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: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g71Gmd925359 for ietf-smime-bks; Thu, 1 Aug 2002 09:48:39 -0700 (PDT)
Received: from wfhqex05.gfgsi.com (netva01.getronicsgov.com [67.105.229.98]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g71Gmdw25355 for <[e-mail]>; Thu, 1 Aug 2002 09:48:39 -0700 (PDT)
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: v1.4 Enhanced SNACC Freeware Now Available
Date: Thu, 1 Aug 2002 12:48:34 -0400
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: v1.4 Enhanced SNACC Freeware Now Available
Thread-Index: AcI5cp6Z14OJyzHGQ8i472hAAgjQnA==
From: "Pawling, John" <[e-mail]>
To: "SMIME WG (SMIME WG)" <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g71Gmdw25356
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 the v1.4 eSNACC
Abstract Syntax Notation.1 (ASN.1) Compiler, C++ library and C library
source code compilable for Linux, Sun Solaris 2.8 and Microsoft (MS) 
Windows NT/98/2000/XP.  The eSNACC software is freely available to
everyone from: <http://www.getronicsgov.com/hot/snacc_home.htm>.

The eSNACC ASN.1 software can be used to ASN.1 encode and decode
objects.  In past releases, Getronics improved the eSNACC C++ 
library to implement the Distinguished Encoding Rules (DER), 
support large ASN.1 INTEGERs, and improve memory usage.    


v1.4 eSNACC enhancements (compared to v1.3 R10 release):

1) Enhanced AsnInt class to support string form of large 
integers (binary & hex strings).   

2) Enhances AsnInt so that it does not use AsnOcts or 
CSM_Buffer. 

3) Remove CSM_Buffer as base class for AsnInt and all of 
the string classes.  Also deleted the xxxStringSNACC 
classes (i.e., BMPStringSNACC).  

4) Added the remaining asn-useful types (UTCTime, 
GeneralizedTime, etc.) into eSNACC C and C++ libraries as
native built-in types.  This removes the unnecessary
complexity of having to build a boot compiler prior to 
building the final compiler.

5) Enhanced to use a standard Exception class derived from the
C++ std::exception class that will enable applications to catch 
all exceptions using the standard class.  This enhancement will 
reduce the amount of time required to integrate the SFL, CML, ACL,
and eSNACC libraries into applications.  

6) Re-wrote makefiles to make build process easier and faster.

7) Enhanced AsnBits class to construct BitStrings from 
binary strings.

8) Added AsnSetOf and AsnSeqOf templates.

9) Moved BDecPdu to AsnType, so every type as access to it now.
This was done to reduce the number of symbols & methods the
compiler generates.
  
10) Enhanced compiler to remove -u switch because useful types
are now in the runtime library.


We successfully tested the v1.4 eSNACC ASN.1 C++ and C libraries
using the Simple Network Management Protocol (SNMP) v1 test
suite (18,000 test cases) developed by the University of Oulu.    

We tested the v1.4 eSNACC release with the v2.1 S/MIME
Freeware Library (SFL) available from 
<http://www.getronicsgov.com/hot/sfl_home.htm> that 
uses the eSNACC ASN.1 software to encode and decode the IETF 
S/MIME v3 Cryptographic Message Syntax (RFC 2630) and Enhanced
Security Services for S/MIME (RFC 2634) security protocol.  

We tested the v1.4 eSNACC release with the freeware v2.1
Certificate Management Library (CML) available from
<http://www.getronicsgov.com/hot/cml_home.htm> 
that uses the eSNACC ASN.1 software to encode and decode X.509 
certificates, attribute certificates and Certificate Revocation 
Lists as specified in the 2000 X.509 Recommendation.

We tested the v1.4 eSNACC release with the freeware v2.1 
Access Control Library (ACL) available from 
<http://www.getronicsgov.com/hot/acl_home.htm>
that uses the eSNACC ASN.1 software to encode and decode security
labels and other objects (such as Security Policy Information 
Files) required to provide rule based automated access control 
as specified in SDN.801.

The eSNACC ASN.1 software implements the majority of the 
ASN.1 encoding/decoding rules as specified in the 1988 X.209 
Recommendation.  It implements the DER as specified in the 1997 
X.690 Recommendation.  It does not support all of the latest ASN.1
features, but there are strategies that allow it to be used to 
produce ASN.1 hex encodings that are identical to those produced by
ASN.1 libraries that do support the latest ASN.1 features.  Also note
that many of the PKIX specs, such as RFC 3280 and RFC 2630, include 
1988-compliant ASN.1 syntax modules which can be compiled using the
eSNACC compiler.  Getronics plans to enhance eSNACC to support 
additional ASN.1 features.

The eSNACC ASN.1 library is totally unencumbered as stated 
in the Enhanced SNACC Software Public License.  All source code
for the eSNACC software is being provided at no cost and with no
financial limitations regarding its use and distribution.  
Organizations can use the eSNACC software without paying
any royalties or licensing fees.  

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

We welcome all feedback regarding the eSNACC software.
If bugs are reported, then we will investigate each reported
bug and, if required, will produce a patch or an updated
release of the software to repair the bug. 

This release announcement was sent to several mail lists,
but please send all messages regarding the eSNACC 
software to the imc-snacc mail list ONLY.  Please do not send 
messages regarding the eSNACC software to any of the 
IETF mail lists.  We will respond to all messages sent to the
imc-snacc mail list.

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


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g71BkiJ10101 for ietf-smime-bks; Thu, 1 Aug 2002 04:46:44 -0700 (PDT)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g71Bkgw10090 for <[e-mail]>; Thu, 1 Aug 2002 04:46:42 -0700 (PDT)
Received: from ruru.cs.auckland.ac.nz (ruru-nfs.cs.auckland.ac.nz [130.216.35.12]) by hermes.cs.auckland.ac.nz (8.12.4/8.12.4) with ESMTP id g71Bkbq9023137; Thu, 1 Aug 2002 23:46:37 +1200
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id XAA447290; Thu, 1 Aug 2002 23:46:35 +1200 (NZST) (sender [e-mail])
Date: Thu, 1 Aug 2002 23:46:35 +1200 (NZST)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail], [e-mail]
Subject: RE: digested-data
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>

Trevor Perrin <[e-mail]> writes:

>I still don't understand why you can't do two layers in a single pass. I'd
>assume that at a certain point the inner layer is finished with the previous X
>bytes, so it could pass control to the outer layer who could chew on them, and
>when it's consumed that chunk, pass control back to the inner layer, etc..
>But I don't really know anything about ASN.1, so never mind..

I've been going through this in private mail with someone else, so I'll be lazy
and cut&paste:

-- Snip --

Changing a single byte of inner content can change several bytes of outer
content due to variable-length length-of-length encoding, and there are some
data lengths which can never be achieved, eg. when you move from a short-
encoded data length to a long-encoded one and adding a single byte to the data
also increases the length-of-length value.  When you combine this with data
blocking requirements and requirements for PKCS #5 padding, it becomes
unworkably complex to implement and test unless you buffer an entire message,
in which case you're just doing a standard two-pass encoding.

>indefinite length constructed form.

That's the magic phrase.  If you use definite-length encoding, it becomes an
unsolveable problem in the general case.  You have to do this (use the use
definite-length form) because there are implementations which can't process
indefinite-length data ("Gee, we never thought anyone would use that!") or
process it really badly (bad buffer management, "Why is our code two orders of
magnitude slower than yours?").

-- Snip --

Peter.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g719uro02517 for ietf-smime-bks; Thu, 1 Aug 2002 02:56:53 -0700 (PDT)
Received: from bsd.sigaba.com (bsd.sigaba.com [67.113.238.131]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g719upw02513 for <[e-mail]>; Thu, 1 Aug 2002 02:56:51 -0700 (PDT)
Received: from exchange1.sigaba.com (exchange1.sigaba.com [10.10.10.10]) by bsd.sigaba.com (8.12.2/8.12.2) with ESMTP id g719ug3E007492; Thu, 1 Aug 2002 02:56:42 -0700
Received: by exchange.sigaba.com with Internet Mail Service (5.5.2653.19) id <QBYZ2XQB>; Thu, 1 Aug 2002 02:57:20 -0700
Message-ID: <[e-mail]>
From: Trevor Perrin <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, Trevor Perrin <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: digested-data
Date: Thu, 1 Aug 2002 02:57:19 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g719upw02514
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 Peter,

I still don't understand why you can't do two layers in a single pass.  I'd
assume that at a certain point the inner layer is finished with the previous
X bytes, so it could pass control to the outer layer who could chew on them,
and when it's consumed that chunk, pass control back to the inner layer,
etc..  But I don't really know anything about ASN.1, so never mind..

Anyways, I was thinking S/MIME clients might reject a message that decrypts
with garbled, non-ASCII characters.  Outlook Express at least doesn't.
Given CBC chaining it was easy to modify the ciphertext block previous to a
known plaintext block to change the known plaintext block to anything
desired, at the cost of garbling the modified block.  Presumably I could cut
and paste chunks of ciphertext around as well, and with a stereotyped
plaintext and some experimentation I'm sure all sorts of devilment could be
done with that...

Maybe this is "working as designed", but I think most users of S/MIME would
be surprised.  Has this been discussed before?  Is there a group consensus
I'm unaware of?  If not, is it worth trying to remedy this now? 


modified plaintext line, as displayed by OE:
AAAAAAAAAAAAAAAAAAAAAAA8á8$2@ HELLOAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

Trevor




-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
Sent: Sunday, July 28, 2002 8:55 PM
To: [e-mail]; [e-mail]; [e-mail]
Subject: RE: digested-data, surreptitious forwarding, D-H


Trevor Perrin <[e-mail]> writes:

>Interesting, I'd assumed that you could do multiple layers (like a
>digestedData and envelopedData, or signedData and envelopedData) in a
single
>pass, by hashing and then encrypting each content block, then moving to the
>next one, etc..  You're saying that this isn't possible, 

It isn't, because of ASN.1 encoding restrictions.  Changing a single byte of
inner content can change several bytes of outer content due to
variable-length
length-of-length encoding, and there are some data lengths which can never
be
achieved, eg. when you move from a short-encoded data length to a
long-encoded
one and adding a single byte to the data also increases the length-of-length
value.  When you combine this with data blocking requirements and
requirements
for PKCS #5 padding, it becomes unworkably complex to implement and test
unless
you buffer an entire message, in which case you're just doing a standard
two-
pass encoding.

>but the scheme below can be done in one pass?

Sure, since the encoding is one-step.  With DigestedData you're
encapsulating
the entire data block just to add a 20-byte hash at the end.  All this does
it add the hash at the end of the EncryptedData.

Peter.