Subject: WA:NT" A. BIG C'O.C"K _' wqqophaevt

From: "Freeman Waller" <[email-masked]>
Date: Mon, 01 Dec 2003 16:59:33 +0000

Traditional,
liberal or newschool? Depends on how you were raised.
Are we getting political here? Hell, no! This is just
to describe
your sex life.

If you're traditional, delete this mail
now. Please.
If you're liberal, you get yourself some pills
after you've
realized that hanging a two-pounds stone
from your cock doesn't
make it longer.
If you're newschool, you happily dabble
with things others don't
even know about.

Traditionals have already deleted this
mail. Ahem.
Liberals -
click here for the VP-RX, the best
penis enlargement ever
invented. If you're
liberal heart rebels, no worry, it's
money back guarantee. Check out what
VP-RX can do to you remember, if
the name sounds like a robot, it surely
does a lot of things to you!

Newschoolers - use the most
advanced scientific solution to
enlarge
your treasured organ - with a Magna-RX
patch! Tht's right, no pills,
creams, pumps, exercises - but the
fuller, thicker feeling and the
visible results can surely give you
that tingling boost of self-
confidence..
and the aching of that cock after four
hours of a steamy threesome!

Click
here to know more about this brand-new patch!

Remove
me

Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAIFUAkT069780 for ; Tue, 18 Nov 2003 07:30:10 -0800 (PST) (envelope-from [email-masked])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAIFUAKh069779 for ietf-smime-bks; Tue, 18 Nov 2003 07:30:10 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [email-masked] using -f
Received: from smtp006.bizmail.sc5.yahoo.com (smtp006.bizmail.sc5.yahoo.com [66.163.175.83]) by above.proper.com (8.12.10/8.12.8) with SMTP id hAIFUAkT069773 for ; Tue, 18 Nov 2003 07:30:10 -0800 (PST) (envelope-from [email-masked])
Received: from pcp04425525pcs.nrockv01.md.comcast.net (HELO Obsidian) ([email-masked]@69.140.137.37 with login) by smtp2.bm.vip.sc5.yahoo.com with SMTP; 18 Nov 2003 15:30:11 -0000
From: "Bonatti, Chris"
To: "'Jack Lloyd'"
Cc:
Subject: RE: CMS Implementation Questions
Date: Tue, 18 Nov 2003 10:30:10 -0500
Organization: IECA, Inc.
Message-ID: <[email-masked]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
In-Reply-To:
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id hAIFUAkT069774
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Jack Lloyd writes:
>
> On Mon, 17 Nov 2003, Bonatti, Chris wrote:
>
> > To take on a couple of the questions that Peter didn't
address...
> >
> > Jack Lloyd writes:
> >
> > > 3) It is legal to include SignedAttributes and sign
everything
> > > that way even when signing plain data content, correct?
> >
> > Yes, this is basically what SignedData is for. %-}
> > Maybe I'm not grokking the question.
> >
>
> When signing something other than plain data content, using
> the attributes is required (section 5.3 of 3369). Otherwise,
> they are described as "optional"; I'm presuming this means an
> implementation MAY use signed attributes when signing plain
> data content as well? It is all-in-all fairly clear, but I
> would prefer being 100% certain I know what it's trying to
> say. When an RFC isn't completely and totally clear, I don't
> like to just assume I'm guessing the correct interpretation.
>

The 'signedAttrs' field is an old function that goes back to
PKCS-7 (i.e., the 'authenticatedAttributes' field). It has
always been an option to include signed attributes in the
signature regardless of the type. I think the reason for the
requirement to include these for content types other than id-data
stems from the desire to have the PKCS-9 'ContentType' attribute
included to bind the type to the data. There has always been a
perception that MIME content was the "default" for PKCS-7. This
is supported by the fact that a MIME object is easily recognized,
and self-identifies what type(s) it carries. This is not true
for many other possible object types. I think that the
requirement to include the 'ContentType' attribute originally
comes from PKCS-9, though, not PKCS-7. There is no converse
requirement to omit signed attributes when signing MIME data.

I hope this helps.

Chris

Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAHI9nkT041064 for ; Mon, 17 Nov 2003 10:09:49 -0800 (PST) (envelope-from [email-masked])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAHI9nnq041063 for ietf-smime-bks; Mon, 17 Nov 2003 10:09:49 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [email-masked] using -f
Received: from centaur.acm.jhu.edu ([email-masked] [128.220.223.65]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAHI9mkT041049 for ; Mon, 17 Nov 2003 10:09:48 -0800 (PST) (envelope-from [email-masked])
Received: by centaur.acm.jhu.edu (Postfix, from userid 528) id ABC8C3EB56; Mon, 17 Nov 2003 13:09:48 -0500 (EST)
Received: from localhost (localhost [127.0.0.1]) by centaur.acm.jhu.edu (Postfix) with ESMTP id AAABB46840; Mon, 17 Nov 2003 13:09:48 -0500 (EST)
Date: Mon, 17 Nov 2003 13:09:48 -0500 (EST)
From: Jack Lloyd
X-X-Sender: [email-masked]
To: "Bonatti, Chris"
Cc: [email-masked]
Subject: RE: CMS Implementation Questions
In-Reply-To: <[email-masked]>
Message-ID:
X-GPG-Key-ID: 4DCDF398
X-GPG-Key-Fingerprint: 2DD2 95F9 C7E3 A15E AF29 80E1 D6A9 A5B9 4DCD F398
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

On Mon, 17 Nov 2003, Bonatti, Chris wrote:

> To take on a couple of the questions that Peter didn't address...
>
> Jack Lloyd writes:
>
> > 3) It is legal to include SignedAttributes and sign everything
> > that way even when signing plain data content, correct?
>
> Yes, this is basically what SignedData is for. %-}
> Maybe I'm not grokking the question.
>

When signing something other than plain data content, using the attributes
is required (section 5.3 of 3369). Otherwise, they are described as
"optional"; I'm presuming this means an implementation MAY use signed
attributes when signing plain data content as well? It is all-in-all fairly
clear, but I would prefer being 100% certain I know what it's trying to
say. When an RFC isn't completely and totally clear, I don't like to just
assume I'm guessing the correct interpretation.

> IMPLICIT.
>
> The module in clause 12.1 of RFC 3369 defaults to IMPLICIT
> tagging, and nothing in the definitions of SignerIdentifier or
> RecipientIdentifier override this default. In both instances,
> this means that the context-specific tag [0] replaces the OCTET
> STRING tag.

I saw the default tagging, but given the ease of mixups, I wanted to be
sure. There is lots of stuff in the module with explicit IMPLICIT tags,
which shouldn't really have to be there given that is the default encoding.
Sometimes IMPLICT tags are there, sometimes they are not. See last sentence
of my previous paragraph.

Thanks,
Jack

Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAHGOxkT036710 for ; Mon, 17 Nov 2003 08:24:59 -0800 (PST) (envelope-from [email-masked])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAHGOxfl036709 for ietf-smime-bks; Mon, 17 Nov 2003 08:24:59 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [email-masked] using -f
Received: from smtp004.bizmail.sc5.yahoo.com (smtp004.bizmail.sc5.yahoo.com [66.163.175.81]) by above.proper.com (8.12.10/8.12.8) with SMTP id hAHGOxkT036704 for ; Mon, 17 Nov 2003 08:24:59 -0800 (PST) (envelope-from [email-masked])
Received: from pcp04425525pcs.nrockv01.md.comcast.net (HELO Obsidian) ([email-masked]@69.140.137.37 with login) by smtp2.bm.vip.sc5.yahoo.com with SMTP; 17 Nov 2003 16:24:50 -0000
From: "Bonatti, Chris"
To: "'Jack Lloyd'"
Cc:
Subject: RE: CMS Implementation Questions
Date: Mon, 17 Nov 2003 11:24:49 -0500
Organization: IECA, Inc.
Message-ID: <[email-masked]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
In-Reply-To:
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id hAHGOxkT036705
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

To take on a couple of the questions that Peter didn't address...

Jack Lloyd writes:

> 3) It is legal to include SignedAttributes and sign everything
> that way even when signing plain data content, correct?

Yes, this is basically what SignedData is for. %-}
Maybe I'm not grokking the question.

> 4) Is the encoding of subjectKeyIdentifier in SignerIdentifier
and
> RecipientIdentifier supposed to be with EXPLICIT or IMPLICIT
tags?
> This is not particularly clear to me from the texts of RFCs
2630
> and 3369.

IMPLICIT.

The module in clause 12.1 of RFC 3369 defaults to IMPLICIT
tagging, and nothing in the definitions of SignerIdentifier or
RecipientIdentifier override this default. In both instances,
this means that the context-specific tag [0] replaces the OCTET
STRING tag.

Maybe somebody with RC2 code in front of them can address
question 5.

Chris

Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAHFLHkT032672 for ; Mon, 17 Nov 2003 07:21:17 -0800 (PST) (envelope-from [email-masked])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAHFLHYE032671 for ietf-smime-bks; Mon, 17 Nov 2003 07:21:17 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [email-masked] using -f
Received: from smtp001.bizmail.yahoo.com (smtp001.bizmail.yahoo.com [216.136.172.125]) by above.proper.com (8.12.10/8.12.8) with SMTP id hAHFLGkT032665 for ; Mon, 17 Nov 2003 07:21:16 -0800 (PST) (envelope-from [email-masked])
Received: from pcp04425525pcs.nrockv01.md.comcast.net (HELO Obsidian) ([email-masked]@69.140.137.37 with login) by smtp2.bm.vip.sc5.yahoo.com with SMTP; 17 Nov 2003 15:21:17 -0000
From: "Bonatti, Chris"
To:
Subject: Draft S/MIME WG Notes
Date: Mon, 17 Nov 2003 10:21:10 -0500
Organization: IECA, Inc.
Message-ID: <[email-masked]>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_NextPart_000_0037_01C3ACF4.8966CFC0"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
In-Reply-To:
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

This is a multi-part message in MIME format.

------=_NextPart_000_0037_01C3ACF4.8966CFC0
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit

Draft notes from last week's WG meeting are attached. Comments
or corrections are welcome, of course.

Regards,
Chris

------=_NextPart_000_0037_01C3ACF4.8966CFC0
Content-Type: text/plain;
name="IETF#58-SMIME-Notes.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
filename="IETF#58-SMIME-Notes.txt"

IETF 58th Meeting
Hilton Hotel - Minneapolis, Minnesota
SMIME WG
11 November 2003, 1700-1800

INTRODUCTION

The meeting was chaired by Blake Ramsdell of Brute Squad
Labs. The other co-chair, Sean Turner of IECA, was unable to
attend. Approximately 40 participants were in attendance.

The Chairman introduced the agenda. There were no comments
on the agenda from the WG. He acknowledged that Chris Bonatti
agreed to serve as note-taker. He asked for an official XMPP scribe,
but there were no volunteers. So the Chairman suggested that anybody
using XMPP act on their own recognizance to highlight important
statements over that service.

WG STATUS

The Chairman gave an update of the status of WG activities.
He reported the following:

There are two newly completed RFCs:

- RFC 3560: Use of the RSAES-OAEP Key Transport
Algorithm in the Cryptographic Message Syntax (CMS),
Russ Housley, July 2003.

- RFC 3565: Use of the Advanced Encryption Standard
(AES) Encryption Algorithm in Cryptographic Message
Syntax (CMS), Jim Schaad, July 2003.

Reported that four I-Ds were approved and were now in the
RFC Editor's Queue:
- draft-ietf-smime-camellia-05
- draft-ietf-smime-symkeydist-09
- draft-ietf-smime-x400wrap-09
- draft-ietf-smime-x400transport-09

WG Last Call coming up again on:
- draft-ietf-smime-rfc2632bis-04 (Son-of-CERT)
- draft-ietf-smime-rfc2633bis-06 (Son-of-MSG)
- draft-ietf-smime-examples-12

Up and coming drafts include:
- draft-ietf-smime-cms-rsa-kem-01
- draft-ietf-smime-gost-00

New draft coming in soon:
- draft-park-cms-seed-00

Completed milestones
- Submittted x400wrap and x400transport drafts

Open Milestones
- Complete rfc2632bis and rfc2633bis=20
- Complete examples draft
- Develop draft on RSA PSS algorithm

Longer Term
- WG Last Call on RSA KEM
- Submit RSA KEM
- Final S/MIME version 3.1 interoperability matrix

New Milestones
- SEED
- GOST

EXAMPLES

Paul Hoffman reported on the update to the CMS and ESS
Examples draft. He noted that major revision was performed since
Vienna. Essentially we admitted that we were in denial about a
lot of the examples, and so rethought the scope so that it took
at least two working implementations to include the case. Thus
many examples were deleted. There are still some outstanding
comments from Jim Schaad noting some bugs in the code. These
should be resolved shortly. He noted that comments are still
welcome. At least one comment outstanding.

MSGbis and CERTbis

Blake Ramsdell reported as the editor of MSGbis and CERTbis drafts.
He noted numerous changes from Jim Schaad (mostly editorial) had been
integrated into the document. He noted that he still needs to clear up
the "I-D Nits" issues (i.e., splitting references, etc.). He also
noted that he is waiting for a secondary validation of hex dump. Jim
Schaad is looking at this, but additional comments from others would
be helpful. He noted that there was a new issue on definition of
smimeCapabilities attribute values for the RC2 algorithm. It is not
clear that these are defined anywhere. Ideally, we would like to have
this elsewhere, but since it's kind of an afterthought we're going to
have to squeeze it into MSG. Another new issue that has been discussed
on the list is the guidance text on selection encryption algorithm.
There was some obsolete language that dealt with weaker algorithms.
Ramsdell indicated that he was revising text to update the decision
tree to lead you instead to 3DES.=20

Another new issue was clarification of the semantics of the
smime-type subtype. The smime-type is indicated an attribute on
the Content-Type MIME header. Current values defined in MSG
include signed-data, enveloped-data, compressed-data, and certs-
only. The question is, what is the right way to use this.

- As a hint for IMAP?
- As a content hint for processing?

Ramsdell stated that he believed this should really reflect the
outermost wrapper that must first be processed. Chris Bonatti
stated that he didn't have an answer to this question, but
pointed out that the x400wrap and x400transport drafts added some
new values of smime-type for signed-x400 and encrypted-x400.
While these clearly address more than just the outer wrapper,
they distinguish a different service and message spec than S/MIME
per se so there is some value. Indicating that he was an e-mail
implementer, DABOO stated that he does not want to have to decode
the entire content to know what kind of visual indicator to
present, but he does not think that these two things are
separate. Jim Schaad indicated that what brought this issue up
is the ambiguity of signed receipts. In the instance of a signed-
receipt that is also encrypted, which smime-type value should be
used: the signed-receipt (defined in RFC 2634) or encrypted-data
(as per the MSG spec)? Somebody (Blake?) noted that they have
the same issue with the SIP WG, in that they want to easily
identify data that contains SIP so that they can further process
them. The chairman noted that he was not sure whether the
Application Area should be consulted before deciding this matter.
The WG tentatively agreed that the strawman solution is that
smime-type is more a display hint than a processing hint, and
that we will clarify this in the document. More discussion on
the list is possible.

Ramsdell noted that there is a PKIX issue that may require
clarifications to the language regarding the subjectKeyIdentifier
(SKI), and that he is not clear what the outcome should be. The
problem is that use of the SKI to identify certificates is not
sufficiently unique by itself. The reason for this seems to be
that some implementations may issue crappy SKIs that are short,
locally incremented identifiers. We need to add language to
clarify that certificate processing when identified with SKI
should:

- Be prepared for matching multiple certificates;
- Be prepared for some of those candidate certificates to
fail.

This would help implementations to bullet-proof against failing
in what is a predictable scenario. Russ Housley, the Security
Area Director, stated that he agreed with most of this, but
indicated that we should preface this new text with the statement
that if the recommendations of RFC 3280 are followed (i.e., SKI
is the hash of the public key) then the overlap of these
identifiers is possible but unlikely. This text is required
mainly because that recommendation is a SHOULD instead of a
MUST.

Ramsdell also indicated that he had made several minor updates
to the CERTbis document. He reported that he has added
differences since 3.0 certificate profile to the document. He
has also added credits and minor editorial fixes.

PSS STATUS

Jim Schaad reported that he has finished the edits of the PKIX
version of PSS. This S/MIME PSS draft should be completed
shortly. He also indicated that the Interoperability Matrix
entries for CMS and CMSALG are finished. He still needs to do
some editorial work to clean up the document. The ESSbis issue
is still alive, but there has been no recent movement.

KEM STATUS

The Chairman reported speaking to Burt Kaliski of RSA, and
noted that the KEM draft is temporarily stalled. The KEM draft
is based on ANSI X9.44, which has not yet stabilized its ASN.1
syntax. The KEM draft cannot progress to RFC status until
relevant X9.44 areas are stabilized.

GOST STATUS

The Chairman reported that the GOST draft is being updated and
will be posted after the meeting. The new draft will add
normative references to CMS and Russian law. He noted there are
still some additional comments that need to be taken care of.
Normative reference to CPALGS is a problem. The GOST algorithm
needs to be described in an international standard, national
standard, or RFC. An informational RFC would be easiest. Russ
Housley stated that he thinks they are aiming to provide such an
informative RFC for the Seoul meeting. Paul Hoffman pointed out
that making it an RFC makes things a lot easier than the
alternatives. Ramsdell and Housley agreed. Another issue is
ASN.1 modules. The -00 draft uses the X.680 version of ASN.1,
and needs to switch to X.208-88 to align with the rest of S/MIME.
There are also too many modules in the draft. There were six
modules in the -00 version, and will be 5 in -01, but they can
still be further merged.

SEED STATUS

Jongwook Park from KISA gave a presentation introducing the
SEED algorithm. He noted that SEED is based on a Feistel
structure with 16 rounds. It has a 128-bit blocksize, and
employs a 128-bit key. He proposed publishing the SEED algorithm
description as an informational RFC prior to the Seoul meeting.
All the documentation is available now from
http://www.kisa.or.kr/seed/index.html. He invited comments from
the WG. Park also noted that we should watch for feedback from
ISO/IEC JTC1 SC27. The Chairman asked whether SEED was currently
being considered by ISO. Park indicated that it was. He noted
that he does not attend the ISO meetings, but some of his
colleagues do. Ramsdell asked whether ISO has assigned OIDs for
the algorithm. Park indicated that they have not. He stated
that they were examining the strength of the algorithm, but there
had been no results yet. Russ Housley asked whether SEED was the
Korean national algorithm. Park responded that SEED was
mandatory in Korea.

------=_NextPart_000_0037_01C3ACF4.8966CFC0--

Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAEJAjkT028396 for ; Fri, 14 Nov 2003 11:10:45 -0800 (PST) (envelope-from [email-masked])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAEJAig7028395 for ietf-smime-bks; Fri, 14 Nov 2003 11:10:45 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [email-masked] using -f
Received: from vahqex2.gfgsi.com (netva01.getronicsgov.com [67.105.229.98]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAEJAdkT028369; Fri, 14 Nov 2003 11:10:39 -0800 (PST) (envelope-from [email-masked])
Received: from digitalnet.com ([158.189.2.70]) by vahqex2.gfgsi.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 14 Nov 2003 14:10:40 -0500
Message-ID: <[email-masked]>
Date: Fri, 14 Nov 2003 14:10:39 -0500
From: Matt Bertapelle
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: imc-sfl , [email-masked]
Subject: v2.3 S/MIME Freeware Library (SFL) Now Available
Content-Type: multipart/alternative; boundary="------------040801000409060109070908"
X-OriginalArrivalTime: 14 Nov 2003 19:10:40.0860 (UTC) FILETIME=[FEAD31C0:01C3AAE2]
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

This is a multi-part message in MIME format.
--------------040801000409060109070908
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

All,

DigitalNet Government Solutions has delivered the Version 2.3 S/MIME Freeware Library (SFL) source code. The SFL source code files and documents are freely available at
.

The SFL implements the IETF S/MIME v3 RFC 3369 Cryptographic Message Syntax (CMS) and RFC 2634 Enhanced Security Services (ESS) specifications. It implements portions of the RFC 2633 Message Specification, RFC 2632 Certificate Handling, and RFC 3370 CMS Algorithms specifications. 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 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.3 SFL uses the v2.3
Certificate Management Library (CML) and v1.6 Enhanced SNACC (eSNACC)
ASN.1 C++ Library to encode/decode objects. The v2.3 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 3369, 3370, 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.3 SFL is described in the v2.3 SFL Application
Programming Interface (API) and v2.3 SFL Software Design Description
documents. The use of the v2.3 CTIL API is described in the v2.3
CTIL API document.

v2.3 SFL includes the following enhancements (compared to v2.2
SFL and CTIL releases):

1) The SFL library now provides Compressed Data Content Type for CMS.
This is implemented as a new ContentInfo type and is an extension to the
types currently defined in CMS. Compressed data can be performed on the
SignedData and EnvelopedData items without application interaction, by
providing the appropriate compressDataFlag flag during the session.

2) There is a major change in how the content is stored in the
CSM_CommonData object. With the addition of Compressed Data Content
Type for CMS, it was necessary to distinguish between clear content and
unclear content. CSM_CommonData now stores both clear and unclear
content making the application determine which content to use according
to desired processing. See the CSM_CommonData section for the changes.

3) The SFL library now provides Password-Based Encryption for CMS. This
provides a method of encrypting data using user-supplied passwords. It
is implemented as a RecipientInfo type and is an extension to the
RecipientInfo Types currently defined in CMS.

4) The thread support logic was updated in the SFL and libCtilMgr.
Specifically, the CSM_CSInst::AccessCertificates() method has been
removed to eliminate thread access problems. This does not affect the
CSM_CtilInst class, used by the CML. The "AccessCertificcates()" and
"AccessCRLs()" methods have been removed due to thread issues. They are
described more fully in the CSM_CSInst class description.

v2.3 CTILs include the following enhancements (compared to
v2.2 release):

1) Elliptic Curve functionality has been added to the
sm_free3 CTIL crypto library. This includes ECDSA and ECDH processing.

v2.3 Certificate Builder include the following enhancements since v2.2:

1) Certificate Builder has been enhanced with ECDSA certificate public/private key generation.

2) Certificate Builder has been enhanced with PKCS#12 generation logic.

3) Certificate Builder has been enhanced to generate UTF-8 strings.

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. DigitalNet 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
. 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: .

The SFL has been successfully tested in conjunction with the Access
Control Library (ACL) that is freely available to everyone from:
.

The National Institute of Standards and Technology (NIST) is providing
test S/MIME messages (created by DigitalNet) at
.
DigitalNet 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
). 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
. 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.

--
Matthew J. Bertapelle
DigitalNet Government Solution, LLC
www.DigitalNet.com

--------------040801000409060109070908
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

All,

DigitalNet Government Solutions has delivered the Version 2.3 S/MIME Freeware Library (SFL) source code. The SFL source code files and documents are freely available at
<http://www.digitalnet.com/knowledge/sfl_home.htm>.

The SFL implements the IETF S/MIME v3 RFC 3369 Cryptographic Message Syntax (CMS) and RFC 2634 Enhanced Security Services (ESS) specifications. It implements portions of the RFC 2633 Message Specification, RFC 2632 Certificate Handling, and RFC 3370 CMS Algorithms specifications. 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 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.3 SFL uses the v2.3
Certificate Management Library (CML) and v1.6 Enhanced SNACC (eSNACC)
ASN.1 C++ Library to encode/decode objects. The v2.3 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 3369, 3370, 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.3 SFL is described in the v2.3 SFL Application
Programming Interface (API) and v2.3 SFL Software Design Description
documents. The use of the v2.3 CTIL API is described in the v2.3
CTIL API document.

v2.3 SFL includes the following enhancements (compared to v2.2
SFL and CTIL releases):

1) The SFL library now provides Compressed Data Content Type
for CMS.  This is implemented as a new ContentInfo type and is an
extension to the types currently defined in CMS.  Compressed data can
be
performed on the SignedData and EnvelopedData items without application
interaction, by providing the appropriate compressDataFlag flag during
the
session.

2) There is a
major change in how the content is stored in the CSM_CommonData
object.   With the addition of Compressed Data Content Type for CMS,
it was necessary to distinguish between clear content and unclear
content.  CSM_CommonData now stores both clear and unclear content
making
the application determine which content to use according to desired
processing.
See the CSM_CommonData section for the changes.

3) The SFL library now provides Password-Based Encryption
for CMS.  This provides a method of encrypting data using user-supplied
passwords. It is implemented as a RecipientInfo type and is an
extension to the
RecipientInfo Types currently defined in CMS.

4) The thread support logic was updated in the SFL and
libCtilMgr.  Specifically, the CSM_CSInst::AccessCertificates() method
has
been removed to eliminate thread access problems. This does not affect
the
CSM_CtilInst class, used by the CML.  The
"AccessCertificcates()" and "AccessCRLs()" methods have
been removed due to thread issues.  They
are described more fully in the CSM_CSInst class description.

v2.3 CTILs include the following enhancements (compared to
v2.2 release):

1) Elliptic Curve functionality has been added to the
sm_free3 CTIL crypto library.  This includes ECDSA and ECDH processing.

v2.3 Certificate Builder include the following enhancements since v2.2:

1) Certificate Builder has been enhanced with ECDSA certificate public/private key generation.

2) Certificate Builder has been enhanced with PKCS#12 generation logic.

3) Certificate Builder has been enhanced to generate UTF-8 strings.

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. DigitalNet 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.DigitalNet.com/knowledge/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.DigitalNet.com/knowledge/acl_home.htm>.

The National Institute of Standards and Technology (NIST) is providing
test S/MIME messages (created by DigitalNet) at
<http://csrc.nist.gov/pki/testing/x509paths.html>.
DigitalNet 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.

--
Matthew J. Bertapelle
DigitalNet Government Solution, LLC
www.DigitalNet.com

--------------040801000409060109070908--

Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hADDEWkT055748 for ; Thu, 13 Nov 2003 05:14:33 -0800 (PST) (envelope-from [email-masked])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hADDEWXH055747 for ietf-smime-bks; Thu, 13 Nov 2003 05:14:32 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [email-masked] using -f
Received: from smtp.cs.auckland.ac.nz (csmail.cs.auckland.ac.nz [130.216.33.150]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hADDETkT055738 for ; Thu, 13 Nov 2003 05:14:31 -0800 (PST) (envelope-from [email-masked])
Received: from cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by smtp.cs.auckland.ac.nz (Postfix) with ESMTP id D7EB163C15; Fri, 14 Nov 2003 02:14:27 +1300 (NZDT)
Received: (from pgut001@localhost) by cs.auckland.ac.nz (8.11.6/8.11.6) id hADDEVT10649; Fri, 14 Nov 2003 02:14:31 +1300
Date: Fri, 14 Nov 2003 02:14:31 +1300
Message-Id: <[email-masked]>
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: CMS Implementation Questions
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Jack Lloyd writes:

>1) I'm pretty sure I understand how to nest CMS structures correctly, but the
> existing S/MIME examples draft doesn't have any examples of, say, compress
> then encrypt then sign. Are there any examples floating around, or, are
> there any free implementations of CMS that do this, which I could use to
> generate a few tests? (Preferably PEM or raw binary, rather than MIME, but
> I'll take what I can get).

You can do it with cryptlib, http://www.cs.auckland.ac.nz/~pgut001/cryptlib/,
just run the self-tests and it'll dump one of every kind of CMS message you
can think of into /tmp (you need to create this directory first if you're
running under Windows). If I hadn't deleted them all in a cleanup about 15
minutes ago I'd send you pre-built examples.

>2) In section 6.2.3 of RFC 3369, "keyIdentifier identifies the key-encryption
> key that was previously distributed to the sender and one or more
> recipients." Is there some typical mechanism for choosing this value?
> Obviously, as far as the RFC is concerned, one can do pretty much anything
> they please, but if there is a simple and commonly used method, I figure I
> might as well go with the crowd.

Uhh, go to the PKIX archives and read the recent thread. Basically, this
doesn't work properly if used with certain PKIX interpretations of
keyIdentifiers.

Peter.

Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hADCLTkT053489 for ; Thu, 13 Nov 2003 04:21:29 -0800 (PST) (envelope-from [email-masked])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hADCLTej053488 for ietf-smime-bks; Thu, 13 Nov 2003 04:21:29 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [email-masked] using -f
Received: from centaur.acm.jhu.edu ([email-masked] [128.220.223.65]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hADCLSkT053483 for ; Thu, 13 Nov 2003 04:21:28 -0800 (PST) (envelope-from [email-masked])
Received: by centaur.acm.jhu.edu (Postfix, from userid 528) id A8A563EB45; Thu, 13 Nov 2003 07:21:27 -0500 (EST)
Received: from localhost (localhost [127.0.0.1]) by centaur.acm.jhu.edu (Postfix) with ESMTP id A78A346842 for ; Thu, 13 Nov 2003 07:21:27 -0500 (EST)
Date: Thu, 13 Nov 2003 07:21:27 -0500 (EST)
From: Jack Lloyd
X-X-Sender: [email-masked]
To: [email-masked]
Subject: CMS Implementation Questions
Message-ID:
X-GPG-Key-ID: 4DCDF398
X-GPG-Key-Fingerprint: 2DD2 95F9 C7E3 A15E AF29 80E1 D6A9 A5B9 4DCD F398
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

I've been looking over the various CMS RFCs, and have a few questions, most
of which probably have obvious and simple answers, but I could use some
help.

1) I'm pretty sure I understand how to nest CMS structures correctly, but the
existing S/MIME examples draft doesn't have any examples of, say, compress
then encrypt then sign. Are there any examples floating around, or, are
there any free implementations of CMS that do this, which I could use to
generate a few tests? (Preferably PEM or raw binary, rather than MIME, but
I'll take what I can get).

2) In section 6.2.3 of RFC 3369, "keyIdentifier identifies the key-encryption
key that was previously distributed to the sender and one or more
recipients." Is there some typical mechanism for choosing this value?
Obviously, as far as the RFC is concerned, one can do pretty much anything
they please, but if there is a simple and commonly used method, I figure I
might as well go with the crowd.

3) It is legal to include SignedAttributes and sign everything that way even
when signing plain data content, correct?

4) Is the encoding of subjectKeyIdentifier in SignerIdentifier and
RecipientIdentifier supposed to be with EXPLICIT or IMPLICIT tags? This is
not particularly clear to me from the texts of RFCs 2630 and 3369.

5) Is the RC2 key wrap example in RFC 3217 right? For the KEK/IV/LCEKPADICV
given there, I get:
03 5E 97 2A B1 5C C4 C9 C4 A0 3D BA A3 5A 21 66
67 E4 3E BC A2 67 46 AE 86 08 DB C8 9E 64 CA 29
for TEMP1. I found a mention of at least one other person who had the same
problem, and am wondering if the RFC is incorrect, or if my RC2 code manages
to pass ~30 test vectors while still being wrong. Either way, something
needs fixing.

Any help would be much appreciated.

Jack

Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hACKGDkT041134 for ; Wed, 12 Nov 2003 12:16:13 -0800 (PST) (envelope-from [email-masked])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hACKGDL5041133 for ietf-smime-bks; Wed, 12 Nov 2003 12:16:13 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [email-masked] using -f
Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hACKGBkT041126; Wed, 12 Nov 2003 12:16:12 -0800 (PST) (envelope-from [email-masked])
Received: from ROMANS (dyn070-253.ietf58.ietf.org [130.129.70.253]) by smtp2.pacifier.net (Postfix) with ESMTP id 354796ADC1; Wed, 12 Nov 2003 12:16:11 -0800 (PST)
Reply-To:
From: "Jim Schaad"
To:
Cc:
Subject: RE: I-D ACTION:draft-ietf-smime-examples-12.txt
Date: Wed, 12 Nov 2003 14:18:41 -0600
Message-ID: <[email-masked]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
Importance: Normal
In-Reply-To: <[email-masked]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Paul,

I have the following comments on the draft:

1. Section 3 examples passed.

2. Section 4 -
Passing - 4.1, 4.2, 4.5, 4.7, 4.11
Untested - 4.3, 4.6, 4.8
Comments - 4.4 - Passes but also includes Alice RSA certificate.
4.9 - Body is not from 4.1, body is modified MIME
body
4.10 - Actual list is [unknown OID, contentHints,
smimeCapablilties, securityLabel, ContentReference,
smimeEncryptKeyPreference, mlExpansionHistory, EquivalentLabel]

3. Section 5 -
Passing - 5.1,
Untested - 5.3,
Comments - 5.2 the encoded and decode examples are not the same
item

4. 6.0, 7.1, 7.2 passed

5. I would like to keep section 10 from the old document.

I found that there were two example 4.4 in the old message thus the
difference between my last message where I said that 4.5 did not exist
in the binaries and the fact that I tested it in this message. I will
get to the rest of the testing later this week.

Jim

Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hACGTpkT032479 for ; Wed, 12 Nov 2003 08:29:51 -0800 (PST) (envelope-from [email-masked])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hACGTpOW032478 for ietf-smime-bks; Wed, 12 Nov 2003 08:29:51 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [email-masked] using -f
Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hACGTlkT032454; Wed, 12 Nov 2003 08:29:48 -0800 (PST) (envelope-from [email-masked])
Received: from ROMANS (dyn070-253.ietf58.ietf.org [130.129.70.253]) by smtp1.pacifier.net (Postfix) with ESMTP id 339B570049; Wed, 12 Nov 2003 08:29:47 -0800 (PST)
Reply-To:
From: "Jim Schaad"
To:
Cc:
Subject: RE: I-D ACTION:draft-ietf-smime-examples-12.txt
Date: Wed, 12 Nov 2003 10:32:18 -0600
Message-ID: <[email-masked]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
Importance: Normal
In-Reply-To: <[email-masked]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Paul,

There are three problems I have encountered during extracting the
document.

1. Example 3.1.bin has a name mismatch

2. Example 3.2.bin has a name mismatch

3. Example 4.5.bin appears to be missing

Jim

Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAB3gKkT009163 for ; Mon, 10 Nov 2003 19:42:20 -0800 (PST) (envelope-from [email-masked])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAB3gKnC009162 for ietf-smime-bks; Mon, 10 Nov 2003 19:42:20 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [email-masked] using -f
Received: from lakemtao02.cox.net (lakemtao02.cox.net [68.1.17.243]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAB3gIkT009150; Mon, 10 Nov 2003 19:42:19 -0800 (PST) (envelope-from [email-masked])
Received: from WJJCUSCLANGSTO1 ([68.101.35.22]) by lakemtao02.cox.net (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with SMTP id <20031111034205.OWO2297.lakemtao02.cox.net@WJJCUSCLANGSTO1>; Mon, 10 Nov 2003 22:42:05 -0500
Message-ID: <[email-masked]>
From: "Peter Hesse"
To: ,
Subject: request for change in son-of-rfc2633
Date: Mon, 10 Nov 2003 22:41:52 -0500
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_000D_01C3A7DB.D5E6B950"
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
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

This is a multi-part message in MIME format.

------=_NextPart_000_000D_01C3A7DB.D5E6B950
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

All,

I have recently run into a problem with signed emails not being able to be
verified, because of the presence of the word "From" in the first columns of
a line of the email message. This email will serve as an example of this
potential problem. If your email client sees this message as signed but the
signature is invalid, the next paragraph should start with the word
"From"--see if it has been modified.

>From appearing as the first characters after a blank line will result in
some email delivery agents (such as sendmail or exim) escaping the
word--"From" is replaced with ">From". The reason for this behavior has to
do with the UNIX mbox mail storage file format. The mbox format stores
multiple messages in one file, and the messages are separated by the word
"From" as the first characters following a blank line. Some mail delivery
agents do not have this problem (i.e. Exchange), because they do not store
messages in the mbox format. Many do, however, resulting in a modification
of the message and the signature being invalidated.

I would like to request that this issue be more directly dealt with in
son-of-RFC2633. (Currently, it is mentioned in the example MIME-encoded
message, but nowhere in the text.) One recommendation might be to borrow
from RFC2015 (MIME Security with PGP), which states:
Though not required, it is generally a good idea to use Quoted-
Printable encoding in the first step (writing out the data to be
signed in MIME canonical format) if any of the lines in the data
begin with "From ", and encode the "F". This will avoid an MTA
inserting a ">" in front of the line, thus invalidating the
signature!

Perhaps this might even be a SHOULD, although I will ask the group to weigh
in on that.

Thanks,

--Peter

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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIF1zCCAokw
ggHyoAMCAQICAQAwDQYJKoZIhvcNAQEEBQAwWzELMAkGA1UEBhMCVVMxKDAmBgNVBAoTH0dlbWlu
aSBTZWN1cml0eSBTb2x1dGlvbnMsIEluYy4xIjAgBgNVBAMTGUdTUyBDZXJ0aWZpY2F0ZSBBdXRo
b3JpdHkwHhcNMDIwNDI1MjE1NjI3WhcNMDUwMjEyMjE1NjI3WjBbMQswCQYDVQQGEwJVUzEoMCYG
A1UEChMfR2VtaW5pIFNlY3VyaXR5IFNvbHV0aW9ucywgSW5jLjEiMCAGA1UEAxMZR1NTIENlcnRp
ZmljYXRlIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAtl3UwxhHyP05YqIF
kyfkWt8669gO/VKxC51PhJaV+hb9swwtaMVtJ9k8WjfQLt3fZpaNCNKB7V61KHxY1K1JCP67AwBy
W4TRuGRwEb+PXu5XdpNs3kxKtunlR4/WPsrrvuMx9/R/Fx9ld3TUqXCJ/JN7Zg68IappkcMy9S3w
koECAwEAAaNdMFswHQYDVR0OBBYEFJpr3UY3Hh5dngW5n9h72/GKMy7GMB8GA1UdIwQYMBaAFJpr
3UY3Hh5dngW5n9h72/GKMy7GMAwGA1UdEwQFMAMBAf8wCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEB
BAUAA4GBAHSd4BGG4le+QZBw/6bCq6mGpr4aJAE7UuXEW/I5YXqlQs1CkAzEHV8UnnXgDd0xONTQ
CdznbzCBNAE1EoxL14Kdp5I6omEeNulMd/tGAvxdw0qbbSaT9LolqtnPL2RbnI3j0JsQlncN1+l2
Dzx8Ka39NU4Gb/P6qo/PKa5+YRHSMIIDRjCCAq+gAwIBAgIBCzANBgkqhkiG9w0BAQUFADBbMQsw
CQYDVQQGEwJVUzEoMCYGA1UEChMfR2VtaW5pIFNlY3VyaXR5IFNvbHV0aW9ucywgSW5jLjEiMCAG
A1UEAxMZR1NTIENlcnRpZmljYXRlIEF1dGhvcml0eTAeFw0wMjA4MDUxODIxMTZaFw0wNDA4MDQx
ODIxMTZaMIGNMQswCQYDVQQGEwJVUzEnMCUGA1UEChMeR2VtaW5pIFNlY3VyaXR5IFNvbHV0aW9u
cyBJbmMuMRQwEgYDVQQLEwtEZXZlbG9wbWVudDEUMBIGA1UEAxMLUGV0ZXIgSGVzc2UxKTAnBgkq
hkiG9w0BCQEWGnBtaGVzc2VAZ2VtaW5pc2VjdXJpdHkuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GN
ADCBiQKBgQCvREu1eU1kCNW+lz+ZV9xvljBC7O6iESK10wzKPlrgnhL87+V5/joAbnwsXt25NsmP
8MIY6tuRxCbZzZn3bFTyPerhIOENWrA/HVdIP29TXfHL1YZn7bqBRHyjKcNdYS02GCw4gR4Fr5QS
SQzy62WbLcaoSG/wnhBqBesLxZMsOwIDAQABo4HmMIHjMAkGA1UdEwQCMAAwEQYJYIZIAYb4QgEB
BAQDAgSwMAsGA1UdDwQEAwIE8DAdBgNVHQ4EFgQUG8pDjEsHMZVS4/sJThNbtamIzEswHwYDVR0j
BBgwFoAUmmvdRjceHl2eBbmf2Hvb8YozLsYwJQYDVR0RBB4wHIEacG1oZXNzZUBnZW1pbmlzZWN1
cml0eS5jb20wNwYDVR0fBDAwLjAsoCqgKIYmaHR0cDovL3d3dy5nZW1pbmlzZWN1cml0eS5jb20v
cm9vdC5jcmwwFgYDVR0gBA8wDTALBgkrBgEEAe8oAQEwDQYJKoZIhvcNAQEFBQADgYEABOIVgnmX
5u4gHHRMsIG5H9WAbMqUeqjhGiFMxDjFXoS2Fkk6eVS6wLJZiS54mWrT1NLA9UOcqfvX8pdpp+pw
IpCwK9ywIco4mrqRdJ5Ja7vuxiO0e0J236mWdTQqPXWxZCOYumBtLkqoOcDFQYjuM4ZPLKSbFiMs
j1OYuQnyz6cxggHDMIIBvwIBATBgMFsxCzAJBgNVBAYTAlVTMSgwJgYDVQQKEx9HZW1pbmkgU2Vj
dXJpdHkgU29sdXRpb25zLCBJbmMuMSIwIAYDVQQDExlHU1MgQ2VydGlmaWNhdGUgQXV0aG9yaXR5
AgELMAkGBSsOAwIaBQCggbowGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx
DxcNMDMxMTExMDM0MTUyWjAjBgkqhkiG9w0BCQQxFgQUiwZyw+XEkLYZTGXX7PJ5QjnYr/0wWwYJ
KoZIhvcNAQkPMU4wTDAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAw
BwYFKw4DAgcwDQYIKoZIhvcNAwICASgwBwYFKw4DAh0wDQYJKoZIhvcNAQEBBQAEgYCfsEWDj+Vi
HEn1kAAVx6yfGTkolRIR7uuC0KS1d4zrT1omaUnVTTKET9QBY7QUqdfb2gcvw9pZuRb4bBtYir0W
Rfnmfuob1NwKXaPPSv6inoySZ2/j/LR3nHsMd2GWYQFI5Q9LGyhqahQcyEWV/vSe9YSd0yUl9hSS
cL3sbEfE6AAAAAAAAA==

------=_NextPart_000_000D_01C3A7DB.D5E6B950--

Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA4A8KkT045901 for ; Tue, 4 Nov 2003 02:08:20 -0800 (PST) (envelope-from [email-masked])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA4A8KKx045900 for ietf-smime-bks; Tue, 4 Nov 2003 02:08:20 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [email-masked] using -f
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.33.151]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA4A8GkT045889; Tue, 4 Nov 2003 02:08:17 -0800 (PST) (envelope-from [email-masked])
Received: from cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by hermes.cs.auckland.ac.nz (8.12.9-20030924/8.12.9) with ESMTP id hA4A8Go9028250; Tue, 4 Nov 2003 23:08:16 +1300
Received: (from pgut001@localhost) by cs.auckland.ac.nz (8.11.6/8.11.6) id hA4ABfi05617; Tue, 4 Nov 2003 23:11:41 +1300
Date: Tue, 4 Nov 2003 23:11:41 +1300
Message-Id: <[email-masked]>
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: Request change in son-of-rfc2633
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

I wrote:

>Mozilla (and no doubt some others that didn't get any publicity) did the same
>thing, and I'm sure they didn't get asked to do that by customers.

Actually that's not right, I thought Mozilla (or at least some apps that used
the Mozilla/Gecko/NSS/whatever code base) were vulnerable because Konqueror
was vulnerable, but it turns out that this was Konqueror with khtml rather
than with kmozilla, with OpenSSL supplying the crypto. Apologies for the
mixup.

Before this gets read as "OpenSSL is vulnerable", that isn't the case either.
OpenSSL provides application-defined callbacks that can be used to override
some checks (used to handle, as one source aptly described it, "the mass of
broken certs out there"). Some apps provide callbacks that ignore all errors,
which apparently is what happened here. Standard OpenSSL doesn't have this
problem.

Peter.

Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA44qmkT067053 for ; Mon, 3 Nov 2003 20:52:48 -0800 (PST) (envelope-from [email-masked])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA44qmdF067052 for ietf-smime-bks; Mon, 3 Nov 2003 20:52:48 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [email-masked] using -f
Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.173]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA44qlkT067044 for ; Mon, 3 Nov 2003 20:52:47 -0800 (PST) (envelope-from [email-masked])
Received: from ROMANS (ip237.c132.blk1.bel.nwlink.com [209.20.132.237]) by smtp3.pacifier.net (Postfix) with ESMTP id D62886DD55; Mon, 3 Nov 2003 20:52:41 -0800 (PST)
Reply-To:
From: "Jim Schaad"
To: "'Blake Ramsdell'" ,
Subject: RE: WG LAST CALL: draft-ietf-smime-rfc2633bis-04
Date: Mon, 3 Nov 2003 20:55:14 -0800
Message-ID: <[email-masked]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
In-Reply-To:
Importance: Normal
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Blake,

I have now finished (almost) this year's work in the winery. Items of
agreement are gone.

jim

> >
> > Comments are on the -05 version of the document.
> >
>
> > 11. Section 2.5.2 - where do we document SMimeCapabilities
> for RC2?
> > Should be a 40-bit vs 128-bit difference between these
> which needs an
> > ASN.1 structure and encoding. Based on reading of this document I
> > could not correctly encode these values.
>
> I believe that this definition should be in the CMSALG
> document (but it's not). Should we bite the bullet and just
> stick it in this one? I agree that it needs to be specified
> somewhere, but I feel a bit icky about sticking it in here.

[JLS] - I agree that the best place is to put it into the CMSALG draft.
This falls into the - Yes, but we can't do it. Since SMimeCapabilities
is not defined in the CMS document, CMSALG can't reference it. CMSALG
must not reference the S/MIME documents. Unless you want Russ to add
SMIMECapabilities to CMS and this to CMSALG then it must go into this
document however icky.

>
> > 15. Section 2.7.1.3: Need to be updated to comment on AES.
>
> I see your point. The intent is to fall back to something
> useful for any version of S/MIME, and the older evil US-only
> RC2/40 clients. It's not clear what discussion you'd have
> about AES here.
>
> It may be the case that this rule should be removed
> completely. Comments?
>
> Not changed, but needs discussion.

[JLS] I think the best thing to do with be an information reference to
"For what we use to do look at .... We no longer provide guidence on
this because things have changed so much.
>
> > 20. Section 3.2.2: I would like to get some rewrites on
> this section
> > as to the purpose of S/MIME type. I think it is JUST to provide
> > information about the information (misspelt in the
> document) about the
> > contained content. It just happens that for display via UAs, the
> > distinction between signed and enveloped was consisted to be an
> > important part of the content. Additionally, I think this is the
> > correct direction for us to tell people about how to define new
> > smime-types in the future.
> >
> > The next question is weither a compressed only message would
> > show up in
> > my mailbox. I think that the correct smime-type for a
> compressed and
> > signed message is actually signed-data not compressed data.
>
> So I think your position is that the smime-type should have
> the "most relevant interpretation of the protected data",
> instead of the "actual type that is being protected". I
> think the best example is an IMAP client getting the headers
> and changing the icon next to the message to indicate what
> kind of message you've got.
>
> We can ask the audience, but I think that the conventional
> wisdom is that the smime-type represents the type of the
> outermost layer, and that's it -- just a further
> clarification of the overloaded application/pkcs7-mime.
>
> Fixed speling of information, but I want to hear more about
> how else we should change this to clarify the semantic (and
> what the semantic is).

[JLS] I have definitely moved to the position that this information is
to tell what is inside the message rather than what security has been
added to the message.. This is also the position that is held in
several different documents (include ESS with receipts).

>
> > 23. Section 3.4.3.3: Just for giggles, I think that
> adding a section
> > with the hex encoding of the acutal bytes hashed for this
> sample would
> > be a good idea. This is one of the things people always
> have problems
> > with when doing multipart signed data. Also it might be
> interesting
> > to make the body a multipart/alternative. On the other hand this
> > would probably be better in an appendix.
>
> I think that getting too far with the examples should be left
> to the Examples draft and any successors. I do agree that
> adding the hex dump would be a good idea.
>
> My attempt at the hex dump is this, but I need at least one
> other person to double check it.
>
> Updated:
>
> The content that is digested (the first part of the
> multipart/signed) are the bytes:
>
> 43 6f 6e 74 65 6e 74 2d 54 79 70 65 3a 20 74 65 78 74 2f 70
> 6c 61 69 6e 0d 0a 0d 0a 54 68 69 73 20 69 73 20 61 20 63 6c
> 65 61 72 2d 73 69 67 6e 65 64 20 6d 65 73 73 61 67 65 2e 0d 0a
>

[JLS] I will look at doing this before next week.

> > 26. Appendix B: Refernces need to be divided.
>
> I'm not sure what you mean by "divided"...

Normative vs Informational as you have noted elsewhere.

> Blake

Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA433jkT063143 for ; Mon, 3 Nov 2003 19:03:45 -0800 (PST) (envelope-from [email-masked])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA433jJb063142 for ietf-smime-bks; Mon, 3 Nov 2003 19:03:45 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [email-masked] using -f
Received: from brutesquadlabs.com (gtec136-m.isomedia.com [207.115.67.136] (may be forged)) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA433ikT063135 for ; Mon, 3 Nov 2003 19:03:44 -0800 (PST) (envelope-from [email-masked])
Received: from DEXTER ([192.168.0.12]) by brutesquadlabs.com with ESMTP ; Mon, 3 Nov 2003 19:03:41 -0800
From: "Blake Ramsdell"
To: ,
Cc: "'Sean P. Turner'" , "'Russ Housley'"
Subject: S/MIME Working Group Agenda for the 58th IETF
Date: Mon, 3 Nov 2003 19:03:41 -0800
Message-ID:
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

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

Introductions (Blake Ramsdell)
Working group status (Blake Ramsdell)
CMS and ESS examples update (Paul Hoffman)
MSGbis and CERTbis update (Blake Ramsdell)
KEM status (Blake Ramsdell)
GOST status (Blake Ramsdell)
SEED overview (Jongwook Park)

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