Subject: COMMERICAL: Internet Security Conference

From: "Bill Gram-Reefer" <[email-masked]>
Date: Mon, 30 Aug 1999 10:31:24 -0700

Please be advised registration is now open for The Internet Security
Conference (TISC) to be held in Boston, October 11-15. Please see
http://tisc.corecom.com for more detail.

Date: Mon, 30 Aug 1999 10:31:24 -0700
Subject: COMMERICAL: Internet Security Conference
From: "Bill Gram-Reefer" <[email-masked]>
To: [email-masked]
Sender: [email-masked]

Please be advised registration is now open for The Internet Security
Conference (TISC) to be held in Boston, October 11-15. Please see
http://tisc.corecom.com for more detail.

From: "Teiwes, Stephan (Ascom Systec AG)" <[email-masked]>
To: "'Adam Montville'" <[email-masked]>
Cc: [email-masked]
Subject: RE: Supporting Software
Date: Fri, 27 Aug 1999 17:15:01 +0200
Sender: [email-masked]

Hi Adam,

please check out the following URL

http://jcewww.iaik.tu-graz.ac.at/SMime/smime.htm

Best wishes

*Stephan

----------------------------------------------------------------------------
|  Dr. Stephan Teiwes
|  Consultant in IT Security and Trusted E-Business 
|  iT_Security AG, Ascom Systec AG 
|  Gewerbepark, CH-5506 Maegenwil
|  Phone: +41 (0)62 / 889 59 36, Fax: +41 (0)62 / 889 59 99
|  EMail: [email-masked], [email-masked] 
|
|  Check our Web Pages for iT_SEC products and services
|  http://www.ascom.com/infosec
|  http://www.itsec.ch
----------------------------------------------------------------------------

> -----Original Message-----
> From:	Adam Montville [SMTP:[email-masked]]
> Sent:	Freitag, 27. August 1999 16:21
> To:	[email-masked]
> Subject:	Supporting Software
> 
> This may be a "dumb" question to some, but I don't know the answer.
> What are the names (and perhaps URLs) for some Java libraries that
> support MIME and S/MIME message formatting?
> 
> Regards,
> 
> Adam.

Date: Fri, 27 Aug 1999 09:20:44 -0500
From: Adam Montville <[email-masked]>
To: [email-masked]
Subject: Supporting Software
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms253FEAFF8FEACADF19A58077
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

This may be a "dumb" question to some, but I don't know the answer.
What are the names (and perhaps URLs) for some Java libraries that
support MIME and S/MIME message formatting?

Regards,

Adam.

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

--------------ms253FEAFF8FEACADF19A58077--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-idea-01.txt
Date: Fri, 27 Aug 1999 06:56:34 -0400
Sender: [email-masked]

--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		: Incorporation of IDEA Encryption Algorithm in S/MIME
	Author(s)	: S. Teiwes, P. Hartmann, D. Kuenzi
	Filename	: draft-ietf-smime-idea-01.txt
	Pages		: 5
	Date		: 26-Aug-99
	
S/MIME (Secure/Multipurpose Internet Mail Extensions) [SMIME2, 
SMIME3] is a specification for secure sending and receiving of MIME
[MIME] data. Based on the Internet MIME standard, S/MIME provides 
cryptographic services for authentication, message integrity and 
non-repudiation of origin by using digital signatures. It also 
supports privacy and data security by using encryption. The S/MIME
framework can be flexibly extended to meet future requirements. 
However, its extentability can also be used to introduce specific
add-on functionality which might be desired in messaging applications.

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

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

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

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

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

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

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

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

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-smime-idea-01.txt

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

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Wed, 25 Aug 1999 14:00:43 -0600
From: "Bob Jueneman" <[email-masked]>
To: <[email-masked]>
Subject: Re: Interesting test case
Sender: [email-masked]

I'm curious to know whether anyone tried the test case, either with S/MIME v2 or v3 code.

Any takers?

Bob

>>> <[email-masked]> 08/20/99 05:45PM >>>
This is an interesting S/MIME test case.  Since our GroupWise S/MIME beta software had some difficulty handling it, I'll describe it.

The attachment (yes, there is an attachment to this signed message, just in case there doesn't appear to be), is a result of a signed message in cleartext form that I originally sent to the PKIX list.  Tom Gundin replied, but his reply included my entire original message, including my .vcf file, my certificates, and the associated signature, and hence it appears that the message was signed by me.  However, since he had modified it when replying, the signature doesn't verify.

If signature checking gets carried away, it may reject this outer message as invalid, when in fact it should be valid (I think). The fact that the apparently signed attachment is invalid should not cause the outer signed message to be invalidated -- only the attachment.

I'd be curious to know how different software packages handle this case, both S/MIME V2 and V3.

Bob

Robert R. Jueneman
Security Architect
Network Security Development
Novell, Inc.
122 East 1700 South
Provo, UT 84606
[email-masked] 
1-801-861-7387

From: "Peter lewis" <[email-masked]>
To: <[email-masked]>
Subject: From Firewalls to IPSec VPNs
Date: Wed, 25 Aug 1999 10:44:13 +0200
Sender: [email-masked]

Security services and protection mechanisms
IPv6 promises regarding IPSec
Certification infrastructure 
Standardization update
Case Studies: ISPs, carriers, private networks
AH and ESP protocols description
Possible future extensions and modifications of the IKE protocol
Complementarity between IPSec and firewalls
Global Site-to-Site IPSec VPN's with End-to-End SLA's
Managing widespread IPSEC virtual private networks
Solving IPSec VPNs scalability
Results of some interoperability tests
IPSec architectures and non-standardized aspects of IPSec
Adding IPSec VPN functions in an existing router network
Impact of fragmentation on the performance of IPSec coding

IPSEC 99 Conference
>From Firewall to IPSec VPNs

October 26, 27, 28, 29, 1999
Paris - France

More infos: www.upperside.fr/baipsec.htm

Sorry to post this message on the list.

Thanks

From: "Pawling, John" <[email-masked]>
To: "'Core Scott-P18750'" <[email-masked]>, [email-masked]
Subject: RE: Forwarding of signedData objects
Date: Tue, 24 Aug 1999 18:31:08 -0400
Sender: [email-masked]

Scott,

If the signer of the forwarded (i.e. inner) signedData includes a
receiptRequest attribute that includes the receiptsFrom allOrFirstTier set
to allReceipts, then every entity that verifies the signature of the
signerInfo containing the receiptRequest is supposed to return a signed
receipt (unless superseded by a Mail List Receipt Policy as noted below).
Note that the signer may have designated that only specified recipients
(ReceiptsFrom receiptList CHOICE) or first-tier recipients (receiptsFrom
allOrFirstTier set to firstTierRecipients) should return a signed receipt.  

As stated in RFC 2634, Section 2.3, the presence of an mlExpansionHistory
attribute in the outermost signedData can supersede the receiptRequest in
the inner signedData.  If the last mlData element in the mlExpanisonHistory
attribute includes a mlReceiptPolicy value of NONE, "then the receipt policy
of the Mail List supersedes the originator's request for a signed receipt
and a signed receipt MUST NOT be created."

============================================
John Pawling, Director - Systems Engineering
J.G. Van Dyke & Associates, Inc.,
a Wang Government Services Company
[email-masked]
============================================ 

From: Tim Dean <[email-masked]>
Reply-To: "[email-masked]" <[email-masked]>
To: "\"[email-masked]\"@mail.proper.com" <"[email-masked]"@mail.proper.com>, "[email-masked]'" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: NR -- what the real issues are, and  a proposal
Date: Tue, 24 Aug 1999 11:57:19 +0100
Organization: DERA
Sender: [email-masked]

Rich,

>Of course, ANSI X9.45 defines a useful (CMS signed) attribute
>to indicate the purpose of a signature.  Could we overload this (or
>define something new but similar) to indicate intent?  The
>syntax was an OID, so doing this is pretty simple.  I'd be
>glad to force this thru X9 if the IETF crowd is not interested.

Speaking as one very small part of the "IETF crowd" we are very interested in 
this. We have long believed that the ability to specify signature semantics 
when signing messages would be a "Very Useful Thing". But we come at it from a 
negative perspective - viz, there are many situations where signing messages 
protects against real threats in the network but where the signing entity does 
not wish to be encumbered by legal liabilities. Two examples are (1) a human 
user who wants to protect herself against a law-suit (2) a machine which has no 
understanding of its legal liabilities and can't easily be taken to court ;-). 
In the absence of anything better we created the "signature type" attribute and 
put it in our Domsec draft in the S/MIME working group - which we hope to 
re-issue later on this year .  Would that be a suitable container for your 
OID(s)?

Tim

____________________________________
Tim Dean
DERA
E-mail: [email-masked]
Web: http://www.dera.gov.uk/
____________________________________

----------
From: 	[email-masked][SMTP:[email-masked]]
Sent: 	19 August 1999 17:58
To: 	"[email-masked]"@mail.proper.com
Cc: 	[email-masked]; [email-masked]
Subject: 	Re: NR -- what the real issues are, and  a proposal

<<File: ATT00011.htm>>
>>> "Rich Ankney" <[email-masked]> 08/17/99 05:07PM >>>
Bob,

Thanks for finally posting all of the relevant stuff in one
message.  My first thought would be to minimize reliance
on the NR bit, i.e. follow Steve's suggestion that if it's
FALSE, you can't use the cert for NR, else you migbe able to.

Of course, ANSI X9.45 defines a useful (CMS signed) attribute
to indicate the purpose of a signature.  Could we overload this (or
define something new but similar) to indicate intent?  The
syntax was an OID, so doing this is pretty simple.  I'd be
glad to force this thru X9 if the IETF crowd is not interested.

Best regards,
Rich

PS: I sent this to you personally rather than to the list in case
you'd like to discuss the details.  If not, of course, feel free
to post your response to the list.

Hi, Rich,

I'll take you upon your offer to post your note to the list, and
I'll also comment in passing on some other contributions from
Ed, Tony, and Steve, recognizing that some other suggestions have
partially overtaken some of these ideas while I was preparing
this note and attending meetings. :-)

I agree with you regarding the case when the NR bit is off -- you
can't use the certificate for any nonrepudiation purpose in that case.
Perhaps I wasn't sufficiently clear in the proposal summary,
although I think I was in the more detailed text, where I said that the NR
bit has to be used to ENABLE the NR bit in the message itself.

If NR bit is off, any message signed with the key in that certificate
CANNOT intentionally or unintentionally be used for any legally
binding purpose -- you are denying, in advance, that that was
your intent, and signaling a prospective relying party that relying
on your signature and certificate would be repudiated in court, if
necessary, and hence such reliance would be quite unwise,
to say the least.

Why should you try to deny in advance something that might be
legally binding (to answer someone else's question)?  Because
you might be concerned about the possibility that your key might
be stolen, and that it might not be YOU that is signing in that fashion!

Obviously you know (or at least ought to know) the strengths and
weakness of your own key management system, and you might
very well decide that a given key/certificate was not sufficiently
well protected to be used for any legally binding purposes -- it would
just be too risky. Maybe your ordinary digital-signature-key-used-for-
network-logon-authentication-via-SSL is kept on your hard
drive with relatively weak password encryption, and your
nonrepudiation key/certificate is kept on a removable smart card.
(I think this is Ed's point -- that if I don't have the power to deny
a given capability in advance, it really isn't nonrepudiation -- it's
just an option that I can't control and hence can't be binding, since
it isn't voluntary.)

As I read Steve's note, I think he is in agreement with at least this point.

However, Steve, Tony, and even Ed then go down a path that I think is
highly questionable, and that is the CA-centric view of enabling
or disabling nonrepudiation within the CPS. Granted, if there is even
the faintest suggestion that the CA might be liable for the user's
actions with respect to his key and how they are used, then the
CA ought to be able to deny the user the ability to set the NR bit.
But it should do, obviously, by simply refusing to issue a certificate
containing that bit.  But whether the CA can impose other conditions
on the subscriber, or on the RP, in this particular area seems highly
doubtful, as I will explain. (And as I expect that you, Rich,
already know because of your banking involvement.)

There are three reasons why something like a NR bit should be in the
certificate, and not just rely on a certificate policy OID (or worse yet,
just a statement in the CPS itself.)

The first is a practical one -- very little RP software to date (none that I 
know of)
implements the policy OID constraint, and without that constraint there is no
enforcement.  In fact, I would bet that a lot of software would ignore the
constraint even if it were marked critical -- they certainly ignore a lot of 
other
critical attributes.

The second reason is more important.  Although I can, if I am the relying
party, choose a superior CA whose certificate specifies a policy OID 
constraint,
I am not required to do so. In fact, I can import and "trust" (accept as valid) 
a user's certificate directly, without relying on any intervening CA's 
certificate
at all.  I'm not quite certain whether a policyOID constraint can be placed on
the end-user's certificate -- can it? -- but even if it is it is far from 
obvious that
such a constraint is binding upon the application. What mechanisms are
postulated to tell the RP what particular policy OID the user feels like 
accepting
today?

So the relying party, or the relying party's IS department, may specify such a 
policy
constraint, BUT THEY ARE NOT REQUIRED TO DO SO.

Finally, as I believe I explained in a previous message, to the best of my
knowledge there is no legal way that I know of whereby the relying party
can be required to even read the CA's CPS prior to accepting a digital 
signature,
or more importantly why a CPS that reflects an agreement between the CA
and the subscriber would be binding upon the RP.

This is a contractual privity issue, and there simply isn't any way around it 
that
I know of -- a contract between A and B is not binding on C, even if there were 
also a contract between B and C.

So the only way that I know of to specify something of this type is in the 
defined
semantics of the attribute itself.  If the NR bit is now so hopeless confused 
that
someone could wriggle out of this definition, then we ought to define a new 
one,
perhaps intentToBeLegallyBound, and deprecate the old one. But I don't think we 
are there yet -- I think we can use the existing bit for this purpose, so long 
as we
recognize that it is the turning off of the bit that is really the most 
important thing.

With respect to the suggestion to define a new signedAttribute to be applied
to the message, Russ Housely indicates that would be outside of the current
SMIME WG's charter, but that the charter could be amended if there was
sufficient interest.

If we can get some reasonable consensus on the overall approach, I would
be happy to work with you, Rich, to perhaps define a joint IETF-SMIME and
 X9 contribution in this area.

Bob

-----Original Message-----
From: Bob Jueneman <[email-masked]>
To: [email-masked] <[email-masked]>
Date: Tuesday, August 17, 1999 5:39 PM
Subject: NR -- what the real issues are, and a proposal

>The message which follows is a rather lengthy attempt to recap of
>the last five years or so of technical/legal discussion regarding
>digital signatures, followed by a proposal for what to do to fix these
>problems.
>
>However, since many may want to skip the justification and cut t
>o the bottom line, I'll put the proposal up front, and then justify it:
>
>My proposal is that the text of the nonrepudiation key usage bit I
>n the PKIX RFC (and hopefully in X.509) be revised to unambiguously
>state that the defined semantics of this bit is to indicate the willingness
>of the subscriber to be legally bound by a digital signature which can be
>verified by a certificate that can be established to have been valid at the
>time of signature, where "valid" has the normal meaning of not expired, not
>revoked, etc., etc.
>
>In addition, I propose that we create an additional indicator of a
>human being's conscious and willful intent to be legally bound by
>a digital signature that would be applied on a message by message
>basis. This additional indicator would require, as an integral part of
>its semantic definition, that an explicit computer-to-human interaction
>be required to provide some reasonable level of ceremonial and due
>caution warning be provided to the user.  In addition, the semantics
>of this indicator should specify that its use must be ENABLED by the
>NR bit ( as redefined) in the certificate which includes the corresponding
>public key.  If the certificate does not have the bit turned on, the
>application is not obligated to request the ceremonial, due caution
>approval; and relying party software should ignore a per-message
>indicator even if present in that case.
>
>The obvious, but not necessarily the only, place to put such a message
>by message indicator would be in the Cryptographic Message Syntax
>used by S/MIME V3, in particular as a new signedAttribute.  Since
>signedAttributes is a SET of self-describing attributes, adding
>an additional one would be very simple.
>
>Now for the history lesson.
[snip]

Date: Mon, 23 Aug 1999 16:20:31 -0600
From: "Tolga Acar" <[email-masked]>
To: <[email-masked]>
Subject: Re: ASN.1 for the Internet (was Re: Compressed data type for S/MIME)
Sender: [email-masked]

Regarding "a bunch of people who use ASN.1", the IEEE P1363 WG on public-key cryptography standards is getting ready to deploy another project "ASN.1 Syntax for P1363" that basically covers all public-key cryptosystems. Thus, I expect that there will be more people using ASN.1 in the cryptographic framework. 

It is not very likely - like it or not - that ASN.1 in cryptography will go away. It may not be the best method, but it is there, and we have to use it for a while. 

Regarding an RFC interpreting ASN.1, this may be a good opportunity to, in a way, combine the P1363 effort and a possible RFC on ASN.1/BER/DER.
Any thoughts on such an RFC ?

- Tolga

>>> Marc Branchaud <[email-masked]> 8/16/99 16:25:38 >>>

There seems to be some strong opinions that an ASN.1-Internet
reconciliation is a pointless and futile task.  I can live with that,
but I'd like to try to explain my objective one more time before it gets
thrown out with the bath water.  (On top of that, this topic is a bit
off for S/MIME -- but things are slow these days anyway.)

My basic premises are these:

1. There are a bunch of people who use ASN.1.

2. There are a bunch of other people who don't like ASN.1 because it is
very difficult to look at some ASN.1 code and figure out what the bits
on the wire will look like.  (There may be many more people who don't
like ASN.1 for other reasons, but I'm not trying to deal with them
here.)

3. The people using ASN.1 would like to see their ASN.1-based protocols
widely adopted.

Given these premises (which weren't founded on any facts and may or may
not reflect any reality anywhere), it seems to me that if there were a
version of ASN.1 that was easier to interpret then the people in my
second premise would be happier and the goal in the third premise might
be more achievable.

It also seems to me that such an ASN.1 "lite" could be defined that
would still be standard ASN.1, especially if the PER rules were used.

So I'm not suggesting a Grand Unified Syntax that will bring peace to
the world.  I'm not trying to replace ABNF or S-expressions or
whatever-your-favorite-protocol-definition-language-is.  I'm just trying
to make ASN.1 easier to digest for people who haven't read X.whatever.  

Or am I the only one who thinks it's a bit weird that the IETF is
pushing protocols defined in ASN.1 without having an RFC that explains
how to interpret them?

		Marc

+------------------------------------------------------------------------+
 Marc Branchaud                                  \/
 Chief PKI Architect                             /\CERT INTERNATIONAL
INC.
 [email-masked]        PKI References page:             
www.xcert.com 
 604-640-6227          www.xcert.com/~marcnarc/PKI/ 
+------------------------------------------------------------------------+
  PGP key fingerprint:  60 11 4B 9D 4E E5 2F 47  BD C5 C2 BF 26 DF 5A E1

From: Core Scott-P18750 <[email-masked]>
To: [email-masked]
Subject: Forwarding of signedData objects
Date: Mon, 23 Aug 1999 14:20:11 -0700
Sender: [email-masked]

All

I am curious how forwarding of signedData Objects is being implemented. It
would be desirable when forwarding a triple wrapped signedData object to
retain the original signature value, however if a signed receipt were
requested in this object it would propagate to the forwarded message also.
That would mean that a signed receipt would be generated from all of the
recipients of the forwarded message whether or not that was the desire of
the person forwarding the message. 

Can anyone shed some light on this or is there something wrong with my
interpretation of the signed receipt attribute in ESS? 

thanks

scott core
motorola

From: <[email-masked]>
Subject: Free Research Report Enclosed.......(adv)
Date: Sun, 22 Aug 1999 02:41:50
Sender: [email-masked]

<base HREF="http://www.ismh.com/">
<html>

<head>

<meta name="DESCRIPTION"
content="International Sports Management Holding Corporation is a publicly held Corporation established in 1993 and currently listed under the symbol (ISMH)">
<meta name="KEYWORDS"
content="international, ISM, Team, IRL, ISMH, Holding, Marketing, Management, sports, Athlete, football, basketball, golf, racing, Indy Racing League, auto, sports, Indy-car, Indy, Indiana, Indianapolis, track, sports, motorsports,  Jeff Ward, 500, 200, oval, Sponsors, Fan Club">
<meta name="RATING" content="General">
<meta name="ROBOTS" content="All">
<meta name="AUTHOR" content="Webize, Inc. - http://www.webize.com">
<script language="JavaScript">

<!-- 
if (top==self) self.location.href = "index.htm";
//-->

</script>

<title>ISM HOLDING CORP.</title>
<base Target="body">
</head>

<body topmargin="0" leftmargin="0" bgcolor="#FFFFFF"
style="font-family: Arial, verdana, sans-serif">
<div align="left">

<table border="0" cellpadding="0" cellspacing="0" width="909">
</table>
</div><div align="center"><center>

<table border="0" cellspacing="0" width="90%">
  <tr>
    <td width="100%"><div align="center"><center><table border="1" cellspacing="0"
    bordercolor="#FFFFFF" bordercolorlight="#FFFFFF" bordercolordark="#0000FF" cellpadding="4">
      <tr>
        <td><blink>EMERGING GROWTH RESEARCH REPORTS PRESENTS</blink></td>
      </tr>
    </table>
    </center></div><p><small><font face="Arial">International Sports Management Holding
    Corporation (ISM) is a publicly held Corporation established in 1993 and currently listed
    under the symbol (ISMH). The company&#146;s offices and race shops are located in a 42,000
    square foot state of the art building at 4500 W. 96<sup>th</sup> St. in Indianapolis,
    Indiana in the Mayflower Business Park. ISM specializes in sports marketing and
    sponsorship solicitation for sports properties, as well as owning, marketing and managing
    its own professional auto racing teams. ISM currently owns a team in the Indy Racing
    League (IRL), which races in the prestigious Indianapolis 500 as well as ten additional
    races in eight major cities in the United States. </font></small></p>
    <font face="Arial"><p><small>It is ISM&#146;s objective to maximize shareholder value
    through the utilization of its corporate officers&#146; vast knowledge and experience in
    the field of sports marketing and management as well as incremental revenue programs.
    ISM&#146;s business philosophy and practices are geared toward maximizing success and
    minimizing uncertainty and instability. Together with a staff of highly experienced and
    competent personnel, ISM has enjoyed great success in efficient utilization its capital
    resources.</small></font></p>
    <p align="center"><a name="DESCRIPTION OF BUSINESS"><font face="Arial" size="3"><strong>DESCRIPTION
    OF BUSINESS</strong></font></a></p>
    <p align="left"><font FACE="Arial" size="2">ISM is a nationally recognized sports
    management company specializing in three major areas of professional sports management;
    Sports Marketing, Athlete Management, and Professional Race Team Management. Since its
    inception, a number of major corporations and professional athletes have engaged the
    services of ISM to assist them in their sports marketing needs. The company has cultivated
    marketing opportunities for athletes in professional and collegiate sports such as;
    professional golf, football and basketball as well as owning and managing several
    professional auto-racing teams.</font></p>
    <p align="center"><font face="Arial" size="3"><strong>ISM HOLDING <a name="MANAGEMENT">MANAGEMENT</a></strong></font></p>
    <p align="left"><font face="Arial"><small>L.G. Hancher and Gary D. Sallee were co-founders
    of the company and are currently its principal shareholders.</small></font></p>
    <p><small><font face="Arial"><strong>L. G. Hancher</strong>, Chairman of ISM Holding, has
    a diversified professional motor sports marketing background. In 1985 while serving as
    Sales and Marketing Manager for the Raynor Garage Door Company, Mr. Hancher initiated
    Raynor&#146;s involvement in motorsports with a product sponsorship at the Indianapolis
    500 garages. The program was so successful in increasing sales of Raynor products that the
    following year Raynor purchased their own racing team and appointed Mr. Hancher as
    President and General Manager of the team.</font></small></p>
    <p><small><font face="Arial">He then went on to lead the Raynor team to a top ten standing
    in 1987 and 1988.</font></small></p>
    <p><small><font face="Arial">Following Mr. Hancher&#146;s success at Raynor, he began an
    entrepreneurial endeavor as an importer for Pi Research computer systems where he worked
    with leading race teams in NASCAR, INDY Car, Formula One and IMSA. He then furthered his
    racing experience as General Manager for the McKenzie Group Financial racing team and
    achieved top ten finishes in every oval race for the 1990 season. Mr. Hancher was managing
    partner of ISM Holding&#146;s FIRST PLUS/Team Cheever sponsored IRL Team, winning
    it&#146;s third race as a new team and the first race in 1997 at the Walt Disney 200 and
    continuing on to a third place finish at the prestigious Indianapolis 500 that year</font></small></p>
    <p><font face="Arial"><small><strong>Gary Sallee</strong>, President of ISM Holding, has
    been practicing general business law in Indianapolis, Indiana since 1981. His law practice
    has focused on sports and entertainment management as well as commercial real estate
    development. In 1993, Mr. Sallee together with Mr. Hancher formed International Sports
    Management. Mr. Sallee is an NFLPA contract advisor and has represented players in the
    NFL; USFL, CFL, NHL and other team based sports. During the early 80&#146;s He was also a
    member of the Board of Advisors of the Indianapolis Checkers IHL Hockey Team. Mr. Sallee
    has represented many personalities from the entertainment world including record
    companies, a recording studio, promoters and sponsors. He has also been involved in the
    organizing of special events such as the closing ceremonies for the Pan American games and
    the National Sports Festival, hosted by the city of Indianapolis. Mr. Sallee has also been
    involved with various charitable organizations such as the Hemophilia Foundation of
    Indiana where he served on the Board of Directors for more than ten years and as President
    has for five years. He recently served as a member of the Board of Directors of the
    National Hemophilia Foundation.</small></font></p>
    <p align="center"><a name="MOTORSPORTS"><strong><font face="Arial">MOTORSPORTS</font></strong></a></p>
    <p align="left"><font face="Arial"><small>In the motorsports field, ISM has actively been
    involved in race team ownership since 1997 and management since it&#146;s inception.
    Currently the company owns and manages a team that competes in the Indy Racing League
    (IRL) series. ISM Holding has been very successful in fielding winning cars and numerous
    front-line drivers since the team&#146;s inception in 1993.</small></font></p>
    <p><small><font face="Arial">For the 1997-1998 IRL season ISM Racing Corp. a subsidiary of
    ISM, fielded one car driven by Jeff Ward in all 11 IRL events. At the Disney 200, and the
    Phoenix 200 ISM fielded a two-car team. ISM was the only team in 1998 to have entered and
    successfully qualified three cars in the 1998 Indianapolis 500. Steve Knapp who finished
    third and won the coveted ROOKIE OF THE YEAR AWARD in 1998 drove one of the cars.</font></small></p>
    <p><font face="Arial"><small>During the 1997-1998 IRL season Jeff Ward finished third and
    won THE ROOKIE OF THE YEAR AWARD in the 1997 Indianapolis 500. In addition Jeff completed
    his first full IRL season with ISM Racing Corp. Jeff finished sixth in the 1997-1998
    points standings, was second in laps led with 326, had five top ten finishes, eight top
    ten starts, with one pole position, and started from the front row four times in eleven
    races.</small></font></p>
    <div align="center"><center><table border="0" cellpadding="0" cellspacing="0" width="100%">
      <tr>
        <td width="50%"><small><font face="Arial">With multi year co-title sponsorships from
        Thermo Tech Technologies (TTRIF) and Cease-Fire (BIOF), ISM Racing Corp. is again poised
        to be a top contending team for the 1998-1999 IRL season. </font></small></td>
        <td width="50%"><img src="../images/car35a.gif" WIDTH="368" HEIGHT="78"></td>
      </tr>
    </table>
    </center></div><p><small><font face="Arial">Associate sponsors Prolong Super Lubricants,
    National Car Rental, Volvo, Nextel, and other sponsors at various levels will benefit from
    the exposure on race day and the proven experience that the ISM team has in nurturing
    Business to Business relationships.</font></small></p>
    <p><small><font face="Arial">It is ISM&#146;s intent to own a majority interest in all
    open wheel-racing venues. All race teams will be based out of ISM&#146;s offices and shop
    facility, located in Indianapolis, Indiana. ISM will control all operational, financial,
    and management functions of the teams.</font></small></p>
    <p><font face="Arial"><small>In 1997, ISM became involved in the highly successful NASCAR
    Winston Cup series as an owner of a newly formed team. At the end of the season the
    company elected to sell its interest in the team. Nevertheless, ISM will continue to be
    involved in securing sponsors for the teams new owners.</small></font></p>
    <p align="center"><a name="SPORTS MANAGEMENT"><strong><font face="Arial">SPORTS </font><font
    face="Arial" size="3">MANAGEMENT</font></strong></a></p>
    <p align="left"><font face="Arial"><small>ISM management and staff have successfully
    developed programs for major corporations desiring to promote their products through
    professional athletes and sports leagues including The PGA, LPGA, SPGA Tour, NFL, NHL,
    NHRA, IMSA, USAC, NASCAR, and the IRL. With the diversified expertise and vast knowledge
    ISM intends to continue to expand the Sports Management segment of the business as sports
    marketing continues to grow as a viable way for corporations to market their products.</small></font></p>
    <p align="center"><a name="MARKETING"><font face="Arial"><strong>MARKETING</strong></font></a></p>
    <p align="left"><small><font face="Arial">ISM has a full time staff of professionals that
    focus on &quot;sports sponsorship solicitation&quot; for both motor sports as well as
    athletes. ISM marketing personnel focus on soliciting sponsorship monies from corporations
    looking to use sports marketing as a way to promote their products and services. As a
    result of the national media exposure and its fast pace level of excitement, auto racing
    has and is continuing to become one of the most popular areas of involvement for corporate
    America. Brand loyalty among race fans is the highest of any fan base in the world of
    professional sports.</font></small></p>
    <p><font face="Arial"><small>ISM through its management and marketing personnel have
    successfully developed and implemented many successful and profitable incremental revenue
    programs. ISM will continue to develop programs that can be designed to utilize the
    business to business relationships that the company has established in the past.</small></font></p>
    <p align="center"><a name="BUSINESS STRATEGY"><strong><font face="Arial">BUSINESS STRATEGY</font></strong></a></p>
    <p align="left"><font face="Arial"><small>The company is committed to solid systematic
    profitable growth through the expansion of its existing motorsports division. The company
    plans to expand from a one-car team to a two-car team in the IRL series. The company will
    continue to aggressively pursue its Athlete Management endeavors by finding new players to
    join the ever-growing stable of professional athletes that it currently represents. The
    company will continue ride the current wave of corporate sponsorship involvement to
    maximize their sports marketing programs.</small></font></td>
  </tr>
</table>
</center></div>

<p align="center"><br>
<small><font face="Arial">DISCLAIMER </font></small></p>

<p align="center">=========================================================== </p>

<p><font face="Arial"><small>The sender of this report cannot and does not warrant the
completeness, accuracy, merchant ability, or fitness of the news, information, or
entertainment content found herein for any particular purpose. Further, you agree that the
sender shall not be held liable to anyone for any loss or injury resulting from the direct
or indirect use of this report. This includes, but is not limited to, loss or injury
caused in whole or in part by its negligence or by contingencies beyond its control in
procuring, compiling, interpreting, reporting or delivering any portion of this report.
You agree that you bear responsibility for your own investment research and investment
decisions, and that the sender of this report shall not be liable for any decision made or
action taken by you or others based upon reliance on news, information, or any material
published herein. All information provided herein is to be used on an &quot;as is, with
all faults&quot; basis. The sender of this report relies on various sources of information
that we believe to be accurate and reliable. However, the sender makes no claims or
representations with regard to the accuracy, completeness, or truth of any material
contained herein. The sender of this email was paid $2,000 in return for this service. </small></font></p>

<p align="center"><small><font face="Arial">TO UNSUBSCRIBE </font></small></p>

<p align="center">=========================================================== </p>

<p><small>To be removed from the Stock Alert mailing list, reply to this message with the
word REMOVE or UNSUBSCRIBE in the subject and include your e-mail address in the text of
your reply. Please note: if you have more than one e-mail address, include ALL of your
addresses in the text of your reply to ensure removal from the mailing list. </small></p>
</body>
</html>

From: [email-masked]
Date: Fri, 20 Aug 1999 17:45:00 -0600
Subject: Interesting test case
To: [email-masked]
Sender: [email-masked]

--____RXBQHFRQSACVAWREOUDE____
Content-type: multipart/mixed; boundary="____GLYVGGEUTJVQYJTMHCNC____"

--____GLYVGGEUTJVQYJTMHCNC____
Content-type: text/plain; charset=iso-8859-1
Content-disposition: inline

This is an interesting S/MIME test case.  Since our GroupWise S/MIME beta software had some difficulty handling it, I'll describe it.

The attachment (yes, there is an attachment to this signed message, just in case there doesn't appear to be), is a result of a signed message in cleartext form that I originally sent to the PKIX list.  Tom Gundin replied, but his reply included my entire original message, including my .vcf file, my certificates, and the associated signature, and hence it appears that the message was signed by me.  However, since he had modified it when replying, the signature doesn't verify.

If signature checking gets carried away, it may reject this outer message as invalid, when in fact it should be valid (I think). The fact that the apparently signed attachment is invalid should not cause the outer signed message to be invalidated -- only the attachment.

I'd be curious to know how different software packages handle this case, both S/MIME V2 and V3.

Bob

Robert R. Jueneman
Security Architect
Network Security Development
Novell, Inc.
122 East 1700 South
Provo, UT 84606
[email-masked]
1-801-861-7387

--____GLYVGGEUTJVQYJTMHCNC____
Content-type: message/rfc822

From: [email-masked]
To: [email-masked], [email-masked]
cc: [email-masked]
Date: Fri, 20 Aug 1999 17:49:02 -0400
Subject: Re: NR and Private Key Usage Period

--0__=oyhsLd76eBszZHvSKe2qARxIC6Eny8oyRwHESDyA43fCrt8KzRKfSLpx
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

[email-masked] on 08/20/99 04:54:00 PM

To:   "[email-masked]"@e1.ny.us.ibm.com, [email-masked]
cc:
Subject:  Re: NR and Private Key Usage Period

Tom,

Unless I read your message too quickly, to my way of thinking
you have this exactly backwards.  The Private Key Usage
period was supposed to be shorter than, not longer than the
certificate validity.

[Tom Gindin]   You did read it too quickly, because I didn't say which of the
two periods was longer - I thought everybody understood that.  The idea was that
a certificate which was created with a private key usage period shorter than the
certificate validity would be usable for NR signatures only until the PKUP
expired, but that those signatures could be checked against CRL's until the
certificate itself expired.  It is true that X.509 section 11.2 has a note which
might require archiving of expired CRL's, but they wouldn't be available online
and the note's wording is fairly unhelpful: "If a non-repudiation of data
service is dependent on keys provided by the CA, the service should ensure that
all relevant keys of the CA (revoked or expired) and the timestamped revocation
lists are archived and certified by a current authority."  The emphasis on
CA-provided (not CA-certified) keys here might make this note inapplicable to
the case where the NR keys are generated by end-user clients.  This wording is
from the June 1997 version, and perhaps it has been replaced by something which
more obviously binds CA's which certify externally generated keys as NR ones.
If it hasn't been replaced, it should be.

If the current definition of NR means anything at all (which
isn't clear), then I would submit that it PROBABLY means that
that the signature is intended to endure and still be considered
valid long AFTER the certificate has been expired, or even
been revoked, so long as it can be established that it was valid
at the time of signing, e.g., with OCSP, CRLs plus notarized timestamps,
Papal archives, or whatever.

There is virtually no reason I can think of why the Private Key Usage
should extend beyond the expiration date of the certificate --
that just increases the risk of compromise with no concomitant
benefit.

What the Private Key Validity period should do, and the reason why
I am still opposed to deprecating it, is to set a time after which a signature
which was apparently created using a key that was supposedly zeroized
should be looked at with considerable scepticism, to say the least.

(For those who may have tuned in late -- the fact that a certificate has
expired or even been revoked does NOT ipso facto mean that the
signature is not legally binding -- it just means that it may be
more difficult to prove.)

Assuming that keys and certificates are relatively inexpensive, but that
validation of a signature once the certificate has expired is considerably
more expensive than during the validity period (because of the
additional archiving, etc., required), then from the user's perspective
what he would like to do is use short-lived keys and long-lived certificates.

Ignoring cryptanalytic attacks, zeroizing a key is the surest possible
way of protecting against a key compromise. So if a key management
system provides a way to automatically schedule a key for destruction
(or at least to remind the user to destroy it), that would be a Good Thing.

Once the key has been zeroized, from the user's perspective, and especially
from the Relying Party's perspective, the longer the certificate lifetime, the
better, since during the validity period it isn't necessary to have all of the
time stamped archives -- you can just query the CA to see whether
the key is still valid..  But from the CA's perspective, of course, this
isn't too good, because it increases the size of the CRL's.

[Tom Gindin]   This argument only applies to signing certificates, especially
NR, right?

Regards,

Bob

(P.S. -- this is a beta version of GroupWise 5.5 with S/MIME support.
If anyone notices anything wrong with the format, etc., please let
me know so we can fix it.)

Robert R. Jueneman
Security Architect
Network Security Development
Novell, Inc.
122 East 1700 South
Provo, UT 84606
[email-masked]
1-801-861-7387

>>> <[email-masked]> 08/20/99 10:12AM >>>
     Today, Private Key Usage Period is recommended against by RFC 2459 (section
4.2.1.4).  Given that most of the scenarios for NR require that certificates be
valid at the time when a signature is to be checked by a third party, which may
be long after the object is signed, shouldn't Private Key Usage Period be used
with NR certificates?

     A possible new wording would be:
     The Private Key Usage Period extension should only be present in
certificates which possess a keyUsage extension with the nonRepudiation bit of
that extension set.

     Similar, but weaker, arguments would apply to permitting this extension
when the keyCertSign bit is set as well, since certificates may also be valid
for a long time.

          Tom Gindin

--0__=oyhsLd76eBszZHvSKe2qARxIC6Eny8oyRwHESDyA43fCrt8KzRKfSLpx
Content-type: application/octet-stream; 
	name="Bob Jueneman.vcf"
Content-Disposition: attachment; filename="Bob Jueneman.vcf"
Content-transfer-encoding: base64

--0__=oyhsLd76eBszZHvSKe2qARxIC6Eny8oyRwHESDyA43fCrt8KzRKfSLpx
Content-type: application/octet-stream; 
	name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-transfer-encoding: base64

--0__=oyhsLd76eBszZHvSKe2qARxIC6Eny8oyRwHESDyA43fCrt8KzRKfSLpx--

--____GLYVGGEUTJVQYJTMHCNC____
Content-type: text/x-vcard; charset=iso-8859-1; name="Bob Jueneman.vcf"
Content-transfer-encoding: quoted-printable
Content-id: <QSBCUBDQOIKJKJOABZMI>
Content-disposition: attachment; filename="Bob Jueneman.vcf";
	modification-date="Fri, 20 Aug 1999 17:45:14 -0600"

BEGIN:VCARD
VERSION:2.1
X-GWTYPE:USER
FN:Bob Jueneman
TEL;WORK:1-801-861-7387, 1-800-453-1267
ORG:Novell, Inc.;Network Security Development
TEL;PREF;FAX:801-861-2522
EMAIL;WORK;PREF;NGW:[email-masked]
N:Jueneman;Robert
TITLE:Security Architect
ADR;INTL;WORK;PARCEL;POSTAL:;PRV-F331;122 E. 1700 South;Provo;Utah;84606;US=
A
LABEL;INTL;WORK;PARCEL;POSTAL;ENCODING=3DQUOTED-PRINTABLE:Bob Jueneman=3D0A=
=3D
PRV-F331=3D0A=3D
122 E. 1700 South=3D0A=3D
Provo, Utah  84606=3D0A=3D
USA
LABEL;DOM;WORK;PARCEL;POSTAL;ENCODING=3DQUOTED-PRINTABLE:Bob Jueneman=3D0A=
=3D
PRV-F331=3D0A=3D
122 E. 1700 South=3D0A=3D
Provo, Utah  84606
TEL;HOME:1-801-765-4378
TEL;CELL:1-80-1-361-1410
TEL;PREF:1-801-861-7387, 1-800-453-1267
X-GWUSERID:BJUENEMAN
END:VCARD

--____GLYVGGEUTJVQYJTMHCNC____--

--____RXBQHFRQSACVAWREOUDE____
Content-type: application/x-pkcs7-signature; name="smime.p7s"
Content-transfer-encoding: base64
Content-disposition: attachment; filename="smime.p7s"
CONTENT-DESCRIPTION: S/MIME Cryptographic Signature

--____RXBQHFRQSACVAWREOUDE____--

To: Peter Siklosi <[email-masked]>
Cc: "John Hughes" <[email-masked]>, [email-masked], [email-masked], Darren Harter <[email-masked]>, [email-masked], [email-masked]
Date: Tue, 17 Aug 1999 11:00:19 +0100
From: Andrew Farrell <[email-masked]>
Sender: [email-masked]

Fcc: +sent
Subject: Re: X9.42 and RFC2459 inconsistency? 
In-Reply-To: Your message of "Tue, 17 Aug 1999 11:26:55 +0200."
             <[email-masked]> 
--------
In message <[email-masked]>you write:
>Andrew,

>In the RFC2459, section 7.3.2, it says:

>   "The Diffie-Hellman OID supported by this profile is defined by ANSI X9.42"

>I am not sure what you mean by the "X9.42 oid with the pfc 2459 semantics".

What I said. The OID in RFC 2459 is taken from X9.42, but the semantics
specifed below are different to the ones specified in X9.42. In RFC
2459, the subjectPublicKey is a bitstring wrapping an encoded integer
which has the value of the public key. This is consistent with the
treatment of DSA and RSA, but contradicts X9.42, which specifies that
the subjectPublicKey is a bitstring which has the value of the public
key.

This is something that PKIX may have to push back on X9.42 on, so it's
not clear which will be the winning semantics.

Andrew.

From: "Pawling, John" <[email-masked]>
To: "'SMIME WG'" <[email-masked]>
Subject: Final 15 July 1999 S/MIME WG Minutes
Date: Thu, 19 Aug 1999 16:29:47 -0400
Sender: [email-masked]

This message includes the minutes of the IETF S/MIME Working Group
(WG) meeting held on 15 July 1999 in Oslo, Norway.  All briefing slides
are stored at: ftp://ftp.ietf.org/ietf/smime/.  These minutes 
include comments from the briefing presenters.  Reported by John Pawling.

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

Introductions - Russ Housley
 
Russ reviewed the agenda.  It was identical to that publicized prior to the
meeting except that the DOMSEC Draft Discussion was cancelled and Russ
substituted for several of the presenters who were unable to attend the
meeting.  Nobody objected to the agenda.

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

RFC 2630-2634 Status - Russ Housley

The following IETF S/MIME v3 Proposed Standards are available at
http://www.ietf.org/rfc/:
RFC 2630  Cryptographic Message Syntax, R. Housley, June 1999
RFC 2631  Diffie-Hellman Key Agreement Method, E. Rescorla, June 1999
RFC 2632  S/MIME Version 3 Certificate Handling, B. Ramsdell, June 1999
RFC 2633  S/MIME Version 3 Message Specification, B. Ramsdell, June 1999
RFC 2634  Enhanced Security Services for S/MIME, P. Hoffman, June 1999

To become Internet Draft Standards, the aforementioned documents must 
meet the following requirements:
1) Exist as Proposed Standards for 6 months.
2) Each MUST and SHOULD requirement must be implemented by at least two
independent implementations such that they are interoperable.
 
Russ requested that all S/MIME v3 implementors provide a description of the
S/MIME v3 features that are supported by their implementation.

Paul Hoffman stated that RFC 2632 is dependent on RFC 2459 (Internet X.509
Public Key Infrastructure Certificate and CRL Profile), so RFC 2632 can not
become a Draft Standard until RFC 2459 becomes one.  Similarly, RFC 2633 is
dependent on RFC 2632 and RFC 2634 is dependent on RFC 2633.  Therefore, RFC
2459 must become a Draft Standard before RFC 2632, RFC 2633 or RFC 2634 can
become Draft Standards.  Paul noted that there are still unresolved issues
with RFC 2459.  Russ stated that neither RFC 2630 nor RFC 2631 are 
dependent on the portions of RFC 2459 that are unresolved.  

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

Charter Revision - Russ Housley

Russ reviewed the following proposed changes to the S/MIME WG charter that
he had previously sent to the mail list.

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

Small Subgroup Attacks:

The use of D-H Key Agreement as the mandatory to implement key establishment
mechanism may expose some implementations to vulnerabilities based on "small
subgroup" attacks.  An informational document will be prepared describing
techniques that can be used to avoid these attacks. 

Proposed Milestones:
History: First "Methods for Avoiding the "Small-Subgroup" Attacks on the
Diffie-Hellman Key Agreement Method for S/MIME" Internet-Draft (I-D)
published.
Aug 1999: Last call.
Nov 1999: Submit Informational RFC.

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

Additional Algorithms

CMS is cryptographic algorithm independent, yet there is always more than
one way to use any algorithm.  To ensure interoperability, each algorithm
should have a specification that describes its use with CMS. 

Proposed Milestones:
History: First "CMS KEA and SKIPJACK Conventions" I-D published.
	   First " Incorporation of IDEA encryption algorithm in S/MIME" I-D
published.
Aug 1999: KEA and Skipjack last call.
Nov 1999: KEA and Skipjack Informational RFC.
Dec 1999: IDEA last call.
Mar 2000: IDEA Informational RFC.

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

CMS and ESS Examples

To aid implementors, documents containing example output for CMS and ESS
will
be collected and published.

Proposed Milestones:
History: First "Examples of S/MIME Messages" I-D published.
Dec 1999: Last call.
Mar 2000: Informational RFC.

Russ asked that implementors provide interesting invalid cases in addition
to valid cases.

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

CERTDIST

Current methods of publishing certificates in the Directory do not 
allow the inclusion of secondary support information such as the 
SMIMECapabilities attribute.  A method of publishing certificates 
along with authenticated secondary support information will be 
defined. 

Proposed Milestones:
History: First "Certificate Distribution Specification" I-D published.
Sep 1999: Last call.
Jan 2000: Proposed Standard RFC.

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

Password-based Key Management

In some situations it would be advantageous for the CMS RecipientInfo
structure to support additional key management techniques, including
cryptographic keys derived from passwords.  A mechanism to facilitate 
the definition of additional key management techniques will be defined.

Proposed Milestones:
History: First "Password-based Encryption for S/MIME" I-D published.
Dec 1999: Last call.
Mar 2000: Proposed Standard RFC.

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

Mail List Key Distribution

S/MIME version 3 supports encrypted mail lists.  Specifications for the 
distribution of symmetric mail list keys to mail list agents (MLAs) and
message recipients will be developed.  The specification will be 
cryptographic algorithm independent.

Proposed Milestones:
Sep 1999: First Mail List Key Distribution I-D will be published.
Jan 2000: Last call.
Mar 2000: Proposed Standard RFC.

Russ stated that an editor is needed for this document.  He stated that this
I-D will document the distribution of pre-placed symmetric keys that can be
used to process CMS KEKRecipientInfo.  He noted that this capability can be
used for purposes other than to support mail lists.  

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

Security Label Usage

S/MIME version 3 supports security labels.  Specifications that show 
how this feature can be used to implement an organizational security 
policy will be developed.  Security policies from large corporations will
be used as examples.

Proposed Milestones:
Jul 1999: First Security Label Usage I-D will be published.
Nov 1999: Last call.
Feb 2000: Informational RFC.

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

DOMSEC

S/MIME version 3 can be used to protect electronic mail to and from a
domain. "Domain Security Services" result when the S/MIME v3 processing is
performed by message transfer agents, guards or gateways.  Mechanisms are
needed to solve a number of interoperability problems and technical
limitations that arise when domains supporting different security policies
wish to interoperate.

Proposed Milestones:
History: First "Domain Security Services using S/MIME" I-D published.
Jul 2000: Last call.
Sep 2000: Experimental RFC.

Sean Turner asked if the proposed charter could be changed to allow I-Ds to
be submitted that document environments other than those described in the
DOMSEC I-D.  Russ stated that he would edit the text in the charter
regarding DOMSEC so that it is more generic to allow other I-Ds to be
submitted.

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

Charter Wrap-Up

Russ asked if any attendees knew of any issues, had comments or wished to
discuss any related topics.  He asked if the attendees believed that the
revised charter was ready for the Security Area Directors and IESG. 

Paul Hoffman requested that text be added to the charter that allows work to
be performed related to adding other options for mandatory-to-implement
strong encryption algorithms.

Jim Schaad asked if the WG should consider replacing D-H with RSA as the
mandatory-to-implement key management algorithm once the RSA patent expires.
Russ added that the RSA patent expires in about a year.

An attendee expressed his opinion that the RSA algorithm should be
deprecated from the S/MIME v3 specifications altogether.

Another attendee stated that European software uses the RSA algorithm 
because the RSA patent doesn't apply outside of the US.
 
Andrew Farrell requested that the name of the Mail List Key Distribution I-D
be changed to "Previously-Distributed Symmetric Keys".  Nobody objected.

Paul Hoffman recommended that the WG should consider replacing D-H with RSA
as the mandatory-to-implement key management algorithm, but not to associate
any milestones with the work.

Russ stated that he will send out a revised draft charter.

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

Avoiding Small Subgroups - Russ Housley 

Robert Zuccherato generated the "Methods for Avoiding the "Small-Subgroup"
Attacks on the Diffie-Hellman Key Agreement Method for S/MIME" I-D.  Russ
stated that the I-D has not has not been discussed much on the mail list.
The WG is obligated to generate this I-D to address the subject
vulnerabilities.  He strongly recommends that implementors read the I-D so
that they are aware of the vulnerabilities.  He asked how many attendees
have read the I-D.  Only 6 people raised their hands.  Russ asked that the
WG members review and provide comments to the document.   

Tony Mione stated a comment to the I-D.  Russ asked him to send his 
comment to the mail list, and he did so.  See Tony's 15 July 1999 message
sent to the list, subject: "Quick comment on the Small Subgroup Attack
draft". 

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

CERTDIST Draft Discussion - Jim Schaad

Jim stated that he has only received comments from Russ to the 25 February
1999 Certificate Distribution (CERTDIST-03) I-D.  

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

CMS/ESS Examples - Paul Hoffman

Paul stated that the following companies have been participating in the
generation of the "Examples of S/MIME Messages" I-D: Microsoft, Worldtalk,
Baltimore, SPYRUS and J.G. Van Dyke & Associates (VDA).  He stated that the
June draft includes placeholders for examples from ESS.  He requested that
the WG members review the I-D and provide comments.  He is planning to
establish an "Examples" mail list for people to exchange information 
regarding interoperability testing.  The document will include some
incorrect examples that flag common implementation errors including 
explanations of the mistakes.  Russ stated that he is especially looking
for folks who have implemented the AuthenticatedData, EncryptedData
and/or DigestedData content types.

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

Security Policies and Labels - Russ Housley

Russ stated that Weston Nicolls is developing an I-D that will document the
security policies of Whirlpool, Caterpillar and Amoco.  The draft will
document how the ESSSecurityLabel can be used to implement those
corporations' security policies.  

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

S/MIME Freeware Library (SFL) - John Pawling

The SFL is a freeware implementation of RFC 2630 and RFC 2634.  It uses the
Crypto++ freeware library to implement RFC 2631.  It provides functions to
support the use of RFC 2632 and RFC 2633.  The goal of the SFL is to provide
a reference implementation of RFC 2630 and RFC 2634 to encourage their
acceptance as Internet Standards.  VDA is developing the SFL.

The SFL protects any type of data (not just MIME).  It is algorithm
independent.  It is used with external crypto libraries that provide the
crypto algorithms.  It uses the VDA-enhanced SNACC freeware library to
perform all ASN.1 encoding (including DER) and decoding of CMS and ESS
objects as well as certificates, CRLs, etc.  All SFL source code is provided
(all code is C++).  

The SFL implements the optional RFC 2634 security services such as signed
receipts, security labels, mail list information, signing certificate
attribute and equivalent security labels.  It has been used with the RSA
BSAFE v3.0 and Crypto++ v3.0 libraries.  VDA is currently enhancing the SFL
to work with the Fortezza Cryptologic Interface Library and SPYRUS SPEX/
Library.  

VDA provides several test utilities along with the SFL including: 
- Test driver to build and process a variety of CMS/ESS messages; 
- Test utility that processes and displays contents of MIME encoded messages
containing single body part or multi-part CMS/ESS components; and
- Test utility to generate key material, certificates (such as D-H) and
CRLs.

Version 1.0 SFL was released in June 1999.  It was tested on MS Windows
95/NT, Sun Solaris 2.6 and Linux.  It was tested using the mandatory and RSA
algorithm suites.  VDA continues to enhance the SFL.  

The SFL has been used to exchange signedData and envelopedData messages with
MS Internet Explorer Outlook Express v4.01 and Netscape Communicator 4.X.
Signed messages have been exchanged with RSA S/MAIL, WorldTalk and Entrust
S/MIME v2 products.  S/MIME v3 interoperability testing between SFL and 
Microsoft includes all envelopedData features such as using Ephemeral-Static
D-H pairwise key with 3DES-wrapped and RC2-wrapped content encryption keys. 
RSA-signed signedData messages have also been exchanged.  The majority of 
the ESS features have been tested.  S/MIME v3 interoperability testing also
performed with Baltimore, Inc.  VDA plans to participate in the IETF S/MIME
WG interoperability testing including providing CMS/ESS messages for
inclusion in the S/MIME "Examples of S/MIME Messages" document.

Organizations can use the SFL as part of their applications without paying
any royalties or licensing fees (see SFL Public License).  VDA-enhanced
SNACC ASN.1 software and SFL documents are freely available to everyone at:
http://www.jgvandyke.com/services/infosec/sfl.htm.  All other portions of
the SFL are available at:
http://www.armadillo.huntsville.al.us/software/smime and are export
controlled as per U.S. Government Export Administration Regulations (see:
http://www.bxa.doc.gov/Encryption/Default.htm).

The IMC has established an SFL mail list 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 IMC SFL web page:
http://www.imc.org/imc-sfl.

An attendee asked if there was any way that the SFL could be obtained from
outside the U.S.  John stated that the vendor would need to obtain an export
license and referred him to the aforementioned U.S. Government Export
Administration Regulations web page.  Several attendees then discussed how
the SFL could be distributed outside the U.S. such as publishing the source
code in a book.

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

Wrap Up - Russ Housley
None of the attendees had any other comments or issues.

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

ACTION ITEMS:

1. Tony Mione will send his comment regarding the Avoiding Small Subgroup
Attacks I-D to the mail list.

2. ALL S/MIME v3 Implementors: Provide a description to Russ of the S/MIME
v3 features that are supported by your software.

3. ALL S/MIME v3 Implementors: Provide valid and invalid sample data to Paul
Hoffman for inclusion in the "Examples of S/MIME Messages" I-D.

4. Russ will send the revised charter to the mail list.

====================================================================
John Pawling,  Director - Systems Engineering,  [email-masked] 
J.G. Van Dyke & Associates, Inc., a Wang Government Services Company
====================================================================

From: [email-masked]
Date: Thu, 19 Aug 1999 10:58:00 -0600
Cc: [email-masked], [email-masked]
Subject: Re: NR -- what the real issues are, and  a proposal
To: "[email-masked]"
Sender: [email-masked]

--____JVKELTVPWVZXCRLXUMYG____
Content-type: text/plain; charset=iso-8859-1

>>> "Rich Ankney" <[email-masked]> 08/17/99 05:07PM >>>
Bob,

Thanks for finally posting all of the relevant stuff in one
message.  My first thought would be to minimize reliance
on the NR bit, i.e. follow Steve's suggestion that if it's
FALSE, you can't use the cert for NR, else you might
be able to.

Of course, ANSI X9.45 defines a useful (CMS signed) attribute
to indicate the purpose of a signature.  Could we overload this (or
define something new but similar) to indicate intent?  The
syntax was an OID, so doing this is pretty simple.  I'd be
glad to force this thru X9 if the IETF crowd is not interested.

Best regards,
Rich

PS: I sent this to you personally rather than to the list in case
you'd like to discuss the details.  If not, of course, feel free
to post your response to the list.

Hi, Rich,

I'll take you upon your offer to post your note to the list, and
I'll also comment in passing on some other contributions from
Ed, Tony, and Steve, recognizing that some other suggestions have 
partially overtaken some of these ideas while I was preparing
this note and attending meetings. :-)

I agree with you regarding the case when the NR bit is off -- you
can't use the certificate for any nonrepudiation purpose in that case.
Perhaps I wasn't sufficiently clear in the proposal summary, 
although I think I was in the more detailed text, where I said that the NR
bit has to be used to ENABLE the NR bit in the message itself.

If NR bit is off, any message signed with the key in that certificate 
CANNOT intentionally or unintentionally be used for any legally 
binding purpose -- you are denying, in advance, that that was 
your intent, and signaling a prospective relying party that relying 
on your signature and certificate would be repudiated in court, if 
necessary, and hence such reliance would be quite unwise,
to say the least.
 
Why should you try to deny in advance something that might be 
legally binding (to answer someone else's question)?  Because 
you might be concerned about the possibility that your key might 
be stolen, and that it might not be YOU that is signing in that fashion!

Obviously you know (or at least ought to know) the strengths and 
weakness of your own key management system, and you might
very well decide that a given key/certificate was not sufficiently 
well protected to be used for any legally binding purposes -- it would 
just be too risky. Maybe your ordinary digital-signature-key-used-for-
network-logon-authentication-via-SSL is kept on your hard 
drive with relatively weak password encryption, and your 
nonrepudiation key/certificate is kept on a removable smart card.  
(I think this is Ed's point -- that if I don't have the power to deny 
a given capability in advance, it really isn't nonrepudiation -- it's 
just an option that I can't control and hence can't be binding, since 
it isn't voluntary.)

As I read Steve's note, I think he is in agreement with at least this point.

However, Steve, Tony, and even Ed then go down a path that I think is 
highly questionable, and that is the CA-centric view of enabling 
or disabling nonrepudiation within the CPS. Granted, if there is even 
the faintest suggestion that the CA might be liable for the user's 
actions with respect to his key and how they are used, then the 
CA ought to be able to deny the user the ability to set the NR bit. 
But it should do, obviously, by simply refusing to issue a certificate 
containing that bit.  But whether the CA can impose other conditions 
on the subscriber, or on the RP, in this particular area seems highly 
doubtful, as I will explain. (And as I expect that you, Rich, 
already know because of your banking involvement.)

There are three reasons why something like a NR bit should be in the 
certificate, and not just rely on a certificate policy OID (or worse yet, 
just a statement in the CPS itself.)

The first is a practical one -- very little RP software to date (none that I know of) 
implements the policy OID constraint, and without that constraint there is no 
enforcement.  In fact, I would bet that a lot of software would ignore the
constraint even if it were marked critical -- they certainly ignore a lot of other
critical attributes.

The second reason is more important.  Although I can, if I am the relying
party, choose a superior CA whose certificate specifies a policy OID constraint,
I am not required to do so. In fact, I can import and "trust" (accept as valid) 
a user's certificate directly, without relying on any intervening CA's certificate 
at all.  I'm not quite certain whether a policyOID constraint can be placed on 
the end-user's certificate -- can it? -- but even if it is it is far from obvious that
such a constraint is binding upon the application. What mechanisms are 
postulated to tell the RP what particular policy OID the user feels like accepting 
today?

So the relying party, or the relying party's IS department, may specify such a policy
constraint, BUT THEY ARE NOT REQUIRED TO DO SO.  

Finally, as I believe I explained in a previous message, to the best of my
knowledge there is no legal way that I know of whereby the relying party
can be required to even read the CA's CPS prior to accepting a digital signature,
or more importantly why a CPS that reflects an agreement between the CA 
and the subscriber would be binding upon the RP.  

This is a contractual privity issue, and there simply isn't any way around it that 
I know of -- a contract between A and B is not binding on C, even if there were 
also a contract between B and C.

So the only way that I know of to specify something of this type is in the defined 
semantics of the attribute itself.  If the NR bit is now so hopeless confused that
someone could wriggle out of this definition, then we ought to define a new one,
perhaps intentToBeLegallyBound, and deprecate the old one. But I don't think we 
are there yet -- I think we can use the existing bit for this purpose, so long as we 
recognize that it is the turning off of the bit that is really the most important thing.

With respect to the suggestion to define a new signedAttribute to be applied 
to the message, Russ Housely indicates that would be outside of the current
SMIME WG's charter, but that the charter could be amended if there was 
sufficient interest.

If we can get some reasonable consensus on the overall approach, I would 
be happy to work with you, Rich, to perhaps define a joint IETF-SMIME and
 X9 contribution in this area.

Bob

-----Original Message-----
From: Bob Jueneman <[email-masked]>
To: [email-masked] <[email-masked]>
Date: Tuesday, August 17, 1999 5:39 PM
Subject: NR -- what the real issues are, and a proposal

>The message which follows is a rather lengthy attempt to recap of
>the last five years or so of technical/legal discussion regarding
>digital signatures, followed by a proposal for what to do to fix these
>problems.
>
>However, since many may want to skip the justification and cut t
>o the bottom line, I'll put the proposal up front, and then justify it:
>
>My proposal is that the text of the nonrepudiation key usage bit I
>n the PKIX RFC (and hopefully in X.509) be revised to unambiguously
>state that the defined semantics of this bit is to indicate the willingness
>of the subscriber to be legally bound by a digital signature which can be
>verified by a certificate that can be established to have been valid at the
>time of signature, where "valid" has the normal meaning of not expired, not
>revoked, etc., etc.
>
>In addition, I propose that we create an additional indicator of a
>human being's conscious and willful intent to be legally bound by
>a digital signature that would be applied on a message by message
>basis. This additional indicator would require, as an integral part of
>its semantic definition, that an explicit computer-to-human interaction
>be required to provide some reasonable level of ceremonial and due
>caution warning be provided to the user.  In addition, the semantics
>of this indicator should specify that its use must be ENABLED by the
>NR bit ( as redefined) in the certificate which includes the corresponding
>public key.  If the certificate does not have the bit turned on, the
>application is not obligated to request the ceremonial, due caution
>approval; and relying party software should ignore a per-message
>indicator even if present in that case.
>
>The obvious, but not necessarily the only, place to put such a message
>by message indicator would be in the Cryptographic Message Syntax
>used by S/MIME V3, in particular as a new signedAttribute.  Since
>signedAttributes is a SET of self-describing attributes, adding
>an additional one would be very simple.
>
>Now for the history lesson.
[snip]
--____JVKELTVPWVZXCRLXUMYG____
Content-type: multipart/related; boundary="____AHXCDJKVBWFYUXNLTMAP____"

--____AHXCDJKVBWFYUXNLTMAP____
Content-type: text/html; charset=iso-8859-1

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content="text/html; charset=unicode" http-equiv=Content-Type>
<META content="MSHTML 5.00.2314.1000" name=GENERATOR></HEAD>
<BODY bgColor=#ffffff 
style="FONT: 10pt Arial; MARGIN-LEFT: 2px; MARGIN-TOP: 2px">
<DIV><FONT face="MS Sans Serif" size=1><FONT face="MS Sans Serif" 
size=1>&gt;&gt;&gt; "Rich Ankney" &lt;[email-masked]&gt; 08/17/99 05:07PM 
&gt;&gt;&gt;<BR>Bob,<BR><BR>Thanks for finally posting all of the relevant stuff 
in one<BR>message.&nbsp; My first thought would be to minimize reliance<BR>on 
the NR bit, i.e. follow Steve's suggestion that if it's<BR>FALSE, you can't use 
the cert for NR, else you might<BR>be able to.<BR><BR>Of course, ANSI X9.45 
defines a useful (CMS signed) attribute<BR>to indicate the purpose of a 
signature.&nbsp; Could we overload this (or<BR>define something new but similar) 
to indicate intent?&nbsp; The<BR>syntax was an OID, so doing this is pretty 
simple.&nbsp; I'd be<BR>glad to force this thru X9 if the IETF crowd is not 
interested.<BR><BR>Best regards,<BR>Rich<BR><BR>PS: I sent this to you 
personally rather than to the list in case<BR>you'd like to discuss the 
details.&nbsp; If not, of course, feel free<BR>to post your response to the 
list.<BR><BR></FONT></FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1></FONT>&nbsp;</DIV>
<DIV><FONT face="MS Sans Serif" size=1>Hi, Rich,</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face="MS Sans Serif" size=1>I'll take you upon your offer to post 
your note to the list, and</FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1>I'll also comment in passing on some 
other contributions from</FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1>Ed, Tony, and Steve, recognizing that 
some other suggestions have </FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1>partially overtaken some of these ideas 
while I was preparing</FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1>this note and attending meetings. 
:-)</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face="MS Sans Serif" size=1>I agree with you regarding the case when 
the NR bit is off -- you</FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1>can't use the certificate for any 
nonrepudiation purpose in that case.</FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1>Perhaps I wasn't suffici</FONT><FONT 
face="MS Sans Serif" size=1>ently clear in </FONT><FONT face="MS Sans Serif" 
size=1>the proposal summary, </FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1>although I think I was in the more 
</FONT><FONT face="MS Sans Serif" size=1>detailed text, where I said that the 
NR</FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1>bit has to be used to ENABLE the NR bit 
in the message itself.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face="MS Sans Serif" size=1>If </FONT><FONT face="MS Sans Serif" 
size=1>NR bit is off, any message signed </FONT><FONT face="MS Sans Serif" 
size=1>with the key in that certificate </FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1>CANNOT intentionally or 
unintentionally&nbsp;be used for</FONT><FONT face="MS Sans Serif" size=1> any 
</FONT><FONT face="MS Sans Serif" size=1>legally </FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1>binding purpose -- you are denying, 
</FONT><FONT face="MS Sans Serif" size=1>in advance, </FONT><FONT 
face="MS Sans Serif" size=1>that that&nbsp;was </FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1>your intent, and signaling a prospective 
</FONT><FONT face="MS Sans Serif" size=1>relying party that relying 
</FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1>on your signature and certificate would 
</FONT><FONT face="MS Sans Serif" size=1>be repudiated in court, if 
</FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1>necessary, and hence such reliance 
</FONT><FONT face="MS Sans Serif" size=1>would be quite unwise,</FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1>to say the least.</FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1></FONT>&nbsp;</DIV>
<DIV><FONT face="MS Sans Serif" size=1>Why should you try to deny in advance 
</FONT><FONT face="MS Sans Serif" size=1>something that might be </FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1>legally binding (to answer someone else's 
</FONT><FONT face="MS Sans Serif" size=1>question)?&nbsp; Because </FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1>you might be concerned about the 
possibility </FONT><FONT face="MS Sans Serif" size=1>that your key might 
</FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1>be stolen, and that it might not be YOU 
</FONT><FONT face="MS Sans Serif" size=1>that is signing in that 
fashion!</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face="MS Sans Serif" size=1>Obviously you know (or at least ought to 
know) the strengths and </FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1>weakness of your own key management 
system, and you might</FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1>very well decide that a given 
key/certificate was not sufficiently </FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1>well protected to be used for any legally 
binding purposes -- it would </FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1>just be too risky. Maybe your ordinary 
</FONT><FONT face="MS Sans Serif" 
size=1>digital-signature-key-used-for-</FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1>network-logon-authentication-via-SSL is 
kept on your hard </FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1>drive with relatively weak password 
encryption, and your </FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1>nonrepudiation </FONT><FONT 
face="MS Sans Serif" size=1>key/certificate is kept on a removable smart 
card.&nbsp; </FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1>(I think this is Ed's point -- 
</FONT><FONT face="MS Sans Serif" size=1>that if I don't have the power to deny 
</FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1>a given&nbsp;capability in advance, it 
really </FONT><FONT face="MS Sans Serif" size=1>isn't nonrepudiation -- it's 
</FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1>just an option that I can't control and 
hence can't be binding, since </FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1>it isn't voluntary.)</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face="MS Sans Serif" size=1>As I read Steve's note, I think he is in 
agreement with at least this point.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face="MS Sans Serif" size=1>However, Steve, Tony, and even Ed then go 
down a path that I think is </FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1>highly questionable, and that is the 
CA-centric view of enabling </FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1>or disabling nonrepudiation within the 
CPS. Granted, if there is even </FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1>the faintest suggestion </FONT><FONT 
face="MS Sans Serif" size=1>that the CA might be liable for the user's 
</FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1>actions with respect to his key 
</FONT><FONT face="MS Sans Serif" size=1>and how they are used, then the 
</FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1>CA ought to be able to deny the user 
</FONT><FONT face="MS Sans Serif" size=1>the ability to set the NR bit. 
</FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1>But it should do, obviously, by simply 
refusing to </FONT><FONT face="MS Sans Serif" size=1>issue a certificate 
</FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1>containing that bit.&nbsp; But whether 
the CA can impose </FONT><FONT face="MS Sans Serif" size=1>other conditions 
</FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1>on the subscriber, or on the RP, in this 
particular area </FONT><FONT face="MS Sans Serif" size=1>seems highly 
</FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1>doubtful, as I will explain. (And as I 
expect that you, Rich, </FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1>already know because of your banking 
involvement.)</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face="MS Sans Serif" size=1>There are three reasons why something 
like a NR bit should be in the </FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1>certificate, and not </FONT><FONT 
face="MS Sans Serif" size=1>just rely on a certificate policy OID (or worse yet, 
</FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1>just a statement in the CPS </FONT><FONT 
face="MS Sans Serif" size=1>itself.)</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face="MS Sans Serif" size=1>The first is a practical one -- very 
little RP software to date (none that I know of) </FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1>implements the policy OID constraint, and 
without that constraint there is no </FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1>enforcement.&nbsp; In fact, I would bet 
that a lot of software would ignore the</FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1>constraint even if it were marked 
critical -- they certainly ignore a lot of other</FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1>critical attributes.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face="MS Sans Serif" size=1>The second reason is more 
important.&nbsp; Although I can, if I am the relying</FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1>party, choose a superior CA whose 
certificate specifies a policy OID constraint,</FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1>I am not required to do so. In fact, I 
can import and "trust" (accept as valid) </FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1>a user's certificate directly, 
</FONT><FONT face="MS Sans Serif" size=1>without relying on any intervening CA's 
certificate </FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1>at all.&nbsp; I'm not quite certain 
whether a policyOID constraint can be placed on </FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1>the end-user's certificate -- can it? -- 
but even if it is it is far from obvious that</FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1>such a constraint is binding upon the 
application. What mechanisms are </FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1>postulated to tell the RP what particular 
policy OID the user feels like accepting </FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1>today?</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face="MS Sans Serif" size=1>So the relying party, or the relying 
party's IS department, may specify such a policy</FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1>constraint, BUT THEY ARE NOT REQUIRED TO 
DO SO.&nbsp; </FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face="MS Sans Serif" size=1>Finally, as I believe I explained in a 
previous message, to the best of my</FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1>knowledge there is no legal way that I 
know of whereby the relying party</FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1>can be required to even read the CA's CPS 
prior to accepting a digital signature,</FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1>or more importantly why a CPS that 
reflects </FONT><FONT face="MS Sans Serif" size=1>an agreement between the CA 
</FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1>and the subscriber would be binding upon 
the </FONT><FONT face="MS Sans Serif" size=1>RP.&nbsp; </FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face="MS Sans Serif" size=1>This is a contractual privity issue, and 
there simply isn't any way around it that </FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1>I know of -- a contract between A and B 
is not binding on C, even if there were </FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1>also </FONT><FONT face="MS Sans Serif" 
size=1>a contract between B and C.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face="MS Sans Serif" size=1>So the only way that I know of to specify 
something of this type is in the defined </FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1>semantics of the attribute itself.&nbsp; 
If the NR bit is now so hopeless confused that</FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1>someone could wriggle out of this 
definition, then we ought to define a new one,</FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1>perhaps intentToBeLegallyBound, and 
deprecate the old one. But I don't think we </FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1>are there yet -- I think we can use the 
existing bit for&nbsp;this purpose, so long as we </FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1>recognize that it is the turning off of 
the bit that is really the most important thing.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face="MS Sans Serif" size=1>With respect to the suggestion to define 
a new signedAttribute to be applied </FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1>to the message, Russ Housely indicates 
that would be outside of the current</FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1>SMIME WG's charter, but that the charter 
could be amended if there was </FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1>sufficient </FONT><FONT 
face="MS Sans Serif" size=1>interest.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face="MS Sans Serif" size=1>If we can get some reasonable consensus 
on the overall approach, I would </FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1>be happy to work with you, Rich, to 
perhaps define a joint IETF-SMIME and</FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1>&nbsp;X9 contribution in this 
area.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face="MS Sans Serif" size=1>Bob</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face="MS Sans Serif" size=1>-----Original Message-----<BR>From: Bob 
Jueneman &lt;[email-masked]&gt;<BR>To: [email-masked] 
&lt;[email-masked]&gt;<BR>Date: Tuesday, August 17, 1999 5:39 PM<BR>Subject: 
NR -- what the real issues are, and a proposal<BR><BR><BR>&gt;The message which 
follows is a rather lengthy attempt to recap of<BR>&gt;the last five years or so 
of technical/legal discussion regarding<BR>&gt;digital signatures, followed by a 
proposal for what to do to fix these<BR>&gt;problems.<BR>&gt;<BR>&gt;However, 
since many may want to skip the justification and cut t<BR>&gt;o the bottom 
line, I'll put the proposal up front, and then justify it:<BR>&gt;<BR>&gt;My 
proposal is that the text of the nonrepudiation key usage bit I<BR>&gt;n the 
PKIX RFC (and hopefully in X.509) be revised to unambiguously<BR>&gt;state that 
the defined semantics of this bit is to indicate the willingness<BR>&gt;of the 
subscriber to be legally bound by a digital signature which can 
be<BR>&gt;verified by a certificate that can be established to have been valid 
at the<BR>&gt;time of signature, where "valid" has the normal meaning of not 
expired, not<BR>&gt;revoked, etc., etc.<BR>&gt;<BR>&gt;In addition, I propose 
that we create an additional indicator of a<BR>&gt;human being's conscious and 
willful intent to be legally bound by<BR>&gt;a digital signature that would be 
applied on a message by message<BR>&gt;basis. This additional indicator would 
require, as an integral part of<BR>&gt;its semantic definition, that an explicit 
computer-to-human interaction<BR>&gt;be required to provide some reasonable 
level of ceremonial and due<BR>&gt;caution warning be provided to the 
user.&nbsp; In addition, the semantics<BR>&gt;of this indicator should specify 
that its use must be ENABLED by the<BR>&gt;NR bit ( as redefined) in the 
certificate which includes the corresponding<BR>&gt;public key.&nbsp; If the 
certificate does not have the bit turned on, the<BR>&gt;application is not 
obligated to request the ceremonial, due caution<BR>&gt;approval; and relying 
party software should ignore a per-message<BR>&gt;indicator even if present in 
that case.<BR>&gt;<BR>&gt;The obvious, but not necessarily the only, place to 
put such a message<BR>&gt;by message indicator would be in the Cryptographic 
Message Syntax<BR>&gt;used by S/MIME V3, in particular as a new 
signedAttribute.&nbsp; Since<BR>&gt;signedAttributes is a SET of self-describing 
attributes, adding<BR>&gt;an additional one would be very 
simple.<BR>&gt;<BR>&gt;Now for the history lesson.</FONT></DIV>
<DIV><FONT face="MS Sans Serif" size=1>[snip]</DIV></FONT></BODY></HTML>

--____AHXCDJKVBWFYUXNLTMAP____--

--____JVKELTVPWVZXCRLXUMYG____--

From: [email-masked]
Date: Thu, 19 Aug 1999 10:40:00 -0600
Subject: Re: Nonrepudiation and what to do about it
To: [email-masked]
Sender: [email-masked]

The number of people who have asked me privately for 
the entire summary is such that I think that sending the original note
to the entire list may not be too great a waste of bandwidth.

Just be advised that the topic is being debated extensively 
on the PKIX list, and that some points are being made that are 
prompting me to think about some minor adjustments to my 
proposal.  Before we get to that point, however, I think it 
would be useful to hear from other people.

Vin McLellan asked for a URL, but unfortunely, our firewall policy 
makes it a little too awkward for me to post something.  Feel free to 
circulate it as desired, however.

Bob

The message which follows is a rather lengthy attempt to recap of 
the last five years or so of technical/legal discussion regarding 
digital signatures, followed by a proposal for what to do to fix these 
problems.

However, since many may want to skip the justification and cut t
o the bottom line, I'll put the proposal up front, and then justify it:

My proposal is that the text of the nonrepudiation key usage bit I
n the PKIX RFC (and hopefully in X.509) be revised to unambiguously 
state that the defined semantics of this bit is to indicate the willingness 
of the subscriber to be legally bound by a digital signature which can be 
verified by a certificate that can be established to have been valid at the 
time of signature, where "valid" has the normal meaning of not expired, not 
revoked, etc., etc.

In addition, I propose that we create an additional indicator of a 
human being's conscious and willful intent to be legally bound by 
a digital signature that would be applied on a message by message 
basis. This additional indicator would require, as an integral part of 
its semantic definition, that an explicit computer-to-human interaction 
be required to provide some reasonable level of ceremonial and due 
caution warning be provided to the user.  In addition, the semantics 
of this indicator should specify that its use must be ENABLED by the 
NR bit ( as redefined) in the certificate which includes the corresponding 
public key.  If the certificate does not have the bit turned on, the 
application is not obligated to request the ceremonial, due caution 
approval; and relying party software should ignore a per-message 
indicator even if present in that case.

The obvious, but not necessarily the only, place to put such a message 
by message indicator would be in the Cryptographic Message Syntax 
used by S/MIME V3, in particular as a new signedAttribute.  Since 
signedAttributes is a SET of self-describing attributes, adding 
an additional one would be very simple.

Now for the history lesson.

When the ABA Digital Signature Guidelines were being formulated within the 
Information Security Committee, with lots of very bright, well-informed 
attorneys and technologists contributing, there was a fundamental, underlying 
assumption that PKI technology could be used to reduce some of the uncertainty that 
was perceived to be a barrier to the efficient use of electronic commerce.

Instead of having to use proprietary, value added networks and negotiate 
N*(N-1) contracts between all of the trading partners, it was expected that 
the use of a common PKI technology and appropriate legal frameworks 
would eliminate most of that overhead.

It was recognized that a accretion of case law had resulted in a situation 
where printed forms, letterhead, FAXs, telegrams and later Telexes, 
ordinary e-mail, and who knows what else forms of communications could, 
under the proper circumstances, be interpreted as being a legally binding 
signature.  The trouble was that the technology had moved much faster t
han the case law, and the uncertainty was increasing at a compounded rate.

For example, back when printed forms were created on letterhead presses, 
and were filled in using either handwriting or a typewriter, it was pretty obvious 
what the difference was. And because going to a printer and having a lot of 
standard forms printed involved some expense, time and effort, the 
conventional use of such a form for purposes of trade might reasonably 
be considered tantamount to a signature of the company. Unfortunately, 
a technological decision that was rational at the time is no longer rational 
in the age of laser printers, when preprinted forms have almost disappeared.  
But the case law hasn't changed, so the question of what constitutes 
signature becomes more of a risk, both for the relying party who thought 
it was valid, and for the originator, who really didn't intend for it to be anything 
more than a draft proposal.

In addition to these technical/legal issues, there was also the issue of 
liability in the event of something going wrong, such as a key being compromised.

One approach would be the very loose standard of care embodied in 
the US credit card law (Regulation E), where even the most egregious 
carelessness on the part of the subscriber could only result in a $50 loss.  
The problem with that approach is that it effectively required the 
establishment of a mechanism that would be very similar to the 
credit card industry to centralize the reporting of every time 
a certificate was used to verify a transaction, so that loss 
limits could be enforced.

At the other end of the spectrum was "strict liability,' which is 
the standard used between major financial institutions.  Because 
of the volume of the business, and the difficulty of backing out 
transactions in error that might otherwise leave an innocent third 
party holding the bag for a transaction gone wrong, inter-bank 
transactions are generally governed by strict liability -- no matter 
what the extenuating circumstances might be the bank was 
still liable for a transaction that went out in its name.

In between these two poles were standards of simple negligence 
or gross negligence as a possible defense.

The final decision that was incorporated in the Guidelines, 
Section 5.6 Presumption in dispute resolution, was to create 
a "rebuttable presumption" that a digital signature verified by 
reference to the public key listed in a valid certificate is the 
digital signature of the subscriber listed in that certificate.

The effect of this presumption was to allocate the burden of 
proof to the person who is challenge the validity of the 
signature.  In the case of a claimed forgery, for example, 
the burden of proof (independent of the risk of loss) falls on 
the subscriber, who would generally be in a much better 
position to know how the keys were protected, etc., than 
the relying party.

The State of Utah, in their pioneering Digital Signature Act, 
didn't go quite so far as that. Instead, they applied the rebuttable 
presumption argument only to a special class of certificates created 
by so-called "Licensed Certification Authorities" that were subject 
to a higher level of assurance, involving inspection and audit and 
financial viability controls that were intended to make the imposition 
of a rebuttable presumption a more reasonable proposition.  And 
these Licensed CA certificates were strictly a voluntary opt-in provision.  
No one had to use them, and if they didn't, the traditional common-law 
provisions regarding signatures was explicitly stated to be unaffected.  
Some other states, including Washington and Minnesota, and a large 
number of foreign countries, also adopted this model.

Nonetheless, some elements of the legal profession were strongly opposed.  
A law student by the name of Bradford Biddle published a law review article 
or polemic bitterly attacking the Utah statute as an unholy interference in the 
market by creating financial subsidies for a particular class of technology 
while disadvantaging others (which others were being disadvantaged was 
never explained.) A noted lobbyist for a company who was marketing a 
biometric-based, digitized signature device managed to get the Secretary of 
State of California to effectively gut their digital signature law by completely 
redefining a "digital signature" to be something else entirely.  (At the same
time he has made a rather convincing case for a certain element of 
"ceremonial" and "due caution" protection in any device or 
program that applies a legally binding signature to a document, whether a 
digital signature or not. In particular, he has effectively raised the issue of 
an automaton or daemon applying a digital signature automatically, without 
any human input at all. And of course that is precisely what S/MIME v3 "
Enhanced" Security Services with automatically signed receipts is intended to do!)

Meanwhile, a young but influential attorney in the Massachusetts state 
government, responding the electoral "mandate" of their Libertarian governor, 
Gov. Weld, strongly opposed the "regulatory burden" that might be imposed by 
State licensing of CAs, leading to the rather ironic situation of arch-conservative 
Utah sponsoring a regulatory regime, while ultra-liberal Massachusetts was trying 
to privatize CAs  and let the lawyers fight it out in court. In addition, some of the 
computer industry was also opposed to any kind of regulatory regime -- they didn't 
want the government, any government, telling them what they could do, ever. 
So the establishment of some kind of a rebuttable presumption faced serious 
political difficulties. 

And then another segment of the academic legal community raised a consumer 
protection issue that quickly became even more of an political hot potato.  If a 
digital signature was presumed to be valid, then, since "everybody knows" that 
operating systems are not secure and that the Internet is a cesspool of viruses, 
etc., poor Grandma is going to lose her house someday because her keys were 
compromised.  (This is q variation on the "death-penalty" certificate theme.)

>From this perspective, what was desired was not more nonrepudiation, but 
LESS!  Or to be more precise, a better way to control exactly when and 
how a signature might reasonably be viewed as being intended to be legally 
binding, and when it might be restricted to being used for more benign applications.

Restricting such usages to a certificate issued by a Licensed CA might have 
been a reasonable option – Grandma should never apply for or accept such a 
certificate if she never wanted to be legally bound, especially for a high-value 
transaction such as selling her house, and the CA would presumably be 
obligated to make sure that she understood the possible risks and need to 
adequately protect her keys before accepting such a certificate.  Unfortunately, 
since statutes enabling the use of a Licensed CA are not yet common and are 
being opposed by some, this may not be a viable approach.

Another approach MIGHT be to very carefully spell out the terms and 
conditions of use for a certificate in the CAs Certification Practice Statement.  
But despite the general belief in the PKIX community of the efficacy of a CPS 
to cure all ills, there are very grave doubts about whether a CPS is really all t
hat helpful in this case.

First of all, there is not necessarily any requirement for a relying party to even 
read the CPS.  Granted, if the relying party does not conform to the terms of 
the CPS, it may have a more difficult time suing the CA for damages, but even 
this is arguable.

Second, no matter what the CPS states with respect to what the subscriber 
is obligated to do with respect to the CA, and no matter what the CPS might 
imply with regard to the relying party, (assuming it can be demonstrated that 
an enforceable contract even exists between the CA and the RP), there is 
absolutely no privity of contract between the subscriber and the relying party 
that is caused by the CA and the CPS.  The RP can't sue the CA because of 
something the subscriber did or didn't do, and likewise the subscriber can't sue 
the CA for something the RP did or didn't do. The RP can sue the CA if it 
misrepresented the subscriber to the RP, and the subscriber can likewise 
sue the CA if it misrepresented the subscriber to the RP, but that is about it.

So relying on the CPS to protect the subscriber against a claim that she 
signed a legally binding document when she never intended to do so is a 
rather shaky legal premise.  Of course, like the fabled chicken soup remedy 
for a cold, it probably won't hurt, either, and so CPS's tend to include all sorts
of things just in case they might help.

What is really needed, given the lack of legal consensus as to how to 
approach these issues, is an unambiguous, standards-based way of indicating 
whether even a relatively naive consumer did or did not intend to be legally 
bound, ever, by a particular public key and certificate, and in particular by 
any kind of a high-value transaction that might allegedly be signed by t
hat person.  (In a certain ironic sense, we really need a positive, 
"repudiation" bit in a certificate, rather than the absence of a nonrepudiation 
bit.)  Insofar as possible, this indication must not depend on the existence or
nonexistence of digital signature laws, especially laws providing a rebuttable 
presumption to certain classes of certificates, because of the uncertainty of 
passage of such laws and the possibility that they might be preempted by 
federal legislation.. The desired effect therefore must be clearly stated in 
the semantics of the indicator itself, and interpreted as such by application 
programs, so that there can be very little doubt.

Secondly, in the case where a knowledgeable subscriber is in fact willing to 
be legally bound by a digital signature, it seems highly advisable to define a 
means of explicitly indicating, on a case by case, document by document 
basis, the subscriber's human consent and intent to be so bound, and to 
ensure that such an indication could not reasonably be interpreted as 
applying to any kind of an automatic or programmed generation of a 
digital signature by a human user.  (A server or automated process may 
automatically generate a digital signature on behalf a subscriber such as 
an organization, but it must NOT be applied in such as way as to indicate 
human consent on a case by case basis.)

My proposal, therefore, is that the text of the nonrepudiation key usage bit in 
the PKIX RFC (and hopefully in X.509) be revised to unambiguously state that 
the defined semantics of this bit is to indicate the willingness of the subscriber 
to be legally bound by a digital signature which can be verified by a certificate 
that can be established to have been valid at the time of signature.

In addition, I propose that we create an additional indicator of a human 
being's conscious and willful intent to be legally bound by a digital signature 
that would be applied on a message by message basis. This additional 
indicator would require, as an integral part of its semantic definition, that 
an explicit computer-to-human interaction be required to provide some 
reasonable level of ceremonial and due caution warning be provided to 
the user.  In addition, the semantics of this indicator should specify that 
its use must be ENABLED by the NR bit ( as redefined) in the certificate 
which includes the corresponding public key.  If the certificate does not 
have the bit turned on, the application is not obligated to request the 
ceremonial, due caution approval; and relying party software should 
ignore a per-message indicator even if present in that case.

The obvious, but not necessarily the only, place to put such a message 
by message indicator would be in the Cryptographic Message Syntax 
used by S/MIME V3, in particular as a new .  Since signedAttributes 
is a SET of self-describing attributes, adding an additional one would 
be very simple.

Comments?

Bob

Robert R. Jueneman
Security Architect
Network Security Development
Novell, Inc.
122 East 1700 South
Provo, UT 84606
[email-masked]
1-801-861-7387

From: "Phillip M Hallam-Baker" <[email-masked]>
To: "Bob Jueneman" <[email-masked]>, <[email-masked]>
Subject: RE: Nonrepudiation and what to do about it
Date: Wed, 18 Aug 1999 17:11:13 -0400
Importance: Normal
Sender: [email-masked]

I agree in part and disagree in part.

First non repudiation must be an attribute of the signed document.

For this reason I don't see a need to modify the NR semantics of the
certificate - if indeed this is possible. I don't see that the working group
can increase the legal weight applied to this bit at this point.

The second issue is that NR is not a binary attribute. The issue for the
recipient is whether they can trust the degree of certainty in the assurance
provided by the signature. This will inevitably be a complex function of
many factors, not least the CPS governing issue of the certificate in
question.

If anyone thinks they can compress a CP or CPS into one bit...

All the NR bit can do is signal 'the circumstances of issue for this cert
are such that it is not intended to create contracts'.

Since NR is complex attribute the most appropriate format for the document
indicator would be an attribute with a URI as the parameter. The URI could
then identify the governing semantics.

Again, I think folk are overestimating the extent to which complex legal
issues can be eliminated through bits on the wire. I see an issue raised and
a 'solution' advanced which does not solve the problem identified as far as
I am concerned.

Three things are certain: death; taxes and lawyers.

	Phill

To: "Bob Jueneman" <[email-masked]>, <[email-masked]>
From: Vin McLellan <[email-masked]>
Subject: Re: Nonrepudiation and what to do about it
Date: Wed, 18 Aug 1999 16:32:47 -0400
Sender: [email-masked]

Hi Bob,

        I'd appreciate a copy of the post you mention below.  If you have a
URL at Novell  (or a URL for the PKIX archive where I could find it) I could
spread it around and limit the number of folks asking you for a copy.  On
Cyberia-L, a legal forum, and elsewhere, this is a topic of current interest
too.

        Regards,

                        _Vin

At 09:30 AM 8/18/99 -0600, Bob Jueneman wrote:

>I have recently posted a fairly lengthy summary of the legal/technical issues
>that are involved in issue of whether or not a digital signature is binding,
>and in particular whether it could be construed as being binding when
>that was not the intent -- particularly from a consumer protection standpoint.
>
>I'll be happy to send any one the entire note who is interested

Date: Wed, 18 Aug 1999 14:29:24 -0400
To: "Bob Jueneman" <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: Nonrepudiation and what to do about it
Cc: <[email-masked]>
Sender: [email-masked]

Bob:

First, the current charter does not include your suggestion.  But, the 
charter could be updated if there is sufficient interest in your suggestion.

Second, some of the things that you are suggesting are included in RFC 2634 
(Enhanced Security Services for S/MIME).  Take a look at section 5.4 
(Signing Certificate Attribute).

Russ

At 09:30 AM 8/18/99 -0600, Bob Jueneman wrote:
>(Apologies if this shows up twice. It was sent yesterday at 3:01PM, and hadn't
>shown up on the list by 9:10 this morning.)
>
>For those who have been asleep or don't subscribe to the PKIX list,
>there has been an argument raging about the meaning of the nonrepudiation
>key usage in a certificate.
>
>I have recently posted a fairly lengthy summary of the legal/technical issues
>that are involved in issue of whether or not a digital signature is binding,
>and in particular whether it could be construed as being binding when
>that was not the intent -- particularly from a consumer protection standpoint.
>
>I'll be happy to send any one the entire note who is interested, but since
>part of my proposal suggests the creation of a new attribute to be included
>in the CMS signedAttibutes, let me at least summarize the proposal for 
>this group.
>
>------
>
>The message which follows is a rather lengthy attempt to recap of
>the last five years or so of technical/legal discussion regarding
>digital signatures, followed by a proposal for what to do to fix these
>problems.
>
>However, since many may want to skip the justification and cut
>to the bottom line, I'll put the proposal up front, and then justify it:
>
>My proposal is that the text of the nonrepudiation key usage bit I
>n the PKIX RFC (and hopefully in X.509) be revised to unambiguously
>state that the defined semantics of this bit is to indicate the willingness
>of the subscriber to be legally bound by a digital signature which can be
>verified by a certificate that can be established to have been valid at the
>time of signature, where "valid" has the normal meaning of not expired, not
>revoked, etc., etc.
>
>In addition, I propose that we create an additional indicator of a
>human being's conscious and willful intent to be legally bound by
>a digital signature that would be applied on a message by message
>basis. This additional indicator would require, as an integral part of
>its semantic definition, that an explicit computer-to-human interaction
>be required to provide some reasonable level of ceremonial and due
>caution warning be provided to the user.  In addition, the semantics
>of this indicator should specify that its use must be ENABLED by the
>NR bit ( as redefined) in the certificate which includes the corresponding
>public key.  If the certificate does not have the bit turned on, the
>application is not obligated to request the ceremonial, due caution
>approval; and relying party software should ignore a per-message
>indicator even if present in that case.
>
>The obvious, but not necessarily the only, place to put such a message
>by message indicator would be in the Cryptographic Message Syntax
>used by S/MIME V3, in particular as a new signedAttribute.  Since
>signedAttributes is a SET of self-describing attributes, adding
>an additional one would be very simple.
>
>[snip]
>
>Comments?
>
>Bob
>
>
>
>
>Robert R. Jueneman
>Security Architect
>Network Security Development
>Novell, Inc.
>122 East 1700 South
>Provo, UT 84606
>[email-masked]
>1-801-861-7387

Date: Wed, 18 Aug 1999 09:30:24 -0600
From: "Bob Jueneman" <[email-masked]>
To: <[email-masked]>
Subject: Nonrepudiation and what to do about it
Sender: [email-masked]

(Apologies if this shows up twice. It was sent yesterday at 3:01PM, and hadn't
shown up on the list by 9:10 this morning.)

For those who have been asleep or don't subscribe to the PKIX list,
there has been an argument raging about the meaning of the nonrepudiation 
key usage in a certificate.

I have recently posted a fairly lengthy summary of the legal/technical issues
that are involved in issue of whether or not a digital signature is binding,
and in particular whether it could be construed as being binding when
that was not the intent -- particularly from a consumer protection standpoint.

I'll be happy to send any one the entire note who is interested, but since
part of my proposal suggests the creation of a new attribute to be included 
in the CMS signedAttibutes, let me at least summarize the proposal for this group.

------

The message which follows is a rather lengthy attempt to recap of 
the last five years or so of technical/legal discussion regarding 
digital signatures, followed by a proposal for what to do to fix these 
problems.

However, since many may want to skip the justification and cut 
to the bottom line, I'll put the proposal up front, and then justify it:

My proposal is that the text of the nonrepudiation key usage bit I
n the PKIX RFC (and hopefully in X.509) be revised to unambiguously 
state that the defined semantics of this bit is to indicate the willingness 
of the subscriber to be legally bound by a digital signature which can be 
verified by a certificate that can be established to have been valid at the 
time of signature, where "valid" has the normal meaning of not expired, not 
revoked, etc., etc.

In addition, I propose that we create an additional indicator of a 
human being's conscious and willful intent to be legally bound by 
a digital signature that would be applied on a message by message 
basis. This additional indicator would require, as an integral part of 
its semantic definition, that an explicit computer-to-human interaction 
be required to provide some reasonable level of ceremonial and due 
caution warning be provided to the user.  In addition, the semantics 
of this indicator should specify that its use must be ENABLED by the 
NR bit ( as redefined) in the certificate which includes the corresponding 
public key.  If the certificate does not have the bit turned on, the 
application is not obligated to request the ceremonial, due caution 
approval; and relying party software should ignore a per-message 
indicator even if present in that case.

The obvious, but not necessarily the only, place to put such a message 
by message indicator would be in the Cryptographic Message Syntax 
used by S/MIME V3, in particular as a new signedAttribute.  Since 
signedAttributes is a SET of self-describing attributes, adding 
an additional one would be very simple.

[snip]

Comments?

Bob

Robert R. Jueneman
Security Architect
Network Security Development
Novell, Inc.
122 East 1700 South
Provo, UT 84606
[email-masked]
1-801-861-7387

Date: Tue, 17 Aug 1999 11:26:55 +0200
To: "Andrew Farrell" <[email-masked]>
From: Peter Siklosi <[email-masked]>
Subject: RE: X9.42 and RFC2459 inconsistency? 
Cc: "John Hughes" <[email-masked]>, [email-masked], [email-masked], Darren Harter <[email-masked]>, <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Andrew,

In the RFC2459, section 7.3.2, it says:

   "The Diffie-Hellman OID supported by this profile is defined by ANSI X9.42"

I am not sure what you mean by the "X9.42 oid with the pfc 2459 semantics".

Regards,
Peter

John Hughes wrote:
>We can generate D-H certificates - and we use the rfc 2459 dhpublicnumber
>OID.

Andrew Farrel wrote:
> You mean the X9.42 oid with the pfc 2459 semantics? Do you have serious
> "Permanent root for paying customer" certs using this out there? And if
> so, why? :)

Date: Mon, 16 Aug 1999 15:25:38 -0700
From: Marc Branchaud <[email-masked]>
Organization: Xcert International Inc.
To: [email-masked]
Subject: Re: ASN.1 for the Internet (was Re: Compressed data type for S/MIME)
Sender: [email-masked]

There seems to be some strong opinions that an ASN.1-Internet
reconciliation is a pointless and futile task.  I can live with that,
but I'd like to try to explain my objective one more time before it gets
thrown out with the bath water.  (On top of that, this topic is a bit
off for S/MIME -- but things are slow these days anyway.)

My basic premises are these:

1. There are a bunch of people who use ASN.1.

2. There are a bunch of other people who don't like ASN.1 because it is
very difficult to look at some ASN.1 code and figure out what the bits
on the wire will look like.  (There may be many more people who don't
like ASN.1 for other reasons, but I'm not trying to deal with them
here.)

3. The people using ASN.1 would like to see their ASN.1-based protocols
widely adopted.

Given these premises (which weren't founded on any facts and may or may
not reflect any reality anywhere), it seems to me that if there were a
version of ASN.1 that was easier to interpret then the people in my
second premise would be happier and the goal in the third premise might
be more achievable.

It also seems to me that such an ASN.1 "lite" could be defined that
would still be standard ASN.1, especially if the PER rules were used.

So I'm not suggesting a Grand Unified Syntax that will bring peace to
the world.  I'm not trying to replace ABNF or S-expressions or
whatever-your-favorite-protocol-definition-language-is.  I'm just trying
to make ASN.1 easier to digest for people who haven't read X.whatever.  

Or am I the only one who thinks it's a bit weird that the IETF is
pushing protocols defined in ASN.1 without having an RFC that explains
how to interpret them?

		Marc

+------------------------------------------------------------------------+
 Marc Branchaud                                  \/
 Chief PKI Architect                             /\CERT INTERNATIONAL
INC.
 [email-masked]        PKI References page:             
www.xcert.com
 604-640-6227          www.xcert.com/~marcnarc/PKI/
+------------------------------------------------------------------------+
  PGP key fingerprint:  60 11 4B 9D 4E E5 2F 47  BD C5 C2 BF 26 DF 5A E1

Date: Tue, 10 Aug 1999 16:41:22 -0400
To: [email-masked], [email-masked]
From: Russ Housley <[email-masked]>
Subject: Five AES Candidates
Sender: [email-masked]

For those of you who have not heard, on Monday NIST announced the five
finalists for the Advanced Encryption Standard:

	MARS
	RC6
	Rijndael
	Serpent
	Twofish

More information is available at http://www.nist.gov/aes.

From: "Phillip M Hallam-Baker" <[email-masked]>
To: "Marc Branchaud" <[email-masked]>, <[email-masked]>
Subject: RE: ASN.1 for the Internet (was Re: Compressed data type for S/MIME)
Date: Mon, 9 Aug 1999 10:32:18 -0400
Importance: Normal
Sender: [email-masked]

I don't accept this case.

The priciple problem with ASN.1 is that there are enough people
who violently detest it that the syntax issue is continually
being revisited. We get this in PKIX about twice a year.

I certainly don't suggest rewriting ASN.1 protocols in ABNF
or any other formalism for that matter, just as I do not propose
to revisit the ABNF decision for HTTP.

Once a system is deployed it is a legacy system. It is futile
to revisit core design decisions. For the ABNF parser I wrote
I developed the formalism to match the practice and not vice-versa.

If one has the luxury of starting from scratch with no legacy
BOTH approaches (ABNF, ASN.1) strike me as defective. The designers
of SSL took the right decision in my view in choosing a formalism
which was very simple and had a direct mapping to a well supported
programming language.

Development of a formalism requires expertise but so does
programming. It is not as time consuming as some would suggest.
Certainly my experience suggests that attempting to re-use
ASN.1 is more time consuming than starting from scratch with
a less baroque approach.

Attempts to rewrite ASN.1 systems in ABNF and vice versa strike
me as equally pointless and profitless exercises.

The correct comparison to make in my view is with a defunct
programming language. I would not advise anyone to code a
new system in COBOL or FORTRAN (ASN.1) nor would I suggest
existing systems be rewritten in Java.

And of course there will always be people who claim COBOL
and FORTRAN are not defunct.

		Phill

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Marc Branchaud
> Sent: Friday, August 06, 1999 2:51 PM
> To: [email-masked]
> Subject: Re: ASN.1 for the Internet (was Re: Compressed data type for
> S/MIME)
>
>
>
> There are (at least) a couple of issues here:
>
> 1. Are ABNF/ASCII protocols enough?  Things like SMTP, FTP and HTTP are
> fine protocols, but they are based on an ASCII command-response system.
> Things like SSL/TLS and IPSec didn't use an ASCII protocol for various
> reasons, and so I doubt that ASCII is adequate.  BTW, someone sent me a
> pointer to draft-cordell-messaging-00.txt which is essentially an ASCII
> encoding for ASN.1 (a sort of AER).
>
> 2. We already have a lot of ASN.1 in IETF RFCs, and so I don't think
> abandoning ASN.1 is a viable solution.  We're stuck with ASN.1 notation,
> it seems, barring some drastic paradigm shift.  My thinking is we might
> as well adapt that ASN.1 notation into something that maps (relatively)
> easily into bits-on-the-wire.
>
> I wasn't thinking of using this for ASCII-based protocols.  I don't
> think ASN.1 is a good choice for that.
>
> 		M.
>
>
> Phillip M Hallam-Baker wrote:
> >
> > It is worthwhile to use a formalism to express the
> > syntax of IETF protocols. It would be much better to
> > capture both syntax and semantics and this is easy
> > enough using augmented finite state machines and such.
> >
> > Using ASN.1 for the task would be futile. It would
> > be like trying to convert a steam locomotive to run
> > on roads.
> >
> > I wrote a synthesizer for most of the IETF protocols
> > back in '92 which covered SMTP, NNTP, FTP and of course
> > HTTP. The data structure it used was pretty simple as
> > I recall - about ten pages in all. If folk are interested
> > I might be able to find it.
> >
> >                 Phill
>
>
> +------------------------------------------------------------------------+
>  Marc Branchaud                                  \/
>  Chief PKI Architect                             /\CERT INTERNATIONAL
> INC.
>  [email-masked]        PKI References page:
> www.xcert.com
>  604-640-6227          www.xcert.com/~marcnarc/PKI/
> +------------------------------------------------------------------------+
>   PGP key fingerprint:  60 11 4B 9D 4E E5 2F 47  BD C5 C2 BF 26 DF 5A E1
>

Date: Fri, 06 Aug 1999 19:45:40 -0700
To: Marc Branchaud <[email-masked]>, [email-masked]
From: Bruce Greenblatt <[email-masked]>
Subject: Re: ASN.1 for the Internet (was Re: Compressed data type for S/MIME)
Sender: [email-masked]

I'd point out that ABNF and ASCII have nothing to do with each other.  It
is just fine to define a binary protocol using ABNF.  I'd also note that it
is very helpful for the wire protocol to contain some sort of viewable
keywords for those of us that are unfortunate enough to have to view the
protocol.  I'm especially fond of the ABNF that Ryan Moats created for the
Tagged Index Object in the Common Indexing Protocol (but of course, I'm
biased).  This ABNF specifically allows for the inclusion of binary data,
as well as UTF-8 encoded characters...  So, I specifically disagree with
your point 2 below.  I can't think of anything that would be better than to
abandon ASN.1.  I don't think that there are any advantages to its use
versus ABNF.

At 11:51 AM 8/6/99 -0700, Marc Branchaud wrote:
>
>There are (at least) a couple of issues here:
>
>1. Are ABNF/ASCII protocols enough?  Things like SMTP, FTP and HTTP are
>fine protocols, but they are based on an ASCII command-response system. 
>Things like SSL/TLS and IPSec didn't use an ASCII protocol for various
>reasons, and so I doubt that ASCII is adequate.  BTW, someone sent me a
>pointer to draft-cordell-messaging-00.txt which is essentially an ASCII
>encoding for ASN.1 (a sort of AER).
>
>2. We already have a lot of ASN.1 in IETF RFCs, and so I don't think
>abandoning ASN.1 is a viable solution.  We're stuck with ASN.1 notation,
>it seems, barring some drastic paradigm shift.  My thinking is we might
>as well adapt that ASN.1 notation into something that maps (relatively)
>easily into bits-on-the-wire.
>
>I wasn't thinking of using this for ASCII-based protocols.  I don't
>think ASN.1 is a good choice for that.
>
>		M.
>
>
>Phillip M Hallam-Baker wrote:
>> 
>> It is worthwhile to use a formalism to express the
>> syntax of IETF protocols. It would be much better to
>> capture both syntax and semantics and this is easy
>> enough using augmented finite state machines and such.
>> 
>> Using ASN.1 for the task would be futile. It would
>> be like trying to convert a steam locomotive to run
>> on roads.
>> 
>> I wrote a synthesizer for most of the IETF protocols
>> back in '92 which covered SMTP, NNTP, FTP and of course
>> HTTP. The data structure it used was pretty simple as
>> I recall - about ten pages in all. If folk are interested
>> I might be able to find it.
>> 
>>                 Phill
>
>
>+------------------------------------------------------------------------+
> Marc Branchaud                                  \/
> Chief PKI Architect                             /\CERT INTERNATIONAL
>INC.
> [email-masked]        PKI References page:             
>www.xcert.com
> 604-640-6227          www.xcert.com/~marcnarc/PKI/
>+------------------------------------------------------------------------+
>  PGP key fingerprint:  60 11 4B 9D 4E E5 2F 47  BD C5 C2 BF 26 DF 5A E1
>
>
>
==============================================
Bruce Greenblatt
Directory Tools and Application Services, Inc.
http://www.directory-applications.com

Date: Fri, 06 Aug 1999 16:41:09 -0600
From: "Bob Jueneman" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: RE: X9.42 and RFC2459 inconsistency?
Sender: [email-masked]

We aren't shipping it yet, but have planned to use the RFC 2459 OID,
as we haven't been following X9 that closely.  We could potentially 
support both uses, but rather not, especially for VPN.

Of course, I'm not all that hot on the use of DH to begin with,
since the primary rational seems to be intellectual property-related 
rather than technical.

Bob

>>> "Jim Schaad (Exchange)" <[email-masked]> 08/06/99 02:34PM >>>
I would object to changing this.  I have code which has shipped and uses
these OIDs.

jim

-----Original Message-----
From: Andrew Farrell [mailto:[email-masked]] 
Sent: Friday, July 30, 1999 6:22 AM
To: [email-masked]; [email-masked] 
Subject: Re: X9.42 and RFC2459 inconsistency? 

I wrote:

>Cool (and a welcome gesture towards fixing broken stuff). So why do we
>use their OID?

Sine there's been a deafing silence on this topic, I have two further
questions:

(1) Are there any deployed codebases which would object to changing the
Diffie-Hellman OID in rfc2459 to reflect the fact that it has different
semantics than in X9.42? 

I know that John Pawling has stated that Van Dyke's S/MIME Freeware
Library has no issues, and as far as I know Microsoft haven't shipped
anything with Diffie-Hellman, so that S/MIME would appear to be in the
clear on this.

(2) Are there any other groups that profile 2459 that we should ask
about this?.

Andrew

From: "Jim Schaad (Exchange)" <[email-masked]>
To: "'Andrew Farrell'" <[email-masked]>, [email-masked], [email-masked]
Subject: RE: X9.42 and RFC2459 inconsistency? 
Date: Fri, 6 Aug 1999 13:34:24 -0700 
Sender: [email-masked]

I would object to changing this.  I have code which has shipped and uses
these OIDs.

jim

-----Original Message-----
From: Andrew Farrell [mailto:[email-masked]]
Sent: Friday, July 30, 1999 6:22 AM
To: [email-masked]; [email-masked]
Subject: Re: X9.42 and RFC2459 inconsistency? 

I wrote:

>Cool (and a welcome gesture towards fixing broken stuff). So why do we
>use their OID?

Sine there's been a deafing silence on this topic, I have two further
questions:

(1) Are there any deployed codebases which would object to changing the
Diffie-Hellman OID in rfc2459 to reflect the fact that it has different
semantics than in X9.42? 

I know that John Pawling has stated that Van Dyke's S/MIME Freeware
Library has no issues, and as far as I know Microsoft haven't shipped
anything with Diffie-Hellman, so that S/MIME would appear to be in the
clear on this.

(2) Are there any other groups that profile 2459 that we should ask
about this?.

Andrew

Date: Fri, 06 Aug 1999 11:51:16 -0700
From: Marc Branchaud <[email-masked]>
Organization: Xcert International Inc.
To: [email-masked]
Subject: Re: ASN.1 for the Internet (was Re: Compressed data type for S/MIME)
Sender: [email-masked]

There are (at least) a couple of issues here:

1. Are ABNF/ASCII protocols enough?  Things like SMTP, FTP and HTTP are
fine protocols, but they are based on an ASCII command-response system. 
Things like SSL/TLS and IPSec didn't use an ASCII protocol for various
reasons, and so I doubt that ASCII is adequate.  BTW, someone sent me a
pointer to draft-cordell-messaging-00.txt which is essentially an ASCII
encoding for ASN.1 (a sort of AER).

2. We already have a lot of ASN.1 in IETF RFCs, and so I don't think
abandoning ASN.1 is a viable solution.  We're stuck with ASN.1 notation,
it seems, barring some drastic paradigm shift.  My thinking is we might
as well adapt that ASN.1 notation into something that maps (relatively)
easily into bits-on-the-wire.

I wasn't thinking of using this for ASCII-based protocols.  I don't
think ASN.1 is a good choice for that.

		M.

Phillip M Hallam-Baker wrote:
> 
> It is worthwhile to use a formalism to express the
> syntax of IETF protocols. It would be much better to
> capture both syntax and semantics and this is easy
> enough using augmented finite state machines and such.
> 
> Using ASN.1 for the task would be futile. It would
> be like trying to convert a steam locomotive to run
> on roads.
> 
> I wrote a synthesizer for most of the IETF protocols
> back in '92 which covered SMTP, NNTP, FTP and of course
> HTTP. The data structure it used was pretty simple as
> I recall - about ten pages in all. If folk are interested
> I might be able to find it.
> 
>                 Phill

+------------------------------------------------------------------------+
 Marc Branchaud                                  \/
 Chief PKI Architect                             /\CERT INTERNATIONAL
INC.
 [email-masked]        PKI References page:             
www.xcert.com
 604-640-6227          www.xcert.com/~marcnarc/PKI/
+------------------------------------------------------------------------+
  PGP key fingerprint:  60 11 4B 9D 4E E5 2F 47  BD C5 C2 BF 26 DF 5A E1

From: "Phillip M Hallam-Baker" <[email-masked]>
To: "Marc Branchaud" <[email-masked]>, <[email-masked]>
Subject: RE: ASN.1 for the Internet (was Re: Compressed data type for S/MIME)
Date: Fri, 6 Aug 1999 13:50:45 -0400
Importance: Normal
Sender: [email-masked]

It is worthwhile to use a formalism to express the
syntax of IETF protocols. It would be much better to 
capture both syntax and semantics and this is easy 
enough using augmented finite state machines and such.

Using ASN.1 for the task would be futile. It would 
be like trying to convert a steam locomotive to run
on roads.

I wrote a synthesizer for most of the IETF protocols
back in '92 which covered SMTP, NNTP, FTP and of course
HTTP. The data structure it used was pretty simple as
I recall - about ten pages in all. If folk are interested 
I might be able to find it.

		Phill

Date: Thu, 05 Aug 1999 10:12:04 -0700
From: Marc Branchaud <[email-masked]>
Organization: Xcert International Inc.
To: [email-masked]
Subject: ASN.1 for the Internet (was Re: Compressed data type for S/MIME)
Sender: [email-masked]

Peter Gutmann wrote:
> 
> "David P. Kemp" <[email-masked]> writes:
> 
> >I've often wondered whether ASN.1 could be used to express the bits on the
> >wire of an existing protocol such as IPSEC's AH.   To do so, one would need
> >to define "Fixed-field Encoding Rules" (FER) which would place only data
> >(not tag or length) octets in the datastream, and a set of macros to
> >conveniently represent the necessary fields.
> 
> I dunno about IPSEC, but I'm pretty sure you could shoehorn the SSL encoding
> into it without too much trouble, it's just a stripped-down ASN.1+DER (the
> best description I can think of is a kiddies ASN.1, without meaning that in a
> negative way).  I've even seen an attempt at EDI using an ASN.1-like notation,
> although the result was... unpleasant (actually I think Colonel Kurtz had
> appropriate words for the result).
> 
> Peter.

I've been toying with this kind of idea recently, too.  I was actually
thinking of PER instead of DER.  I've only glanced through the PER spec,
but it seems to me that a stripped-down ASN.1 encoded with PER would be
easy to map into those 32-bit block diagrams you usually see in Internet
specs.

My reading of PER is that it provides a way to strip out as much of the
tag and length values as possible.  To me, this most closely resembles
the "usual" Internet way of specifying a protocol -- the first four
bytes are a value for foo, the next two are for a bar, etc.  

It's obvious that many people don't like ASN.1 for all sorts of
reasons.  I believe that a definition of ASN.1 that allowed a reader to
easily visualize the bits on the wire would go a long way towards making
ASN.1 more acceptable to the Internet community.  This thought led to my
speculations about a "thin" ASN.1 and PER.  I can even envision a Perl
script that takes thin ASN.1 and spits out a 32-bit block diagram...

I'm happy to work with someone on this sort of thing if people think it
has merit.

		M.

+------------------------------------------------------------------------+
 Marc Branchaud                                  \/
 Chief PKI Architect                             /\CERT INTERNATIONAL
INC.
 [email-masked]        PKI References page:             
www.xcert.com
 604-640-6227          www.xcert.com/~marcnarc/PKI/
+------------------------------------------------------------------------+
  PGP key fingerprint:  60 11 4B 9D 4E E5 2F 47  BD C5 C2 BF 26 DF 5A E1

From: [email-masked] (Peter Gutmann)
To: [email-masked]
Subject: Re: Compressed data type for S/MIME
Reply-To: [email-masked]
Date: Thu, 5 Aug 1999 13:47:49 (NZST)
Sender: [email-masked]

"David P. Kemp" <[email-masked]> writes:

>I've often wondered whether ASN.1 could be used to express the bits on the 
>wire of an existing protocol such as IPSEC's AH.   To do so, one would need 
>to define "Fixed-field Encoding Rules" (FER) which would place only data 
>(not tag or length) octets in the datastream, and a set of macros to 
>conveniently represent the necessary fields.

I dunno about IPSEC, but I'm pretty sure you could shoehorn the SSL encoding
into it without too much trouble, it's just a stripped-down ASN.1+DER (the 
best description I can think of is a kiddies ASN.1, without meaning that in a
negative way).  I've even seen an attempt at EDI using an ASN.1-like notation, 
although the result was... unpleasant (actually I think Colonel Kurtz had 
appropriate words for the result).

Peter.

Date: Wed, 4 Aug 1999 22:07:25 +0200 (CEST)
From: [email-masked] (Bodo Moeller)
To: [email-masked], [email-masked]
Subject: P1363: Re: I-D ACTION:draft-ietf-smime-small-subgroup-01.txt
Reply-To: [email-masked] (Bodo Moeller)
Sender: [email-masked]

--------------------------------------------------------------
This is a stds-p1363 broadcast.  See the IEEE P1363 web  page
(http://grouper.ieee.org/groups/1363/)  for more information,
including how to subscribe/unsubscribe.
--------------------------------------------------------------

draft-ietf-smime-small-subgroup-01.txt:

>      ya is Party A's public key; ya = g ^ xa mod p
>      yb is Party B's public key; yb = g ^ xb mod p
>      xa is Party A's private key
>      xb is Party B's private key         
>      p is a large prime
>      g = h^((p-1)/q) mod p, where
>      h is any integer with 1 < h < p-1 such that h^((p-1)/q) mod p > 1
>            (g has order q mod p)         
>      q is a large prime
>      j a large integer such that p=q*j + 1

> 3.4 Compatible Cofactor Exponentiation 
> 
> This method of protection is specified in [p1363] and [KALISKI].  It 
> involves modifying the computation of ZZ.  Instead of computing ZZ as 
> ZZ=yb^xa mod p, Party A would compute it as ZZ=(yb^j)^c mod p where 
> c=j^(-1)*xa mod q.  (Similarly for Party B.) 
> 
> If the resulting value ZZ satisfies ZZ==1, then the key agreement should 
> be abandoned because the public key being used is invalid.
> 
> Note that this procedure may be subject to pending patents.

Patent applications by whom, dating from when?  I described DH with
what this draft calls "compatible cofactor exponentiation" in a
message to the coderpunks mailing list in September 1996 -- although
in a different setting in that factors from "wrong" subgroups were not
injected by an attacker but by the sender, because the issue was
steganography.  (A little difference in presentation is that where I
assume that an integer  m  such that  m = 1 (mod q)  and
m = 0 (mod (p-1)/q)  is used as an exponent, the draft uses in two
exponentiations two factors of an explicit solution to these
congruences, namely  j := (p-1)/q  and  j^(-1) (mod q).  When all
exponents are multiplied at first instead of using multiple
exponentiations, this difference disappears.)

The DH scheme with cofactors is described in the second message
reproduced below, the first one is to provide context so that
the statements about steganography are comprehensible.

Message-Id: <[email-masked]>
Date: Tue, 10 Sep 96 23:58 MET DST
Subject: Re: Project idea
From: [email-masked] (Bodo Moeller)
To: [email-masked]
In-Reply-To: <[email-masked]>

[email-masked] (Ron Rivest):

> Joe Kilian suggested the following cute idea as a project over lunch
> at CRYPTO 96: Implement a "stealth" version of Internet Phone (or
> equivalent) that contains a subliminal crypto channel in the
> low-order bit of the voice amplitude numbers.
[...]
> Key management for the crypto could be handled out-of-band, or with
> any of the standard techniques.
[...]
> trying to do key-establishment in-line (e.g. with Diffie-Hellman)
> probably can't hide the fact that key-establishment is happening.

Why not?

E.g., for Diffie-Hellman:

The prime p and a generator g of the whole multiplicative group
(Z/pZ)* can be built into the software.  Let us assume that p has 1024
bits.  Alice uniformly chooses a random numbers x (1 <= x < p) and
wants to transmit the integer y = g^x MOD p.  Note that y is uniform
in [1, p).  Now Alice does not directly send y through the
stego-channel (if she did, an eavesdropper would have statistical
evidence that Alice uses steganography); rather, she randomly chooses
a number z in [0, 2^(1024+128)) satisfying z == y (mod p) and
transmits z.  This integer z looks like a randomly chosen (1024+128)
bits integer (there is a bias, but it is negligible if an appropriate
value of 128 is used), and thus Alice's stego-message consists of
1024+128 seemingly random bits.

Bob acts similarly, and when each of them has transmitted 1024+128
bits (via the stego-channel), the Diffie-Hellman key negotiation is
complete.  Before they know the encryption key and can start sending
real data, Alice and Bob will probably have to send some random filler
bits because the exponentation takes too much time.  (This problem,
plus that of the possibility of a man-in-the-middle attack, vanishes
if a public key infrastructure exists.  Unfortunately, Alice and Bob
cannot simply use their DSA keys because DSA employs a generator of a
subgroup of (Z/pZ)* and not of the whole group.)
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

Date: Wed, 11 Sep 1996 18:39:40 +0200 (MET DST)
Message-Id: <[email-masked]>
From: [email-masked]
To: [email-masked]
Subject: Re: Project idea
In-Reply-To: <[email-masked]>

I wrote:

[...]
> y is uniform in [1, p).  Now Alice does not directly send y through
> the stego-channel (if she did, an eavesdropper would have
> statistical evidence that Alice uses steganography); rather, she
> randomly chooses a number z in [0, 2^(1024+128)) satisfying z == y
> (mod p) and transmits z.  This integer z looks like a randomly
> chosen (1024+128) bits integer (there is a bias, but it is
> negligible if an appropriate value of 128 is used), and thus Alice's
> stego-message consists of 1024+128 seemingly random bits.

I forgot to mention that this scheme was not invented by Alice
herself, but (as far as I know) by Hal Finney.  Apologies for the
omission.

[...]
> Unfortunately, Alice and Bob cannot simply use their DSA keys
> because DSA employs a generator of a subgroup of (Z/pZ)* and not of
> the whole group.

Meanwhile, I noticed that there is a simple solution provided that

o   q^2 does not divide p-1 and

o   Alice knows a generator modulo Bob's p (i.e. a generator of
    (Z/pZ)*).

In this case, Alice and Bob can use a variant of the Diffie-Hellman
scheme:

Assume that Bob's public DSA key is (p, q, g, y) where g is a
generator of a order-q subgroup of (Z/pZ)* and y = g^x MOD p (x is
Bob's secret parameter).  Be G a generator of (Z/pZ)* that is known to
Alice.  Then Alice can compute D = G^q; D generates a subgroup of
(Z/pZ)* that is "orthogonal" to the one generated by g.

When Alice wants to establish an encrypted stego-channel to Bob, she
proceeds as follows.  She chooses a random number r in [0, q) and
computes K = y^r MOD p.  The 128 least significant bits of K MOD q (or
something like that) will later be used as Alice's encryption key.
She also computes K' = g^r MOD p.  Alice chooses a random number s in
[0, (p-1)/q) and computes F = D^s MOD p.  Now the product K'*F MOD p
is a random number in [1, p) and can be sent to Bob, using the
procedure described above; i.e., Alice chooses a random number z in
[0, 2^(length(p) +128)) satisfying z == K'*F (mod p) and transmits z.

When Bob receives z, he computes z^m MOD p = K'*F MOD p where m is an
integer satisfying m == 1 (mod q) and m == 0 (mod (p-1)/q).  The
result is K' (because g^m == g (mod p), D^m == 1 (mod p), and K' and F
are in the subgroups generated by g and D, respectively).  Bob can now
obtain K as K'^x MOD p.
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

Bodo M"oller
<[email-masked]>

From: "Tim Dierks" <[email-masked]>
To: <[email-masked]>
Subject: RE: Compressed data type for S/MIME
Date: Wed, 4 Aug 1999 15:36:33 -0700
Importance: Normal
Sender: [email-masked]

If I remember correctly, two patent issues were in the air at the time.
Unfortunately, I don't remember the companies involved.

  1) A patent involving compressing records individually, rather than a
single compression stream for the communication (or was it vice-versa?).

  2) A patent which covered compressing and encrypting (or encrypting while
compressing, or something).

I'm sure that with investigation, either of these could have been researched
and disposed of and/or worked around, but the basic fact was that noone
really cared enough about compression at the time to invest the effort.
Given that the spec was designed in such a way as to allow us to put the
issue off, that inevitably occured.

 - Tim

Tim Dierks
VP of Engineering, Certicom
[email-masked]
510.780.5409 [Hayward] -- 905.501.3791 [Mississauga]

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of EKR
> Sent: Tuesday, August 03, 1999 4:01 PM
> To: Peter Gutmann
> Cc: [email-masked]
> Subject: Re: Compressed data type for S/MIME
>
>
> [email-masked] (Peter Gutmann) writes:
> > This seems a bit odd, given that a completely unencumbered
> algorithm and free
> > implementation existed years before the web (let alone SSL)
> did.  There are
> > problems with ITU and ISO-standarised algorithms (which seem to
> exist solely
> > to provide patent licensing outlets for vendors, and which in
> any case tend to
> > have mediocre performance), but Zip/zlib has never had any problems
> I'm quite aware that there are a number of free implementations of
> compression and that the authors claim that those implementations are
> enencumbered, however, discussions with holders of the various
> patents (Hi/Fn comes to mind) seem to indicate that they feel
> otherwise.
>
> -Ekr
>
> --
> [Eric Rescorla                                   [email-masked]]
>           PureTLS - free SSLv3/TLS software for Java
>                 http://www.rtfm.com/puretls/
>

Date: Thu, 5 Aug 1999 09:12:10 +1200 (NZST)
From: [email-masked] (Peter Gutmann)
To: [email-masked]
Subject: Re: Suggested change to PasswordRecipientInfo
Sender: [email-masked]

Russ Housley <[email-masked]>

>I am a bit confused by your message.  You say that you want to add support
>for "a PIN-protected smart card or something similar."
>
>First, this does not seem like an appropriate used of password-based key
>management.  The only password seems to be the local one used to gain access 
>to the KEK stored on the smart card.

In retrospect the term "PasswordRecipientInfo" used in the draft wasn't a very
good one, with the derivation info optional it's really more like a 
GeneralisedKEKRecipientInfo.  At the time the best I could come up with was 
PW-RI.

>Second, if the KEK stored on the smart card has an identifier, then
>KEKRecipientInfo should work as already defined.

I'm not sure what the format is for the KEK on the card, but I suspect it's
just a raw PIN-protected key (I imagine it's something like a PKCS #11
secret key object, or more likely just a 16-byte linear file).  In any case
it won't work with KEKRecipientInfo because it's only defined for RC2 and
3DES, you can't use it with IDEA unless you invent your own 
AlgorithmIdentifier.

Peter.

Date: Wed, 04 Aug 1999 14:41:45 -0400
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: Suggested change to PasswordRecipientInfo
Cc: [email-masked]
Sender: [email-masked]

Peter:

I am a bit confused by your message.  You say that you want to add support 
for "a PIN-protected smart card or something similar."

First, this does not seem like an appropriate used of password-based key 
management.  The only password seems to be the local one used to gain 
access to the KEK stored on the smart card.

Second, if the KEK stored on the smart card has an identifier, then 
KEKRecipientInfo should work as already defined.

Russ

At 09:25 AM 7/23/99 +0000, Peter Gutmann wrote:
>Currently PasswordRecipientInfo assumes you'll be feeding in something
>(referred to in the text as a password, although this is a somewhat misleading
>name since it's really "any keying material") and transforms it into a KEK
>which it uses to wrap a content-encryption key (CEK), in the same way that
>KeyTransRecipientInfo uses a public key to wrap the CEK, etc etc.  The process
>is:
>
>     password -> KEK -> CEK
>
>with the steps "password -> KEK" and "KEK -> CEK" being identified by
>AlgorithmIdentifiers.  Currently "password -> KEK" uses the PKCS #5v2 ID, and
>"KEK -> CEK" uses any standard encryption algorithm ID (DES, 3DES, IDEA, CAST,
>RC2, etc etc).
>
>Someone recently asked how you'd use this when there was no password available
>(ie how to avoid the "password -> KEK" step), in their case they wanted to use
>an IDEA key on a crypto token (I'm guessing this was referring to a
>PIN-protected smart card or something similar).  There are two ways to handle
>this, either use a null ID for the "password -> KEK" ID, or make the use of
>this field optional, ie change:
>
>     PasswordRecipientInfo ::= SEQUENCE {
>       version CMSVersion,   -- Always set to 0
>       keyDerivationAlgorithm KeyDerivationAlgorithmIdentifier,
>       keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
>       encryptedKey EncryptedKey }
>
>to:
>
>     PasswordRecipientInfo ::= SEQUENCE {
>       version CMSVersion,   -- Always set to 0
>       keyDerivationAlgorithm [0] KeyDerivationAlgorithmIdentifier OPTIONAL,
>       keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
>       encryptedKey EncryptedKey }
>
>with a corresponding change in the text to say that if the key derivation
>information is absent then it's assumed the KEK is supplied from an external
>source (in this case the crypto token).  This seems like a nice logical way to
>handle it (if the derivation info is present, ask for a password and 
>convert it
>to a KEK, otherwise get the KEK via some other means), and is more sensible
>than the use of a null ID to denote the absence of a password (using a special
>value to denote that no special value should be used seems silly).
>
>Comments?
>
>Peter.

Date: Wed, 4 Aug 1999 22:07:25 +0200 (CEST)
From: [email-masked] (Bodo Moeller)
To: [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-ietf-smime-small-subgroup-01.txt
Sender: [email-masked]

draft-ietf-smime-small-subgroup-01.txt:

>      ya is Party A's public key; ya = g ^ xa mod p
>      yb is Party B's public key; yb = g ^ xb mod p
>      xa is Party A's private key
>      xb is Party B's private key         
>      p is a large prime
>      g = h^((p-1)/q) mod p, where
>      h is any integer with 1 < h < p-1 such that h^((p-1)/q) mod p > 1
>            (g has order q mod p)         
>      q is a large prime
>      j a large integer such that p=q*j + 1

> 3.4 Compatible Cofactor Exponentiation 
> 
> This method of protection is specified in [p1363] and [KALISKI].  It 
> involves modifying the computation of ZZ.  Instead of computing ZZ as 
> ZZ=yb^xa mod p, Party A would compute it as ZZ=(yb^j)^c mod p where 
> c=j^(-1)*xa mod q.  (Similarly for Party B.) 
> 
> If the resulting value ZZ satisfies ZZ==1, then the key agreement should 
> be abandoned because the public key being used is invalid.
> 
> Note that this procedure may be subject to pending patents.

Patent applications by whom, dating from when?  I described DH with
what this draft calls "compatible cofactor exponentiation" in a
message to the coderpunks mailing list in September 1996 -- although
in a different setting in that factors from "wrong" subgroups were not
injected by an attacker but by the sender, because the issue was
steganography.  (A little difference in presentation is that where I
assume that an integer  m  such that  m = 1 (mod q)  and
m = 0 (mod (p-1)/q)  is used as an exponent, the draft uses in two
exponentiations two factors of an explicit solution to these
congruences, namely  j := (p-1)/q  and  j^(-1) (mod q).  When all
exponents are multiplied at first instead of using multiple
exponentiations, this difference disappears.)

The DH scheme with cofactors is described in the second message
reproduced below, the first one is to provide context so that
the statements about steganography are comprehensible.

Message-Id: <[email-masked]>
Date: Tue, 10 Sep 96 23:58 MET DST
Subject: Re: Project idea
From: [email-masked] (Bodo Moeller)
To: [email-masked]
In-Reply-To: <[email-masked]>

[email-masked] (Ron Rivest):

> Joe Kilian suggested the following cute idea as a project over lunch
> at CRYPTO 96: Implement a "stealth" version of Internet Phone (or
> equivalent) that contains a subliminal crypto channel in the
> low-order bit of the voice amplitude numbers.
[...]
> Key management for the crypto could be handled out-of-band, or with
> any of the standard techniques.
[...]
> trying to do key-establishment in-line (e.g. with Diffie-Hellman)
> probably can't hide the fact that key-establishment is happening.

Why not?

E.g., for Diffie-Hellman:

The prime p and a generator g of the whole multiplicative group
(Z/pZ)* can be built into the software.  Let us assume that p has 1024
bits.  Alice uniformly chooses a random numbers x (1 <= x < p) and
wants to transmit the integer y = g^x MOD p.  Note that y is uniform
in [1, p).  Now Alice does not directly send y through the
stego-channel (if she did, an eavesdropper would have statistical
evidence that Alice uses steganography); rather, she randomly chooses
a number z in [0, 2^(1024+128)) satisfying z == y (mod p) and
transmits z.  This integer z looks like a randomly chosen (1024+128)
bits integer (there is a bias, but it is negligible if an appropriate
value of 128 is used), and thus Alice's stego-message consists of
1024+128 seemingly random bits.

Bob acts similarly, and when each of them has transmitted 1024+128
bits (via the stego-channel), the Diffie-Hellman key negotiation is
complete.  Before they know the encryption key and can start sending
real data, Alice and Bob will probably have to send some random filler
bits because the exponentation takes too much time.  (This problem,
plus that of the possibility of a man-in-the-middle attack, vanishes
if a public key infrastructure exists.  Unfortunately, Alice and Bob
cannot simply use their DSA keys because DSA employs a generator of a
subgroup of (Z/pZ)* and not of the whole group.)
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

Date: Wed, 11 Sep 1996 18:39:40 +0200 (MET DST)
Message-Id: <[email-masked]>
From: [email-masked]
To: [email-masked]
Subject: Re: Project idea
In-Reply-To: <[email-masked]>

I wrote:

[...]
> y is uniform in [1, p).  Now Alice does not directly send y through
> the stego-channel (if she did, an eavesdropper would have
> statistical evidence that Alice uses steganography); rather, she
> randomly chooses a number z in [0, 2^(1024+128)) satisfying z == y
> (mod p) and transmits z.  This integer z looks like a randomly
> chosen (1024+128) bits integer (there is a bias, but it is
> negligible if an appropriate value of 128 is used), and thus Alice's
> stego-message consists of 1024+128 seemingly random bits.

I forgot to mention that this scheme was not invented by Alice
herself, but (as far as I know) by Hal Finney.  Apologies for the
omission.

[...]
> Unfortunately, Alice and Bob cannot simply use their DSA keys
> because DSA employs a generator of a subgroup of (Z/pZ)* and not of
> the whole group.

Meanwhile, I noticed that there is a simple solution provided that

o   q^2 does not divide p-1 and

o   Alice knows a generator modulo Bob's p (i.e. a generator of
    (Z/pZ)*).

In this case, Alice and Bob can use a variant of the Diffie-Hellman
scheme:

Assume that Bob's public DSA key is (p, q, g, y) where g is a
generator of a order-q subgroup of (Z/pZ)* and y = g^x MOD p (x is
Bob's secret parameter).  Be G a generator of (Z/pZ)* that is known to
Alice.  Then Alice can compute D = G^q; D generates a subgroup of
(Z/pZ)* that is "orthogonal" to the one generated by g.

When Alice wants to establish an encrypted stego-channel to Bob, she
proceeds as follows.  She chooses a random number r in [0, q) and
computes K = y^r MOD p.  The 128 least significant bits of K MOD q (or
something like that) will later be used as Alice's encryption key.
She also computes K' = g^r MOD p.  Alice chooses a random number s in
[0, (p-1)/q) and computes F = D^s MOD p.  Now the product K'*F MOD p
is a random number in [1, p) and can be sent to Bob, using the
procedure described above; i.e., Alice chooses a random number z in
[0, 2^(length(p) +128)) satisfying z == K'*F (mod p) and transmits z.

When Bob receives z, he computes z^m MOD p = K'*F MOD p where m is an
integer satisfying m == 1 (mod q) and m == 0 (mod (p-1)/q).  The
result is K' (because g^m == g (mod p), D^m == 1 (mod p), and K' and F
are in the subgroups generated by g and D, respectively).  Bob can now
obtain K as K'^x MOD p.
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

Bodo M"oller
<[email-masked]>

Date: Wed, 4 Aug 1999 12:29:57 -0400 (EDT)
From: "David P. Kemp" <[email-masked]>
Reply-To: "David P. Kemp" <[email-masked]>
Subject: Re: Compressed data type for S/MIME
To: [email-masked]
Content-MD5: egoFtneN8OUhvRGfMmshTw==
Sender: [email-masked]

> What would it take to get SSL/TLS, IPSEC, and some of the other protocols
> to adopt CMS, if that is the preferred solution?

Bob,

  That wouldn't work.  CMS is about Independent Data Unit Protection,
whereas both IPSEC and TLS are stream protection mechanisms.  (IPSEC
protects individual packets, but relies on a previously established
Security Association to provide the symmetric key for that protection).

Besides, both IPSEC and TLS have their own unique syntax representation
languages, and wouldn't want to use CMS's ASN.1 :-).

Dave

---------------- snip here to avoid rant ----------------------

I've often wondered whether ASN.1 could be used to express the bits on
the wire of an existing protocol such as IPSEC's AH.   To do so, one
would need to define "Fixed-field Encoding Rules" (FER) which would
place only data (not tag or length) octets in the datastream, and a set
of macros to conveniently represent the necessary fields.

For example:

   Int8  ::= INTEGER (0..255)
   Int16 ::= INTEGER (0..65535)
   Int32 ::= INTEGER (0..<4G>)
   
   AuthenticationHeader ::= SEQUENCE {
       nextHeader          Int8,
       payloadLen          Int8,
       reserved            Int16,
       spi                 Int32,
       sequenceNumber      Int32,
       authenticationData  OCTET STRING }

The bits-in-boxes notation used by IPSEC is easy for humans to read and
steeped in tradition, even if not easily machine readable.  But inventing a
unique language for the sole purpose of describing SSL 3.0 strikes me as,
well, goofy.  Wouldn't a protocol-independent description language be
easier on everyone?

From: "Phillip M Hallam-Baker" <[email-masked]>
To: "Ned Freed" <[email-masked]>, "EKR" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: RE: Compressed data type for S/MIME
Date: Wed, 4 Aug 1999 11:23:49 -0400
Importance: Normal
Sender: [email-masked]

Disclaimer: I am not a lawyer, this is not legal advice.

> Second, one of the basic principles underlying patents is that you either
> enforce them or lose them. 

This is not the case for patent law. It is central to trademark doctrine
but the application in patent law is not fundamental.

It is possible to claim that a patent holder willfully failed to enforce 
the patent with the intention of encouraging people to infringe it and 
that by doing so the patent holder created a public license.

The contract structures by which patents are licensed but not sold
create a number of arguable defenses.

It is also possible to put the patent holder on notice and to force
them to defend a claim or loose it - a tactic which could probably
be used to effect by the Internet community to sink certain patants
whose holders pockets are far from deep.

The principle game with patents however is to use the threat of
litigation to extort payments. In the UK this game is illegal, as the
owner of a certain US trademark discovered when they attempted to
grab a domain name from a UK company and found themselves paying a
considerable sum in damages.

In the middle ages this type of thing was rife. I think it was
called barratry but the term has a somewhat more specific meaning 
today. In any case Dante suggested a suitable damnation for such
folk.

		Phill

Date: Wed, 04 Aug 1999 09:15:01 -0600
From: "Bob Jueneman" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: Re: Compressed data type for S/MIME
Sender: [email-masked]

Well said, Ned.

Granted that this isn't the SSL forum, we at Novell have devoting a lot of time 
and attention to optimizing the performance of our SSL implementation

Although most of that effort has been devoted to cleaning up code paths 
in some third-party software and worrying about the public key handshake, 
improvements in the encryption performance for long blocks (large GIF images,
or megabyte file transfers) would certainly be welcome.

At present, it isn't clear to me exactly how much support the CMS spec has 
outside of the S/MIME community, although I understand that it was intended 
to be more general.

What would it take to get SSL/TLS, IPSEC, and some of the other protocols
to adopt CMS, if that is the preferred solution?

If crossing that bridge is too hard, defining a new crypto algorithm that includes 
compression, despite the admitted ugliness and combinatorial problems that
would bring, might still be the preferred answer -- at least for non-CMS protocols.

Bob

Robert R. Jueneman
Security Architect
Network Security Development
Novell, Inc.
122 East 1700 South
Provo, UT 84606
[email-masked]
1-801-861-7387

>>> Ned Freed <[email-masked]> 08/03/99 05:50PM >>>
> > This seems a bit odd, given that a completely unencumbered algorithm and free
> > implementation existed years before the web (let alone SSL) did.  There are
> > problems with ITU and ISO-standarised algorithms (which seem to exist solely
> > to provide patent licensing outlets for vendors, and which in any case tend to
> > have mediocre performance), but Zip/zlib has never had any problems

> I'm quite aware that there are a number of free implementations of
> compression and that the authors claim that those implementations are
> enencumbered, however, discussions with holders of the various
> patents (Hi/Fn comes to mind) seem to indicate that they feel
> otherwise.

First of all, while the IETF prefers unemcumbered algorithms, they are not
required. The only requirement is that intellectual property claims be
disclosed when participants in the effort become aware of them.

Second, one of the basic principles underlying patents is that you either
enforce them or lose them. As such, if someone claims to have a patent that
covers Zip/Zlib/deflate, they should have been going after any number of
vendors of the numerous commercial and free software packages that use these
algorithms. The fact that no such action has been taken (it would generate tons
of publicity if it had) is a strong indicator that either no such patent
exists, or if it is does it is no longer enforeable, people's "feelings"
about the matter notwithstanding.

Third, one of the tactics commonly used in this game is to create FUD over
what's patented and what is not. As such, it is quite common to hear second
or third-hand assertions that so and so or such and such has a patent that
covers various things when in fact no such patent exists (and in some cases
no such assertions have been made).

So, if you know of a specific patent that you believe covers deflate, or of a
specific public statement made by someone that they have such a patent, please
step up to the plate and say exactly what it is so we can evaluate it. This is
a technical forum and rumor and innuendo have no place here.

				Ned

Date: Tue, 03 Aug 1999 16:50:49 -0700 (PDT)
From: Ned Freed <[email-masked]>
Subject: Re: Compressed data type for S/MIME
To: EKR <[email-masked]>
Cc: [email-masked], [email-masked]
Sender: [email-masked]

> > This seems a bit odd, given that a completely unencumbered algorithm and free
> > implementation existed years before the web (let alone SSL) did.  There are
> > problems with ITU and ISO-standarised algorithms (which seem to exist solely
> > to provide patent licensing outlets for vendors, and which in any case tend to
> > have mediocre performance), but Zip/zlib has never had any problems

> I'm quite aware that there are a number of free implementations of
> compression and that the authors claim that those implementations are
> enencumbered, however, discussions with holders of the various
> patents (Hi/Fn comes to mind) seem to indicate that they feel
> otherwise.

First of all, while the IETF prefers unemcumbered algorithms, they are not
required. The only requirement is that intellectual property claims be
disclosed when participants in the effort become aware of them.

Second, one of the basic principles underlying patents is that you either
enforce them or lose them. As such, if someone claims to have a patent that
covers Zip/Zlib/deflate, they should have been going after any number of
vendors of the numerous commercial and free software packages that use these
algorithms. The fact that no such action has been taken (it would generate tons
of publicity if it had) is a strong indicator that either no such patent
exists, or if it is does it is no longer enforeable, people's "feelings"
about the matter notwithstanding.

Third, one of the tactics commonly used in this game is to create FUD over
what's patented and what is not. As such, it is quite common to hear second
or third-hand assertions that so and so or such and such has a patent that
covers various things when in fact no such patent exists (and in some cases
no such assertions have been made).

So, if you know of a specific patent that you believe covers deflate, or of a
specific public statement made by someone that they have such a patent, please
step up to the plate and say exactly what it is so we can evaluate it. This is
a technical forum and rumor and innuendo have no place here.

				Ned

Date: Wed, 4 Aug 1999 11:54:49 +1200 (NZST)
From: [email-masked] (Peter Gutmann)
To: [email-masked]
Subject: Re: Compressed data type for S/MIME
Sender: [email-masked]

EKR <[email-masked]> writes:

>I'm quite aware that there are a number of free implementations of 
>compression and that the authors claim that those implementations are
>enencumbered, 

If any patent did cover zlib, the fact that half the planet uses it and the 
patent holders haven't taken any action would make their case pretty 
difficult in court.

>discussions with holders of the various patents (Hi/Fn comes to mind) seem to
>indicate that they feel otherwise.

... and they'd be very happy to sell you something based on their claims.

Any claim that Hi/Fn may make about coverage of zlib is completely bogus, 
they're either referring to the Waterworth patent which covers what's
generally known as the LZRW1 algorithm (the exact same algorithm was also 
patented by Gibson and Graybill (isn't the US patent system wonderful? :-),
LZRW1 isn't even remotely similar to zlib), or more likely the Whiting 
patent, for which noone's ever really been able to explain how it differs 
from LZSS which was published about a decade earlier.  This is probably why
Stac have never tried to enforce it (they went after MS with Waterworth).

Were any representatives of the data compression community present at these
meetings?  They would have shot down claims like this fairly quickly, these
things have been analysed to death in comp.compression.  Any claims that you 
can get into trouble for using zlib are about as valid as claims that you 
have to pay Hitachi every time you use SHA-1.

Peter.

To: [email-masked] (Peter Gutmann)
Cc: [email-masked]
Subject: Re: Compressed data type for S/MIME
From: EKR <[email-masked]>
Date: 03 Aug 1999 16:01:14 -0700
Lines: 18
Sender: [email-masked]

[email-masked] (Peter Gutmann) writes:
> This seems a bit odd, given that a completely unencumbered algorithm and free
> implementation existed years before the web (let alone SSL) did.  There are 
> problems with ITU and ISO-standarised algorithms (which seem to exist solely 
> to provide patent licensing outlets for vendors, and which in any case tend to
> have mediocre performance), but Zip/zlib has never had any problems
I'm quite aware that there are a number of free implementations of
compression and that the authors claim that those implementations are
enencumbered, however, discussions with holders of the various
patents (Hi/Fn comes to mind) seem to indicate that they feel
otherwise.

-Ekr

-- 
[Eric Rescorla                                   [email-masked]]
          PureTLS - free SSLv3/TLS software for Java
                http://www.rtfm.com/puretls/

Date: Wed, 4 Aug 1999 08:50:53 +1200 (NZST)
From: [email-masked] (Peter Gutmann)
To: [email-masked]
Subject: Re: Compressed data type for S/MIME
Sender: [email-masked]

EKR <[email-masked]> writes:

>My interpretation of the history is that compression support foundered on 
>intellectual property issues. I.e. there was no algorithm which everyone 
>could agree was unencumbered. Since there was a desire to get the spec out 
>quickly and the issue was sticky, it was punted. I definitely remember 
>several meetings of the IPSEC working group where the IP situation was 
>discussed and it was distinctly murky.

This seems a bit odd, given that a completely unencumbered algorithm and free
implementation existed years before the web (let alone SSL) did.  There are 
problems with ITU and ISO-standarised algorithms (which seem to exist solely 
to provide patent licensing outlets for vendors, and which in any case tend to
have mediocre performance), but Zip/zlib has never had any problems

Peter.

To: [email-masked]
Cc: [email-masked]
Subject: Re: Compressed data type for S/MIME
From: EKR <[email-masked]>
Date: 03 Aug 1999 13:09:02 -0700
Lines: 31
Sender: [email-masked]

[email-masked] (Peter Gutmann) writes:
> I think the real reason compression in SSL is been slow to come to market (and
> the reason it will probably never be supported even though it's defined in the
> spec, and OpenSSL nee SSLeay has supported it for some time) is because the 
> original implementations (Netscape/SSLref and later MS) never bothered 
> implementing it, and since it wasn't in there from the start noone else has 
> been able to get it in.  In contrast ssh has has compression built in from the
> start, as a result of which every single other implementation also has it, and
> everyone uses it.
My reading of the TLS/SSL compression situation is rather
different. 

First, neither SSL nor TLS in fact defines compression.
Rather, they define a slot in which compression could be 
fitted if one were to define it. No specific algorithm is
defined. 

My interpretation of the history is that compression support
foundered on intellectual property issues. I.e. there was no
algorithm which everyone could agree was unencumbered. Since
there was a desire to get the spec out quickly and the issue
was sticky, it was punted. I definitely remember several
meetings of the IPSEC working group where the IP situation
was discussed and it was distinctly murky.

-Ekr

-- 
[Eric Rescorla                                   [email-masked]]
          PureTLS - free SSLv3/TLS software for Java
                http://www.rtfm.com/puretls/

From: "Pawling, John" <[email-masked]>
To: "'SMIME WG'" <[email-masked]>
Subject: Draft 15 July 1999 S/MIME WG Minutes
Date: Mon, 2 Aug 1999 11:34:30 -0400 
Sender: [email-masked]

All,

This message includes the draft minutes of the IETF S/MIME Working Group
(WG) meeting held on 15 July 1999 in Oslo, Norway.  These minutes have not
been approved by the S/MIME WG chairman.  The final minutes will be provided
to the S/MIME WG mail list once they are finalized.  All briefing slides
will eventually be stored at: ftp://ftp.ietf.org/ietf/smime/.  Reported by
John Pawling.

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

Introductions - Russ Housley
 
Russ reviewed the agenda.  It was identical to that publicized prior to the
meeting except that the DOMSEC Draft Discussion was cancelled and Russ
substituted for several of the presenters who were unable to attend the
meeting.  Nobody objected to the agenda.

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

RFC 2630-2634 Status - Russ Housley

The following IETF S/MIME v3 Proposed Standards are available at
http://www.ietf.org/rfc/:
RFC 2630  Cryptographic Message Syntax, R. Housley, June 1999
RFC 2631  Diffie-Hellman Key Agreement Method, E. Rescorla, June 1999
RFC 2632  S/MIME Version 3 Certificate Handling, B. Ramsdell, June 1999
RFC 2633  S/MIME Version 3 Message Specification, B. Ramsdell, June 1999
RFC 2634  Enhanced Security Services for S/MIME, P. Hoffman, June 1999

To become IETF Draft Standards, the aforementioned documents must meet the
following requirements:
1) Exist as Proposed Standards for 6 months.
2) Each MUST and SHOULD requirement must be implemented by at least two
independent implementations such that they are interoperable.
 
Russ requested that all S/MIME v3 implementers provide a description of the
S/MIME v3 features that are supported by their implementation.

Paul Hoffman stated that RFC 2632 is dependent on RFC 2459 (Internet X.509
Public Key Infrastructure Certificate and CRL Profile), so RFC 2632 can not
become a Draft Standard until RFC 2459 becomes one.  Similarly, RFC 2633 is
dependent on RFC 2632 and RFC 2634 is dependent on RFC 2633.  Therefore, RFC
2459 must become a Draft Standard before RFC 2632, RFC 2633 or RFC 2634 can
become Draft Standards.  Paul noted that there are still unresolved issues
with RFC 2459.

Russ stated that neither RFC 2630 nor RFC 2631 rely on RFC 2459, so they can
progress to Draft Standards in 6 months (assuming that the other requirement
is met).  Nobody disagreed with Russ' statement.

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

Charter Revision - Russ Housley

Russ reviewed the following proposed changes to the S/MIME WG charter that
he had previously sent to the mail list.

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

Small Subgroup Attacks:

The use of D-H Key Agreement as the mandatory to implement key establishment
mechanism may expose some implementations to vulnerabilities based on "small
subgroup" attacks.  An informational document will be prepared describing
techniques that can be used to avoid these attacks. 

Proposed Milestones:
History: First "Methods for Avoiding the "Small-Subgroup" Attacks on the
Diffie-Hellman Key Agreement Method for S/MIME" Internet-Draft (I-D)
published.
Aug 1999: Last call.
Nov 1999: Submit Informational RFC.

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

Additional Algorithms

CMS is cryptographic algorithm independent, yet there is always more than
one way to use any algorithm.  To ensure interoperability, each algorithm
should have a specification that describes its use with CMS. 

Proposed Milestones:
History: First "CMS KEA and SKIPJACK Conventions" I-D published.
	   First " Incorporation of IDEA encryption algorithm in S/MIME" I-D
published.
Aug 1999: KEA and Skipjack last call.
Nov 1999: KEA and Skipjack Informational RFC.
Dec 1999: IDEA last call.
Mar 2000: IDEA Informational RFC.

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

CMS and ESS Examples

To aid implementers, documents containing example output for CMS and ESS
will
be collected and published.

Proposed Milestones:
History: First "Examples of S/MIME Messages" I-D published.
Dec 1999: Last call.
Mar 2000: Informational RFC.

Russ asked that implementers provide interesting invalid cases in addition
to valid cases.

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

CERTDIST

Current methods of publishing certificates in the Directory do not 
allow the inclusion of secondary support information such as the 
SMIMECapabilities attribute.  A method of publishing certificates 
along with authenticated secondary support information will be 
defined. 

Proposed Milestones:
History: First "Certificate Distribution Specification" I-D published.
Sep 1999: Last call.
Jan 2000: Proposed Standard RFC.

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

Password-based Key Management

In some situations it would be advantageous for the CMS RecipientInfo
structure to support additional key management techniques, including
cryptographic keys derived from passwords.  A mechanism to facilitate 
the definition of additional key management techniques will be defined.

Proposed Milestones:
History: First "Password-based Encryption for S/MIME" I-D published.
Dec 1999: Last call.
Mar 2000: Proposed Standard RFC.

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

Mail List Key Distribution

S/MIME version 3 supports encrypted mail lists.  Specifications for the 
distribution of symmetric mail list keys to mail list agents (MLAs) and
message recipients will be developed.  The specification will be 
cryptographic algorithm independent.

Proposed Milestones:
Sep 1999: First Mail List Key Distribution I-D will be published.
Jan 2000: Last call.
Mar 2000: Proposed Standard RFC.

Russ stated that an editor is needed for this document.  He stated that this
I-D will document the distribution of pre-placed symmetric keys that can be
used to process CMS KEKRecipientInfo.  He noted that this capability can be
used for purposes other than to support mail lists.  

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

Security Label Usage

S/MIME version 3 supports security labels.  Specifications that show 
how this feature can be used to implement an organizational security 
policy will be developed.  Security policies from large corporations will
be used as examples.

Proposed Milestones:
Jul 1999: First Security Label Usage I-D will be published.
Nov 1999: Last call.
Feb 2000: Informational RFC.

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

DOMSEC

S/MIME version 3 can be used to protect electronic mail to and from a
domain. "Domain Security Services" result when the S/MIME v3 processing is
performed by message transfer agents, guards or gateways.  Mechanisms are
needed to solve a number of interoperability problems and technical
limitations that arise when domains supporting different security policies
wish to interoperate.

Proposed Milestones:
History: First "Domain Security Services using S/MIME" I-D published.
Jul 2000: Last call.
Sep 2000: Experimental RFC.

Sean Turner asked if the proposed charter could be changed to allow I-Ds to
be submitted that document environments other than those described in the
DOMSEC I-D.  Russ stated that he would edit the text in the charter
regarding DOMSEC so that it is more generic to allow other I-Ds to be
submitted.

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

Charter Wrap-Up

Russ asked if any attendees knew of any issues, had comments or wished to
discuss any related topics.  He asked if the attendees believed that the
revised charter was ready for the Security Area Directors and IESG. 

Paul Hoffman requested that text be added to the charter that allows work to
be performed related to adding other options for mandatory-to-implement
strong encryption algorithms.

Jim Schaad asked if the WG should consider replacing D-H with RSA as the
mandatory-to-implement key management algorithm once the RSA patent expires.
Russ added that the RSA patent expires in about a year.

An attendee expressed his opinion that the RSA algorithm should be
deprecated from the S/MIME v3 specifications altogether.

Another attendee stated that European software uses RSA because US patents
don't apply outside of the US.
 
Andrew Farrell requested that the name of the Mail List Key Distribution I-D
be changed to "Previously-Distributed Symmetric Keys".  Nobody objected.

Paul Hoffman recommended that the WG should consider replacing D-H with RSA
as the mandatory-to-implement key management algorithm, but not to associate
any milestones with the work.

Russ stated that he will send out a revised draft charter.

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

Avoiding Small Subgroups - Russ Housley 

Robert Zuccherato generated the "Methods for Avoiding the "Small-Subgroup"
Attacks on the Diffie-Hellman Key Agreement Method for S/MIME" I-D.  Russ
stated that the I-D has not has not been discussed much on the mail list.
The WG is obligated to generate this I-D to address the subject
vulnerabilities.  He strongly recommends that implementers read the I-D so
that they are aware of the vulnerabilities.  He asked how many attendees
have read the I-D.  Only 6 people raised their hands.  Russ asked that the
WG members review and provide comments to the document.   

Tony Mione stated a comment to the I-D.  See Tony's 15 July 1999 message
sent to the list, subject: "Quick comment on the Small Subgroup Attack
draft". 

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

CERTDIST Draft Discussion - Jim Schaad

Jim stated that he has only received comments from Russ to the 25 February
1999 Certificate Distribution (CERTDIST-03) I-D.  

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

CMS/ESS Examples - Paul Hoffman

Paul stated that the following companies have been participating in the
generation of the "Examples of S/MIME Messages" I-D: Microsoft, Worldtalk,
Baltimore and J.G. Van Dyke & Associates (VDA).  He stated that the June
draft includes placeholders for examples from ESS.  He requested that the WG
members review the I-D and provide comments.  He is planning to establish an
"Examples" mail list for people to exchange information regarding
interoperability testing.  The document will include some incorrect examples
that flag common implementation errors including explanations of the
mistakes.  Russ stated that he is especially looking for folks who have
implemented the AuthenticatedData, EncryptedData and/or DigestedData content
types.

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

Security Policies and Labels - Russ Housley

Russ stated that Weston Nicolls is developing an I-D that will document the
security policies of Whirlpool, Caterpillar and Amoco.  The draft will
document how the ESSSecurityLabel can be used to implement those
corporations' security policies.  

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

S/MIME Freeware Library (SFL) - John Pawling

The SFL is a freeware implementation of RFC 2630 and RFC 2634.  It uses the
Crypto++ freeware library to implement RFC 2631.  It provides functions to
support the use of RFC 2632 and RFC 2633.  The goal of the SFL is to provide
a reference implementation of RFC 2630 and RFC 2634 to encourage their
acceptance as IETF Standards.

The SFL protects any type of data (not just MIME).  It is algorithm
independent.  It is used with external crypto libraries that provide the
crypto algorithms.  It uses the VDA-enhanced SNACC freeware library to
perform all ASN.1 encoding (including DER) and decoding of CMS and ESS
objects as well as certificates, CRLs, etc.  All SFL source code is provided
(all code is C++).  

The SFL implements the optional RFC 2634 security services such as signed
receipts, security labels, mail list information, signing certificate
attribute and equivalent security labels.  It has been used with the RSA
BSAFE v3.0 and Crypto++ v3.0 libraries.  VDA is currently enhancing the SFL
to work with the Fortezza Cryptologic Interface Library and Spyrus SPEX/
Library.  

VDA provides several test utilities along with the SFL including: 
- Test driver to build and process a variety of CMS/ESS messages; 
- Test utility that processes and displays contents of MIME encoded messages
containing single body part or multi-part CMS/ESS components; and
- Test utility to generate key material, certificates (such as D-H) and
CRLs.

Version 1.0 SFL was released in June 1999.  It was tested on MS Windows
95/NT, Sun Solaris 2.6 and Linux.  It was tested using the mandatory and RSA
algorithm suites.  VDA continues to enhance the SFL.  

The SFL has been used to exchange signedData and envelopedData messages with
MS Internet Explorer Outlook Express v4.01 and Netscape Communicator 4.X.
Signed messages have been exchanged with RSA S/MAIL, WorldTalk and Entrust
S/MIME v2 products.  S/MIME v3 interop testing between SFL and MS includes
all envelopedData features such as using Ephemeral-Static D-H pairwise key
with 3DES-wrapped and RC2-wrapped content encryption keys.  RSA-signed
signedData messages have also been exchanged.  The majority of the ESS
features have been tested.  S/MIME v3 interoperability testing also
performed with Baltimore, Inc.  VDA plans to participate in the IETF S/MIME
WG interoperability testing including providing CMS/ESS messages for
inclusion in the S/MIME "Examples of S/MIME Messages" document.

Organizations can use the SFL as part of their applications without paying
any royalties or licensing fees (see SFL Public License).  VDA-enhanced
SNACC ASN.1 software and SFL documents are freely available to everyone at:
http://www.jgvandyke.com/services/infosec/sfl.htm.  All other portions of
the SFL are available at:
http://www.armadillo.huntsville.al.us/software/smime and are export
controlled as per U.S. Government Export Administration Regulations (see:
http://www.bxa.doc.gov/Encryption/Default.htm).

The IMC has established an SFL mail list 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 IMC SFL web page:
http://www.imc.org/imc-sfl.

An attendee asked if there was any way that the SFL could be obtained from
outside the U.S.  John stated that the vendor would need to obtain an export
license and referred him to the aforementioned U.S. Government Export
Administration Regulations web page.  Several attendees then discussed how
the SFL could be distributed outside the U.S. such as publishing the source
code in a book.

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

Wrap Up - Russ Housley
None of the attendees had any other comments or issues.

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

ACTION ITEMS:

1. Tony Mione will send his comment regarding the Avoiding Small Subgroup
Attacks I-D to the mail list.

2. ALL S/MIME v3 Implementers: Provide a description to Russ of the S/MIME
v3 features that are supported by your software.

3. ALL S/MIME v3 Implementers: Provide valid and invalid sample data to Paul
Hoffman for inclusion in the "Examples of S/MIME Messages" I-D.

4. Russ will send the revised charter to the mail list.

====================================================================
John Pawling,  Director - Systems Engineering,  [email-masked] 
J.G. Van Dyke & Associates, Inc., a Wang Government Services Company
====================================================================

Date: Mon, 2 Aug 1999 10:42:36 -0400 (EDT)
From: "David P. Kemp" <[email-masked]>
Reply-To: "David P. Kemp" <[email-masked]>
Subject: RE: Cert Attributes in CERTDIST
To: [email-masked]
Content-MD5: ppULEuAWlWnOYruDh3atew==
Sender: [email-masked]

Jim,

>From the perspective of a PKI serving an audience wider than just S/MIME,
it would be helpful if the information concerning a user is stored in a
canonical form, so that when an application asks a question ("what certs
apply to [email-masked]"), it gets a consistent answer regardless of where
the question is asked and which application is doing the asking.

If user certs are stored in a special S/MIME attribute, it makes them less
accessible to other applications.  They could be stored twice, but that
raises the issue of keeping the attributes in sync.

Would it be possible to both achieve the objectives of certdist AND
minimize unnecessary data denormalization in "the directory" by stating
that the certdist CertificateSet MUST NOT contain any certificates?
Instead, a pointer (SEQUENCE OF ESSCertID, similar to the
SigningCertificate attribute) to the certs would be stored in the
certdist signed attributes along with the three other required
attributes.

I don't object to a directory attribute containing S/MIME-specific data
bound to the user, but I do believe that that attribute should not
duplicate data contained in the standard directory attributes.

Dave Kemp

> From: "Jim Schaad (Exchange)" <[email-masked]>
> 
> That is one of the issues.  The reasons why this field is not used are as
> follows:
> 
> 1.  userCertificate holds X509 certificates for the use (there may be more
> than one) and what we are publishing is a SignedData object not an X509
> certificate.
> 2.  We want to include additional attributes which also are not certificates
> and bind them together with the certificate in a cryptographic manner.  (The
> main attributes being encryption algorithms and a publishing time.)
> 
> jim
> 
> -----Original Message-----
> From: Blake Ramsdell [mailto:[email-masked]]
> Sent: Thursday, July 22, 1999 2:23 PM
> To: 'Sean Turner'; [email-masked]
> Subject: RE: Cert Attributes in CERTDIST
> 
> 
> > -----Original Message-----
> > From: Sean Turner [mailto:[email-masked]]
> > Sent: Thursday, July 22, 1999 2:31 PM
> > To: [email-masked]
> > Subject: Cert Attributes in CERTDIST
> > 
> > I'm sorry if I'm coming at this a bit late, but why are the attributes
> > that are used to store signature and encryption certificates not
> > userCertificate as defined in the LDAP schema RFC from PKIX?
> 
> I think that the problem is because userCertificate refers to exactly one
> certificate.  In order to put in a certificate chain, along with the S/MIME
> capabilities of the certificate holder, a new convention must be used.
> 
> I may have some of this wrong, so anyone feel free to correct me.
> 
> Blake
> --
> Blake C. Ramsdell
> Worldtalk Corporation
> For current info, check http://www.deming.com/users/blaker
> Voice +1 425 376 0225 x103  Fax +1 425 376 0915

From: [email-masked] (Peter Gutmann)
To: [email-masked]
Subject: Re: Compressed data type for S/MIME
Reply-To: [email-masked]
Date: Tue, 3 Aug 1999 01:12:30 (NZST)
Sender: [email-masked]

Dean Povey <[email-masked]> writes:

>SSL/TLS has built in compression support as part of the protocol, but this
>has been slow to come to market.  Why?  One of the reasons has been that
>you want to turn compression on and off depending on the underlying content
>(e.g. if it is a GIF or JPG or .gz etc, don't compress).  

zlib already does this transparently, it won't try to compress uncompressible
data (try running zip on a mixture of text and (say) other zip files, when it
says "Storing (0%)" it's generally zlib making the decision for you).  For 
SSL it's rather different because you've got an arbitrary stream of who 
knows what rather than individual files like zip or CMS.

I think the real reason compression in SSL is been slow to come to market (and
the reason it will probably never be supported even though it's defined in the
spec, and OpenSSL nee SSLeay has supported it for some time) is because the 
original implementations (Netscape/SSLref and later MS) never bothered 
implementing it, and since it wasn't in there from the start noone else has 
been able to get it in.  In contrast ssh has has compression built in from the
start, as a result of which every single other implementation also has it, and
everyone uses it.

I think this supports my earlier argument that you need to add something like 
this to a new(-ish) protocol, because it's never going to be retrofitted to 
anything with an installed base (eg MIME).  SSL vs ssh compression (and also
PGP vs S/MIME, which I'd already mentioned) only proves this point.

Peter.