Subject: New list for S/MIME developers

From: Paul Hoffman / IMC <[email-masked]>
Date: Sat, 30 Oct 1999 19:33:17 -0700

At the request of a couple of S/MIME folks on the ietf-smime list, I've set 
up a new mailing list for discussing implementation of S/MIME. Note that 
this new list is *not* for discussing the S/MIME spec; the ietf-smime list 
is still doing quite a good job of that. But the new list will be a good 
place to ask about who has actually implemented what and to send sample 
messages.

The list is called [email-masked]. To subscribe, send a message to:
      [email-masked]
with the single word
      subscribe
in the body of the message.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Sat, 30 Oct 1999 19:33:17 -0700
To: [email-masked], [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: New list for S/MIME developers
Sender: [email-masked]

At the request of a couple of S/MIME folks on the ietf-smime list, I've set 
up a new mailing list for discussing implementation of S/MIME. Note that 
this new list is *not* for discussing the S/MIME spec; the ietf-smime list 
is still doing quite a good job of that. But the new list will be a good 
place to ask about who has actually implemented what and to send sample 
messages.

The list is called [email-masked]. To subscribe, send a message to:
      [email-masked]
with the single word
      subscribe
in the body of the message.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Fri, 29 Oct 1999 11:29:29 -0500
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-smime-ecc-00.txt
Sender: [email-masked]

François:

 >I was very please to see this new Internet Draft for the support of
 >Elliptic Curve Cryptography (ECC) under S/MIME Version 3.
 >
 >What do others think about also supporting "key transport" using ECC in the
 >next version of this Internet Draft in addition to supporting ECC based
 >digital signatures and key agreements?

Most of the EC key management work that I have seen uses EC D-H (key 
agreement).  As the S/MIME WG chairman, it is my responsibility to ensure 
that we document the algorithm suites that have a constituency; not that we 
document every possible algorithm suite.  Where do you see EC key transport 
being used?

Russ

Date: Thu, 28 Oct 1999 15:25:56 -0700
From: Lisa Repka <[email-masked]>
Organization: Netscape Communications Corporation
To: [email-masked]
Subject: Re: S-MIME key length
Sender: [email-masked]

Dennis Glatting wrote:
> 
> I did not add a Novell root cert. However, NS says there is a "NOVELL
> EMPLOYEE CA - NOVELL_INC" and another Novell cert loaded. When I read
> your messages I notice your cert listed in "Other People's
> Certificates." I can add that cert but I don't that that is your
> point, is it?

It may not be a problem of having the cert, just of trust.  More below.
 
> It's possible my mail tool modified the input. I am working on my mail
> environment, turning off my NeXTSTEP machines, using different mail
> tools, adding TLS to secure IMAP transport -- generally having fun.

If the hash-matching were the problem, you would have seen a
different error than what you saw.

> When I click on the Invalid Signature icon associated with your
> messages NS displays:
> 
>         The Certificate that was used to digitally
>         sign this message is invalid.
> 
>         The error was: The certificate issuer for
>         this server has been marked as not trusted
>         by the user. Netscape refuses to connect
>         to this server.
> 
> (I did?)

Please ignore the "Netscape refuses to connect to this server."
and imagine the "for this server" was "for this user" or "for
this peer" or something slightly better like that.

(And don't blame me.  It's a long story (and this is hardly
our worst error message, either. ;-)  Short explanation: it's
a shared error message that was originally written when the
only thing you did with certificates was SSL.)

What it comes down to is that it means your problem was
one of trust, not of keysize (or modified input).
 
> What do you suggest I do?

You can do one of two things.  You can trust Bob's individual
cert directly, or you can trust his CA cert.  Both can be
accomplished via the Security Info (aka Security Advisor;
also same thing that comes up when you click on the Invalid
Signature icon in the message or when you click on the Security
button in the toolbar).  The CA cert should show up in the
Signers page; Bob's individual cert in the People page.  It sounds
like you've already located both.  Select the one you want to trust,
and then click on Edit to change the trust.

(BTW, if you're paranoid, you would check that the cert you
are trusting is really the cert you should trust.  For example
by calling Bob and asking him to tell you his certificate's
fingerprint.  Not that anybody, including those of us who
presumably "know better" *ever* do this. ;-)
 
lisa

Date: Thu, 28 Oct 1999 13:43:05 -0500
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: dog food
Cc: [email-masked]
Sender: [email-masked]

Bob:

While there is some irony in the situation, S/MIME-enabled mail clients are 
not a requirement to participate in this IETF Working Group.  We want to 
allow the widest possible participation on this list.

Russ
S/MIME WG Chair

At 05:20 PM 10/27/99 -0600, [email-masked] wrote:
 >[snip]
 >And BTW, Has anyone notied the irony of having these kinds of problem
 >on this list? Maybe we should all start eating our own dog food, and
 >actually use the stuff we're building, on this list in particular?
 >[snip]

Date: Thu, 28 Oct 1999 14:29:17 -0400
To: [email-masked]
From: Francois Rousseau <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-smime-ecc-00.txt
Sender: [email-masked]

I was very please to see this new Internet Draft for the support of
Elliptic Curve Cryptography (ECC) under S/MIME Version 3.

What do others think about also supporting "key transport" using ECC in the
next version of this Internet Draft in addition to supporting ECC based
digital signatures and key agreements?

François Rousseau

At 08:48 AM 27/10/99 -0400, you wrote:
>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		: Elliptic Curve S/MIME
>	Author(s)	: P. Lambert
>	Filename	: draft-ietf-smime-ecc-00.txt
>	Pages		: 
>	Date		: 26-Oct-99
>	
>This document is the first draft of a profile for the incorporation 
>of Elliptic Curve (EC) public key algorithms in the Cryptographic 
>Message Syntax (CMS).  The EC algorithms support the creation of 
>digital signatures and the distribution of keys to encrypt or authen-
>ticate message content.  The definition of the algorithm processing 
>is based on the ANSI X9.63 draft, developed by the ANSI X9F1 
>working group.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-ietf-smime-ecc-00.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-ecc-00.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-ecc-00.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.
>
><ftp://ftp.ietf.org/internet-drafts/draft-ietf-smime-ecc-00.txt>
>

From: [email-masked]
Date: Thu, 28 Oct 1999 10:34:00 -0600
Subject: S/MIME interoperability testing.
To: "[email-masked]", [email-masked]
Sender: [email-masked]

--____GZVGTAQPUTWDHONHLVJX____
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Paul,

I strongly support the idea of setting up an S/MIME-clean list
server that could be used for real-world S/MIME interoperability=20
testing.

The results of my own rather extensive testing showed that
although the various products are relatively clean (but far from
perfect), the various list servers, corporate mail gateways, virus=20
checking software, etc., etc., were far from being ready to=20
handled signed or encrypted mail.

Testing all of the various combinations of mail processors,
certificate issuing software, etc., is quite time consuming
for any individual vendors, yet by spreading the load across a
number of cooperating users, can be accomplished rather easily.

Let's do it. And a hearty thank you to you, if you'll set up the list.

Bob

Signed with my 2048 bit dual-use key, in cleartext.

>>> Paul Hoffman / IMC <[email-masked]> 10/27/99 05:50PM >>>
At 05:20 PM 10/27/99 -0600, [email-masked] wrote:
>Maybe we should all start eating our own dog food, and
>actually use the stuff we're building, on this list in particular?

This list is for developing the S/MIME protocol, not for developing =
S/MIME=20
applications. There's a big difference. Many people are on this list to=20
follow CMS issues that have nothing to do with S/MIME MUAs. I think =
it's=20
inappropriate to burden them with experiments in interoperability that =
have=20
nothing to do with the protocol.

If people want, I'd be happy to set up an S/MIME developer's list for=20
issues and testing such as this.

--Paul Hoffman, Director
--Internet Mail Consortium

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

--____GZVGTAQPUTWDHONHLVJX____--

From: "Ward, Jon" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, <[email-masked]>
cc: <[email-masked]>
Subject: RE: S-MIME key length
Date: Thu, 28 Oct 1999 09:41:41 -0400
Sender: [email-masked]

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

------_=_NextPart_000_01BF214A.3092B722
Content-Type: text/plain; 
 charset=iso-8859-1
Content-Transfer-Encoding: 7bit

We, at Blue Cross, are using an SMTP relay with a combined S/MIME Proxy that
stores certificates, performs the encryption, signing, decryption and
validation of signatures at the proxy as the messages pass the proverbial
gate.  It attaches an explanation of the message's security status to
incoming messages.  I have attached the "alert" file itself as an example.
It explains that the certificate was not verifiable because we don't trust
Novell's root certificate yet.

So, we are eating our own dog food, and are not facing a significant
obstacle with 2048 bit keys.  We will trust the root certificate and monitor
the status of new, incoming, signed messages.  Further bulletins will follow
as events warrant.

Jon Ward
Senior Systems Analyst/Messaging Architecture
Blue Cross Blue Shield of Florida
Voice: +1 (904) 791-6057
[email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, October 27, 1999 7:20 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: S-MIME key length

And your signed message causes GroupWise to say, effectively, that 
"[email-masked]" is not the same person 
as the "[email-masked]" that was issued a VeriSign
certificate.

But did Communicator complain because you don't haven't added the 
Novell root certificate to your cache of trusted roots, or because your 
incoming mail processor modified the contents somehow, or was 
there some other kind of problem?

And BTW, Has anyone notied the irony of having these kinds of problem 
on this list? Maybe we should all start eating our own dog food, and 
actually use the stuff we're building, on this list in particular?

This is signed with a 1024 bit key, using the same root certificate, which 
however uses a 2048 bit key.

Bob

>>> Dennis Glatting <[email-masked]> 10/27/99
03:34PM >>>
[email-masked] wrote:
> 
> This message is signed with a 2048 bit key.  So far, I haven't encountered
anyone
> who hasn't been able to validate the signature with that length key.
Encryption
> could conceivably be a different issue, depending on whether or not a
recipient
> is constrained by export and/or import policy.
> 

Funny you should mention that. When I clicked to read your message my
Netscape 4.61 Communicator displays an icon stating "Invalid
Signature".

------_=_NextPart_000_01BF214A.3092B722
Content-Type: text/plain; 
 charset=us-ascii; 
 name=wssalert.txt
Content-Disposition: attachment; 
 filename=wssalert.txt
Content-Transfer-Encoding: 7bit

"Blue Cross Blue Shield of Florida" made the following
 annotations on 10/27/99 13:05:06
------------------------------------------------------------------------------

[ALERT] -- Security Manager:
Message security properties:

   Encrypted: No
   Signed by Sender: Unknown
   Contents Altered after signing: No
   Signature Algorithm: SHA1

The message encryption and/or signature are unacceptable for the following 
reasons:

    The signing certificate is not associated with the sender of the message.
    The signing certificate is either not valid or not trusted.

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

------_=_NextPart_000_01BF214A.3092B722--

Date: Wed, 27 Oct 1999 19:39:22 -0700
From: Dennis Glatting <[email-masked]>
To: Terry Hayes <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: S-MIME key length
Sender: [email-masked]

Terry Hayes wrote:
> 
> Thanks Bob,
> 
> Dennis' message appears invalid to me (Communicator) for 
> the same reason you give.  And yours is invalid because it's 
> issued by Novell, which I don't trust (yet?).
> 

My NS reader says your signature is good.

Date: Wed, 27 Oct 1999 19:37:47 -0700
From: Dennis Glatting <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: S-MIME key length
Sender: [email-masked]

[email-masked] wrote:
> 
> And your signed message causes GroupWise to say, effectively, that
> "[email-masked]" is not the same person
> as the "[email-masked]" that was issued a 
> VeriSign certificate.
> 

Damn. I thought I changed my cert. Obviously I did not. I will fix
that.

> But did Communicator complain because you don't haven't added the
> Novell root certificate to your cache of trusted roots, or because your
> incoming mail processor modified the contents somehow, or was
> there some other kind of problem?
> 

I did not add a Novell root cert. However, NS says there is a "NOVELL
EMPLOYEE CA - NOVELL_INC" and another Novell cert loaded. When I read
your messages I notice your cert listed in "Other People's
Certificates." I can add that cert but I don't that that is your
point, is it?

It's possible my mail tool modified the input. I am working on my mail
environment, turning off my NeXTSTEP machines, using different mail
tools, adding TLS to secure IMAP transport -- generally having fun. 

When I click on the Invalid Signature icon associated with your
messages NS displays:

	The Certificate that was used to digitally 
	sign this message is invalid.

	The error was: The certificate issuer for 
	this server has been marked as not trusted 
	by the user. Netscape refuses to connect 
	to this server.

(I did?)

	This message included the Security 
	Certificate for BJueneman. To check the 
	Certificate or edit Certificate Trust 
	Information, press the ``View/Edit'' button. 

	This Certificate has automatically been 
	added to your list of People's Certificates 
	to make it possible for you to send secure 
	mail to this person.

What do you suggest I do?

> And BTW, Has anyone notied the irony of having these kinds of problem
> on this list? Maybe we should all start eating our own dog food, and
> actually use the stuff we're building, on this list in particular?
> 

Sure. I'm game. Though I have done much reading on PK standards and
read various other books over the years I haven't really used the
technologies, mostly due to stupid vendor implementations (my favorite
is buying a "recently released" package in May of 1999 that wasn't Y2K
compliant and required me to downgrade the NT server to a non-Y2K
version), compatibility issues, implementation issues, licensing
issues, etc. So, since I am between projects and have time on my
hands, to use your own words, I'm eating my own dog food. :)

> This is signed with a 1024 bit key, using the same root certificate, 
> which however uses a 2048 bit key.
> 

Let's resolve this issue off-line.

Date: Wed, 27 Oct 1999 16:55:10 -0700
From: [email-masked] (Terry Hayes)
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: Re: S-MIME key length
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

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

Thanks Bob,

Dennis' message appears invalid to me (Communicator) for the same reason you give.  And
yours is invalid because it's issued by Novell, which I don't trust (yet?).

Yes, I find it amusing that there are complaints about perfectly valid S/MIME messages
on this list.  You would think this would be one of the few places that you could send
signed messages without worrying about confusing the person at the other end.

Terry

[email-masked] wrote:

> And your signed message causes GroupWise to say, effectively, that
> "[email-masked]" is not the same person
> as the "[email-masked]" that was issued a VeriSign
> certificate.
>
> But did Communicator complain because you don't haven't added the
> Novell root certificate to your cache of trusted roots, or because your
> incoming mail processor modified the contents somehow, or was
> there some other kind of problem?
>
> And BTW, Has anyone notied the irony of having these kinds of problem
> on this list? Maybe we should all start eating our own dog food, and
> actually use the stuff we're building, on this list in particular?
>
> This is signed with a 1024 bit key, using the same root certificate, which
> however uses a 2048 bit key.
>
> Bob
>
> >>> Dennis Glatting <[email-masked]> 10/27/99 03:34PM >>>
> [email-masked] wrote:
> >
> > This message is signed with a 2048 bit key.  So far, I haven't encountered anyone
> > who hasn't been able to validate the signature with that length key.  Encryption
> > could conceivably be a different issue, depending on whether or not a recipient
> > is constrained by export and/or import policy.
> >
>
> Funny you should mention that. When I clicked to read your message my
> Netscape 4.61 Communicator displays an icon stating "Invalid
> Signature".

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

--------------ms98CFEB9A6CFBEDC9357B9F0C--

Date: Wed, 27 Oct 1999 16:50:49 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: S-MIME key length
Sender: [email-masked]

At 05:20 PM 10/27/99 -0600, [email-masked] wrote:
>Maybe we should all start eating our own dog food, and
>actually use the stuff we're building, on this list in particular?

This list is for developing the S/MIME protocol, not for developing S/MIME 
applications. There's a big difference. Many people are on this list to 
follow CMS issues that have nothing to do with S/MIME MUAs. I think it's 
inappropriate to burden them with experiments in interoperability that have 
nothing to do with the protocol.

If people want, I'd be happy to set up an S/MIME developer's list for 
issues and testing such as this.

--Paul Hoffman, Director
--Internet Mail Consortium

From: [email-masked]
Date: Wed, 27 Oct 1999 17:20:00 -0600
Cc: [email-masked]
Subject: Re: S-MIME key length
To: [email-masked]
Sender: [email-masked]

--____TDAUBBZBTADSZSVVWNHS____
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

And your signed message causes GroupWise to say, effectively, that=20
"[email-masked]" is not the same person=20
as the "[email-masked]" that was issued a VeriSign
certificate.

But did Communicator complain because you don't haven't added the=20
Novell root certificate to your cache of trusted roots, or because your=20
incoming mail processor modified the contents somehow, or was=20
there some other kind of problem?

And BTW, Has anyone notied the irony of having these kinds of problem=20
on this list? Maybe we should all start eating our own dog food, and=20
actually use the stuff we're building, on this list in particular?

This is signed with a 1024 bit key, using the same root certificate, =
which=20
however uses a 2048 bit key.

Bob

>>> Dennis Glatting <[email-masked]> 10/27/99 =
03:34PM >>>
[email-masked] wrote:
>=20
> This message is signed with a 2048 bit key.  So far, I haven't encountere=
d anyone
> who hasn't been able to validate the signature with that length key.  =
Encryption
> could conceivably be a different issue, depending on whether or not a =
recipient
> is constrained by export and/or import policy.
>=20

Funny you should mention that. When I clicked to read your message my
Netscape 4.61 Communicator displays an icon stating "Invalid
Signature".

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

--____TDAUBBZBTADSZSVVWNHS____--

Date: Wed, 27 Oct 1999 18:48:32 -0400 (EDT)
From: "David P. Kemp" <[email-masked]>
Reply-To: "David P. Kemp" <[email-masked]>
Subject: Re: Working Group Last Call:draft-ietf-smime-certdist-04.txt
To: [email-masked]
Content-MD5: giLQL6wd2OliyN9c4Ds6Tg==
Sender: [email-masked]

> Date: Mon, 25 Oct 1999 09:09:17 -0700
> From: Paul Hoffman / IMC <[email-masked]>

> 
> Disagree. We are far from understanding how certificates are and will be 
> published. LDAP certificate retrieval is well-defined, but not yet widely 
> implemented, particularly for S/MIME MUAs.

Ignoring for now the issue of alternatives to LDAP, do you agree with
my proposal -- namely, that in the case where LDAP *is* used to carry
the SMimeCertificatePublish object, the certificates field shall be
empty?

Date: Wed, 27 Oct 1999 14:34:35 -0700
From: Dennis Glatting <[email-masked]>
To: [email-masked]
CC: [email-masked], V KRISHNA REDDY <[email-masked]>
Subject: Re: S-MIME key length
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

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

[email-masked] wrote:
> 
> This message is signed with a 2048 bit key.  So far, I haven't encountered anyone
> who hasn't been able to validate the signature with that length key.  Encryption
> could conceivably be a different issue, depending on whether or not a recipient
> is constrained by export and/or import policy.
> 

Funny you should mention that. When I clicked to read your message my
Netscape 4.61 Communicator displays an icon stating "Invalid
Signature".
--------------ms967F7AD330FECC810CCC2CB0
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

--------------ms967F7AD330FECC810CCC2CB0--

From: [email-masked]
Date: Wed, 27 Oct 1999 10:41:00 -0600
Subject: RE: Working Group Last Call:draft-ietf-smime-certdist-04.txt
To: [email-masked]
Sender: [email-masked]

--____WADBJNCIRFTLTXQWWZIG____
Content-Type: multipart/mixed; boundary="____RXPVIHJZACUBDQYIVIQA____"

--____RXPVIHJZACUBDQYIVIQA____
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Apparently there are people on the list who don't have
S/MIME compliant readers, and I accidentally used
base64 encoding.  Here is the message in clear text form.

Bob

I'm afraid I strongly disagree with Paul and Rik, and=20
agree with Bartlett and David Kemp instead.

I'm speaking as an architect who is responsible for defining our
future direction with respect to our GroupWise S/MIME V3
implementation, in addition to our PKI product line, including=20
the Novell Certificate Server 2.0 (which was released just
hours ago  as a FREE web release  -- see=20
http://www.novell.com/press/archive/1999/10/pr99130.html),=20
as well as our LDAP direction in this space.

I believe that providing multiple "standard" ways of doing=20
something that is relatively simple inevitably leads to=20
unnecessary duplication of effort, and more importantly,
serious interoperability problems between vendors.

It's difficult enough to get multiple vendors to do something
right when there is only one way to do it. If there are multiple
options, as with the current logic for determining what encryption
algorithm to use, someone is bound to screw it up, with the
result that two different products have difficulty communicating.

If I could turn the clock back a year or two, I would have preferred=20
that the SMIME Capabilities attribute be included in the end-user's
certificate directly.

Failing that, I would have liked to see a "Capabilities" certificate =
that=20
is issued and signed by the end-user herself, that in addition to =
containing
SMIME stuff regarding what algorithms were supported, might
also have contained the equivalent of a CPS statement that defends=20
the user, and not just the CA, from unwanted reliance on a signature, for
example.  If the end-user published such a certificate, it would have =
made=20
sense to put it in the same LDAP bucket as the end-user's own certificate.

Both of those options are probably foreclosed by now, unfortunately,
so we are left with the problem of where to put the SMIME Capabilities, =
and
where to put the user's S/MIME certificates.

With respect to the certificates themselves, I don't think there is any=20
question at all -- all, or nearly all, of the public CAs and CA toolkit =
vendors=20
publish the certificates in the already defined LDAP attributes.

And from a certificate management perspective, the last thing that either =
the
user/system administrator or the vendor wants is to have to manage TWO=20
sets of certificates stored in separate places. The possibilities for =
errors
are obvious -- one certificate gets deleted/replace, and the other one=20
doesn't, etc.

I suppose that it could be argued from an LDAP user's perspective that=20
it might be convenient to be able to browse through a directory, find the
desired user, and click on one directory attribute to retrieve the =
SMIME=20
Capabilities and the entire certificate chain in one operation.  I'm =
relatively
certain that's the scenario that the authors had in mind for this =
capability.

However, I don't think that's what will happen in practice.

Instead, I expect that an e-mail user will type in or select names from=20
his personal or system address book. Then he or she will decide to=20
encrypt the message, without regard to whether or not all of the certificat=
es=20
for all of the addressees have already been cached locally.

At that point, the MUA should automatically fetch the certificates and=20
SMIME capabilities for all of the users, and perhaps prompt the user=20
to make sure that those are in fact the right certificates for those =
users.

But the management of the certificate chain, the SMIME Capabilities, =
and=20
any other "plumbing" that the user doesn't absolutely have to be exposed =
to=20
should be handled by the MUA.  So the retrieval of the end-users certificat=
e(s),=20
the CA certificates, and the SMIME Capabilities should all be handled=20
automatically, without user intervention. Since it is software that is =
going=20
to be doing the retrieval, and not a human user, retrieving from multiple =
attributes
is not a problem.

>From this perspective, I think it is obvious that there should be one and =
only
way to store and retrieve such certificates. Otherwise, it will be =
necessary=20
to implement both types of directory fetches, just in case, and that just
causes more complexity, code bloat, system and interoperability testing, =
etc.
Yuck!

The current way of retrieving certificates is completely adequate, IMHO.
If it ain't broke, don't fix it.

Bob

>>> <[email-masked]> 10/26/99 10:16AM >>>

-----Original Message-----
From: phoffman [SMTP:[email-masked]]=20
Sent: Monday, October 25, 1999 5:09 PM
To: ietf-smime
Cc: phoffman
Subject: Re: Working Group Last Call:draft-ietf-smime-certdist-04.txt

At 09:51 AM 10/25/99 -0400, David P. Kemp wrote:
>Since LDAP directories have both user and CA certificate attributes,

Agree.

>and LDAP is the Internet mechanism of choice for publishing and retrieving=

>certificates,

Disagree. We are far from understanding how certificates are and will =
be=20
published. LDAP certificate retrieval is well-defined, but not yet =
widely=20
implemented, particularly for S/MIME MUAs.
[O'Malley, Bartley] =20
Is this sufficient grounds to junk it? If it is not widely implemented =
yet=20
because of inherent problems, then fine, but if it is simply due to its=20
newness(my vote) we risk delaying the implementation of either by muddying =
the=20
water with the introduction of a second.

>  it would seem that a draft which proposes an alternative
>cert publishing mechanism as an Internet Standard would have a high
>burden of proof to justify the duplication.

If this draft was coming out three years from now, yes. As it is, we =
have=20
so little understanding of S/MIME customer needs, I don't think having =
an=20
alternative mechanism is harmful.

>   The IESG is relatively
>strict in discouraging the definition of overlapping mechanisms.

We only wish. :-) A topically relevant counterexample: S/MIME and OpenPGP.

[O'Malley, Bartley]=20
Pause for a moment... Do you really?(wish that is)

If you did, why would you support the introduction of an overlapping =
standard.

--Paul Hoffman, Director
--Internet Mail Consortium

--____RXPVIHJZACUBDQYIVIQA____
Content-Type: text/x-vcard; charset=windows-1252; name="Bob Jueneman.vcf"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="Bob Jueneman.vcf";
	modification-date="Wed, 27 Oct 1999 10:37:10 -0600"

BEGIN:VCARD
VERSION:2.1
X-GWTYPE:USER
FN:Robert R. Jueneman
TEL;WORK:801-861-7387
ORG:Novell, Inc.;Network Security Development
TEL;PREF;FAX:801-861-2522
EMAIL;WORK;PREF;NGW:[email-masked]
N:Jueneman;Bob
TITLE:Consultant Engineer
ADR;INTL;WORK;PARCEL;POSTAL:;PRV-F331;122 E. 1700 South;Provo;Utah;84606;US=
A
LABEL;INTL;WORK;PARCEL;POSTAL;ENCODING=3DQUOTED-PRINTABLE:Robert R. =
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:Robert R. =
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-801-361-1410
TEL;PREF:1-801-861-7387, 1-800-453-1267
X-GWUSERID:BJUENEMAN
END:VCARD

--____RXPVIHJZACUBDQYIVIQA____--

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

--____WADBJNCIRFTLTXQWWZIG____--

From: [email-masked]
Date: Wed, 27 Oct 1999 09:35:00 -0600
Subject: Re: S-MIME key length
To: [email-masked], V KRISHNA REDDY<[email-masked]>
Sender: [email-masked]

--____ACYPFYRFVBRYBLIJGPKZ____
Content-Type: multipart/mixed; boundary="____ZTOGZPVTRLXLEKEAXCPG____"

--____ZTOGZPVTRLXLEKEAXCPG____
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

This message is signed with a 2048 bit key.  So far, I haven't encountered =
anyone
who hasn't been able to validate the signature with that length key.  =
Encryption=20
could conceivably be a different issue, depending on whether or not a =
recipient
is constrained by export and/or import policy.

We've done some limited testing with "odd-ball" key lengths -- 768, and =
even odd
number such as 1027, etc.  No observed problems. Doesn't guarantee that
everyone's software will handle such keys, of course.

Bob

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

DISCLAIMER:
  If this message (with or without attached documents) is digitally =
signed, and/or if certificates are attached, the intended purpose is to=20
   (1) Ensure that e-mail came from the apparent sender
   (2) Protect e-mail from tampering
   (3) Ensure that the content of e-mail sent to me and encrypted in  my =
dual-use key cannot be viewed by others.
  It is explicitly NOT the intent of any such signed message or document =
to represent any type or form of legally binding contract or other =
representation, and any such interpretation should not be considered =
commercially reasonable and WILL BE REPUDIATED, notwithstanding any =
wording or implications to the opposite effect in the text of the message =
itself; due in part, but not exclusively, to the fact that the security of =
my workstation and its associated cryptography is not judged adequately =
strong for such purposes at present.

>>> Bruce Greenblatt <[email-masked]> 10/26/99 =
09:32PM >>>
As I understand it, the S/MIME spec lets you use any key length that you
want, as long as you have an algorithm OID for it...  So, you can
definitely use 1024 bit keys.

At 03:56 PM 10/25/99 +0530, V KRISHNA REDDY wrote:
>I want the information whether s-mime specification gives us the
>flexibilty to use 1024 bit key length.Actually what is the status of the
>specification regarding key length.
>--krishna=20
>
>
>
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Bruce Greenblatt, Ph. D.
Directory Tools and Application Services, Inc.
http://www.directory-applications.com

--____ZTOGZPVTRLXLEKEAXCPG____
Content-Type: text/x-vcard; charset=windows-1252; name="Bob Jueneman.vcf"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="Bob Jueneman.vcf";
	modification-date="Wed, 27 Oct 1999 09:35:30 -0600"

BEGIN:VCARD
VERSION:2.1
X-GWTYPE:USER
FN:Robert R. Jueneman
TEL;WORK:801-861-7387
ORG:Novell, Inc.;Network Security Development
TEL;PREF;FAX:801-861-2522
EMAIL;WORK;PREF;NGW:[email-masked]
N:Jueneman;Bob
TITLE:Consultant Engineer
ADR;INTL;WORK;PARCEL;POSTAL:;PRV-F331;122 E. 1700 South;Provo;Utah;84606;US=
A
LABEL;INTL;WORK;PARCEL;POSTAL;ENCODING=3DQUOTED-PRINTABLE:Robert R. =
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:Robert R. =
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-801-361-1410
TEL;PREF:1-801-861-7387, 1-800-453-1267
X-GWUSERID:BJUENEMAN
END:VCARD

--____ZTOGZPVTRLXLEKEAXCPG____--

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

--____ACYPFYRFVBRYBLIJGPKZ____--

Date: Wed, 27 Oct 1999 07:59:06 -0700
To: <[email-masked]>
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: s/mime certificate format
Sender: [email-masked]

At 05:07 PM 10/27/99 +0530, krishna Reddy wrote:
>Can you plese give the S/MIME v3 certificate format.What are the field 
>extensions that are necessary for such a certificate.

All the RFCs are available from the WG's web site at 
<http://www.imc.org/ietf-smime/>.

--Paul Hoffman, Director
--Internet Mail Consortium

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-ecc-00.txt
Date: Wed, 27 Oct 1999 08:48:53 -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		: Elliptic Curve S/MIME
	Author(s)	: P. Lambert
	Filename	: draft-ietf-smime-ecc-00.txt
	Pages		: 
	Date		: 26-Oct-99
	
This document is the first draft of a profile for the incorporation 
of Elliptic Curve (EC) public key algorithms in the Cryptographic 
Message Syntax (CMS).  The EC algorithms support the creation of 
digital signatures and the distribution of keys to encrypt or authen-
ticate message content.  The definition of the algorithm processing 
is based on the ANSI X9.63 draft, developed by the ANSI X9F1 
working group.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-ecc-00.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-ecc-00.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-ecc-00.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-ecc-00.txt

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

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

--OtherAccess--

--NextPart--

From: "krishna Reddy" <[email-masked]>
To: <[email-masked]>
Subject: s/mime certificate format
Date: Wed, 27 Oct 1999 17:07:27 +0530
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_00BE_01BF209D.BF176900
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Can you plese give the S/MIME v3 certificate format.What are the field =
extensions that are necessary for such a certificate.
--krishna

------=_NextPart_000_00BE_01BF209D.BF176900
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>

<META content=3Dtext/html;charset=3Diso-8859-1 =
http-equiv=3DContent-Type>
<META content=3D'"MSHTML 4.72.3110.7"' name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT color=3D#000000 size=3D2>Can you plese give the S/MIME v3 =
certificate=20
format.What are the field extensions that are necessary for such a=20
certificate.</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2>--krishna</FONT></DIV></BODY></HTML>

------=_NextPart_000_00BE_01BF209D.BF176900--

From: [email-masked]
To: [email-masked]
Date: Wed, 27 Oct 1999 13:11:37 +0100
Subject: Problem with signatures
Sender: [email-masked]

Hi

I am trying to compose S/MIME messages with signed and encrypted data.
My question is:  what exactly is the input for the signing procedure? For
example(below), should
all the pkcs#7-mime headers(and the blank lines) be included when the signature
is calculated or is it only the base 64 encrypted data?
When this example is opened in Netscape Messenger the decryption works fine but
the signature is invalid, I am quite sure that I use the right certificates.

please advise

Andreas Rehn

Message-ID: <941020533@random-pc>
Date: Wednesday, 27/10/1999 12:35:33 +0200
From: [email-masked]
To: [email-masked]
Subject: encrypted to be signed
MIME-Version: 1.0
Content-Type: multipart/signed;  protocol="application/pkcs7-signature";
      micalg="sha1"; boundary="BOUNDARY"

--BOUNDARY
Content-Type: application/pkcs7-mime; name="test"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="test"
Content-Description: S/MIME Encrypted Message

MIAGCSqGSIb...
...
...qVSnAAAAAA==

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

MIAGCSqGSIb3D...
...UB2KZ9RcTbkAAAAAA==
--BOUNDARY--
.

Date: Wed, 27 Oct 1999 12:55:20 +0530 (IST)
From: V KRISHNA REDDY <[email-masked]>
To: Bruce Greenblatt <[email-masked]>
cc: [email-masked]
Subject: Re: S-MIME key length
Sender: [email-masked]

Can you please send me the format for the S/MIME v3 certificates.i.e. I
want to have the all the required fields in the smime v3 certificates.
--krishna.

On Tue, 26 Oct 1999, Bruce Greenblatt wrote:

> As I understand it, the S/MIME spec lets you use any key length that you
> want, as long as you have an algorithm OID for it...  So, you can
> definitely use 1024 bit keys.
> 
> At 03:56 PM 10/25/99 +0530, V KRISHNA REDDY wrote:
> >I want the information whether s-mime specification gives us the
> >flexibilty to use 1024 bit key length.Actually what is the status of the
> >specification regarding key length.
> >--krishna 
> >
> >
> >
> ==============================================
> Bruce Greenblatt, Ph. D.
> Directory Tools and Application Services, Inc.
> http://www.directory-applications.com
> 

Date: Tue, 26 Oct 1999 20:32:35 -0700
To: V KRISHNA REDDY <[email-masked]>, [email-masked]
From: Bruce Greenblatt <[email-masked]>
Subject: Re: S-MIME key length
Sender: [email-masked]

As I understand it, the S/MIME spec lets you use any key length that you
want, as long as you have an algorithm OID for it...  So, you can
definitely use 1024 bit keys.

At 03:56 PM 10/25/99 +0530, V KRISHNA REDDY wrote:
>I want the information whether s-mime specification gives us the
>flexibilty to use 1024 bit key length.Actually what is the status of the
>specification regarding key length.
>--krishna 
>
>
>
==============================================
Bruce Greenblatt, Ph. D.
Directory Tools and Application Services, Inc.
http://www.directory-applications.com

From: [email-masked]
Date: Tue, 26 Oct 1999 17:15:00 -0600
Subject: RE: Working Group Last Call:draft-ietf-smime-certdist-04.txt
To: [email-masked]
Sender: [email-masked]

NaPkNDoCDGWk

Organization: ESAT, K.U.Leuven, Belgium
Date: Tue, 26 Oct 1999 22:18:24 +0200 (CEST)
From: Eurocrypt 2000 <[email-masked]>
To: [email-masked]
Subject: Eurocrypt 2000 submission deadline: November 3, 1999
Sender: [email-masked]

-------------------------------------------------------------
                  E U R O C R Y P T    2 0 0 0
                         May 14-18, 2000
                    Bruges (Brugge), Belgium

     http://www.esat.kuleuven.ac.be/cosic/eurocrypt2000/
-------------------------------------------------------------

This is a reminder that the submission deadline for 
Eurocrypt 2000 is November 3, 1999. 

Visit http://www.esat.kuleuven.ac.be/cosic/eurocrypt2000/ 
for more information.

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

From: [email-masked]
Date: Tue, 26 Oct 1999 17:16:40 +0100
Subject: RE: Working Group Last Call:draft-ietf-smime-certdist-04.txt
TO: [email-masked], [email-masked]
Sender: [email-masked]

--openmail-part-0c282f9e-00000001
Content-Type: text/plain; charset=US-ASCII; name="BDY.TXT"
Content-Disposition: inline; filename="BDY.TXT"
Content-Transfer-Encoding: 7bit

-----Original Message-----
From: phoffman [SMTP:[email-masked]]
Sent: Monday, October 25, 1999 5:09 PM
To: ietf-smime
Cc: phoffman
Subject: Re: Working Group Last Call:draft-ietf-smime-certdist-04.txt

At 09:51 AM 10/25/99 -0400, David P. Kemp wrote:
>Since LDAP directories have both user and CA certificate attributes,

Agree.

>and LDAP is the Internet mechanism of choice for publishing and retrieving
>certificates,

Disagree. We are far from understanding how certificates are and will be 
published. LDAP certificate retrieval is well-defined, but not yet widely 
implemented, particularly for S/MIME MUAs.
[O'Malley, Bartley]  
Is this sufficient grounds to junk it? If it is not widely implemented yet 
because of inherent problems, then fine, but if it is simply due to its 
newness(my vote) we risk delaying the implementation of either by muddying the 
water with the introduction of a second.

>  it would seem that a draft which proposes an alternative
>cert publishing mechanism as an Internet Standard would have a high
>burden of proof to justify the duplication.

If this draft was coming out three years from now, yes. As it is, we have 
so little understanding of S/MIME customer needs, I don't think having an 
alternative mechanism is harmful.

>   The IESG is relatively
>strict in discouraging the definition of overlapping mechanisms.

We only wish. :-) A topically relevant counterexample: S/MIME and OpenPGP.

[O'Malley, Bartley] 
Pause for a moment... Do you really?(wish that is)

If you did, why would you support the introduction of an overlapping standard.

--Paul Hoffman, Director
--Internet Mail Consortium

--openmail-part-0c282f9e-00000001
Content-Type: application/ms-tnef; name="WINMAIL.DAT"
Content-Disposition: attachment; filename="WINMAIL.DAT"
Content-Transfer-Encoding: base64

--openmail-part-0c282f9e-00000001--

From: "Rik Drummond" <[email-masked]>
To: "Paul Hoffman / IMC" <[email-masked]>, <[email-masked]>
Subject: RE: Working Group Last Call:draft-ietf-smime-certdist-04.txt
Date: Tue, 26 Oct 1999 09:40:54 -0500
Importance: Normal
Sender: [email-masked]

I agree with Paul... Rik

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Paul Hoffman / IMC
Sent: Monday, October 25, 1999 11:09 AM
To: [email-masked]
Subject: Re: Working Group Last Call:draft-ietf-smime-certdist-04.txt

At 09:51 AM 10/25/99 -0400, David P. Kemp wrote:
>Since LDAP directories have both user and CA certificate attributes,

Agree.

>and LDAP is the Internet mechanism of choice for publishing and retrieving
>certificates,

Disagree. We are far from understanding how certificates are and will be 
published. LDAP certificate retrieval is well-defined, but not yet widely 
implemented, particularly for S/MIME MUAs.

>  it would seem that a draft which proposes an alternative
>cert publishing mechanism as an Internet Standard would have a high
>burden of proof to justify the duplication.

If this draft was coming out three years from now, yes. As it is, we have 
so little understanding of S/MIME customer needs, I don't think having an 
alternative mechanism is harmful.

>   The IESG is relatively
>strict in discouraging the definition of overlapping mechanisms.

We only wish. :-) A topically relevant counterexample: S/MIME and OpenPGP.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Mon, 25 Oct 1999 09:09:17 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: Working Group Last Call:draft-ietf-smime-certdist-04.txt
Sender: [email-masked]

At 09:51 AM 10/25/99 -0400, David P. Kemp wrote:
>Since LDAP directories have both user and CA certificate attributes,

Agree.

>and LDAP is the Internet mechanism of choice for publishing and retrieving
>certificates,

Disagree. We are far from understanding how certificates are and will be 
published. LDAP certificate retrieval is well-defined, but not yet widely 
implemented, particularly for S/MIME MUAs.

>  it would seem that a draft which proposes an alternative
>cert publishing mechanism as an Internet Standard would have a high
>burden of proof to justify the duplication.

If this draft was coming out three years from now, yes. As it is, we have 
so little understanding of S/MIME customer needs, I don't think having an 
alternative mechanism is harmful.

>   The IESG is relatively
>strict in discouraging the definition of overlapping mechanisms.

We only wish. :-) A topically relevant counterexample: S/MIME and OpenPGP.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Mon, 25 Oct 1999 09:51:18 -0400 (EDT)
From: "David P. Kemp" <[email-masked]>
Reply-To: "David P. Kemp" <[email-masked]>
Subject: Re: Working Group Last Call:draft-ietf-smime-certdist-04.txt
To: [email-masked], [email-masked]
Content-MD5: 4DrYVkrB/I/zpO9rzRN9hg==
Sender: [email-masked]

Certdist draft 4 is an improvement over draft 3, in that it allows
CAs (not just End Entities) to sign the SMimeCertificatePublish object
and it allows End Entity certificates to be published in the userCertificate
attribute in lieu of the proposed userSmimeCertificate attribute.

However, it is still not clear what certificate publishing problem
certdist is trying to solve.

Section 2 says:

  "LDAP currently has the userCertificate property [attribute? -- dpk]
  defined for just that purpose.  ...  While some directories, such as
  X.500 directories, provide for a directory entry to contain the CA
  certificate, this is not the case for all directories."

Since LDAP directories have both user and CA certificate attributes,
and LDAP is the Internet mechanism of choice for publishing and retrieving
certificates, it would seem that a draft which proposes an alternative
cert publishing mechanism as an Internet Standard would have a high
burden of proof to justify the duplication.  The IESG is relatively
strict in discouraging the definition of overlapping mechanisms.

The draft should cite at least one example of an Internet directory
which:
1) is used to distribute certificates,
2) could be modified to include the proposed userSmimeCertificate attribute, and
3) could not be modified to contain the standard caCertificate attribute.

If such a directory exists, and needs to be accommodated in an Internet
Standard, I propose that the following be added to section 4.3, which
subsumes the LDAP-specific wording currently in section 4.5:

  4.3 CertificateSet
  
  If the SMimeCertificatePublish object is published in the LDAP
  userSmimeCertificate attribute, the SignedData->certificates field
  of the object MUST be absent.  If the SMimeCertificatePublish object
  is distributed by other means, this draft imposes additional
  restrictions ...

This would ensure that LDAP directories only have to store one copy of
user and CA certificates in the standard user- and CA-certificate
attributes, instead of duplicating user certificates in two attributes
and maintaining duplicate copies of CA certificates for every user.  In
LDAP directories, userSmimeCertificate would thus contain only the
signed attributes; the eContent and CertificateSet fields would be empty.

Dave Kemp

> Announcing S/MIME Working Group Last Call.
> 
> 	Title		: Certificate Distribution Specification
> 	Author(s)	: J. Schaad
> 	Filename	: draft-ietf-smime-certdist-04.txt
> 	Pages		: 20
> 	Date		: 21-Oct-99
> 	
> Current methods of publishing certificates in directory services are
> restricted to just certificates.  This document provides a method of
> publishing certificates with secondary support information such as
> the SMimeCapabilities attribute (containing bulk algorithm support)
> in a way that is both authenticated and bound to a given
> certificate.
> 
> Working Group Last Call will close after the IETF meeting.  It will close 
> on 14 November.
> 
> S/MIME WG Chair,
>     Russ

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-examples-03.txt
Date: Mon, 25 Oct 1999 07:01:46 -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		: Examples of S/MIME Messages
	Author(s)	: P. Hoffman
	Filename	: draft-ietf-smime-examples-03.txt
	Pages		: 8
	Date		: 22-Oct-99
	
This document gives examples of message bodies formatted using S/MIME.
Specifically, it has examples of Cryptographic Message Syntax (CMS)
objects, S/MIME messages (including the MIME formatting), and Enhanced
Security Services for S/MIME (ESS). It includes examples of most or all
common CMS and ESS formats; in addition, it gives examples that show
common pitfalls in implementing CMS. The purpose of this document is to
help increase interoperability for S/MIME and other protocols that rely
on CMS.
This draft is being discussed on the 'ietf-smime' mailing list.  To
join the list, send a message to <[email-masked]> with the
single word 'subscribe' in the body of the message.  Also, there is a
Web site for the mailing list at <http://www.imc.org/ietf-smime/>.

This draft is being discussed on the 'ietf-smime' mailing list.  To
join the list, send a message to <[email-masked]> with the
single word 'subscribe' in the body of the message.  Also, there is a
Web site for the mailing list at <http://www.imc.org/ietf-smime/>.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-examples-03.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-examples-03.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-examples-03.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-examples-03.txt

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

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

--OtherAccess--

--NextPart--

Date: Mon, 25 Oct 1999 15:56:24 +0530 (IST)
From: V KRISHNA REDDY <[email-masked]>
To: [email-masked]
Subject: S-MIME key length
Sender: [email-masked]

I want the information whether s-mime specification gives us the
flexibilty to use 1024 bit key length.Actually what is the status of the
specification regarding key length.
--krishna 

Date: Fri, 22 Oct 1999 17:27:54 -0400
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Working Group Last Call:draft-ietf-smime-certdist-04.txt
Sender: [email-masked]

Announcing S/MIME Working Group Last Call.

	Title		: Certificate Distribution Specification
	Author(s)	: J. Schaad
	Filename	: draft-ietf-smime-certdist-04.txt
	Pages		: 20
	Date		: 21-Oct-99
	
Current methods of publishing certificates in directory services are
restricted to just certificates.  This document provides a method of
publishing certificates with secondary support information such as
the SMimeCapabilities attribute (containing bulk algorithm support)
in a way that is both authenticated and bound to a given
certificate.

Working Group Last Call will close after the IETF meeting.  It will close 
on 14 November.

S/MIME WG Chair,
    Russ

Date: Fri, 22 Oct 1999 14:27:52 -0700
To: Russ Housley <[email-masked]>, [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: Proposed Charter Update
Sender: [email-masked]

>December 1999:
>      Last call on CMS and ESS examples document.

We've had a slow start on the examples draft (but are now moving ahead; -03 
was turned in yesterday). I'd move this to February 2000 to be realistic.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Fri, 22 Oct 1999 15:37:45 -0400
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Proposed Charter Update
Sender: [email-masked]

Please review and comment.

Russ

= = = = = = = = = = =

S/MIME Mail Security (smime)

Chair:
      Russ Housley <[email-masked]>

Security Area Director:
      Jeffrey Schiller <[email-masked]>
      Marcus Leech <[email-masked]>

Mailing Lists:
      General Discussion: [email-masked]
      To Subscribe:       [email-masked]
      Archive:            http://www.imc.org/ietf-smime/

Description of Working Group:

The S/MIME Working Group has completed five Proposed Standards that
comprise the S/MIME version 3 specification.  Current efforts build
on these base specifications.

The use of Diffie-Hellman 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.

The Cryptographic Message Syntax (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.  Specifications for the use of additional
cryptographic algorithms will be developed.  An additional suite of
"mandatory to implement" algorithms may be selected.

To aid implementers, documents containing example output for CMS will
be collected and published.  Some of the examples will include structures
and signed attributed defined in the Enhanced Security Services (ESS)
document.

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.

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.

Compressing data before encrypting it or signing it has a number of
advantages.  Compression improves security by removing known data
patterns, improves throughput by reducing the amount of data which needs
to be encrypted or hashed, and reduces the overall message size.  Enabling
S/MIME version 3 to use compressed will provide all of these advantages.

S/MIME version 3 permits the use of previously distributed symmetric
key-encryption keys.  Specifications for the distribution of
symmetric key-encryption keys to mmultiple message recipients will
be developed.  Mail List Agents (MLAs) are one user of symmetric
key-encryption keys.  The specification will be cryptographic
algorithm independent.

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 organizations
will be used as examples.

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

The S/MIME Working Group will attempt to coordinate its efforts with the
OpenPGP Working Group in areas where the work of the two groups overlap.

Goals and Milestones:

History:
      First draft of small subgroup attack avoidance.
      First draft of certificate distribution specification.
      First draft of domain security services document.
      First draft of CMS and ESS examples document.
      First draft of KEA and SKIPJACK algorithm specification.
      First draft of IDEA algorithm specification.
      First draft of CMS RecipientInfo extension.
      First draft of CAST algorithm specification.

October 1999:
      First draft of security label usage specification.
      First draft of elliptic curve algorithm specification.
      First draft of CMS compressed data content type specification.
      Last call on certificate distribution specification.

November 1999:
      First draft of mail list key distribution.
      Updated draft of domain security services document.
      Last call on CAST algorithm specification.
      Last call on small subgroup attack avoidance.
      Last call on KEA and SKIPJACK algorithm specification.
      Submit small subgroup attack avoidance as Informational RFC.
      Submit KEA and SKIPJACK algorithm specification as Informational RFC.

December 1999:
      Last call on CMS and ESS examples document.
      Last call on IDEA algorithm specification.
      Last call on CMS RecipientInfo extension.

January 2000:
      Last call on security label usage specification.
      Last call on mail list key distribution.
      Last call on CMS compressed data content type specification.
      Submit certificate distribution specification as a Proposed Standard.

February 2000:
      Last call on elliptic curve algorithm specification.
      Submit CAST algorithm specification as Informational RFC.

March 2000:
      Submit CMS and ESS examples document as Informational RFC.
      Submit IDEA algorithm specification as Informational RFC.
      Submit CMS RecipientInfo extension as a Proposed Standard.
      Submit mail list key distribution as a Proposed Standard.

April 2000:
      Submit CMS compressed data content type specification as a Proposed 
Standard.

May 2000:
      Submit elliptic curve algorithm specification as a Proposed Standard.
      Submit security label usage specification as Informational RFC.

July 2000:
      Last call on domain security services document.

September 2000:
      Submit domain security services as Experimental RFC.

From: [email-masked]
To: [email-masked]
Date: Fri, 22 Oct 99 14:31:36 EST
Subject: Your Web Page
Sender: [email-masked]

Increase your Web Site visiblity !

Try out :

*** Proven Web Page Optimisation Software ***
>> Audited results 55% Number 1  90% top 5 <<

*** Macro Media Web Page Design Software ****
  >>> Make your Web Pages sparkle <<<<

**** Accept checks from your Web Site *****
 >>>> Improve your margins & Cashflow <<<<

 Go to :  
http://www.pcpages.com/bizzinews/

 ++++ Sender & Remove Instructions ++++
Free Business Links
Bevere Close
Worcester
Tel 121 643 2448
Email : [email-masked]
++++++++++++++++++++++++++++++++++++

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-certdist-04.txt
Date: Fri, 22 Oct 1999 06:59:11 -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		: Certificate Distribution Specification
	Author(s)	: J. Schaad
	Filename	: draft-ietf-smime-certdist-04.txt
	Pages		: 20
	Date		: 21-Oct-99
	
Current methods of publishing certificates in directory services are
restricted to just certificates.  This document provides a method of
publishing certificates with secondary support information such as
the SMimeCapabilities attribute (containing bulk algorithm support)
in a way that is both authenticated and bound to a given
certificate.
This draft is being discussed on the 'ietf-smime' mailing list.  To
join the list, send a message to <[email-masked]> with
the single word 'subscribe' in the body of the message.  Also, there
is a Web site for the mailing list at <http://www.imc.org/ietf-
smime>.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-certdist-04.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-certdist-04.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-certdist-04.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-certdist-04.txt

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

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

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-domsec-03.txt
Date: Wed, 20 Oct 1999 06:58:16 -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		: Domain Security Services using S/MIME
	Author(s)	: T. Dean, W. Ottaway
	Filename	: draft-ietf-smime-domsec-03.txt
	Pages		: 8
	Date		: 19-Oct-99
	
This document describes how the S/MIME protocol can be processed and
generated by a number of components of a communication system, such as
message transfer agents, guards and gateways to deliver security
services. These services are collectively referred to as 'Domain
Security Services'. The mechanisms described in this document are
designed to solve a number of interoperability problems and technical
limitations that arise when different security domains wish to
communicate securely - for example when two domains use incompatible
messaging technologies such as X.400 and SMTP/MIME. This document is
also applicable to organisations and enterprises that have internal PKIs
which are not accessible by the outside world, but wish to interoperate
securely using the S/MIME protocol.

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

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-smime-domsec-03.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-domsec-03.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-domsec-03.txt

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

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

--OtherAccess--

--NextPart--

Date: Thu, 14 Oct 1999 16:51:15 -0400
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Agenda
Sender: [email-masked]

If you want to have a time slot on the agenda in DC, please drop me an note 
today.

Russ

From: "Jim Schaad (Exchange)" <[email-masked]>
To: "'Walter Williams'" <[email-masked]>, "'Russ Housley'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: Cert Attributes in CERTDIST
Date: Mon, 11 Oct 1999 12:48:25 -0700
Sender: [email-masked]

Keyboard focus bug -- lets finish the message this time.

I do know that current clients exist in the market who only look at one
element (mine for one), however I don't believe that this should stand in
the way of creating a "correct" standard.

I agree that it makes sense to allow for the EE certificate to be optional
if it exists in the userCertificates property.  I think that the chain
certificates can be optional if  there are sufficent pointers in the
certificate to allow it to be found. (i.e. an AIA extension with an ldap
URI).

I will update the draft to this and post before the end of the week.

jim

-----Original Message-----
From: Jim Schaad (Exchange) 
Sent: Monday, October 11, 1999 12:46 PM
To: 'Walter Williams'; Russ Housley
Cc: [email-masked]; [email-masked]
Subject: RE: Cert Attributes in CERTDIST

I do know that current clients exist in the market who only look at one
element (mine for one), however I don't believe that this should stand in
the way of creating a "correct" standard.

I agree that it makes sense to allow for the EE certificate to be optional
if it exists in the userCertificates property.  I think that the chain
certificates can be optional if 

-----Original Message-----
From: Walter Williams [mailto:[email-masked]]
Sent: Sunday, September 12, 1999 7:30 PM
To: Russ Housley; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: Cert Attributes in CERTDIST

Russ,

One thought here is backwards compatability of existing s/mime aware
clients.  Some may have been written to check for the cert in only one of
the available attributes.  You don't want to change the directory in a way
which prevents an older client from seeing the certificate. (might though
give vendors a thrill to have to say: so sorry, but due to a standard change
we must force you to upgrade to support s/mime again)  Certificates are also
not very large (compaired with a .jpg picture of the directory entrant as a
comparitive example) and so the data bloat does not waste much drive space.
Of course, if all available clients look in both places, my statement is
pretty much a waste of good bandwidth.

Walt Williams
GTE Internetworking

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Russ Housley
Sent: Sunday, September 12, 1999 12:35 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: Cert Attributes in CERTDIST

Jim:

I must agree with many of the points that Dave Kemp made.  Is it worth
putting multiple copies of the same certificate into the Directory?  This
can lean to inconsistincies.

Maybe it would be better to follow the PKIX LDAP Schema and add an
S/MIME-specific attribute too the directory entry.  The binding you seek
could be achieved by putting a reference to a specific certificate that is
available in the userCertificate attribute inside the S/MIME-specific
attribute.

Thoughts?

Russ

From: "Jim Schaad (Exchange)" <[email-masked]>
To: "'Walter Williams'" <[email-masked]>, Russ Housley <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: RE: Cert Attributes in CERTDIST
Date: Mon, 11 Oct 1999 12:46:01 -0700
Sender: [email-masked]

I do know that current clients exist in the market who only look at one
element (mine for one), however I don't believe that this should stand in
the way of creating a "correct" standard.

I agree that it makes sense to allow for the EE certificate to be optional
if it exists in the userCertificates property.  I think that the chain
certificates can be optional if 

-----Original Message-----
From: Walter Williams [mailto:[email-masked]]
Sent: Sunday, September 12, 1999 7:30 PM
To: Russ Housley; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: Cert Attributes in CERTDIST

Russ,

One thought here is backwards compatability of existing s/mime aware
clients.  Some may have been written to check for the cert in only one of
the available attributes.  You don't want to change the directory in a way
which prevents an older client from seeing the certificate. (might though
give vendors a thrill to have to say: so sorry, but due to a standard change
we must force you to upgrade to support s/mime again)  Certificates are also
not very large (compaired with a .jpg picture of the directory entrant as a
comparitive example) and so the data bloat does not waste much drive space.
Of course, if all available clients look in both places, my statement is
pretty much a waste of good bandwidth.

Walt Williams
GTE Internetworking

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Russ Housley
Sent: Sunday, September 12, 1999 12:35 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: Cert Attributes in CERTDIST

Jim:

I must agree with many of the points that Dave Kemp made.  Is it worth
putting multiple copies of the same certificate into the Directory?  This
can lean to inconsistincies.

Maybe it would be better to follow the PKIX LDAP Schema and add an
S/MIME-specific attribute too the directory entry.  The binding you seek
could be achieved by putting a reference to a specific certificate that is
available in the userCertificate attribute inside the S/MIME-specific
attribute.

Thoughts?

Russ

From: "Jim Schaad (Exchange)" <[email-masked]>
To: "'Russ Housley'" <[email-masked]>
Cc: [email-masked]
Subject: RE: Cert Attributes in CERTDIST
Date: Mon, 11 Oct 1999 12:43:20 -0700
Sender: [email-masked]

Use of this element has what I consider to be a fatal flaw -- specifically
it is not protected in any way.  There is nothing to prevent me from
changing the value that you see retrieved from the directory in such a way
to allow you to detect it.  (consider changing the algorithms from 3DES to
RC2/40 for example).  After all, as a rule one does not bother looking up
ones own data in a directory to see if it has been changed recently.

jim

-----Original Message-----
From: Russ Housley [mailto:[email-masked]]
Sent: Thursday, September 16, 1999 9:51 AM
To: [email-masked]
Cc: [email-masked]
Subject: RE: Cert Attributes in CERTDIST

X.509-1997 defines the supported algorithm attribute.  There seems to be a 
lot of overlap.

Russ

= = = = = = = = = =

12.2.2.8  Supported algorithms attribute

A Directory attribute is defined to support the selection of an algorithm 
for use when communicating with a remote end entity using certificates as 
defined in this Directory Specification. The following ASN.1 defines this 
(multi-valued) attribute:

    supportedAlgorithms ATTRIBUTE ::= {
   	WITH SYNTAX SupportedAlgorithm
	EQUALITY MATCHING RULE algorithmIdentifierMatch
   	ID id-at-supportedAlgorithms }

    SupportedAlgorithm ::= SEQUENCE {
   	algorithmIdentifier              AlgorithmIdentifier,
	intendedUsage                [0] KeyUsage OPTIONAL,
	intendedCertificatePolicies  [1] CertificatePoliciesSyntax OPTIONAL
}

Each value of the multi-valued attribute shall have a distinct 
algorithmIdentifier value. The value of the intendedUsage component 
provides an indication of the intended usage of the algorithm (see 12.2.2.3 
for recognized uses). The value of the intendedCertificatePolicies 
component identifies the certificate policies and, optionally, certificate 
policy qualifiers with which the identified algorithm may be used.

From: "Peter Lewis" <[email-masked]>
To: <Undisclosed-Recipient:@s2.smtp.oleane.net;>
Subject: From Firewall to IPSec VPNs
Date: Mon, 4 Oct 1999 15:21:11 +0200
Organization: Upperside
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0069_01BF0E7C.16E36C80
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

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

------=_NextPart_000_0069_01BF0E7C.16E36C80
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT size=3D2>
<DIV><FONT size=3D2>
<DIV>Security services and protection mechanisms<BR>IPv6 promises =
regarding=20
IPSec<BR>Certification infrastructure<BR>Standardization update<BR>Case =
Studies:=20
ISPs, carriers, private networks<BR>AH and ESP protocols =
description<BR>Possible=20
future extensions and modifications of the IKE =
protocol<BR>Complementarity=20
between IPSec and firewalls<BR>Global Site-to-Site IPSec VPN's with =
End-to-End=20
SLA's<BR>Managing widespread IPSEC virtual private networks<BR>Solving =
IPSec=20
VPNs scalability<BR>Results of some interoperability tests<BR>IPSec=20
architectures and non-standardized aspects of IPSec<BR>Adding IPSec VPN=20
functions in an existing router network<BR>Impact of fragmentation on =
the=20
performance of IPSec coding<BR><BR>IPSEC 99 Conference<BR>From Firewall =
to IPSec=20
VPNs<BR><BR>October 26, 27, 28, 29, 1999<BR>Paris - France<BR><BR>More =
infos: <A=20
href=3D"http://www.upperside.fr/baipsec.htm">www.upperside.fr/baipsec.htm=
</A></DIV></FONT></DIV></FONT></DIV>
<DIV>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_0069_01BF0E7C.16E36C80--