Subject: RE: Update of CMS-X.400 Drafts

From: [email-masked]
Date: Mon, 11 Aug 2003 13:15:48 -0400

Hi Chris,

I am very sorry to not have noticed this before, but I did not see any
mention of optionally supporting Compression (i.e. RFC3274) under WRAP like
under MSGbis.  Isn't compression something that could also be useful for
X.400 content?  Was this intentional?

Cheers,

Francois

-----Original Message-----
From: Bonatti, Chris [mailto:[email-masked]]
Sent: Saturday, August 09, 2003 11:32 AM
To: [email-masked]
Subject: Update of CMS-X.400 Drafts

With Paul and Anders help, I have addressed some outstanding IESG (or
AD) comments that I did not hear of until after the Vienna meeting.  The
comments and their resolution are included below.  I also updated WRAP
so that it includes a specification of AES key sizes in alignment with
the -05 issue of MSGbis.  This latter issue was mentioned in my status
report in Vienna.

So you should look for an -08 issue of WRAP and an -09 issue of
TRANSPORT in the Internet-Drafts directory in short order (posted Friday
AM).

Cheers!
Chris

______WRAP COMMENTS________

3.2----->"whatever gateway system that is bridging" seems grammatically
wrong.

Replaced with "any gateway system that might bridge the gap".

3.2.1---->"since it is out" should be "since it is outside"?

Done.

3.3----->"If other binary transport" should "If another binary"?

Replaced with "If other transport (e.g., X.400) that is optimized for
binary content".  I think that's clearer.

3.3.1------> "it is out" again, outside?

Done.

3.4.1---> "7-bit transport, is optional" spurious comma.

Done.

3.4.1--->"certs-only, which is only for signed)" seems to be missing a
noun.

Replaced with "certs-only, which applies only to signed-only messages)".

______TRANSPORT COMMENTS________

2.6.1--->"because those type do not" has subject/verb agreeement
problem.

Changed "type" to "types".

2.6.2-----> "A RecipeintInfo" should be "RecipientInfo".

Done.

---

From: "Bonatti, Chris" <[email-masked]>
Date: Fri, 15 Aug 2003 14:15:03 -0400

Francois,

  This has not been discussed before on this list, but to my
knowledge has there has not been a strong call for this.  My view
is that this is feasible, but presently outside the scope of the
draft.  Since this doesn't constitute a MUST in the 2633bis, I'm
not sure this is significant.

  I do not favor slowing down the spec for this.

  Do others have opinions on this?

Chris

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Monday, August 11, 2003 13:16
To: [email-masked]
Cc: [email-masked]
Subject: RE: Update of CMS-X.400 Drafts

Hi Chris,

I am very sorry to not have noticed this before, but I did not
see any mention of optionally supporting Compression (i.e.
RFC3274) under WRAP like under MSGbis.  Isn't compression
something that could also be useful for X.400 content?  Was this
intentional?

Cheers,

Francois

-----Original Message-----
From: Bonatti, Chris [mailto:[email-masked]]
Sent: Saturday, August 09, 2003 11:32 AM
To: [email-masked]
Subject: Update of CMS-X.400 Drafts

With Paul and Anders help, I have addressed some outstanding IESG
(or
AD) comments that I did not hear of until after the Vienna
meeting.  The comments and their resolution are included below.
I also updated WRAP so that it includes a specification of AES
key sizes in alignment with the -05 issue of MSGbis.  This latter
issue was mentioned in my status report in Vienna.

So you should look for an -08 issue of WRAP and an -09 issue of
TRANSPORT in the Internet-Drafts directory in short order (posted
Friday AM).

Cheers!
Chris

3.2----->"whatever gateway system that is bridging" seems
grammatically wrong.

Done.

Replaced with "If other transport (e.g., X.400) that is optimized
for binary content".  I think that's clearer.

Done.

Done.

3.4.1--->"certs-only, which is only for signed)" seems to be
missing a noun.

Replaced with "certs-only, which applies only to signed-only
messages)".

Done.

---

From: Russ Housley <[email-masked]>
Date: Mon, 18 Aug 2003 09:56:02 -0400

Chris and Francois:

I would like to proceed with the specification "as is."  If we find that 
there is a lot of implementation, and those folks need compression, then we 
can revisit this issue.

Russ

---

From: Graeme Lunt <[email-masked]>
Date: Fri, 29 Aug 2003 12:28:00 +0100

As an implementor of this spec, I have not seen any requirements for
compression.

I am much keener to see the spec published "as is", than add compression
to the scope at this stage.

Graeme
 
> Chris and Francois:
> 
> I would like to proceed with the specification "as is."  If 
> we find that there is a lot of implementation, and those folks 
> need compression, then we can revisit this issue.
> 
> Russ
> 
> >   This has not been discussed before on this list, but to 
> my knowledge 
> >has there has not been a strong call for this.  My view is 
> that this is 
> >feasible, but presently outside the scope of the draft.  Since this 
> >doesn't constitute a MUST in the 2633bis, I'm not sure this is 
> >significant.
> >
> >mention of optionally supporting Compression (i.e.
> >RFC3274) under WRAP like under MSGbis.  Isn't compression something 
> >that could also be useful for X.400 content?  Was this intentional?
> >
> >Cheers,
> >
> >Francois
> >
> >
> grammatically 
> missing a 

Reply-To: "g.lunt" <[email-masked]>
From: Graeme Lunt <[email-masked]>
To: "'Francois.Rousseau'" <[email-masked]>
Cc: "'ietf-smime'" <[email-masked]>
Subject: RE: Update of CMS-X.400 Drafts
Date: Fri, 29 Aug 2003 12:28:00 +0100
Organization: Nexor
Importance: Normal
Sender: [email-masked]

As an implementor of this spec, I have not seen any requirements for
compression.

I am much keener to see the spec published "as is", than add compression
to the scope at this stage.

Graeme
 
> Chris and Francois:
> 
> I would like to proceed with the specification "as is."  If 
> we find that there is a lot of implementation, and those folks 
> need compression, then we can revisit this issue.
> 
> Russ
> 
> >   This has not been discussed before on this list, but to 
> my knowledge 
> >has there has not been a strong call for this.  My view is 
> that this is 
> >feasible, but presently outside the scope of the draft.  Since this 
> >doesn't constitute a MUST in the 2633bis, I'm not sure this is 
> >significant.
> >
> >mention of optionally supporting Compression (i.e.
> >RFC3274) under WRAP like under MSGbis.  Isn't compression something 
> >that could also be useful for X.400 content?  Was this intentional?
> >
> >Cheers,
> >
> >Francois
> >
> >
> grammatically 
> missing a 

Date: Wed, 27 Aug 2003 09:55:24 -0700 (PDT)
From: suchet singh khalsa <[email-masked]>
Subject: RFC 2634 Questions
To: [email-masked]
Cc: [email-masked]
Sender: [email-masked]

Hi Paul,
  Can you please answer the following questions w.r.t
MLA processing of S/MIME messages :

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

According to RFC 2632, while verifying signatures it
should confirmed that the sender (RFC822 From or
Sender headers) of the message is the same as the
signed entity. Does this apply to ONLY the innermost
signature in a triple wrapped message ?
If no, this will impact MLA processing as documented
in RFC 2634 in the following manner :

1.  The MLA creates an outermost SignedData layer
using the private key of the list. The final recipient
will not be able to verify this signature since the
>From header is not the list email address. Is the
solution here to set the list email address as the RFC
822 Sender header ?

2.  Most MLA's support mail merge functionality. Is
the intent of RFC 2634 to mandate that S/MIME and mail
merge do not go hand in hand ? The reason for this
question is : When MLA does mail merge, the innermost
signature in a triple wrapped message will become
invalid -  so the MLA will have to sign with the
private key of the list. So, the end recipient will
not be able to verify this signature since the From
header of the mail is not the list email address.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

RFC 2634 does not talk about this case :
An application/pkcs7-mime bodypart is enclosed in
another multipart, so that it is not the level 1
bodypart. What should the MLA do in this case ?
Possibilities are :
1.  Create the outermost signature (according to
RFC2634 page 34) for the whole mail.

2.  Create the outermost signature (according to
RFC2634 page 34) only for the application/pkcs7-mime
content.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Thanks,
Suchet

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com

Date: Wed, 27 Aug 2003 09:47:35 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: "Hallam-Baker, Phillip" <[email-masked]>
CC: [email-masked]
Subject: Re: PKI and S/MIME
Sender: [email-masked]

(text deleted)

> The specification only defines the interface between the TV and the cable,
> it does not require CNN and Fox News to broadcast exactly the same content
> at all times.

This *document* only defines *examples* but does not *specify* an interface.
This is probably intentional as well.

Denis

> 		Phill

From: "Hallam-Baker, Phillip" <[email-masked]>
To: "'Denis Pinkas'" <[email-masked]>, "Hallam-Baker, Phillip" <[email-masked]>
Cc: [email-masked]
Subject: RE: PKI and S/MIME
Date: Tue, 26 Aug 2003 21:00:35 -0700
Sender: [email-masked]

> > In this second application the XKMS service may choose to 
> impose some form
> > of validation constraint on the certs that it accepts. For 
> example only
> > accepting certs from a limited number of CAs - or it may not.
> 
> This specification does not provide this level of details.

That is intentional. The specification defines the protocol. It does not
state how to use the protocol any more than Kernighan and Richie tell users
how to program in C still less the programs they should write.

> This may be what some vendors are looking for: claiming 
> *compatibility* with 
> XKMS, while in reality each vendor will be non-interoperable 
> with any other 
> vendor and will have its own concept of trust (hidden and 
> different from any 
> other vendor).

That is again intentional. XKMS is not simply an interface to a PKI, it is a
key centric PKI in its own right.

An XKMS vendor can choose to robotically reflect the status of X.509 certs
with its service, or it can choose to reflect its view of the
trustworthiness of the keys themselves. 

The specification only defines the interface between the TV and the cable,
it does not require CNN and Fox News to broadcast exactly the same content
at all times.

		Phill

Date: Tue, 26 Aug 2003 17:53:27 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: "Hallam-Baker, Phillip" <[email-masked]>
CC: [email-masked]
Subject: Re: PKI and S/MIME
Sender: [email-masked]

Phill,

> There are two ways the problem may be solved.

> The simplest solution is that the domain owner appoints a single CA for the
> entire zone and simply directs all XKMS requests to the XKMS server run by
> the CA.

> The second solution is that the domain owner runs a non-authoritative Locate
> service locally. XKMS clients that register certificates with the CA of
> their choice can then in turn register the certificate issued by the CA with
> their local XKMS locate service.

> In this second application the XKMS service may choose to impose some form
> of validation constraint on the certs that it accepts. For example only
> accepting certs from a limited number of CAs - or it may not.

This specification does not provide this level of details.

I have read the XKMS document (I would not call it " a specification" - see 
later) and provided 35 comments during the last call period.

It would have been appropriate to provide these kinds of details but 
apparently the XKMS WG decided to be as general as possible, to provide 
*examples* instead of *specifications* and therefore the XKMS document is 
left open to many different interpretations.  :-(

This may be what some vendors are looking for: claiming *compatibility* with 
XKMS, while in reality each vendor will be non-interoperable with any other 
vendor and will have its own concept of trust (hidden and different from any 
other vendor).

Denis

> Incidentaly XKMS may also be used to register PGP keys or keys in
> alternative PKIs. It is a key centric PKI, not a token centric one.
> 
> 
> Storing end-user certs or keys in the DNS is a lousy idea for several
> reasons. First the DNS is a machine configuration infrastructure and not a
> user configuration infrastructure. Storing user information in the DNS
> requires an administrative interface with a new constituency. Ain't going to
> happen. Moreover the DNSSEC spec itself is still not in a deployable state,
> or at least the IETF version of it is not.
> 
> Storing certificates in LDAP is a lousy idea. LDAP is an internal enterprise
> resource. Enterprises are not going to expose LDAP data in border
> directories in significant numbers. It is not just the security issue, cost
> plays a factor. LDAP is not a simple protocol, it is would be completely
> overspecified for the job of a cert repository if the features LDAP provided
> were relevant to the task.
> 
> We considered certs in the DNS and LDAP before designing XKMS and rejected
> them. Both technologies have been available for at least 6 years with
> negligible uptake. We needed a new protocol because there was no acceptable
> existing solution. Sometimes designing a new protocol from scratch is better
> than attempting to use an inappropriate one.
> 
> 
> 		Phill
> 
> 
>>From: Anders Rundgren [mailto:[email-masked]]
>>Sent: Wednesday, August 13, 2003 1:16 PM
>>To: Blake Ramsdell; Simon Josefsson
>>Cc: [email-masked]; 'Sean P. Turner'
>>Subject: Re: PKI and S/MIME
>>
>>
>>
>>Simon,
>>I respect your work with DNS for location but is this really
>>universal?  How about my [email-masked] cert
>>issued by VeriSign?  Would it be appropriate to require ISPs
>>like Telia to maintain a directory pointing to various TTP CAs?
>>
>>Or should ever domain-owner become a CA?
>>
>>Anders
>>
>>----- Original Message ----- 
>>From: "Simon Josefsson" <[email-masked]>
>>To: "Blake Ramsdell" <[email-masked]>
>>Cc: <[email-masked]>; "'Sean P. Turner'" <[email-masked]>
>>Sent: Wednesday, August 13, 2003 09:32
>>Subject: Re: PKI and S/MIME
>>
>>
>>
>>"Blake Ramsdell" <[email-masked]> writes:
>>
>>
>>>There have been a number of messages recently about the use 
>>
>>of PKI with
>>
>>>S/MIME, and the concerns about that.  I like to think that we're all
>>>pretty much in agreement that we've established a consistent,
>>>interoperable practice for the actual syntax and contents of S/MIME
>>>messages, as well as a reasonable cut of a certificate 
>>
>>syntax profile
>>
>>>for end-entity certificates.
>>>
>>>Should there be a profile for certificate usage 
>>
>>(certificate repository,
>>
>>>distribution and revocation checking) that is specific for 
>>
>>our problem
>>
>>>domain?  That is, select relevant other work and profile it 
>>
>>for use in
>>
>>>the S/MIME interpersonal messaging domain?  I would imagine 
>>
>>that this
>>
>>>would be a new draft, start with a summary of the requirements, and
>>>progress to profiles of relevant standards.
>>>
>>>It's also not clear if this is something to discuss in this working
>>>group, or somewhere else.
>>>
>>>Comments?
>>
>>Since in practice, addressing this problem would help in getting
>>"opportunistic S/MIME" to work, I believe it would be useful to
>>address it.  ("Opportunistic S/MIME" means to be able to encrypt
>>messages to someone you don't have a prior trust relationship with,
>>simply to provide encryption of data.  There is a man in the middle
>>attack, of course, but in practice the result often isn't worse than
>>not using S/MIME.)
>>
>>A strawman at a requirement:
>>
>>* Be able to locate a certificate for a Internet user given only her
>>  email address.
>>
>>I should mention that this has been discussed several times before, in
>>various fora, for similar applications (e.g., OpenPGP, IPSEC, SSH), so
>>there is prior work to look at how to design this.  To do even more
>>self-promoting, I'd again like to mention the following draft:
>>
>>http://josefsson.org/draft-josefsson-pkix-dns.txt
>>
>>which do discuss it for S/MIME context as well.  I don't have an
>>opinion on if this WG is the proper place for it.
>>
>>Regards,
>>Simon
>>
> 
> 

Date: Sun, 24 Aug 2003 12:23:20 +1200
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: dissemination of public encryption certificates
Sender: [email-masked]

[email-masked] (Julien Pierre) writes:

>I was wondering what thoughts you may have on the following problem :
>
>If I have a keypair and e-mail certificate, and I want to send encrypted 
>e-mail to somebody knowing his e-mail address, what's a systematic way 
>to obtain the recipient's encryption certificate ?
>[...]
>I'm envisioning some standardized scheme where, by starting with the 
>recipient's email address, it would be possible to locate a public 
>directory server, then find the recipient's certificate by looking it up 
>in that directory server.

Sure.  See http://www.ietf.org/internet-drafts/draft-ietf-pkix-certstore-http-05.txt,
which proposes various methods of automated cert discovery, not just for
email clients but also for things like embedded devices.  The automated
discovery work is related to other work I did for automated PKI service
discovery, available at http://www.usenix.org/publications/library/proceedings/sec03/tech/gutmann.html.
It'll also be available from my home page in a week or two when I get back
home (uhh, and ignore the tongue-in-cheek comments about AOL users in there
:-).

Peter.

Date: Tue, 19 Aug 2003 15:08:39 -0400
To: "g.lunt" <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: RE: Signed Receipts and Mail Lists
Cc: [email-masked]
Sender: [email-masked]

Graeme:

> > When we designed the MLA mechanism, we assumed that each mail
> > list would have a separate key pair and certificate.  I do not
> > think that this is an unreasonable assumption.  Today, Web servers
> > that support more than one site have a certificate for each of the
> > sites.
>
>I had reached this conclusion on further reading of 2634. Whilst being
>able to use a single certificate (and ACs for example) for hundreds of
>lists would be useful, it is not a major concern at the moment.
>
>My main issue was to have a mechanism to indicate on whose behalf of
>whom a signed receipt was generated (e.g. in the case of an "All"
>request from  a ML).
>Either a specific field in the Receipt structure, or just an extension
>mechanism (which may be more generally useful).

I do not know if an update to RFC 2634 is planned.  I do not see it on the 
S/MIME WG charter.

Russ

From: "Anders Rundgren" <[email-masked]>
To: "Steve Hole" <[email-masked]>, "Julien Pierre" <[email-masked]>
Cc: <[email-masked]>
Subject: Re (subtopic): Four corner model
Date: Tue, 19 Aug 2003 08:50:56 +0200
Sender: [email-masked]

Some more on this topic.

Some TTP CAs (read: banks) have modeled their services after
their payment services.  e-governments have signed up such CAs
to supply citizen certificates.    Although I am fully convinced that
banks have an important role to fill in a TTP-based market (as
the on-line banking security requirements and on-line e-government
security requirements, are likely to be very similar), I strongly believe that
the four-corner model where each receiver (a,k.a. relying party)
must have
- a business contract with each trust network
- a unique relying party ID for each trust network
- a proprietary software installation for each trust network 
and pay for each revocation check, is something that governments
should reject.  For more details see:  
http://www.x-obi.com/OBI400/e-government-ID-A.Rundgren.pdf

Another problem I see with this model is that it seems rather impossible
to support secure e-mail between individuals as e-mail packages
cannot easily match the requirements above.

Anders Rundgren
Consultant PKI and secure e-business

Date: Mon, 18 Aug 2003 16:49:01 -0700
From: [email-masked] (Julien Pierre)
Subject: Re: Re (subtopic): certificate issuance and trust
To: "Steve Hole" <[email-masked]>
cc: [email-masked]
Organization: Netscape
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms010704000904080802040505
Content-Type: TEXT/PLAIN; CHARSET=us-ascii

Steve

Steve Hole wrote on 08/18/2003, 10:14:

 > I talk about cost a lot.   The average cost of a call to support is $18,
 > so it needs to be avoided at all costs (pun intended).
 >
 > The interfaces provided by IE and/or Netscape provide much simpler,
 > not so
 > "in-your-face" UI for cert management when there is no trust involved.

It sounds to me like your grief is not with so much with the current 
trust model and PKI or S/MIME specifications, but with certain vendor 
implementations. I'm afraid that's something you have to work with these 
vendors.

 > > What are the advantages of these pseudo-security products ?
 >
 > They avoid certification.
 >
 > They address the 36% of the Internet that doesn't use or have access to
 > S/MIME software -- primarily AOL, Yahoo!Mail and Hotmail.   If your in a
 > model 2 scenario you MUST do something useful with those and the solution
 > is psuedo security.   Interestingly, it seems good enough for most
 > people,
 > especially if it avoids calls to service reps.

AOL will be taken care of, eventually. The newest client software (AOL 
Communicator) already supports S/MIME. There are still issues with the 
mail servers unfortunately so it doesn't work today. Encryption works 
through it, but signing doesn't (sigh).

Webmail in general is a problem and cannot be truly taken care of, 
unless the user is willing to trust his ISP with his private key - e.g.. 
by uploading a PKCS12 file ...

Another solution might be some sort of Java applet that would decrypt 
the message. But it would have to know about each webmail provider and 
the layout, so it would be icky.

Perhaps some standard for webmail is the only solution - e.g.. a MIME 
type transmitted over HTTP that would allow the browser to invoke the 
proper S/MIME client.

 > This sucks!

In general the users don't have only webmail access though, they 
typically have a mailbox from their access ISP which can work with the 
S/MIME clients that already exist today.

 > Well, I'm not an expert on ISP business models.   Everything I've ever
 > been told suggests that there is almost no margin in the business model
 > and additional costs are hard to bear or pass through.   For this you
 > have
 > to convince the masses that security is what they want, and I can tell
 > you
 > from experience that that is a very difficult thing to do.   And my
 > experience comes from a business usage perspective where the content
 > definitely is sensitive in nature -- much more so that most email between
 > Mom and Aunt Jane.

I'm not an expert on this business model either either, but look at the 
latest AOL ads - "safe broadband", etc. This is certainly an area in 
which consumers are being educated right now, and security is something 
that consumers are getting interested in. I personally think there is 
hope for mass S/MIME deployment in the not so-distant future.

 > If you can acquire a delegated cert.   We haven't check recently, but 6
 > months ago we couldn't buy one.    Thawte used to sell them for $100K,
 > but
 > since have discontinued because there was no business there.   We should
 > go check again.   It was the simple and obvious thing to do, but because
 > there was nobody doing it, the service wasn't offerred by the CA's.

We have had our own chained CA chained with a known public root at 
Netscape for years. We did change issuer a couple times. Our current one 
is GTE. I think previously we used Verisign. I wasn't the one dealing 
with it, and I don't know the cost, but I can tell you that the service 
exists. Since there are about 100 known roots now, you could go to any 
of them and ask about the service. I think I read year's that RSA 
Security was offering that service as well, and it cost less than $100k.

 > The client would have to have some secure means of "synchronizing" it's
 > cache to a centralized service.   You get this with Microsoft services by
 > downloading a cert package from Windows Update.   The problem is that it
 > only works for Windows products (at least that way) and we need something
 > that is vendor independent.   The approach seems OK to me as long as
 > it is
 > "automatic".

Yes. We need a standard way of distributing root. We also need a way of 
distributing trust, ie. a subscriber model.
It sounds to me like this proposal belongs on the PKIX list, so maybe we 
should move it there.
I don't see the root distribution problem as a major roadblock to 
deployment today since the services for getting chained CAs exists.

 > Seems logical.   In practice we were unable to make it happen.   We
 > needed
 > to go through special negotiation because it wasn't a standard service
 > offering and there was a serious price issue for the signing cert.

Yes, it may not be a standard service, but if you need it there is far 
more than one issuer to go to these days.

 > In Netscape, yes.   In others no.   You actually get a Hex dump of the
 > cert with a message that says something like "Do you trust this
 > certificate with policy blah blah".   About 45% of the test group stopped
 > at this point.   Most of our customers simply said "too complex, too
 > scary".

As I recall IE brings up something similar to Netscape when the root is 
untrusted. What is the "other" software that is so inflexible ? It seems 
to me that you need to take it up with the software vendor.

 > Yes, I know it should be scary etc.   The problem is that the average
 > user
 > just doesn't get it, doesn't want to get it.  It's a barrier to uptake.
 > For the model 2 usage scenario uptake is everything because the economic
 > benefit is based on paper suppression and resulting cost reductions.
 >
 > That's all.

You can't require everybody to move to the S/MIME model at once. Even if 
a small percentage starts using it, the cost of printing and mailing is 
high. If you eliminate things like printed monthly statements, it 
shouldn't take a bank more than a small percentage of users to move to 
S/MIME to recoup its costs or actually profit.

 > >  > First of all, $0.01 per cert for 25M customers is $2.5M annually.
 > >
 > > No, it is $250,000 .
 >
 > Woops ... dislexic on the cost per cert.   The cheapest price we got was
 > $0.10 (man, I *looked* that at least five times too - senility).

That's still very low, but it's also likely less than the cost of 
printing and sending a single traditional communication.

 > Anyway,
 > the numbers weren't randomly chosen.  They were the numbers that we used
 > in an actual RFP response in which the customer eventually took the
 > one-way signing + encryption and decided against two-way with
 > bidirectional signing.   The actual cost was $2.5M per year.
 >
 > Security costs.  My example was intended to show that, in this
 > instance at
 > least, it costs too much even for relatively rich organizations.

I also know there are other financial organizations that spend much more 
on better security, and get more returns out of it. Look at credit card 
issuers starting to use smartcards. They have to bear the cost of the 
hardware in addition to the certs. They have millions of customers too. 
But some are doing it still (Amex). In Europe banks have been using 
smart chips on bank cards for decades. And believe it or not, they have 
been charging each customer to get those bank cards, too. Every bank 
over there is doing it though, because it reduces the transaction costs. 
We are not talking 10 cents per chip. With current generation smartcards 
they could afford to throw in certs for email as an extra and also 
eliminate the paper statements. Many of the issuers already have their 
own public roots to do it.

-- 
I am the dog in dogfood

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

--------------ms010704000904080802040505--

From: Steve Hole <[email-masked]>
Date: Mon, 18 Aug 2003 10:14:58 -0700
To: Julien Pierre <[email-masked]>
Subject: Re: Re (subtopic): certificate issuance and trust
Cc: [email-masked]
Sender: [email-masked]

On Fri, 15 Aug 2003 20:10:16 -0700 Julien Pierre <[email-masked]> 
wrote:

> 
> I'm not sure I understand why the trust is less of a problem for 
> encryption certs than signing certs.
> If you want to receive encrypted communications, you need to create an 
> encryption key and cert. And you need to make the other party aware of 
> it. Typically in S/MIME today this transfer of the public encryption 
> cert is done by ... signing an e-mail. Which requires you to have a 
> signing cert...
> Otherwise the user could also publish the encryption cert to LDAP.
> Still there would need to be some authentication at that time.

If you either (1) engage the desktop keypair generation CSR issuance or 
(2) generate a keypair and deliver it via PKcS12 at enrollment time, then 
you can issue data encipherment only key-usage keys that are only used for
encryption.   The keys can be self signed and really are only ever used to
decrypt data sent from the document issuer and cannot be used for signing.
By doing this, you avoid all root signing issues and all of the extremely 
nasty UI that prevents people from enrolling and generates calls to 
customer service.   The certificates need to be validated before we use 
them to encrypt, but that is all local security policy and we do a lot of 
stuff beyond normal certificate validation to make sure our certs are 
valid.   Once encrypted, the user just needs to have the private key to 
decrypt and the cert is really only used to keep the cert store happy on 
the desktop.

I talk about cost a lot.   The average cost of a call to support is $18, 
so it needs to be avoided at all costs (pun intended).

The interfaces provided by IE and/or Netscape provide much simpler, not so
"in-your-face" UI for cert management when there is no trust involved.
 
>  > There are a series of companies that provide "e-mail encryption" using
>  > proprietary formats and Javascript symetric decryptors that completely
>  > bypass S/MIME altogether.   And people buy it!  BIG organizations buy
>  > it.
>  > It's depressing.   And when talking about S/MIME it has to be concern to
>  > this group and people who implement S/MIME clients.
> 
> What are the advantages of these pseudo-security products ?

They avoid certification.

They address the 36% of the Internet that doesn't use or have access to 
S/MIME software -- primarily AOL, Yahoo!Mail and Hotmail.   If your in a 
model 2 scenario you MUST do something useful with those and the solution 
is psuedo security.   Interestingly, it seems good enough for most people,
especially if it avoids calls to service reps.

This sucks!
 
>  > No it won't :-)   Will your Mom pay to be certified?   I know for a fact
>  > mine won't because I tried to get her to get a Verisign cert and when she
>  > found out it was $20, that terminated that conversation quickly :-)
> 
> Yes, I know the feeling, I got the same reaction from my family members, 
> which is why I got many of them to enroll with the freemail Thawte CA 
> instead.
> 
> However the service doesn't have to be directly paid for, or all at 
> once. It can be bundled by the ISP with her account. Even if it wasn't 
> bundled with every account, the one-time $20 might be only a $1.66 
> option/month extra, which is the same price, but suddenly doesn't look 
> so bad. Especially if that $1.66 buys you more than just the ability to 
> communicate with family members, but also with businesses (ie. banks).

Well, I'm not an expert on ISP business models.   Everything I've ever 
been told suggests that there is almost no margin in the business model 
and additional costs are hard to bear or pass through.   For this you have
to convince the masses that security is what they want, and I can tell you
from experience that that is a very difficult thing to do.   And my 
experience comes from a business usage perspective where the content 
definitely is sensitive in nature -- much more so that most email between 
Mom and Aunt Jane.
 
>  > First of all, this problem really is a usage model 2 issue.   An
>  > organization wants to certify a very large number of users.  It really
>  > doesn't apply to usage model 1, for which most of the existing S/MIME
>  > clients are targeted.
> 
> Still, a corporate organization can run its own CA which doesn't have to 
> be a root CA.

If you can acquire a delegated cert.   We haven't check recently, but 6 
months ago we couldn't buy one.    Thawte used to sell them for $100K, but
since have discontinued because there was no business there.   We should 
go check again.   It was the simple and obvious thing to do, but because 
there was nobody doing it, the service wasn't offerred by the CA's.   
 
> I think it cannot ever entirely be removed from the client, because you 
> need to start with some trust, but it could be aggregated.
> Before this can be dynamically controlled however, the very notion of 
> what a trust domain is needs to be defined and standardized. Then we can 
> define means to transfer it, through existing protocols hopefully.

The client would have to have some secure means of "synchronizing" it's 
cache to a centralized service.   You get this with Microsoft services by 
downloading a cert package from Windows Update.   The problem is that it 
only works for Windows products (at least that way) and we need something 
that is vendor independent.   The approach seems OK to me as long as it is
"automatic".
 
> 
> My huge bank doesn't have to run a root, my huge bank can run a CA and 
> get it signed by one of the root CAs. Then it doesn't need to deploy a 
> root to every desktop.

Seems logical.   In practice we were unable to make it happen.   We needed
to go through special negotiation because it wasn't a standard service 
offering and there was a serious price issue for the signing cert.
 
> If it insists on running a root, there is going to be at least one 
> config change to make it happen. Right now I think it is as simple as 
> clicking on a URL and accepting a dialog. I don't know how much simpler 
> one can make it.

In Netscape, yes.   In others no.   You actually get a Hex dump of the 
cert with a message that says something like "Do you trust this 
certificate with policy blah blah".   About 45% of the test group stopped 
at this point.   Most of our customers simply said "too complex, too 
scary".

Yes, I know it should be scary etc.   The problem is that the average user
just doesn't get it, doesn't want to get it.  It's a barrier to uptake.   
For the model 2 usage scenario uptake is everything because the economic 
benefit is based on paper suppression and resulting cost reductions.

That's all.
 
>  > > The price figure you cite is absurdly low. Do you really, seriously
>  > > think $250,000 to enable secure services matters much to a company with
>  > > 25 million customers ? Certainly it wouldn't matter much to a bank,
>  > > especially since it would probably reduce certain mailing costs. I'd
>  > > guess that even one bulk USPS communication is going to cost more
>  > than 1
>  > > cent per recipient. I only know one ISP with 25 million customers or
>  > > more, and I happen to work for it, but I'm not at liberty to comment
>  > > further on the costs.
>  >
>  > First of all, $0.01 per cert for 25M customers is $2.5M annually.
> 
> No, it is $250,000 .

Woops ... dislexic on the cost per cert.   The cheapest price we got was 
$0.10 (man, I *looked* that at least five times too - senility).  Anyway, 
the numbers weren't randomly chosen.  They were the numbers that we used 
in an actual RFP response in which the customer eventually took the 
one-way signing + encryption and decided against two-way with 
bidirectional signing.   The actual cost was $2.5M per year.

Security costs.  My example was intended to show that, in this instance at
least, it costs too much even for relatively rich organizations.
 
Cheers.

---
Steve Hole
Chief Technology Officer - Billing and Payment Systems
ACI Worldwide
<mailto:[email-masked]>
Phone: 780-424-4922

Date: Mon, 18 Aug 2003 09:56:02 -0400
To: "Bonatti, Chris" <[email-masked]>, <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: RE: Update of CMS-X.400 Drafts
Cc: <[email-masked]>
Sender: [email-masked]

Chris and Francois:

Russ

>2.6.2-----> "A RecipeintInfo" should be "RecipientInfo".

Date: Mon, 18 Aug 2003 14:34:49 +0300
From: Vadim Fedukovich <[email-masked]>
To: [email-masked]
Subject: Re: Re (subtopic):  LDAP certificate distribution
Sender: [email-masked]

On Fri, Aug 15, 2003 at 10:30:11AM -0700, Steve Hole wrote:
> 
> On Thu, 14 Aug 2003 19:58:11 -0700 Julien Pierre <[email-masked]> 
> wrote:
> 
> > Why ?
> 
> Because you have to run a root.  That is, the hierarchy has to have a top 
> level interconnect.

really?

I believe RSA works fine both for subject name matching issuer name
and for any other subject name. One could put trust directly in some
CA certificate (say, a corporation-wide one) and it could be root,
self-signed or otherwise. Fine-tuned client software is the point

>   This quickly becomes an issue of governance.   
> National goverments get involved the way they got involved in DNS.   The 
> difference is that the governments got involved *before* the service was 
> running, not after the way they did with DNS.

One can easily sign with DSS/DSA using widely distributed quorum system,
maybe Shamir secret-sharing one. No single one would own
the signing key and it could be generated in shares right from the start

regards,
Vadim

Reply-To: <[email-masked]>
From: "Jim Schaad" <[email-masked]>
To: "'Deepak'" <[email-masked]>, <[email-masked]>
Subject: RE: Query regarding BER/DER encoding of CMS data
Date: Sun, 17 Aug 2003 08:21:54 -0600
Importance: Normal
Sender: [email-masked]

DER is a legal encoding when BER is called for.  BER is not required to
be indefinite length encoding.

jim

> [mailto:[email-masked]] On Behalf Of Deepak
> Sent: Thursday, August 14, 2003 9:29 AM
> To: [email-masked]
> Subject: Query regarding BER/DER encoding of CMS data
> 
> 
> 
> Hi,
> 
>   When i go through the CMS RFC's its saying, all the
> contenttype(SignedData,EnvelopedData) should be BER
> encoded. But when i go thorugh the some of the ietf
> examples, especially in EnvelopedData->RecipientInfo
> is encoded by DER.(its starting with 31 82 ..). It
> should be like sequence 30 80 .. ? 
> 
> Could you please explain why was it happend ?
> 
> Thanks,
> Deepak
> 
> 
> __________________________________
> Do you Yahoo!?
> Yahoo! SiteBuilder - Free, easy-to-use web site design 
> software http://sitebuilder.yahoo.com
> 

Date: Fri, 15 Aug 2003 20:10:16 -0700
From: [email-masked] (Julien Pierre)
Subject: Re: Re (subtopic): certificate issuance and trust
To: "Steve Hole" <[email-masked]>
cc: [email-masked]
Organization: Netscape
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms010704000904080802040505
Content-Type: TEXT/PLAIN; CHARSET=us-ascii

Steve,

Steve Hole wrote on 08/15/2003, 12:48:

 >
 > I broke the reply into to parts because they really are quite separate
 > issues.   This topic deals primarily with the issuance of certificates
 > and
 > trust management in deployed S/MIME clients.   I debated taking it
 > offline, but I think that it is useful discussion from a usage point of
 > view.   It has little technical merit on a primarily technical forum, but
 > it has overall import for S/MIME -- I hope :-)

I would also have taken most of the discussion offline already due to 
the direction it is going if there hadn't been many people expressing 
their interest in the topics.

 > I see that we need to talk a bit about the usage models that are evolving
 > on the Internet. There are at least two with variations:
 >
 > 1.  Interpersonal secure mail.   This is Mom exchanging secure email with
 > Aunt Jane on the other side of the country.
 >
 > 2.  Organizational communications.   This is the business to consumer or
 > organization to partipant communications (ie. my bank wanting to send me
 > statements and me wanting to complain to my bank).
 >
 > <apology>
 > Because I am so focused on usage model 2 these days I tend to forget
 > about
 > usage model 1.   My apologies.   Conversely, I suspect that very little
 > thought has gone into usage model 2 as it is an entirely new thing for
 > business to be doing on the Internet.
 > </apology>

No need to apologize. Likewise I focused mostly on the first usage due 
to the fact that I work for an ISP. However I believe the two uses very 
often intersect. Consumers want to make secure electronic communications 
with businesses (I know I do), which they can't do by e-mail today. 
S/MIME certification allows both.

 > So what?   Your assertions and the priority you assign them are spot on
 > for usage model 1.   I would still add both cost and complexity of
 > certification to this model.   For Mom to sign up to get a cert is
 > actually pretty daunting from a user interface point of view.   We and
 > our
 > customers have done lots of user tests and it is a problem.

The complexity was my third one on the list - how S/MIME is difficult to 
use . That included the enrollment process.  I completely agree it is 
very daunting. Actually I have gotten my mother running on S/MIME so I 
know what you are talking about when you mention complexity of 
enrollment. I got her running with Thawte and it was quite long to 
enroll. But there is no reason that it has to be that way - it entirely 
depends on the CA.

 > My assertion that cost is a big deal is very applicable to usage model 2.
 > In this case organizations want to certify their consumers for secure
 > document receipt and (possibly) reply.   Outbound is fairly easy -- just
 > issue an encryption only cert to the user on enrollment.   No trust
 > issues
 > and it is reasonably easy to get to the user's desktop.   The problem
 > comes when you want bidirectional communication and are therefore issuing
 > signing certs.   The cost of doing this for millions of customers is so
 > high using the existing certification model (because of root trust
 > requirements) that to use S/MIME becomes impractical or forces
 > alternative
 > solutions.

I'm not sure I understand why the trust is less of a problem for 
encryption certs than signing certs.
If you want to receive encrypted communications, you need to create an 
encryption key and cert. And you need to make the other party aware of 
it. Typically in S/MIME today this transfer of the public encryption 
cert is done by ... signing an e-mail. Which requires you to have a 
signing cert...
Otherwise the user could also publish the encryption cert to LDAP.
Still there would need to be some authentication at that time.

 > There are a series of companies that provide "e-mail encryption" using
 > proprietary formats and Javascript symetric decryptors that completely
 > bypass S/MIME altogether.   And people buy it!  BIG organizations buy
 > it.
 > It's depressing.   And when talking about S/MIME it has to be concern to
 > this group and people who implement S/MIME clients.

What are the advantages of these pseudo-security products ?

 > Correct.   This means that interpersonal secure email usage is
 > impractical because there is no way to obtain necessary security
 > information for an arbitrary recipient.   This is the original stated
 > problem and we all agree that it is a major, if not the major barrier.
 >
 > I think that we have some good concensus building on that and maybe there
 > are some actions that we can now take to try to resolve the issue.

While we don't have any consensus yet on the technical direction, I 
would certainly be willing to participate in writing a draft that would 
make recommendations on additional ways to distribute S/MIME 
certificates. Of course the actual deployment of a global directory is a 
problem, but perhaps by having this draft written by people involved in 
companies potentially interested in using/running it we will end up 
writing a deployable proposal.

 > > 3) S/MIME is too complex to use
 >
 > S/MIME isn't so complicated (at least our user testing doesn't indicate
 > that).   We get very few usage calls back to customer support.
 >
 > Certification is certainly complicated.   Even the easiest of the
 > commercial (Verisign) CA's are quite daunting to the average user.
 > This is
 > an implementation issue that needs some work.   This accounts for better
 > than 95% of our TOTAL service calls.   Ouch!

Yes, that's what I meant. Enrollment is part of the usage of S/MIME.
I had to sit with my mother last year to get her to sign up, and I 
talked to her at length at international rates for the recent renewal.

 > The only way to solve it (I think) is to have organizations initiate
 > certificate issuance.   That is, ISP's need to offer to do this as
 > part of
 > their enrollment.

Agreed.

 > So it is a question of how do we initiate certification?   More
 > importantly how do we get ISP's (or a proxy third party) to engage users
 > in the certification process.

I wish I had the answer to that one.

 > > The first two issues are related. As more people become aware of
 > > certification and certified, the value of being certified will
 > increase.
 > > I believe the cost of the certification will be much less of an issue
 > > once people realize they are paying for a something useful.
 >
 > No it won't :-)   Will your Mom pay to be certified?   I know for a fact
 > mine won't because I tried to get her to get a Verisign cert and when she
 > found out it was $20, that terminated that conversation quickly :-)

Yes, I know the feeling, I got the same reaction from my family members, 
which is why I got many of them to enroll with the freemail Thawte CA 
instead.

However the service doesn't have to be directly paid for, or all at 
once. It can be bundled by the ISP with her account. Even if it wasn't 
bundled with every account, the one-time $20 might be only a $1.66 
option/month extra, which is the same price, but suddenly doesn't look 
so bad. Especially if that $1.66 buys you more than just the ability to 
communicate with family members, but also with businesses (ie. banks).

 > First of all, this problem really is a usage model 2 issue.   An
 > organization wants to certify a very large number of users.  It really
 > doesn't apply to usage model 1, for which most of the existing S/MIME
 > clients are targeted.

Still, a corporate organization can run its own CA which doesn't have to 
be a root CA.

 > All of the above is correct.   I'm saying two things:
 >
 > 1.  It would be very nice if there is some way that the trust domain
 > could
 > be removed from client configuration to a centralized service.   This is
 > simply good engineering and allows for dynamic control over what is
 > trusted and what is not.

I think it cannot ever entirely be removed from the client, because you 
need to start with some trust, but it could be aggregated.
Before this can be dynamically controlled however, the very notion of 
what a trust domain is needs to be defined and standardized. Then we can 
define means to transfer it, through existing protocols hopefully.

 > 2.  Modifying desktop settings to support security policy and certificate
 > issuance is a non-starter for usage model 2.   It's the old adage --
 > people want security but they don't want to have to do anything to get
 > it.
 >
 > I'll give you an example that might help.   If My Huge Bank wanted to
 > issue certificates to their users to establish a secure email
 > community of
 > trust, then they have two choices: acquire certificates from one of the
 > CA's that is already in the "trusted root" category or try to issue
 > self-signed certificates and become a trusted root.  Cost is a big
 > barrier
 > in the first option.   Deployment complexity (and some cost) is a barrier
 > for option 2.   Because a new root certificate has to be downloaded to
 > every desktop you've got a deployment latency problem.   Because it costs
 > (in some non-insubstantial set of S/MIME implementations) to get a
 > registered root certificate, the costs of this are not insubstantial
 > either.
 >
 > If the cost that an organization like My Huge Bank will bear to roll
 > out a
 > new service is $1M - $500K you can see that the cost of deployment for an
 > S/MIME solution is severly compromised by the costs of certification.
 > Companies and solutions like Tumbleweed exist that provide
 > alternatives to
 > S/MIME simply because of this fact.

My huge bank doesn't have to run a root, my huge bank can run a CA and 
get it signed by one of the root CAs. Then it doesn't need to deploy a 
root to every desktop.

If it insists on running a root, there is going to be at least one 
config change to make it happen. Right now I think it is as simple as 
clicking on a URL and accepting a dialog. I don't know how much simpler 
one can make it.

Yes, a means to distribute the trust domain (see above) would help, but 
one would still need to configure the software to use the distribution 
channel - whatever it would be (HTTP, LDAP ...). I don't see how this 
would be simpler than the click and confirmation of the dialog.
The only advantage is that you might only need to enable that trust 
domain service once, and several organizations could publish their root 
to it. You could imagine for example a consortium of financial 
institutions ... Of course the consortium could just have one root and 
bear its cost, and issue one CA for each institution.
FYI, I believe Microsoft might already update roots when you do a 
windows update, but of course that's a proprietary solution, and you 
still have the upfront cost of getting certified when you create your root.

 > > The price figure you cite is absurdly low. Do you really, seriously
 > > think $250,000 to enable secure services matters much to a company with
 > > 25 million customers ? Certainly it wouldn't matter much to a bank,
 > > especially since it would probably reduce certain mailing costs. I'd
 > > guess that even one bulk USPS communication is going to cost more
 > than 1
 > > cent per recipient. I only know one ISP with 25 million customers or
 > > more, and I happen to work for it, but I'm not at liberty to comment
 > > further on the costs.
 >
 > First of all, $0.01 per cert for 25M customers is $2.5M annually.

No, it is $250,000 .

 > You need to go have a look at who I work for :-)

The name doesn't ring a bell, but I will check.

 > The example that I give above is by far the rule.   The costs that even a
 > large bank with 25M consumers will bear for *any* Internet application is
 > quite low at this point.

First class stamps are up to 37 cents last time I checked. I don't know 
what the bulk rate is, but using your (unrealistic) proposed cost of 1 
cert per cert, the investment would pay for itself at the first paper 
communication saved even if only 3 percent of the bank customers ever 
used their cert. Of course, it's up to the banks to decide what's 
beneficial to them, but if something is going to save them so much 
money, the bank has responsibility to their shareholders to look into 
it. I don't have any more to add on this topic.

 >   Most of that has to do with the series of
 > disappointing Internet applications and middleware that were invested in
 > over the years has seriously damaged their trust in real return on
 > investment in Internet applications.

Someone has to do it right first. Competitors will follow. Same thing 
happened with online account access - not everybody offered SSL. Lots of 
banks erred in offering proprietary software solutions for a while. It 
sorted itself out. We are just at an earlier stage in the process.

 > However, it is important to note that the cost of running a your own CA
 > today is largely a matter of the licensing costs of running the CA
 > software.   There are operational costs, but those costs can and
 > should be
 > part of the cost of operating the application the uses S/MIME.   We do
 > NOT
 > charge for certificate issuance in our product.   We charge for documents
 > delivered. There is a direct and easy comparison for any usage model 2
 > document issuer to compare the cost of paper mail to secure email.
 > If we
 > had the ability to "Register" a self certifying organization root
 > certificate in one place (not one for every desktop client) that would be
 > a huge step forward.

Even if that service existed, it would still need some kind of client 
configuration to point to that one place.

-- 
I am the dog in dogfood

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

--------------ms010704000904080802040505--

Date: Fri, 15 Aug 2003 17:37:10 -0700
From: [email-masked] (Julien Pierre)
Subject: Re: dissemination of public encryption certificates
To: "Anders Rundgren" <[email-masked]>
cc: [email-masked]
Organization: Netscape
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms010704000904080802040505
Content-Type: TEXT/PLAIN; CHARSET=us-ascii

Anders,

Anders Rundgren wrote on 08/15/2003, 0:06:

 > May I add some naive thought to the table?
 >
 > That the issuer is of great importance for signatures and authentication
 > purposes is undoubtedly true.
 >
 > But I cannot really say that I see the same need for TPP-issued
 > encryption
 > certificates.  Is there even a need for encryption-certificates?  It
 > seems sufficient
 > that users in their e-mail client create key-pairs and publish the public
 > key in the associated domain.  If you trust the lookup service like XKMS
 > why should this not be enough?

Certificates establish a permanent, traceable link between the user's 
identity and the public key.

If I correctly understand what you propose, the XKMS service would 
provide a temporary link between the user's identity and the the public key.

One reason this link isn't enough is revocation. If the key gets 
compromised at some point, how do you indicate at a later time not to 
trust that key anymore ? And how do you do it retroactively ?

Correct me if I'm wrong, but most revocation systems today are based on 
CRLs rather than KRLs. The government was the only user of KRLs but even 
they are using CRLs now. Most software as a result primarily supports 
certificate-based revocation, not key-based revocation.

 > Well you could actually create a
 > self-signed
 > certificate in your mail client and send a signed message (using
 > a trusted signer cert/key) containg the generated encryption key or
 > cert to
 > encryptionregistry@yourdomain to get it automatically published.
 > No apparent need for CAs and associated root and path validation
 > for encryption certificates.

It should be a policy of the repository however to decide whether or not 
to apply path validations for certificates it stores. Certainly one 
could decide not to do any validation if they so chose.
However eventually, when an end user does a query, they most likely 
won't trust that self-signed certificate due to their trust domain 
configuration. So it would not be in the interest of the repository to 
have too lax of a policy on cert issuers.

 > XKMS introduces an optional trust-anchor itself but that would not
 > work (scale)with encryption certificates for a global Internet.  So no
 > matter what you do, there will be lose ends on all lookup solutions.
 > Only the hard transfer-the-globally-recognized-TTP-certificate-out-
 > band will be "fully secure" and we already know that this does not
 > support the more dynamic scenarious we are currently discussing.

It can work if there is a set of well-known accepted trusted roots. I 
don't think every single random root should be automatically trusted. 
What's missing is a way to easily replicate the trust domain - ie. let 
the repositories dynamically add roots once a new CA goes in business 
and gains acceptance.

 > For enterprise usage I doubt that end-to-end encryption is of much value
 > as lost keys create too much hassles.  Most business systems are likely
 > to rather use HTTPS which is easier to handle than S/MIME encryption.

HTTPS and S/MIME have different uses and benefits. If you sign a 
contract over HTTPS there is no persistent proof, whereas there is with 
S/MIME.

The problem of lost encryption keys for enterprises is already solved 
with key escrow. All the necessary mechanisms are already in place 
today. Most businesses want to be able to access their employees' 
communications anyway, so there is another reason that they use key 
escrow for encryption keys. Signing keys are of course a different 
matter and should not be escrowed.

-- 
I am the dog in dogfood

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

--------------ms010704000904080802040505--

From: "Blake Ramsdell" <[email-masked]>
To: "'Steve Hole'" <[email-masked]>, "'Simon Josefsson'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: PKI and S/MIME
Date: Fri, 15 Aug 2003 16:09:16 -0700
Importance: Normal
Sender: [email-masked]

> [mailto:[email-masked]] On Behalf Of Steve Hole
> Sent: Friday, August 15, 2003 9:50 AM
> To: Simon Josefsson
> Cc: [email-masked]
> Subject: Re: PKI and S/MIME
> 
> On Fri, 15 Aug 2003 01:41:22 +0200 Simon Josefsson 
> <[email-masked]> wrote:
> 
> > But this isn't an important point, and I don't see anything that can
> > be seen as a _disadvantage_ for DNS compared to LDAP or XKMS here.
> > Perhaps this tangental issue only distract us from the big picture.
> 
> Agreed.   I think that the provision of a simple-to-use API 
> would be a 
> huge help here.

I thought I published this at one point, though it might have been
internal only.  I'll use a somewhat Java-ish syntax here.

EncryptingInformation
findInformationRequiredForEncryptingForEmailAddress(
    String emailAddress
    );

boolean
isCertificateSuitableForSigningEmail(
    String emailAddress,
    X509Certificate signingCertificate,
    X509CertificateList otherCertificates,
    CRLList cRLs
    );

EncryptingInformation contains:

1. Any cached SMIMECapabilities

2. An X.509 certificate for encrypting

OK, now we just fill in the details ;).

Blake

From: Steve Hole <[email-masked]>
Date: Fri, 15 Aug 2003 12:48:59 -0700
To: Julien Pierre <[email-masked]>
Subject: Re (subtopic): certificate issuance and trust
Cc: [email-masked]
Sender: [email-masked]

I broke the reply into to parts because they really are quite separate 
issues.   This topic deals primarily with the issuance of certificates and
trust management in deployed S/MIME clients.   I debated taking it 
offline, but I think that it is useful discussion from a usage point of 
view.   It has little technical merit on a primarily technical forum, but 
it has overall import for S/MIME -- I hope :-)

On Thu, 14 Aug 2003 19:58:11 -0700 Julien Pierre <[email-masked]> 
wrote:

> I think you have it backwards, cost of certification is way down on the 
> list of obstacles to mass deployment of S/MIME right now. Let me mention 
> some other important barriers  :
> 
> 1) the general public is completely unaware that certification even 
> exists. I think this is the #1 issue by far.
> Many companies have been trying to raise awareness for PKI, but none 
> have succeeded in getting the masses to adopt it yet.
> 
> 2) the value of certification is low today because there are so few 
> certified users, and encryption only works between certified people. 
> This is like being one of the first one to have a telephone.

OK.  Before I go on, I will state that I agree with both of these 
assertions on an individual basis.   The issue is really how many of these
things work in combination to stall or make S/MIME usage difficult.

I see that we need to talk a bit about the usage models that are evolving 
on the Internet. There are at least two with variations:

1.  Interpersonal secure mail.   This is Mom exchanging secure email with 
Aunt Jane on the other side of the country.

2.  Organizational communications.   This is the business to consumer or 
organization to partipant communications (ie. my bank wanting to send me 
statements and me wanting to complain to my bank).

<apology>
Because I am so focused on usage model 2 these days I tend to forget about
usage model 1.   My apologies.   Conversely, I suspect that very little 
thought has gone into usage model 2 as it is an entirely new thing for 
business to be doing on the Internet.
</apology>

So what?   Your assertions and the priority you assign them are spot on 
for usage model 1.   I would still add both cost and complexity of 
certification to this model.   For Mom to sign up to get a cert is 
actually pretty daunting from a user interface point of view.   We and our
customers have done lots of user tests and it is a problem. 

My assertion that cost is a big deal is very applicable to usage model 2. 
In this case organizations want to certify their consumers for secure 
document receipt and (possibly) reply.   Outbound is fairly easy -- just 
issue an encryption only cert to the user on enrollment.   No trust issues
and it is reasonably easy to get to the user's desktop.   The problem 
comes when you want bidirectional communication and are therefore issuing 
signing certs.   The cost of doing this for millions of customers is so 
high using the existing certification model (because of root trust 
requirements) that to use S/MIME becomes impractical or forces alternative 
solutions.

There are a series of companies that provide "e-mail encryption" using 
proprietary formats and Javascript symetric decryptors that completely 
bypass S/MIME altogether.   And people buy it!  BIG organizations buy it.  
It's depressing.   And when talking about S/MIME it has to be concern to 
this group and people who implement S/MIME clients.
 
> (Even worse than that, without even having a directory in existence to 
> find out who else you could communicate with - this is the problem at 
> stake).

Correct.   This means that interpersonal secure email usage is 
impractical because there is no way to obtain necessary security 
information for an arbitrary recipient.   This is the original stated 
problem and we all agree that it is a major, if not the major barrier.

I think that we have some good concensus building on that and maybe there 
are some actions that we can now take to try to resolve the issue. 
 
> 3) S/MIME is too complex to use

S/MIME isn't so complicated (at least our user testing doesn't indicate 
that).   We get very few usage calls back to customer support.   

Certification is certainly complicated.   Even the easiest of the 
commercial (Verisign) CA's are quite daunting to the average user. This is
an implementation issue that needs some work.   This accounts for better 
than 95% of our TOTAL service calls.   Ouch!
 
> I don't believe the first issue can be solved by any specifications or 
> talk in this group, but several companies will continue to work on it. 
> Hopefully they will succeed.

The only way to solve it (I think) is to have organizations initiate 
certificate issuance.   That is, ISP's need to offer to do this as part of 
their enrollment.   

Certificate awareness is very high in my usage model 2 because either Joe 
Customer wants to get e-documents from Sam Business or Sam Business wants 
Joe Customer to get e-documents.   Either way, there is explicit 
communication that initiates certification (in all the various ways that 
can be done).

So it is a question of how do we initiate certification?   More 
importantly how do we get ISP's (or a proxy third party) to engage users 
in the certification process. 
 
> The first two issues are related. As more people become aware of 
> certification and certified, the value of being certified will increase. 
> I believe the cost of the certification will be much less of an issue 
> once people realize they are paying for a something useful.

No it won't :-)   Will your Mom pay to be certified?   I know for a fact 
mine won't because I tried to get her to get a Verisign cert and when she 
found out it was $20, that terminated that conversation quickly :-)

It will improve yes, but you won't get anywhere near universal uptake.
 
 ... some stuff skipped ...
 
> Yes, vendors have to ship a certain set of roots. We can't just 
> automagically trust every self-signed root there is. We ship with about 
> a hundred roots already though. It is true Netscape has charged in the 
> past for including it. Microsoft requests that your root goes through an 
> independent certification process. Either way, the process costs a lot 
> of money.
> 
> You aren't limited to using the roots that are shipped.
> You can add your own roots if you want to trust it. All it takes is a 
> couple of clicks in the client application.
> If you don't like your users having to click, you can pull a Mozilla 
> source tree, and add your very own root certificates and mark them 
> trusted if you like. It is a simple process and I'll be happy to show 
> anyone how to do it, as I have been the one checking in the roots to the 
> official tree. Any ISP could do it. Any CA could do it. Any corporation 
> could do that.

You are right.   I knew when I was writing that part that I was going to 
get into trouble :-).

First of all, this problem really is a usage model 2 issue.   An 
organization wants to certify a very large number of users.  It really 
doesn't apply to usage model 1, for which most of the existing S/MIME 
clients are targeted.

> All the client vendors do is provide a default trust domain, which is a 
> list of well-known root certificates with trust settings. What do you 
> want them to do ? Ship with no roots at all ? Automatically trust every 
> single self-signed root under the sun ?
> 
> The default trust domain that ships with client software is not static. 
> Like any other software setting, it can be configured. Any user is free 
> to add another root and mark it trusted.
> If the trust domain was static then you would have a point, but as I see 
> it, you miss the point.

All of the above is correct.   I'm saying two things:

1.  It would be very nice if there is some way that the trust domain could
be removed from client configuration to a centralized service.   This is 
simply good engineering and allows for dynamic control over what is 
trusted and what is not.

2.  Modifying desktop settings to support security policy and certificate 
issuance is a non-starter for usage model 2.   It's the old adage -- 
people want security but they don't want to have to do anything to get it. 

I'll give you an example that might help.   If My Huge Bank wanted to 
issue certificates to their users to establish a secure email community of
trust, then they have two choices: acquire certificates from one of the 
CA's that is already in the "trusted root" category or try to issue 
self-signed certificates and become a trusted root.  Cost is a big barrier
in the first option.   Deployment complexity (and some cost) is a barrier 
for option 2.   Because a new root certificate has to be downloaded to 
every desktop you've got a deployment latency problem.   Because it costs 
(in some non-insubstantial set of S/MIME implementations) to get a 
registered root certificate, the costs of this are not insubstantial 
either.

If the cost that an organization like My Huge Bank will bear to roll out a
new service is $1M - $500K you can see that the cost of deployment for an 
S/MIME solution is severly compromised by the costs of certification.   
Companies and solutions like Tumbleweed exist that provide alternatives to
S/MIME simply because of this fact.

If we could arrange things to avoid the cost and provide zero deployment 
latency, that would greatly enhance usage model 2 scenarios and make life 
difficult for non-standard email security solutions.
 
> The price figure you cite is absurdly low. Do you really, seriously 
> think $250,000 to enable secure services matters much to a company with 
> 25 million customers ? Certainly it wouldn't matter much to a bank, 
> especially since it would probably reduce certain mailing costs. I'd 
> guess that even one bulk USPS communication is going to cost more than 1 
> cent per recipient. I only know one ISP with 25 million customers or 
> more, and I happen to work for it, but I'm not at liberty to comment 
> further on the costs.

First of all, $0.01 per cert for 25M customers is $2.5M annually. 

You need to go have a look at who I work for :-)

The example that I give above is by far the rule.   The costs that even a 
large bank with 25M consumers will bear for *any* Internet application is 
quite low at this point.   Most of that has to do with the series of 
disappointing Internet applications and middleware that were invested in 
over the years has seriously damaged their trust in real return on 
investment in Internet applications.

The *only* reason that we can sell secure document delivery systems to our
customers with S/MIME based security is that we do one-way encryption only
solutions which obviates the need for signing certs and trust.   Even with
that, many of our customers find the simple certification issuance that we
do (two dialogs and a single page turn) too much and want to use password 
based encryption instead.   We have been forced to write an S/MIME viewer 
application that supports the S/MIME shared secret profile because very 
few of the shipping clients support it yet.
 
> The bottom line is, running a CA is a service, and it costs money, 
> probably far, far more than $0.01 per cert per year. Whether an ISP runs 
> it itself or outsources it, the service is going to cost some money 
> somewhere
> 
> Anyway, I think we are getting quite off-topic here. If people want to 
> run a loss-leader cert service they are welcome to do so, just as 
> Thawte/Verisign does. I don't know how much relevance this has to the 
> mailing list. Or do you want to codify the prices of certificates into 
> the RFCs  ?

Agreed, we can take the remainder of this conversation off line.  

However, it is important to note that the cost of running a your own CA 
today is largely a matter of the licensing costs of running the CA 
software.   There are operational costs, but those costs can and should be
part of the cost of operating the application the uses S/MIME.   We do NOT
charge for certificate issuance in our product.   We charge for documents 
delivered. There is a direct and easy comparison for any usage model 2 
document issuer to compare the cost of paper mail to secure email.   If we
had the ability to "Register" a self certifying organization root 
certificate in one place (not one for every desktop client) that would be 
a huge step forward.

Cheers.

---
Steve Hole
Chief Technology Officer - Billing and Payment Systems
ACI Worldwide
<mailto:[email-masked]>
Phone: 780-424-4922

From: "Bonatti, Chris" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Update of CMS-X.400 Drafts
Date: Fri, 15 Aug 2003 14:15:03 -0400
Organization: IECA, Inc.
Importance: Normal
Sender: [email-masked]

Francois,

Chris

-----Original Message-----

Hi Chris,

Cheers,

Francois

-----Original Message-----
From: Bonatti, Chris [mailto:[email-masked]]
Sent: Saturday, August 09, 2003 11:32 AM
To: [email-masked]
Subject: Update of CMS-X.400 Drafts

Cheers!
Chris

Done.

Done.

Done.

Done.

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-To: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-x400wrap-09.txt
Date: Fri, 15 Aug 2003 12:51:08 -0400
Sender: [email-masked]

--MIMEStream=_0+47629_214518835125604_0543265711

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		: Securing X.400 Content with S/MIME
	Author(s)	: P. Hoffman, C. Bonatti, A. Eggen
	Filename	: draft-ietf-smime-x400wrap-09.txt
	Pages		: 11
	Date		: 2003-8-15
	
This document describes a protocol for adding cryptographic signature
and encryption services to X.400 content.

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

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

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

--MIMEStream=_0+47629_214518835125604_0543265711
Content-Type: Multipart/Alternative; boundary="MIMEStream=_1+254605_0977245551210_29285560305"

--MIMEStream=_1+254605_0977245551210_29285560305
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-x400wrap-09.txt

--MIMEStream=_1+254605_0977245551210_29285560305
Content-Type: Message/External-body; name="draft-ietf-smime-x400wrap-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts"

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

--MIMEStream=_1+254605_0977245551210_29285560305--
--MIMEStream=_0+47629_214518835125604_0543265711--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-x400wrap-09.txt
Date: Fri, 15 Aug 2003 12:51:08 -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		: Securing X.400 Content with S/MIME
	Author(s)	: P. Hoffman, C. Bonatti, A. Eggen
	Filename	: draft-ietf-smime-x400wrap-09.txt
	Pages		: 11
	Date		: 2003-8-15
	
This document describes a protocol for adding cryptographic signature
and encryption services to X.400 content.

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

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

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

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

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

--OtherAccess--

--NextPart--

From: Steve Hole <[email-masked]>
Date: Fri, 15 Aug 2003 10:30:11 -0700
To: Julien Pierre <[email-masked]>
Subject: Re (subtopic):  LDAP certificate distribution
Cc: [email-masked]
Sender: [email-masked]

On Thu, 14 Aug 2003 19:58:11 -0700 Julien Pierre <[email-masked]> 
wrote:

> Why ?

Because you have to run a root.  That is, the hierarchy has to have a top 
level interconnect.   This quickly becomes an issue of governance.   
National goverments get involved the way they got involved in DNS.   The 
difference is that the governments got involved *before* the service was 
running, not after the way they did with DNS.

There is a long track record of attempts at establishing global X.500 
whitepages services.   There were several attempts that I participated in 
that just didn't gain traction.  I think in retrospect it was primarily a 
cost issue again.   The *business* people and organizations who had 
interest in participating couldn't stomach a "build it an they will come" 
approach when there were real costs and somewhat amorphous benefits.   
People just don't get why you need it and the formal delegation and 
governance rules made it non-trivial to set up.

Note that I said "Whitepages".   Regrettably, PKI information at the 
global level was always linked to other personal information that would 
aid in the search and retrieval of useful information on people.   This 
was a goal that I happily promoted and thought "was a great idea".   
Wrong.   What I (and many others) never thought about was the privacy 
concerns.   Sure the system is secure and access controlled etc etc.  But,
the governance issues around actually making this information available on
the Internet was really huge.   By the time some of this was figured out, 
the perception had become that none of it was truly deployable.   Very few
commercial organizations (government doesn't count) wanted that 
information available and didn't believe that secure interpersonal email 
(the one obvious use application) needed that level of support.

There were some not insubstantial technical hurdles with root management 
and scaling as well.   Problems that probably could have been (and were 
for the most part) solved, but took long enough to solve that 
people just didn't believe.   Basically, there was enough disinterest that 
the whole thing just stagnated.

Finally, the one thing that could have driven the service -- storage of 
keys -- was itself a substantial cost item because of the cost of 
certification.   While certification costs have dropped, in the beginning 
they were excruciating and only the richest could play.  Therefore, there 
never was a groundswell of use that demanded that the "situation be 
improved".   You need a Web like uptake to get the necessary 
infrastructure allocated and serviced.

In short there was always a substantial cost.   My experience with the 
Internet is that the only things that successfully deploy to Internet 
scale are things that start with the groundswell of the common user.  It 
has to be easy and it has to be (near) free.

>  > There is only one choice -- DNS.   I (and Steve Kille and others) have
>  > been flogging LDAP directories and working on LDAP/X.500 interconnects
>  > for
>  > a decade.   Global X.500/LDAP isn't going to happen in our lifetime.
> 
> Can you summarize why ?

Pretty much did above :-)

For what it's worth, I am NOT saying "LDAP is useless".  What I'm saying 
is that you need to leverage the one and only global directory service the 
Internet is ever likely to successfully deploy to get to your LDAP (or 
XKMS) services.   Then we avoid the governance, root and cost issues 
associated with global directory whitepages.

>  > Precisely.   They must be able to do a DNS lookup for the information
>  > either as a direct data return or a reference to a secondary storage
>  > service, which absolutely could and probably should be LDAP.   To
>  > work in practice I think that it should be possible to get a direct pull
>  > from the DNS so that organizations are not required to deploy an LDAP
>  > directory and all that goes along with it (much as that pains me).
> 
> I think other people have pointed out that DNS itself is not suited as 
> the repository for the certificates.
> Since the query starts with only the e-mail address, which contains a 
> userid and domain, I think it is appropriate to start the lookup in the 
> DNS. There should be a standard schema to get to the appropriate LDAP 
> server from the user's e-mail domain. The certificate would then be 
> looked up from it. The client application could also fall back to a 
> "default" LDAP server if the DNS query fails to find the appropriate 
> directory.

Works for me.   More LDAP servers sold then :-)

>  > The worst that can happen is that don't find the cert your looking for.
>  > Trust issues MUST be dealt with, but certificate trust chains and
>  > approaches are both well understood.
>  >
>  > The best that can happen is that suddenly I can go and find a cert for
>  > [email-masked] with a simple DNS query.  BEAUTIFUL!   Why wouldn't I want
>  > to do that?
> 
> Sounds good, but we have to make sure this is deployable for a lot of 
> people. I don't really see how it would be.
> 
> If LDAP is used to store the certs, perhaps all a domain owner might 
> have to do would be do add an entry in the DNS, either with a new record 
> type, or even simpler for quicker deployment, a standard name, eg 
> pki-public-ldap . This entry could be pointed to some free public 
> directory if the ISP doesn't want to run it itself.

I think we are in agreement.   That was easy :-)

As noted in other messages the practical hurdles for deployment center on 
management (key issuer) and client (user).  Unless something is specified 
there is no hope of even getting to those hurdles though.

Cheers.

---
Steve Hole
Chief Technology Officer - Billing and Payment Systems
ACI Worldwide
<mailto:[email-masked]>
Phone: 780-424-4922

From: Steve Hole <[email-masked]>
Date: Fri, 15 Aug 2003 09:50:02 -0700
To: Simon Josefsson <[email-masked]>
Subject: Re: PKI and S/MIME
Cc: [email-masked]
Sender: [email-masked]

On Fri, 15 Aug 2003 01:41:22 +0200 Simon Josefsson <[email-masked]> wrote:

> But this isn't an important point, and I don't see anything that can
> be seen as a _disadvantage_ for DNS compared to LDAP or XKMS here.
> Perhaps this tangental issue only distract us from the big picture.

Agreed.   I think that the provision of a simple-to-use API would be a 
huge help here.

Cheers.
---
Steve Hole
Chief Technology Officer - Billing and Payment Systems
ACI Worldwide
<mailto:[email-masked]>
Phone: 780-424-4922

From: "Anders Rundgren" <[email-masked]>
To: "Julien Pierre" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: dissemination of public encryption certificates
Date: Fri, 15 Aug 2003 09:06:50 +0200
Sender: [email-masked]

May I add some naive thought to the table?

That the issuer is of great importance for signatures and authentication
purposes is undoubtedly true.

But I cannot really say that I see the same need for TPP-issued encryption
certificates.  Is there even a need for encryption-certificates?  It seems sufficient
that users in their e-mail client create key-pairs and publish the public
key in the associated domain.  If you trust the lookup service like XKMS
why should this not be enough?  Well you could actually create a self-signed
certificate in your mail client and send a signed message (using
a trusted signer cert/key) containg the generated encryption key or cert to
encryptionregistry@yourdomain to get it automatically published.
No apparent need for CAs and associated root and path validation
for encryption certificates.

XKMS introduces an optional trust-anchor itself but that would not
work (scale)with encryption certificates for a global Internet.  So no
matter what you do, there will be lose ends on all lookup solutions.
Only the hard transfer-the-globally-recognized-TTP-certificate-out-
band will be "fully secure" and we already know that this does not
support the more dynamic scenarious we are currently discussing.

For enterprise usage I doubt that end-to-end encryption is of much value
as lost keys create too much hassles.  Most business systems are likely
to rather use HTTPS which is easier to handle than S/MIME encryption.

Anders

----- Original Message ----- 
From: "Steve Hole" <[email-masked]>
To: "Julien Pierre" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, August 14, 2003 19:30
Subject: Re: dissemination of public encryption certificates

Well, for the first time in a long time my interest is up on this 
list :-).    What a wonderful topic!   General purpose use of 
S/MIME by the masses on the Internet.   Why hasn't it happened and what 
can we do about it.

Before you read on, be assured that it is the large scale use of S/MIME 
that the following diatribe is focused on.

On Wed, 13 Aug 2003 19:29:53 -0700 Julien Pierre <[email-masked]> 
wrote:

> If you send an email today, you can simply sign it and include your 
> certificate in the signature. If you just sign all your mail, then all 
> you always disseminate your certificate. So in what situations does this 
> new MIME extension certificate lookup help ? I suppose this extension 
> would be shorter than a digital signature. However it would also be much 
> less secure.

This highlights one of the key issues.   It is easy enough to exchange 
keys simply by sending a signed message, but there are some significant 
barriers:

1.  What if your encryption key is separate from your signing key.   This 
is not only common but considered good security practice.   How does one 
go about exchanging/discovering the encryption key for the new party you 
want to exchange mail with.

2.  Timeliness of the key exchange.   The problem with mutual signing 
exchange is that the other person has to respond to you.  What if you just
want to send them an encrypted load right off the start.   You can't 
really do it.

The solution is (and always has been) to do a lookup.  The problem is that
there is no directory to look up from.   Global X.500/LDAP directories are 
*never* going to happen.

There is only one choice -- DNS.   I (and Steve Kille and others) have 
been flogging LDAP directories and working on LDAP/X.500 interconnects for
a decade.   Global X.500/LDAP isn't going to happen in our lifetime.

> The case I originally asked about is :
> neither party has exchanged any e-mail yet, but they know each other's 
> e-mail address. They want to communicate securely. How do they avoid or 
> bypass the initial insecure e-mail exchange ?

Precisely.   They must be able to do a DNS lookup for the information 
either as a direct data return or a reference to a secondary storage 
service, which absolutely could and probably should be LDAP.   To 
work in practice I think that it should be possible to get a direct pull 
from the DNS so that organizations are not required to deploy an LDAP 
directory and all that goes along with it (much as that pains me).
 
>  > In summary I think that a certificate-independent configuration
>  > of e-mail clients would be more universal than "fishing" in
>  > domains as the user domain and issuer domain may be entirely
>  > disjunct.
> 
> "Fishing" in domains as you say would be independent of e-mail client 
> configuration for the most part (it could just be turned on or off).

Actually, I think that "fishing" is an entirely appropriate thing to do.  
The worst that can happen is that don't find the cert your looking for.   
Trust issues MUST be dealt with, but certificate trust chains and 
approaches are both well understood. 

The best that can happen is that suddenly I can go and find a cert for 
[email-masked] with a simple DNS query.  BEAUTIFUL!   Why wouldn't I want 
to do that?

This does lead very nicely into my second (and quite separate) issue in 
this area -- the "trusted ROOT certificate".   Julien has provided superp 
leading commentary here.
  
> You correctly point out that in most cases the user's domain and cert 
> issuer domain are disjoint. This is especially true of e-mail users 
> whose ISP isn't a CA (99.9% of them right now). 

Exactly.   Why?   Because it costs TOO MUCH.   The only acceptable cost 
for most ISP's is zero because of the volume of users.   Cost of 
certification is, pure and simple, the primary barrier to the general use 
and deployment of S/MIME on the Internet.

The reason for the cost is that the mechanism for establishing root trust 
is determined solely by the set of ROOT certificates distributed by the 
client vendor -- of all things!.   Thus only those organizations that can 
afford to pay the client vendor -- of all things! -- to be included in 
their "special trusted root certificate club" get to have "trust".   Which 
means that you MUST buy certs from one of the club members.  Doesn't THAT 
just suck.   Nice business if you can get it.

<qualification>
Yes I know about free thawte certs.   I know that any root issuer must be 
secure and provide good protection from having roots keys compromised etc. 
I agree that anyone who issues certificates should be required to be 
secure. I understand that there is risk to the client vendor if they 
report trust in a cert that has been compromised at the root.

Regardless, to have this power rest in the hands of the client vendor is 
ludicrous.   Why should I trust that Microsoft can evaluate the security 
and trustworthiness of "Joe's CA Service" to be a valid issuer.   I'm not 
saying they are unqualified to do so, but I'm a lot more likely to trust a
self signed "Bank of America" certificate issued on it's own behalf and 
obtained from a reliable source, than I am a third party software vendor 
or CA Verisign (not that there's anything wrong with either Microsoft or 
Verisign :-).
</qualification>

The issue comes down to trust brokering.   I just don't think that it is 
working for the *general* mass consumer Internet.   It clearly does work 
for closed communities within the Internet, but it isn't scaling.   
Period.  If we want generalized S/MIME usage throughout the Internet we 
need to think of some mechanism that is:

1.  Easy to deploy.   The track record for the Internet stongly indicates 
that this means that there are freeware versions of software that will 
support the deployment.   This includes both the key management and 
publication software and the usage (client) software. 

2.  Free.   Those who "own" the vast majoritiy of the user population on 
the Internet are ISP's.   They have almost no margin and simply cannot 
afford to pay for certification.  Also (and more importantly IMHO) is the 
desired for businesses to touch their customers.   These are HUGE volume 
relationships in which there are virtually no economically viable ways of
establishing bidirectional trust.   A cert price of $0.01 a year is too 
much if your customer population is 25 million people (banks, utilities, 
etc.)

Why could we not have organizations issue certificates distributed via 
DNS, with a trust relationship provided by DNS-SEC?  That is, you can 
trust that the DNS node your are dealing with is legitimate because they 
have deployed DNS-SEC (which everyone should do anyway for a host of other
security reasons) and the keys that are located within the DNS hierachy 
are legitimate.

I can then lookup certs based on mail address (duh!), where the mail 
domain source is trusted because of DNS-SEC.   This trust relationship 
could be either:

implicit -- the issuer domain location is trusted therefore any keys 
published there are trusted,

explict -- the issuer provides a root signing key which is in turn signed 
by their DNS-SEC key.

There are a number of observations that can be made about this approach:

1.  The security provided by the approach is probably not as strong as the
full commercial CA approach.   I contend "so what".   It's better than 
nothing and Pretty Good (pun intended).  The average user doesn't need 
military grade security.   The average bill issued by the local telephone 
utility doesn't need military grade security.   Think of the vast number 
of paper documents that need only Pretty Good security and trust to be 
useful (292 Trillion a year in the US -- it's my business and I happen to 
know).  All we need is some security to make that paper go away forever.

2.  Some extensions to bind and a new CSP for Windows would get a large 
number people going in a hurry.   Openssl with an HSM card and some 
reasonable security policy has an organization running pretty quickly.

> The only solution for 
> these users is some sort of universal registration service. 

Yup.

> This implies 
> the existence of some sort of free worldwide directory service (LDAP) 
> that would resolve e-mail addresses to certificates ... And clients 
> would need to be (automatically?) configured to do look ups in it.

Well, even though I would love it if it was LDAP, it isn't going to 
happen.   DNS is the only game in town for global directory service.

Cheers.

---
Steve Hole
Chief Technical Officer - Electronic Billing and Payment Systems
ACI Worldwide

Email: [email-masked]
Phone: 780 424 4922

Date: Thu, 14 Aug 2003 20:33:17 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: RE: dissemination of public encryption certificates
Sender: [email-masked]

At 8:05 PM -0700 8/14/03, Julien Pierre wrote:
>It would be highly desirable for one protocol to be designated for the
>purpose of solving these problems, as opposed to having a plethora of
>different solutions and having various client programs use different
>approaches, which would get us back to square one.

We are already at that square.

>I believe this is relevant to the SMIME mailing list, even though
>the choice and design of that protocol may not affect the SMIME message
>format itself, as these are major deployment issues.

I'm not convinced that this WG is the best one for the discussion, 
inasmuch as it is not in our charter and the WG is supposed to wind 
down. On a related note, there may be a new WG starting up to discuss 
how to handle certificate management in IPsec (the IPsec WG has 
failed worse than S/MIME on certificate issues). It might be 
interesting to have a single WG that covers both issues.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Thu, 14 Aug 2003 20:05:04 -0700
From: [email-masked] (Julien Pierre)
Subject: RE: dissemination of public encryption certificates 
To: "Blake Ramsdell" <[email-masked]>
cc: "'Hallam-Baker Phillip'" <[email-masked]>, [email-masked], "'Steve Hole'" <[email-masked]>, [email-masked]
Organization: Netscape
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms010704000904080802040505
Content-Type: TEXT/PLAIN; CHARSET=us-ascii

Blake,

Blake Ramsdell wrote on 08/14/2003, 14:42:
 >
 > Well, I'm not sure I agree.  There are two major questions that
 > constantly need answers in the mind of an S/MIME client.  These are
 > pretty close to what Michael said in his message:
 >
 > 1. Given a particular email address, give me That Which Is Necessary and
 > Sufficient to send encrypted mail to that email address.
 >
 > 2. Given a particular certificate, is it suitable for signing mail that
 > came from a particular email address.  Michael said "what is it good
 > for", which I think is too broad a question.
 >
 > If we're considering protocols that attempt to answer these types of
 > questions, those are the two questions that need to be answered by that
 > protocol (for interpersonal messaging with S/MIME, that is).

Yes. I believe this is relevant to the SMIME mailing list, even though 
the choice and design of that protocol may not affect the SMIME message 
format itself, as these are major deployment issues.

It would be highly desirable for one protocol to be designated for the 
purpose of solving these problems, as opposed to having a plethora of 
different solutions and having various client programs use different 
approaches, which would get us back to square one.

-- 
I am the dog in dogfood

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

--------------ms010704000904080802040505--

Date: Thu, 14 Aug 2003 19:58:11 -0700
From: [email-masked] (Julien Pierre)
Subject: Re: dissemination of public encryption certificates
To: "Steve Hole" <[email-masked]>
cc: [email-masked]
Organization: Netscape
Sender: [email-masked]

Steve,

Steve Hole wrote on 08/14/2003, 10:30:

 > Well, for the first time in a long time my interest is up on this
 > list :-).    What a wonderful topic!   General purpose use of
 > S/MIME by the masses on the Internet.   Why hasn't it happened and what
 > can we do about it.

Yes, that's exactly the problem that prompted my questions. And it's 
coming soon to an AOL mail program near you ... Some of you may have 
heard of this new "AOL Communicator" mail program that was released in 
the last week to the masses. In fact this program already includes 
S/MIME support.
Hopefully, solving this problem doesn't necessitate new specs and 
completely new services and products, but only minor tweaks and 
clarifications of how to use the existing technology.

 > On Wed, 13 Aug 2003 19:29:53 -0700 Julien Pierre <[email-masked]>
 > wrote:
 >
 > This highlights one of the key issues.   It is easy enough to exchange
 > keys simply by sending a signed message, but there are some significant
 > barriers:
 > 1.  What if your encryption key is separate from your signing key.   This
 > is not only common but considered good security practice.   How does one
 > go about exchanging/discovering the encryption key for the new party you
 > want to exchange mail with.

This is supported today in Mozilla mail, Netscape 7.x mail, and AOL 
Communicator.
In fact, in our internal PKI deployment we use different keys for 
encryption and signing. This results in the issuance of two different 
certificates, one for signing and another for encryption.
The digital signature can be configured to include a different 
certificate for encryption. Look at my signature in this message and see 
if you get confused : I signed it with my corporate certificate, but I 
included a recipient Thawte encryption certificate.

 > 2.  Timeliness of the key exchange.   The problem with mutual signing
 > exchange is that the other person has to respond to you.  What if you
 > just
 > want to send them an encrypted load right off the start.   You can't
 > really do it.

That's right, and it's the whole problem I have been asking about. 
Exchanging unencrypted messages first, in my opinion, is not a solution.

 > The solution is (and always has been) to do a lookup.  The problem is
 > that
 > there is no directory to look up from.   Global X.500/LDAP directories
 > are
 > *never* going to happen.

Why ?

 > There is only one choice -- DNS.   I (and Steve Kille and others) have
 > been flogging LDAP directories and working on LDAP/X.500 interconnects
 > for
 > a decade.   Global X.500/LDAP isn't going to happen in our lifetime.

Can you summarize why ?

 > Precisely.   They must be able to do a DNS lookup for the information
 > either as a direct data return or a reference to a secondary storage
 > service, which absolutely could and probably should be LDAP.   To
 > work in practice I think that it should be possible to get a direct pull
 > from the DNS so that organizations are not required to deploy an LDAP
 > directory and all that goes along with it (much as that pains me).

I think other people have pointed out that DNS itself is not suited as 
the repository for the certificates.
Since the query starts with only the e-mail address, which contains a 
userid and domain, I think it is appropriate to start the lookup in the 
DNS. There should be a standard schema to get to the appropriate LDAP 
server from the user's e-mail domain. The certificate would then be 
looked up from it. The client application could also fall back to a 
"default" LDAP server if the DNS query fails to find the appropriate 
directory.

 > > "Fishing" in domains as you say would be independent of e-mail client
 > > configuration for the most part (it could just be turned on or off).
 >
 > Actually, I think that "fishing" is an entirely appropriate thing to do.

I didn't say it wasn't, I just have reservations on how it's done (see 
above).

 > The worst that can happen is that don't find the cert your looking for.
 > Trust issues MUST be dealt with, but certificate trust chains and
 > approaches are both well understood.
 >
 > The best that can happen is that suddenly I can go and find a cert for
 > [email-masked] with a simple DNS query.  BEAUTIFUL!   Why wouldn't I want
 > to do that?

Sounds good, but we have to make sure this is deployable for a lot of 
people. I don't really see how it would be.

If LDAP is used to store the certs, perhaps all a domain owner might 
have to do would be do add an entry in the DNS, either with a new record 
type, or even simpler for quicker deployment, a standard name, eg 
pki-public-ldap . This entry could be pointed to some free public 
directory if the ISP doesn't want to run it itself.

 > This does lead very nicely into my second (and quite separate) issue in
 > this area -- the "trusted ROOT certificate".   Julien has provided superp
 > leading commentary here.
 >
 > > You correctly point out that in most cases the user's domain and cert
 > > issuer domain are disjoint. This is especially true of e-mail users
 > > whose ISP isn't a CA (99.9% of them right now).
 >
 > Exactly.   Why?   Because it costs TOO MUCH.   The only acceptable cost
 > for most ISP's is zero because of the volume of users.   Cost of
 > certification is, pure and simple, the primary barrier to the general use
 > and deployment of S/MIME on the Internet.

I think you have it backwards, cost of certification is way down on the 
list of obstacles to mass deployment of S/MIME right now. Let me mention 
some other important barriers  :

1) the general public is completely unaware that certification even 
exists. I think this is the #1 issue by far.
Many companies have been trying to raise awareness for PKI, but none 
have succeeded in getting the masses to adopt it yet.

2) the value of certification is low today because there are so few 
certified users, and encryption only works between certified people. 
This is like being one of the first one to have a telephone.

(Even worse than that, without even having a directory in existence to 
find out who else you could communicate with - this is the problem at 
stake).

3) S/MIME is too complex to use

I don't believe the first issue can be solved by any specifications or 
talk in this group, but several companies will continue to work on it. 
Hopefully they will succeed.

The first two issues are related. As more people become aware of 
certification and certified, the value of being certified will increase. 
I believe the cost of the certification will be much less of an issue 
once people realize they are paying for a something useful.

IMO, the certificate dissemination issue remains a major obstacle. Even 
if lots of people were certified today, it would still be very hard to 
know who they are and communicate with them.

The complexity of S/MIME usability is also something the group has 
impact on. The specifications heavily impact the implementation and 
usability of S/MIME client software.

 > The reason for the cost is that the mechanism for establishing root trust
 > is determined solely by the set of ROOT certificates distributed by the
 > client vendor -- of all things!.   Thus only those organizations that can
 > afford to pay the client vendor -- of all things! -- to be included in
 > their "special trusted root certificate club" get to have "trust".
 > Which
 > means that you MUST buy certs from one of the club members.  Doesn't THAT
 > just suck.   Nice business if you can get it.

Yes, vendors have to ship a certain set of roots. We can't just 
automagically trust every self-signed root there is. We ship with about 
a hundred roots already though. It is true Netscape has charged in the 
past for including it. Microsoft requests that your root goes through an 
independent certification process. Either way, the process costs a lot 
of money.

You aren't limited to using the roots that are shipped.
You can add your own roots if you want to trust it. All it takes is a 
couple of clicks in the client application.
If you don't like your users having to click, you can pull a Mozilla 
source tree, and add your very own root certificates and mark them 
trusted if you like. It is a simple process and I'll be happy to show 
anyone how to do it, as I have been the one checking in the roots to the 
official tree. Any ISP could do it. Any CA could do it. Any corporation 
could do that.

 > Regardless, to have this power rest in the hands of the client vendor is
 > ludicrous.   Why should I trust that Microsoft can evaluate the security
 > and trustworthiness of "Joe's CA Service" to be a valid issuer.   I'm not
 > saying they are unqualified to do so, but I'm a lot more likely to
 > trust a
 > self signed "Bank of America" certificate issued on it's own behalf and
 > obtained from a reliable source, than I am a third party software vendor
 > or CA Verisign (not that there's anything wrong with either Microsoft or
 > Verisign :-).

All the client vendors do is provide a default trust domain, which is a 
list of well-known root certificates with trust settings. What do you 
want them to do ? Ship with no roots at all ? Automatically trust every 
single self-signed root under the sun ?

The default trust domain that ships with client software is not static. 
Like any other software setting, it can be configured. Any user is free 
to add another root and mark it trusted.
If the trust domain was static then you would have a point, but as I see 
it, you miss the point.

 > Period.  If we want generalized S/MIME usage throughout the Internet we
 > need to think of some mechanism that is:
 >
 > 1.  Easy to deploy.   The track record for the Internet stongly indicates
 > that this means that there are freeware versions of software that will
 > support the deployment.   This includes both the key management and
 > publication software and the usage (client) software.

At least we agree it needs to be easy.

 > 2.  Free.   Those who "own" the vast majoritiy of the user population on
 > the Internet are ISP's.   They have almost no margin and simply cannot
 > afford to pay for certification.  Also (and more importantly IMHO) is the
 > desired for businesses to touch their customers.   These are HUGE volume
 > relationships in which there are virtually no economically viable ways of
 > establishing bidirectional trust.   A cert price of $0.01 a year is too
 > much if your customer population is 25 million people (banks, utilities,
 > etc.)

The price figure you cite is absurdly low. Do you really, seriously 
think $250,000 to enable secure services matters much to a company with 
25 million customers ? Certainly it wouldn't matter much to a bank, 
especially since it would probably reduce certain mailing costs. I'd 
guess that even one bulk USPS communication is going to cost more than 1 
cent per recipient. I only know one ISP with 25 million customers or 
more, and I happen to work for it, but I'm not at liberty to comment 
further on the costs.

The bottom line is, running a CA is a service, and it costs money, 
probably far, far more than $0.01 per cert per year. Whether an ISP runs 
it itself or outsources it, the service is going to cost some money 
somewhere

Anyway, I think we are getting quite off-topic here. If people want to 
run a loss-leader cert service they are welcome to do so, just as 
Thawte/Verisign does. I don't know how much relevance this has to the 
mailing list. Or do you want to codify the prices of certificates into 
the RFCs  ?

 > I can then lookup certs based on mail address (duh!), where the mail
 > domain source is trusted because of DNS-SEC.   This trust relationship
 > could be either:
 >
 > implicit -- the issuer domain location is trusted therefore any keys
 > published there are trusted,
 >
 > explict -- the issuer provides a root signing key which is in turn signed
 > by their DNS-SEC key.

What you are proposing is a new policy to automatically trust the 
certificate because of the security of the channel it traveled through.
But there has to be some prior trust somehow for the channel itself. I'm 
not familiar with DNS-SEC. Does it involve SSL/TLS in any way ? If so 
there would have to be prior trust on the DNS server certificate too.
All in all, I think the implicit trust is very dangerous. It is one 
thing to accept information through that channel while it is open, but 
to continue to use it after it is closed, by automatically trusting the 
certificate that was transferred, is another.
You may argue that it is better than nothing, however, a false sense of 
security may be worse than knowledge of the lack of security.

 > Well, even though I would love it if it was LDAP, it isn't going to
 > happen.   DNS is the only game in town for global directory service.

I don't see why the lookup has to be a 1-part lookup. It could - and 
probably should, given the size of the problem - take more than one step.

-- 
I am the dog in dogfood

To: "Blake Ramsdell" <[email-masked]>
Cc: "'Steve Hole'" <[email-masked]>, <[email-masked]>
Subject: Re: PKI and S/MIME
From: Simon Josefsson <[email-masked]>
Date: Fri, 15 Aug 2003 01:41:22 +0200
Sender: [email-masked]

"Blake Ramsdell" <[email-masked]> writes:

> Well, I'm not sure I agree with you here.  End user SMTP/POP3/IMAP mail
> clients today don't implement lots of DNS operations -- they just say
> "all mail goes to this SMTP server" which is a simple gethostbyname
> style call.  Specifically, they don't deal with MX records.  It has
> actually been pointed out in other forums (and I've had experience with
> this myself) that Windows is particularly ornery to work with for
> arbitrary DNS record types that aren't supported through native APIs (I
> had to write my own DNS client code to handle MX records back in the
> day, and Peter Gutmann told me he got slapped around pretty good trying
> to work with SRV records).

Steve Hole <[email-masked]> writes:

>> Even here there is an advantage for DNS: mail clients already
>> implement DNS.  There is no need to open ports in firewalls etc for
>> LDAP or XKMS.  There is no need to implement new client code in the
>> mail client.
>
> That is, regrettably, not accurate.   Existing clients do very little but 
> hostname to address translation and service port location.   I would be 
> very surprised if they did anything but gethostbyname and getservbyname 
> calls (or the platform API equivalent).   It would be an addition to get 
> them to query and retrieve records directly.

It is clear that I have been spoiled by working with free software
mail clients in the Unix world, which often do implement this.  Even
when they don't, a res_query() is never far away.  Thanks for sharing
experiences from other environments.

Still, I believe part of my argument still holds.  Even if your mail
clients only use gethostbyname(), that still means the DNS
infrastructure is available on the client machine.  It hasn't been
blocked by firewalls etc.  This simplifies deployment.

But this isn't an important point, and I don't see anything that can
be seen as a _disadvantage_ for DNS compared to LDAP or XKMS here.
Perhaps this tangental issue only distract us from the big picture.

Regards,
Simon

From: Steve Hole <[email-masked]>
Date: Thu, 14 Aug 2003 16:54:21 -0700
To: Simon Josefsson <[email-masked]>
Subject: Re: PKI and S/MIME
Cc: [email-masked]
Sender: [email-masked]

On Fri, 15 Aug 2003 00:28:48 +0200 Simon Josefsson <[email-masked]> wrote:

> Since mail clients cannot find certificates for arbitrary users today,
> I believe clients must be modified regardless of the solution chosen.

Yes.
 
> Even here there is an advantage for DNS: mail clients already
> implement DNS.  There is no need to open ports in firewalls etc for
> LDAP or XKMS.  There is no need to implement new client code in the
> mail client.  

That is, regrettably, not accurate.   Existing clients do very little but 
hostname to address translation and service port location.   I would be 
very surprised if they did anything but gethostbyname and getservbyname 
calls (or the platform API equivalent).   It would be an addition to get 
them to query and retrieve records directly.

Of course, this could be greatly aided by a freeware implementation on top
of bind that provided a nice simple "give me a cert for this email 
address".   It could do any of the approaches (direct cert from DNS, SRV 
to LDAP server followed by LDAP lookup, SRV to xkms server followed by 
xkms lookup).   That would aid client developers and abstract things 
nicely but still wouldn't guarantee uptake.

Whatever is done here, we have to convince Microsoft that it is a good 
thing to do and not very hard.   I saw a notice today that Microsoft has 
officially terminated extension of Outlook Express.   They want you to use
Outlook instead.   That means that S/MIME support in Express is more or 
less frozen ... I guess.

Cheers.

---
Steve Hole
Chief Technology Officer - Billing and Payment Systems
ACI Worldwide
<mailto:[email-masked]>
Phone: 780-424-4922

Date: Thu, 14 Aug 2003 15:47:41 -0700
From: [email-masked] (Julien Pierre)
Subject: RE: dissemination of public encryption certificates
To: "Hallam-Baker Phillip" <[email-masked]>
cc: "'Steve Hole'" <[email-masked]>, [email-masked]
Organization: Netscape
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms010704000904080802040505
Content-Type: TEXT/PLAIN; CHARSET=us-ascii

Philip,

Hallam-Baker, Phillip wrote on 08/14/2003, 10:30:
 >
 > 1) Signature
 >         Signature is only possible by changingthe message format.
 > Unfortunately there are still a lot of people out there with broken, non
 > S/MIME capable email clients. Probably more of those than have broken
 > email
 > servers. Of course at this point it is difficult to do anything about
 > this.

I don't think there is any way around that problem, the client simply 
must have at least basic MIME support to support S/MIME signed messages.
Unfortunately, there are many e-mail clients that cannot be supported, 
eg. the very basic e-mail "clients" included in some devices such as 
older cell phones.
The best that we can do is ensure that new client software going forward 
has the proper MIME & S/MIME support.

 > 2) Encryption
 >         Encryption is a big problem for end users, it is simply not
 > transparent. We need to link PKI to the DNS in some way, the SRV service
 > looks the best choice. LDAP is not going to be the answer here, even
 > if you
 > find the right LDAP server the schema issues still have to be solved.
 > Sure
 > LDAP could address the problem - but only to the extent a Turing machine
 > could and only with changes to make LDAP aware of PKI concepts like trust
 > paths.

I think you are overly pessimistic here about the ability of LDAP to 
solve the problem. I agree with you however that a proper schema needs 
to be in place, and that is certainly a problem that hasn't been solved.

 > 3) The end to end obsession
 >         One of the major reasons the IETF has failled in the security
 > space
 > is that the end to end principle alone does not address security issues.
 > Perimeter security is a major concern for enterprises.
 >
 >         As I have been digging into this issue I have discovered that
 > 'end-to-end security' is actually a shiboleth. Go look at the RFCs with
 > security architecture design discussions and you will not find it. Clark
 > never applied it to security either in the naive form that has become the
 > received version.
 >
 >         What we need to do is to build specs that address multi-layer
 > security concerns. It should not be necessary for everyone to have a
 > certificate just to be able to do security. It should be possible to sign
 > outgoing messages at either the end user level OR the domain name
 > level - I
 > only care that an email came from Merril Lynch, not that it came from
 > Freddy
 > Bloggs in accounts.

S/MIME signing can be implemented transparently in the way you want as 
well. Merryl Lynch could have a certificate with regular expressions in 
it, matching all of its employees. The internal Merryl SMTP e-mail 
server, perhaps setup with SSL and some basic authentication of 
employees, could automatically sign each outgoing e-mail message with 
that certificate. This really is not end-to-end at all but I believe it 
can work today. You just have to be a little creative.

 > > The solution is (and always has been) to do a lookup.  The
 > > problem is that
 > > there is no directory to look up from.   Global X.500/LDAP
 > > directories are
 > > *never* going to happen.
 >
 > Amen brother, Amen.

I find it really ironic that I can lookup phone numbers for anyone 
listed in the united states, knowing such sensitive information as their 
name and physical address, through a free service like 
www.switchboard.com, but I can't look-up their e-mail certificate 
knowing their e-mail address ?
I'm sure there is lots of politics involved, but surely the logistics of 
running this service shouldn't be so much of a problem ?

-- 
I am the dog in dogfood

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

--------------ms010704000904080802040505--

From: "Blake Ramsdell" <[email-masked]>
To: "'Simon Josefsson'" <[email-masked]>, "'Steve Hole'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: PKI and S/MIME
Date: Thu, 14 Aug 2003 15:40:51 -0700
Importance: Normal
Sender: [email-masked]

> From: Simon Josefsson [mailto:[email-masked]] 
> Sent: Thursday, August 14, 2003 3:29 PM
> To: Steve Hole
> Cc: Blake Ramsdell; [email-masked]
> Subject: Re: PKI and S/MIME
> 
> Note that distributing certificate DNS does not depend on DNSSEC.
> Thus the argument that DNSSEC may or may not be deployable is not
> relevant to distributing certificate via DNS.

I think that the intent is to point out that in order to get an
implementation of the CERT record, you usually get that in conjunction
with a DNSSEC implementation.  This may be too sweeping a
generalization, however.

> Even here there is an advantage for DNS: mail clients already
> implement DNS.  There is no need to open ports in firewalls etc for
> LDAP or XKMS.  There is no need to implement new client code in the
> mail client.  Instead modify the existing code to query for a CERT
> record where it now queries for MX and A records.  Yes, I know this
> doesn't apply in all situations, such as corporate mode Outlook and
> Exchange, which doesn't use Internet protocols to send and receive
> mail.  But we are here to find a solution for applications that uses
> IETF standards, not Microsoft implementations, aren't we?

Well, I'm not sure I agree with you here.  End user SMTP/POP3/IMAP mail
clients today don't implement lots of DNS operations -- they just say
"all mail goes to this SMTP server" which is a simple gethostbyname
style call.  Specifically, they don't deal with MX records.  It has
actually been pointed out in other forums (and I've had experience with
this myself) that Windows is particularly ornery to work with for
arbitrary DNS record types that aren't supported through native APIs (I
had to write my own DNS client code to handle MX records back in the
day, and Peter Gutmann told me he got slapped around pretty good trying
to work with SRV records).

Now, this situation might have changed, but I want to point out that the
DNS operations done by mail clients today are nowhere near the same as
would be required to handle CERT records.

Blake

To: Steve Hole <[email-masked]>
Cc: Blake Ramsdell <[email-masked]>, [email-masked]
Subject: Re: PKI and S/MIME
From: Simon Josefsson <[email-masked]>
Date: Fri, 15 Aug 2003 00:28:48 +0200
Sender: [email-masked]

Steve Hole <[email-masked]> writes:

> On Wed, 13 Aug 2003 15:05:49 -0700 Blake Ramsdell 
> <[email-masked]> wrote:
>
>> A better question for the DNS distribution of certificates is whether or
>> not this smells like it would be the most likely thing to get deployed.
>> My understanding is that you would need DNS servers that supported the
>> particular record types required for this functionality, as well as
>> administrative tools to upgrade those records that are different than
>> typical DNS administration tools.  To me, that doesn't smell as good.
>
> Actually, I think that there are two barriers:
>
> 1. Deployment of DNS-SEC. People have to go out of their way to do it 
> right now.   It takes some work both to deploy the right software and to 
> get the relationship set up with the domain registration service.   Not 
> all services offer it.

Note that distributing certificate DNS does not depend on DNSSEC.
Thus the argument that DNSSEC may or may not be deployable is not
relevant to distributing certificate via DNS.

However, should DNSSEC (or some close approximation to it) happen, it
would make certificates distributed via DNS become integrity protected
and authenticated via the DNSSEC trust chain.  LDAP or XKMS using SRV
records does not get the same benefit. 

> 2. Client support.   Basically this means that Outlook, Outlook Express, 
> Netscape (and down the list) of clients have to support it.   It means a 
> CSP for the Windows twins and a module in the new Netscape/Mozilla 
> security API.

Since mail clients cannot find certificates for arbitrary users today,
I believe clients must be modified regardless of the solution chosen.

Even here there is an advantage for DNS: mail clients already
implement DNS.  There is no need to open ports in firewalls etc for
LDAP or XKMS.  There is no need to implement new client code in the
mail client.  Instead modify the existing code to query for a CERT
record where it now queries for MX and A records.  Yes, I know this
doesn't apply in all situations, such as corporate mode Outlook and
Exchange, which doesn't use Internet protocols to send and receive
mail.  But we are here to find a solution for applications that uses
IETF standards, not Microsoft implementations, aren't we?

Regards,
Simon

From: "Blake Ramsdell" <[email-masked]>
To: "'Hallam-Baker, Phillip'" <[email-masked]>, <[email-masked]>
Cc: "'Steve Hole'" <[email-masked]>, "'Julien Pierre'" <[email-masked]>, <[email-masked]>
Subject: RE: dissemination of public encryption certificates 
Date: Thu, 14 Aug 2003 14:42:48 -0700
Importance: Normal
Sender: [email-masked]

> Hallam-Baker, Phillip
> Sent: Thursday, August 14, 2003 11:17 AM
> To: [email-masked]'; Hallam-Baker, Phillip
> Cc: 'Steve Hole'; Julien Pierre; [email-masked]
> Subject: RE: dissemination of public encryption certificates 
> 
> XKMS does not answer that question because I can't think of a 
> situation
> where is would be of interest. The certificate is simply a 
> data object that
> is created to establish the trustworthiness of a key. 
> Applications don't ask
> 'what is this good for?', they ask 'how do I do this task?'.

Well, I'm not sure I agree.  There are two major questions that
constantly need answers in the mind of an S/MIME client.  These are
pretty close to what Michael said in his message:

1. Given a particular email address, give me That Which Is Necessary and
Sufficient to send encrypted mail to that email address.

2. Given a particular certificate, is it suitable for signing mail that
came from a particular email address.  Michael said "what is it good
for", which I think is too broad a question.

If we're considering protocols that attempt to answer these types of
questions, those are the two questions that need to be answered by that
protocol (for interpersonal messaging with S/MIME, that is).

Blake

From: "Blake Ramsdell" <[email-masked]>
To: "'Steve Hole'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: PKI and S/MIME
Date: Thu, 14 Aug 2003 14:25:04 -0700
Importance: Normal
Sender: [email-masked]

> From: Steve Hole [mailto:[email-masked]] 
> Sent: Thursday, August 14, 2003 10:42 AM
> To: Blake Ramsdell
> Cc: [email-masked]
> Subject: RE: PKI and S/MIME
> 
> 2. Client support.   Basically this means that Outlook, 
> Outlook Express, 
> Netscape (and down the list) of clients have to support it.   
> It means a 
> CSP for the Windows twins and a module in the new Netscape/Mozilla 
> security API.
> 
> Of the two, the second is the hardest.   Policy, usage and 
> deployment of 
> S/MIME and PKI is very much shaped by the implementation of 
> the clients.  
> Any changes have to propogate through the clients to be useful.

There is no miracle that I can see that wouldn't require modifying the
clients, so we're already signed up for this regardless of what
direction we might go in, I think.

Blake

From: "Hallam-Baker, Phillip" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "Hallam-Baker, Phillip" <[email-masked]>
Cc: "'Steve Hole'" <[email-masked]>, Julien Pierre <[email-masked]>, [email-masked]
Subject: RE: dissemination of public encryption certificates 
Date: Thu, 14 Aug 2003 11:16:47 -0700
Sender: [email-masked]

> Leaving aside who supports what and why, don't understand the
> implied conflict between xkms and scvp.  They seem to do two 
> different things -- I want to find a cert for [email-masked]
> to send email to that entity; I have a cert from [email-masked] --
> what is it good for?  I didn't think SCVP would help much with
> the first, and I clearly don't see what XKMS would do with the
> second question.  Would like a better understanding of this.

Thats quite a good description of SCVP.

XKMS does not answer that question because I can't think of a situation
where is would be of interest. The certificate is simply a data object that
is created to establish the trustworthiness of a key. Applications don't ask
'what is this good for?', they ask 'how do I do this task?'.

		Phill

To: "Hallam-Baker, Phillip" <[email-masked]>
cc: "'Steve Hole'" <[email-masked]>, Julien Pierre <[email-masked]>, [email-masked]
Reply-to: [email-masked]
Subject: Re: dissemination of public encryption certificates 
Date: Thu, 14 Aug 2003 11:01:53 -0700
From: Michael Helm <[email-masked]>
Sender: [email-masked]

"Hallam-Baker, Phillip" writes:
> Again, I designed XKMS to allow enterprises to define their own trust
> evaluations. One of the main considerations was how to support the Federal

> Also, obtain buy-in from the principal stakeholders whose help is required
> to achieve deployment.
> 
> That is why the answer is XKMS and not SCVP. SCVP does not have the public
> support of any of the major stakeholders. I spent a lot of time and effort
> getting buy-in from Microsoft and RSA before we announced XKMS. I worked
> with Entrust and Baltimore so that we could produce a specification that
> they could also support.
> 
> Contrast this to what the IETF mechanism achieves, OK everyone can say what
> they like. But at the end of the day you do not have the support of a major
> software vendor, just the individuals in the working group.

Leaving aside who supports what and why, don't understand the
implied conflict between xkms and scvp.  They seem to do two 
different things -- I want to find a cert for [email-masked]
to send email to that entity; I have a cert from [email-masked] --
what is it good for?  I didn't think SCVP would help much with
the first, and I clearly don't see what XKMS would do with the
second question.  Would like a better understanding of this.

Thanks, ==mwh
Michael Helm
ESnet

From: "Hallam-Baker, Phillip" <[email-masked]>
To: "'Steve Hole'" <[email-masked]>, "Hallam-Baker, Phillip" <[email-masked]>
Cc: "'Anders Rundgren'" <[email-masked]>, Blake Ramsdell <[email-masked]>, Simon Josefsson <[email-masked]>, [email-masked], "'Sean P. Turner'" <[email-masked]>
Subject: RE: PKI and S/MIME
Date: Thu, 14 Aug 2003 10:32:31 -0700
Sender: [email-masked]

> Fair enough.  Then you better figure out how, exactly, you 
> are going to 
> deploy your new protocol for use with S/MIME.   Specifically, 
> you must do 
> what Blake suggests and write a profile for use.  

At the moment I am just recovering from getting the XKMS spec itself through
last call. I also have to get the WS-Security profiles for X.509 and
Kerberos completed.

After that I have to stop spam on the Internet completely. 

That takes us up to the end of September at which point I will be able to
get back to the S/MIME issue.

		Phill

From: "Hallam-Baker, Phillip" <[email-masked]>
To: "'Steve Hole'" <[email-masked]>, Julien Pierre <[email-masked]>
Cc: [email-masked]
Subject: RE: dissemination of public encryption certificates
Date: Thu, 14 Aug 2003 10:30:00 -0700
Sender: [email-masked]

> Well, for the first time in a long time my interest is up on this 
> list :-).    What a wonderful topic!   General purpose use of 
> S/MIME by the masses on the Internet.   Why hasn't it 
> happened and what 
> can we do about it.

Glad you like it...

The reason is simple, S/MIME is not transparent to end users.

1) Signature
	Signature is only possible by changingthe message format.
Unfortunately there are still a lot of people out there with broken, non
S/MIME capable email clients. Probably more of those than have broken email
servers. Of course at this point it is difficult to do anything about this.

2) Encryption
	Encryption is a big problem for end users, it is simply not
transparent. We need to link PKI to the DNS in some way, the SRV service
looks the best choice. LDAP is not going to be the answer here, even if you
find the right LDAP server the schema issues still have to be solved. Sure
LDAP could address the problem - but only to the extent a Turing machine
could and only with changes to make LDAP aware of PKI concepts like trust
paths.

3) The end to end obsession
	One of the major reasons the IETF has failled in the security space
is that the end to end principle alone does not address security issues.
Perimeter security is a major concern for enterprises.

	As I have been digging into this issue I have discovered that
'end-to-end security' is actually a shiboleth. Go look at the RFCs with
security architecture design discussions and you will not find it. Clark
never applied it to security either in the naive form that has become the
received version.

	What we need to do is to build specs that address multi-layer
security concerns. It should not be necessary for everyone to have a
certificate just to be able to do security. It should be possible to sign
outgoing messages at either the end user level OR the domain name level - I
only care that an email came from Merril Lynch, not that it came from Freddy
Bloggs in accounts.

4) Feature support discovery
	An extension of #2. Clients should be able to advertise their
capabilities. Perhaps this is NAPTR, but I doubt it. I see NAPTR as being a
server level feature.

> The solution is (and always has been) to do a lookup.  The 
> problem is that
> there is no directory to look up from.   Global X.500/LDAP 
> directories are 
> *never* going to happen.

Amen brother, Amen.

> The reason for the cost is that the mechanism for 
> establishing root trust 
> is determined solely by the set of ROOT certificates 
> distributed by the 
> client vendor -- of all things!.

Again, I designed XKMS to allow enterprises to define their own trust
evaluations. One of the main considerations was how to support the Federal
Bridge CA, both today and in the future when there are perhaps a thousand
significant bridge CAs in operation.

> 1.  Easy to deploy.   The track record for the Internet 
> stongly indicates 
> that this means that there are freeware versions of software 
> that will 
> support the deployment.   This includes both the key management and 
> publication software and the usage (client) software. 

Also, obtain buy-in from the principal stakeholders whose help is required
to achieve deployment.

That is why the answer is XKMS and not SCVP. SCVP does not have the public
support of any of the major stakeholders. I spent a lot of time and effort
getting buy-in from Microsoft and RSA before we announced XKMS. I worked
with Entrust and Baltimore so that we could produce a specification that
they could also support.

Contrast this to what the IETF mechanism achieves, OK everyone can say what
they like. But at the end of the day you do not have the support of a major
software vendor, just the individuals in the working group.

> 2.  Free.   Those who "own" the vast majoritiy of the user 
> population on 
> the Internet are ISP's.   They have almost no margin and 
> simply cannot 
> afford to pay for certification. 

Substitute cheap. Clearly certification becomes a lot cheaper in volume.

> Why could we not have organizations issue certificates 
> distributed via 
> DNS, with a trust relationship provided by DNS-SEC? 

Because the working group deliberately sabotaged the spec by refusing
changes to make it possible to deploy in .com and .net.

> I can then lookup certs based on mail address (duh!), where the mail 
> domain source is trusted because of DNS-SEC.   This trust 
> relationship 
> could be either:

Not a good choice, very few DNS administrators deal with end users. The TTL
constants in DNS are also completely inappropriate to the problem.

		Phill 

From: Steve Hole <[email-masked]>
Date: Thu, 14 Aug 2003 11:09:47 -0700
To: "Hallam-Baker, Phillip" <[email-masked]>
Subject: RE: PKI and S/MIME
Cc: "'Anders Rundgren'" <[email-masked]>, Blake Ramsdell <[email-masked]>, Simon Josefsson <[email-masked]>, [email-masked], "'Sean P. Turner'" <[email-masked]>
Sender: [email-masked]

On Thu, 14 Aug 2003 05:30:34 -0700 "Hallam-Baker, Phillip" 
<[email-masked]> wrote:

> We considered certs in the DNS and LDAP before designing XKMS and rejected
> them. Both technologies have been available for at least 6 years with
> negligible uptake. 

This is true for LDAP, but is it true for DNS?   What specific "deploy 
certs in DNS" technology are you talking about?

> We needed a new protocol because there was no acceptable
> existing solution. Sometimes designing a new protocol from scratch is better
> than attempting to use an inappropriate one.

Fair enough.  Then you better figure out how, exactly, you are going to 
deploy your new protocol for use with S/MIME.   Specifically, you must do 
what Blake suggests and write a profile for use.    In particular, if I'm 
sitting in my Netscape client and I want to send an encrypted message to 
"Blake Ramsdell <[email-masked]>" without any prior contact, how
am I going to do that?

That profile must describe:

1.  The collection of services and publication points for accessing the 
information.

2.  The approach that a client must take to do the lookup and resolve the 
requested certificate.

I'm sure that you can do it.   I'm also sure that you are going to have to
do *something* with DNS because how are you ever going to find your xkms 
server?   If there is an external xkms global hierarchy planned, then 
pardon me if I'm dubious, but who is going to run the root?   (Hint: I'm 
unlikely to like *any* answer to that last question :-).

Chers.

---
Steve Hole
Chief Technical Officer - Electronic Billing and Payment Systems
ACI Worldwide

Email: [email-masked]
Phone: 780 424 4922

From: Steve Hole <[email-masked]>
Date: Thu, 14 Aug 2003 10:45:45 -0700
To: Simon Josefsson <[email-masked]>
Subject: Re: PKI and S/MIME
Cc: Blake Ramsdell <[email-masked]>, "'Anders Rundgren'" <[email-masked]>, [email-masked], "'Sean P. Turner'" <[email-masked]>
Sender: [email-masked]

On Thu, 14 Aug 2003 01:45:51 +0200 Simon Josefsson <[email-masked]> wrote:

> I believe that what is lacking is not a technical solution (DNS CERT
> RR, LDAP and SRV, etc) but a guideline document, supported by the
> S/MIME community, that you can point at when e-mail application makers
> ask question such as the one that started this thread.
> 
> One reason why the DNS CERT solution has been proposed, may be that
> the LDAP via SRV idea hasn't been fully documented in a Internet-wide
> S/MIME environment, leaving the problem unsolved.

I agree.   The problem with PKI has always been that it is difficult to 
experiment.   I think that we have enough real world experience now that 
we should try some alternative things.   I think that we do need to 
experiment with this.   It's time to come up with some working solutions 
and then document them, not the other way around.

> One argument for certificates in DNS could be that many ISPs are
> familiar with running public DNS, but not as many ISPs run public
> LDAP.  So instead of upgrading their tools, they would have to learn
> new tools with LDAP.  [All under the assumption that ISPs will be
> required to administer the certificate directory, which I'm not sure
> is the best solution.]

Yes.

Cheers.

---
Steve Hole
Chief Technical Officer - Electronic Billing and Payment Systems
ACI Worldwide

Email: [email-masked]
Phone: 780 424 4922

From: Steve Hole <[email-masked]>
Date: Thu, 14 Aug 2003 10:42:02 -0700
To: Blake Ramsdell <[email-masked]>
Subject: RE: PKI and S/MIME
Cc: [email-masked]
Sender: [email-masked]

On Wed, 13 Aug 2003 15:05:49 -0700 Blake Ramsdell 
<[email-masked]> wrote:

> A better question for the DNS distribution of certificates is whether or
> not this smells like it would be the most likely thing to get deployed.
> My understanding is that you would need DNS servers that supported the
> particular record types required for this functionality, as well as
> administrative tools to upgrade those records that are different than
> typical DNS administration tools.  To me, that doesn't smell as good.

Actually, I think that there are two barriers:

1. Deployment of DNS-SEC. People have to go out of their way to do it 
right now.   It takes some work both to deploy the right software and to 
get the relationship set up with the domain registration service.   Not 
all services offer it.

2. Client support.   Basically this means that Outlook, Outlook Express, 
Netscape (and down the list) of clients have to support it.   It means a 
CSP for the Windows twins and a module in the new Netscape/Mozilla 
security API.

Of the two, the second is the hardest.   Policy, usage and deployment of 
S/MIME and PKI is very much shaped by the implementation of the clients.  
Any changes have to propogate through the clients to be useful.

Cheers.

---
Steve Hole
Chief Technical Officer - Electronic Billing and Payment Systems
ACI Worldwide

Email: [email-masked]
Phone: 780 424 4922

From: Steve Hole <[email-masked]>
Date: Thu, 14 Aug 2003 10:34:47 -0700
To: Anders Rundgren <[email-masked]>
Subject: Re: PKI and S/MIME
Cc: [email-masked]
Sender: [email-masked]

On Wed, 13 Aug 2003 19:16:22 +0200 Anders Rundgren 
<[email-masked]> wrote:

> 
> Simon,
> I respect your work with DNS for location but is this really
> universal?  How about my [email-masked] cert
> issued by VeriSign?  Would it be appropriate to require ISPs
> like Telia to maintain a directory pointing to various TTP CAs?
> 
> Or should ever domain-owner become a CA?

Why not?
---
Steve Hole
Chief Technical Officer - Electronic Billing and Payment Systems
ACI Worldwide

Email: [email-masked]
Phone: 780 424 4922

Date: Thu, 14 Aug 2003 09:28:56 -0700 (PDT)
From: Deepak <[email-masked]>
Subject: Query regarding BER/DER encoding of CMS data
To: [email-masked]
Sender: [email-masked]

Hi,

  When i go through the CMS RFC's its saying, all the
contenttype(SignedData,EnvelopedData) should be BER
encoded. But when i go thorugh the some of the ietf
examples, especially in EnvelopedData->RecipientInfo
is encoded by DER.(its starting with 31 82 ..). It
should be like sequence 30 80 .. ? 

Could you please explain why was it happend ?

Thanks,
Deepak

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com

From: Steve Hole <[email-masked]>
Date: Thu, 14 Aug 2003 10:30:28 -0700
To: Julien Pierre <[email-masked]>
Subject: Re: dissemination of public encryption certificates
Cc: [email-masked]
Sender: [email-masked]

Well, for the first time in a long time my interest is up on this 
list :-).    What a wonderful topic!   General purpose use of 
S/MIME by the masses on the Internet.   Why hasn't it happened and what 
can we do about it.

Before you read on, be assured that it is the large scale use of S/MIME 
that the following diatribe is focused on.

On Wed, 13 Aug 2003 19:29:53 -0700 Julien Pierre <[email-masked]> 
wrote:

> If you send an email today, you can simply sign it and include your 
> certificate in the signature. If you just sign all your mail, then all 
> you always disseminate your certificate. So in what situations does this 
> new MIME extension certificate lookup help ? I suppose this extension 
> would be shorter than a digital signature. However it would also be much 
> less secure.

This highlights one of the key issues.   It is easy enough to exchange 
keys simply by sending a signed message, but there are some significant 
barriers:

1.  What if your encryption key is separate from your signing key.   This 
is not only common but considered good security practice.   How does one 
go about exchanging/discovering the encryption key for the new party you 
want to exchange mail with.

2.  Timeliness of the key exchange.   The problem with mutual signing 
exchange is that the other person has to respond to you.  What if you just
want to send them an encrypted load right off the start.   You can't 
really do it.

The solution is (and always has been) to do a lookup.  The problem is that
there is no directory to look up from.   Global X.500/LDAP directories are 
*never* going to happen.

There is only one choice -- DNS.   I (and Steve Kille and others) have 
been flogging LDAP directories and working on LDAP/X.500 interconnects for
a decade.   Global X.500/LDAP isn't going to happen in our lifetime.

> The case I originally asked about is :
> neither party has exchanged any e-mail yet, but they know each other's 
> e-mail address. They want to communicate securely. How do they avoid or 
> bypass the initial insecure e-mail exchange ?

Precisely.   They must be able to do a DNS lookup for the information 
either as a direct data return or a reference to a secondary storage 
service, which absolutely could and probably should be LDAP.   To 
work in practice I think that it should be possible to get a direct pull 
from the DNS so that organizations are not required to deploy an LDAP 
directory and all that goes along with it (much as that pains me).
 
>  > In summary I think that a certificate-independent configuration
>  > of e-mail clients would be more universal than "fishing" in
>  > domains as the user domain and issuer domain may be entirely
>  > disjunct.
> 
> "Fishing" in domains as you say would be independent of e-mail client 
> configuration for the most part (it could just be turned on or off).

Actually, I think that "fishing" is an entirely appropriate thing to do.  
The worst that can happen is that don't find the cert your looking for.   
Trust issues MUST be dealt with, but certificate trust chains and 
approaches are both well understood. 

The best that can happen is that suddenly I can go and find a cert for 
[email-masked] with a simple DNS query.  BEAUTIFUL!   Why wouldn't I want 
to do that?

This does lead very nicely into my second (and quite separate) issue in 
this area -- the "trusted ROOT certificate".   Julien has provided superp 
leading commentary here.
  
> You correctly point out that in most cases the user's domain and cert 
> issuer domain are disjoint. This is especially true of e-mail users 
> whose ISP isn't a CA (99.9% of them right now). 

Exactly.   Why?   Because it costs TOO MUCH.   The only acceptable cost 
for most ISP's is zero because of the volume of users.   Cost of 
certification is, pure and simple, the primary barrier to the general use 
and deployment of S/MIME on the Internet.

The reason for the cost is that the mechanism for establishing root trust 
is determined solely by the set of ROOT certificates distributed by the 
client vendor -- of all things!.   Thus only those organizations that can 
afford to pay the client vendor -- of all things! -- to be included in 
their "special trusted root certificate club" get to have "trust".   Which 
means that you MUST buy certs from one of the club members.  Doesn't THAT 
just suck.   Nice business if you can get it.

<qualification>
Yes I know about free thawte certs.   I know that any root issuer must be 
secure and provide good protection from having roots keys compromised etc. 
I agree that anyone who issues certificates should be required to be 
secure. I understand that there is risk to the client vendor if they 
report trust in a cert that has been compromised at the root.

Regardless, to have this power rest in the hands of the client vendor is 
ludicrous.   Why should I trust that Microsoft can evaluate the security 
and trustworthiness of "Joe's CA Service" to be a valid issuer.   I'm not 
saying they are unqualified to do so, but I'm a lot more likely to trust a
self signed "Bank of America" certificate issued on it's own behalf and 
obtained from a reliable source, than I am a third party software vendor 
or CA Verisign (not that there's anything wrong with either Microsoft or 
Verisign :-).
</qualification>

The issue comes down to trust brokering.   I just don't think that it is 
working for the *general* mass consumer Internet.   It clearly does work 
for closed communities within the Internet, but it isn't scaling.   
Period.  If we want generalized S/MIME usage throughout the Internet we 
need to think of some mechanism that is:

1.  Easy to deploy.   The track record for the Internet stongly indicates 
that this means that there are freeware versions of software that will 
support the deployment.   This includes both the key management and 
publication software and the usage (client) software. 

2.  Free.   Those who "own" the vast majoritiy of the user population on 
the Internet are ISP's.   They have almost no margin and simply cannot 
afford to pay for certification.  Also (and more importantly IMHO) is the 
desired for businesses to touch their customers.   These are HUGE volume 
relationships in which there are virtually no economically viable ways of
establishing bidirectional trust.   A cert price of $0.01 a year is too 
much if your customer population is 25 million people (banks, utilities, 
etc.)

Why could we not have organizations issue certificates distributed via 
DNS, with a trust relationship provided by DNS-SEC?  That is, you can 
trust that the DNS node your are dealing with is legitimate because they 
have deployed DNS-SEC (which everyone should do anyway for a host of other
security reasons) and the keys that are located within the DNS hierachy 
are legitimate.

I can then lookup certs based on mail address (duh!), where the mail 
domain source is trusted because of DNS-SEC.   This trust relationship 
could be either:

implicit -- the issuer domain location is trusted therefore any keys 
published there are trusted,

explict -- the issuer provides a root signing key which is in turn signed 
by their DNS-SEC key.

There are a number of observations that can be made about this approach:

1.  The security provided by the approach is probably not as strong as the
full commercial CA approach.   I contend "so what".   It's better than 
nothing and Pretty Good (pun intended).  The average user doesn't need 
military grade security.   The average bill issued by the local telephone 
utility doesn't need military grade security.   Think of the vast number 
of paper documents that need only Pretty Good security and trust to be 
useful (292 Trillion a year in the US -- it's my business and I happen to 
know).  All we need is some security to make that paper go away forever.

2.  Some extensions to bind and a new CSP for Windows would get a large 
number people going in a hurry.   Openssl with an HSM card and some 
reasonable security policy has an organization running pretty quickly.

> The only solution for 
> these users is some sort of universal registration service. 

Yup.

> This implies 
> the existence of some sort of free worldwide directory service (LDAP) 
> that would resolve e-mail addresses to certificates ... And clients 
> would need to be (automatically?) configured to do look ups in it.

Well, even though I would love it if it was LDAP, it isn't going to 
happen.   DNS is the only game in town for global directory service.

Cheers.

---
Steve Hole
Chief Technical Officer - Electronic Billing and Payment Systems
ACI Worldwide

Email: [email-masked]
Phone: 780 424 4922

From: "Hallam-Baker, Phillip" <[email-masked]>
To: "'Anders Rundgren'" <[email-masked]>, Blake Ramsdell <[email-masked]>, Simon Josefsson <[email-masked]>
Cc: [email-masked], "'Sean P. Turner'" <[email-masked]>
Subject: RE: PKI and S/MIME
Date: Thu, 14 Aug 2003 05:30:34 -0700
Sender: [email-masked]

There are two ways the problem may be solved.

The simplest solution is that the domain owner appoints a single CA for the
entire zone and simply directs all XKMS requests to the XKMS server run by
the CA.

The second solution is that the domain owner runs a non-authoritative Locate
service locally. XKMS clients that register certificates with the CA of
their choice can then in turn register the certificate issued by the CA with
their local XKMS locate service.

In this second application the XKMS service may choose to impose some form
of validation constraint on the certs that it accepts. For example only
accepting certs from a limited number of CAs - or it may not.

Incidentaly XKMS may also be used to register PGP keys or keys in
alternative PKIs. It is a key centric PKI, not a token centric one.

Storing end-user certs or keys in the DNS is a lousy idea for several
reasons. First the DNS is a machine configuration infrastructure and not a
user configuration infrastructure. Storing user information in the DNS
requires an administrative interface with a new constituency. Ain't going to
happen. Moreover the DNSSEC spec itself is still not in a deployable state,
or at least the IETF version of it is not.

Storing certificates in LDAP is a lousy idea. LDAP is an internal enterprise
resource. Enterprises are not going to expose LDAP data in border
directories in significant numbers. It is not just the security issue, cost
plays a factor. LDAP is not a simple protocol, it is would be completely
overspecified for the job of a cert repository if the features LDAP provided
were relevant to the task.

We considered certs in the DNS and LDAP before designing XKMS and rejected
them. Both technologies have been available for at least 6 years with
negligible uptake. We needed a new protocol because there was no acceptable
existing solution. Sometimes designing a new protocol from scratch is better
than attempting to use an inappropriate one.

		Phill

> From: Anders Rundgren [mailto:[email-masked]]
> Sent: Wednesday, August 13, 2003 1:16 PM
> To: Blake Ramsdell; Simon Josefsson
> Cc: [email-masked]; 'Sean P. Turner'
> Subject: Re: PKI and S/MIME
> 
> 
> 
> Simon,
> I respect your work with DNS for location but is this really
> universal?  How about my [email-masked] cert
> issued by VeriSign?  Would it be appropriate to require ISPs
> like Telia to maintain a directory pointing to various TTP CAs?
> 
> Or should ever domain-owner become a CA?
> 
> Anders
> 
> ----- Original Message ----- 
> From: "Simon Josefsson" <[email-masked]>
> To: "Blake Ramsdell" <[email-masked]>
> Cc: <[email-masked]>; "'Sean P. Turner'" <[email-masked]>
> Sent: Wednesday, August 13, 2003 09:32
> Subject: Re: PKI and S/MIME
> 
> 
> 
> "Blake Ramsdell" <[email-masked]> writes:
> 
> > There have been a number of messages recently about the use 
> of PKI with
> > S/MIME, and the concerns about that.  I like to think that we're all
> > pretty much in agreement that we've established a consistent,
> > interoperable practice for the actual syntax and contents of S/MIME
> > messages, as well as a reasonable cut of a certificate 
> syntax profile
> > for end-entity certificates.
> >
> > Should there be a profile for certificate usage 
> (certificate repository,
> > distribution and revocation checking) that is specific for 
> our problem
> > domain?  That is, select relevant other work and profile it 
> for use in
> > the S/MIME interpersonal messaging domain?  I would imagine 
> that this
> > would be a new draft, start with a summary of the requirements, and
> > progress to profiles of relevant standards.
> >
> > It's also not clear if this is something to discuss in this working
> > group, or somewhere else.
> >
> > Comments?
> 
> Since in practice, addressing this problem would help in getting
> "opportunistic S/MIME" to work, I believe it would be useful to
> address it.  ("Opportunistic S/MIME" means to be able to encrypt
> messages to someone you don't have a prior trust relationship with,
> simply to provide encryption of data.  There is a man in the middle
> attack, of course, but in practice the result often isn't worse than
> not using S/MIME.)
> 
> A strawman at a requirement:
> 
> * Be able to locate a certificate for a Internet user given only her
>   email address.
> 
> I should mention that this has been discussed several times before, in
> various fora, for similar applications (e.g., OpenPGP, IPSEC, SSH), so
> there is prior work to look at how to design this.  To do even more
> self-promoting, I'd again like to mention the following draft:
> 
> http://josefsson.org/draft-josefsson-pkix-dns.txt
> 
> which do discuss it for S/MIME context as well.  I don't have an
> opinion on if this WG is the proper place for it.
> 
> Regards,
> Simon
> 

Date: Wed, 13 Aug 2003 19:29:53 -0700
From: [email-masked] (Julien Pierre)
Subject: Re: dissemination of public encryption certificates
To: "Anders Rundgren" <[email-masked]>
cc: [email-masked], "Hallam-Baker Phillip" <[email-masked]>
Organization: Netscape
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms010704000904080802040505
Content-Type: TEXT/PLAIN; CHARSET=us-ascii

Anders,

Anders Rundgren wrote on 08/12/2003, 9:31:

 > Pierre,
 > It is good to hear somebody bring up this question which is absolutely
 > vital for successful deployment of encrypted mail.

I'm also glad to see interest in solving this problem.

 > Personally I don't think that neither the S/MIME WG or XKMS WG
 > have a solution that at least I would call "acceptable".
 >
 > XKMS addresses to some extent the enterprise scenario but only
 > if the enterprise has their own domain and associated CA.  For
 > truly TTP-based certificates you are out of luck if you are looking
 > for automated functionality.

Are you saying basically that this won't work for Joe User at 
randomisp.com, who wants to register with randomca.com ?
 >
 > I believe that the mail protocol and associated applications
 > should be augmented with encryption certificate lookup. A
 > MIME X-extension that you configured in your e-mail client
 > would do a part of this.  I.e. each time you sent a mail, the
 > lookup would be transmitted as well.   Also it would be
 > nice to have an enhanced "mailto:" URL supporting the same
 > mechanism.

If you send an email today, you can simply sign it and include your 
certificate in the signature. If you just sign all your mail, then all 
you always disseminate your certificate. So in what situations does this 
new MIME extension certificate lookup help ? I suppose this extension 
would be shorter than a digital signature. However it would also be much 
less secure.

The case I originally asked about is :
neither party has exchanged any e-mail yet, but they know each other's 
e-mail address. They want to communicate securely. How do they avoid or 
bypass the initial insecure e-mail exchange ?

 > In summary I think that a certificate-independent configuration
 > of e-mail clients would be more universal than "fishing" in
 > domains as the user domain and issuer domain may be entirely
 > disjunct.

"Fishing" in domains as you say would be independent of e-mail client 
configuration for the most part (it could just be turned on or off).

You correctly point out that in most cases the user's domain and cert 
issuer domain are disjoint. This is especially true of e-mail users 
whose ISP isn't a CA (99.9% of them right now). The only solution for 
these users is some sort of universal registration service. This implies 
the existence of some sort of free worldwide directory service (LDAP) 
that would resolve e-mail addresses to certificates ... And clients 
would need to be (automatically?) configured to do look ups in it.

-- 
I am the dog in dogfood

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

AAAA

--------------ms010704000904080802040505--

From: "Blake Ramsdell" <[email-masked]>
To: "'Simon Josefsson'" <[email-masked]>
Cc: "'Anders Rundgren'" <[email-masked]>, <[email-masked]>, "'Sean P. Turner'" <[email-masked]>
Subject: DNS CERT vs. LDAP (was: RE: PKI and S/MIME)
Date: Wed, 13 Aug 2003 17:05:24 -0700
Importance: Normal
Sender: [email-masked]

> From: Simon Josefsson [mailto:[email-masked]] 
> Sent: Wednesday, August 13, 2003 4:46 PM
> To: Blake Ramsdell
> Cc: 'Anders Rundgren'; [email-masked]; 'Sean P. Turner'
> Subject: Re: PKI and S/MIME
> 
> I believe that what is lacking is not a technical solution (DNS CERT
> RR, LDAP and SRV, etc) but a guideline document, supported by the
> S/MIME community, that you can point at when e-mail application makers
> ask question such as the one that started this thread.

Yes, this was the way I indeed started this thread ("PKI and S/MIME"),
by saying "select relevant other work and profile it for use in the
S/MIME interpersonal messaging domain" ;).  I think we're on the same
page.

My only point about LDAP is that I wanted to illustrate some of the
criteria for any potential profile by comparing two certificate
repository methods, and pointing out what I believe is a relevant
difference.

> One reason why the DNS CERT solution has been proposed, may be that
> the LDAP via SRV idea hasn't been fully documented in a Internet-wide
> S/MIME environment, leaving the problem unsolved.

But once again, if someone held a gun to my head and told me to try and
guess if CERT records and the infrastructure to maintain them would
achieve traction before LDAP and SRV records would, I would say LDAP and
SRV records.  This may be a matter of personal taste, but I like to
think that it is a practical answer based on limited experience with
managing my own domains.

> > as well as administrative tools to upgrade those records that are
> > different than typical DNS administration tools.
> 
> Yes, someone, somewhere will have to do work to make the idea happen.

I think the question is whether or not "someone, somewhere" for DNS CERT
records is better than "been there, done that" for LDAP or other
repositories.

Blake

To: "Blake Ramsdell" <[email-masked]>
Cc: "'Anders Rundgren'" <[email-masked]>, <[email-masked]>, "'Sean P. Turner'" <[email-masked]>
Subject: Re: PKI and S/MIME
From: Simon Josefsson <[email-masked]>
Date: Thu, 14 Aug 2003 01:45:51 +0200
Sender: [email-masked]

"Blake Ramsdell" <[email-masked]> writes:

> If I were going to hazard a guess about widely deployed public
> certificate repositories, I would say that there would be a better
> argument for LDAP than anything else.  Notice the careful wording here
> ;).  As much as the attempts to automatically map from an email address
> to an LDAP directory containing a certificate for that email address
> might not have progressed as well as we might like, I think that there
> is some hope of that being addressed through the SRV record which is (as
> far as I can tell) widely supported by DNS implementations.

I believe that what is lacking is not a technical solution (DNS CERT
RR, LDAP and SRV, etc) but a guideline document, supported by the
S/MIME community, that you can point at when e-mail application makers
ask question such as the one that started this thread.

One reason why the DNS CERT solution has been proposed, may be that
the LDAP via SRV idea hasn't been fully documented in a Internet-wide
S/MIME environment, leaving the problem unsolved.

> A better question for the DNS distribution of certificates is whether or
> not this smells like it would be the most likely thing to get deployed.
> My understanding is that you would need DNS servers that supported the
> particular record types required for this functionality, 

Support for this was added to major servers before 2000 or
thereabouts, so many are already using such DNS servers.

> as well as administrative tools to upgrade those records that are
> different than typical DNS administration tools.

Yes, someone, somewhere will have to do work to make the idea happen.

One argument for certificates in DNS could be that many ISPs are
familiar with running public DNS, but not as many ISPs run public
LDAP.  So instead of upgrading their tools, they would have to learn
new tools with LDAP.  [All under the assumption that ISPs will be
required to administer the certificate directory, which I'm not sure
is the best solution.]

Regards,
Simon

Date: Wed, 13 Aug 2003 16:23:47 -0700
From: [email-masked] (Julien Pierre)
Subject: Re: dissemination of public encryption certificates
To: "Simon Josefsson" <[email-masked]>
cc: "Alberto Cozer" <[email-masked]>, [email-masked]
Organization: Netscape
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms010704000904080802040505
Content-Type: TEXT/PLAIN; CHARSET=us-ascii

Simon,

Simon Josefsson wrote on 08/12/2003, 4:26:

 > Julien, Alberto,
 >
 > There is a DNS RR for X.509 certificates (and CRLs), see RFC 2538.
 >
 > Unfortunately it doesn't include useful RR owner name guidelines to
 > make it work in practice.  I have made some clarifications for this in
 >
 > http://josefsson.org/draft-josefsson-pkix-dns.txt
 >
 > which also includes recommended owner names for S/MIME certificates.
 >

Thanks. This is very useful and I will look into it.

-- 
I am the dog in dogfood

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

AAAA

--------------ms010704000904080802040505--

Date: Wed, 13 Aug 2003 16:19:36 -0700
From: [email-masked] (Julien Pierre)
Subject: RE: dissemination of public encryption certificates
To: "Hallam-Baker Phillip" <[email-masked]>
cc: [email-masked]
Organization: Netscape
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms010704000904080802040505
Content-Type: TEXT/PLAIN; CHARSET=us-ascii

Philip,

Hallam-Baker, Phillip wrote on 08/11/2003, 16:55:

 >         This issue is one of the main use cases for XKMS. This has
 > considerable support within the PKI community, VeriSign, Microsoft, RSA,
 > Entrust and Baltimore have been involved in writing the specification
 > which is in the final post last call stage in W3C.
 >
 >         The (almost) final spec is to be found at
 >         http://www.w3.org/2001/XKMS/Drafts/XKMS20030804/xkms-part-1.html
 >         http://www.w3.org/2001/XKMS/Drafts/XKMS20030804/xkms-part-2.html
 >
 >         There will be two further changes to the spec, one to make a
 > minor tweak to the schema sometime this week, the second to change the
 > examples to use exclusive C18N.
 >
 >         An XKMS locate service may be advertised in the DNS using the
 > SRV record. So to send mail to [email-masked] you do an XKMS locate
 > to _xkms_http._tcp.example.com.
 > That gives you the XKMS service.
 >
 >         You then do a locate for a certificate to be used with S/MIME.

Thanks. This is very interesting and I will need to read more on XKMS. 
Until I do, you may be able to answer the following question : can the 
XKMS be easily delegated by the domain owner to a third party in the 
DNS, just like mail and web services usually are typically delegated 
today ? It certainly looks like it from the above, but I just want a 
confirmation.

-- 
I am the dog in dogfood

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

AAAA

--------------ms010704000904080802040505--

Date: Wed, 13 Aug 2003 16:16:47 -0700
From: [email-masked] (Julien Pierre)
Subject: RE: trust domains
To: "Alberti Antoine" <[email-masked]>
cc: "[email-masked]'" <[email-masked]>
Organization: Netscape
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms010704000904080802040505
Content-Type: TEXT/PLAIN; CHARSET=us-ascii

Alberti,

Alberti Antoine wrote on 08/11/2003, 1:50:

 > There was such an issue in TLS, solved, from the server point of view, by
 > sending a list of trusted authorities when requesting a client
 > authentication. However, this list was so ennoying to use for both sides
 > that it is now almost always empty, indicating "Send me whatever you
 > want,
 > we'll see then".
 > I agree that a work could be done on this topic, but it should done
 > carefully to avoid this conclusion.

I'm aware of the change that was made recently to TLS to allow an empty 
list of trusted certificates to be sent by the SSL server.  I don't 
personally like this change at all and considered very useful in SSL 
client authentication.

This provision means that to login to such servers, I'm now presented 
with a list of 12 certificates to choose from, with absolutely no hint 
about which one is correct, instead of having the right one 
automatically chosen by the application, or at least a list of valid 
ones if there are several matches. This is what I call shooting oneself 
in the foot. Some server administrators are probably too lazy to install 
the valid trusted roots. My opinion is that they probably shouldn't be 
running PKI servers. Eventually after the client auth login, the code in 
the SSL server is going to have to check if the client certificate is 
valid anyway, and that operation will require the trusted root to be 
installed. If the check does not involve a particular issuing root, 
there are many spoof attacks I can think of against such SSL servers ...

-- 
I am the dog in dogfood

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

AAAA

--------------ms010704000904080802040505--

Date: Wed, 13 Aug 2003 16:10:17 -0700
From: [email-masked] (Julien Pierre)
Subject: RE: trust domains
To: "Blake Ramsdell" <[email-masked]>
cc: [email-masked]
Organization: Netscape
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms010704000904080802040505
Content-Type: TEXT/PLAIN; CHARSET=us-ascii

Blake,

Blake Ramsdell wrote on 08/08/2003, 20:44:
 >
 > This seems to be a question of certificate policies and mapping those to
 > the content being protected.  That is, if the message being signed is
 > just casual communication, use one certificate, and if it's a purchase
 > order, use another one.  Right now, I think that most clients pretty
 > much allow the user to pick.  Further, I think that a lot of folks just
 > have one, so you'd better like it.

It is indeed a question of policy, and the example you point out is a 
good one. Similarly, for internal communications within a company, I 
shouldn't use my freemail Thawte cert. The internal SSL web servers 
which require client auth don't accept that certs.
Yet mail client accept it just fine.

The specific application I'm interested in is e-mail spam filtering 
based on certificates. You could choose to trust some free CAs (such as 
Thawte) if you like to receive anonymous email, otherwise restrict to a 
set of CAs with a more stringent policy (eg. those that require you to 
pay for the certificate).

As far as the number of certificates, I think most folks have zero 
today, not one. Some will have one, issued by their employer (corporate, 
or government/military typically). Then there are hobbyists or security 
professionals like us who may have dozens of certificates. Nowhere does 
Joe User fit today, because PKI is not widely deployed. Most questions 
I'm asking are in the context of a very large-scale PKI deployment 
happening. The problems may not be so obvious unless you get to that point.

 > Well, I'm not sure that the semantic of multiple SignerInfos is that "if
 > you verify them, you must verify all of them, and if you don't like any
 > of them, freak out".  I think it's more along the lines of "these are
 > all equivalent, so go ahead and choose which one you like and run with
 > it".

Where would that be specified ? I would think this would be completely 
up to the application. If I chose to sign mail with both my personal 
cert and corporate cert, I know I wouldn't treat each signature in the 
same way. Eg. if I am an employee, I might not care about the personal 
cert's signature failing, but care about the corporate cert signature.

 > This might be interesting to discuss.  You could make a capabilities
 > extension where you could identify your roots (off the top of my head,
 > I'd say using a hash of the certificate would work) and go from there.
 > One concern is bloat -- I have over 100 roots on my machine configured
 > with Outlook 2002 and IE6 that are all marked as suitable roots for
 > "Secure email" (in the "secure email" trust domain, using your terms).
 > Sending this stack of hashes with every signed message might make the
 > world a worse place to address this issue.

I think it would be a very bad thing to embed all the root certificates 
in each S/MIME signature. The signatures are already quite big enough as 
they are. I know the number of trusted roots can be quite high - it is 
also high in Netscape products.

What I'm getting to is more along the lines of :
1) defining a standard ASN.1 structure to define the user's trusted 
roots policy WRT email. That structure will most likely be too large to 
embed in signatures.

2) there may be a set of rules that goes along with the roots. Just 
having roots trusted may not be right. Eg. my colleagues shouldn't trust 
email signed with my Thawte cert with [email-masked] in it, it 
should be signed with the Netscape CA ... This one I really haven't 
given much thought to.

3) Some mechanism for transporting that trust structure. I would suggest 
LDAP, but that requires a standard mechanism to get to it, just like we 
need a standard means for disseminating certificates

 > I think the principle is the same, though.

It's very similar, with the possible exceptions of the rules (see above).

 > In the case of S/MIME, it's
 > "sign with all of your certs".  One problem is that you're going to
 > potentially cart around a large number of certs -- each of your
 > individual certs as well as the intermediate certs that go with them.
 > And I'm not sure that there's enough experience with clients handling
 > multiple signers to tell you what would happen if you used that feature.

Definitely not today - multiple signatures is something that would need 
to be added to most S/MIME software and would hamper deployment.

 > >From what I can tell, today we solve the problem by having clients
 > include every root key under the sun,

It's worse than that, some SSL intermediate certs are also included with 
some software (IE) ... Many SSL servers are misconfigured and don't send 
their intermediate certs.

 > and most certificates of
 > significant public value are issued under those roots.  Certificates
 > that aren't issued under those roots are most likely corporate CA
 > certificates, and typically folks just have to hunt around to find the
 > right corporate root to install in order to verify the signatures.
 > Peter Hesse and Sharon Boeyen have recently illustrated this problem on
 > the PKIX list -- not directly, but by sending signed messages for which
 > people don't have the root keys.

This is a case where the trust domain could be useful. Eg. the mailing 
list alias could have a defined trust domain, and their software would 
know not to use that private cert when posting to the list.

-- 
I am the dog in dogfood

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

AAAA

--------------ms010704000904080802040505--

To: "Anders Rundgren" <[email-masked]>
Cc: "Blake Ramsdell" <[email-masked]>, <[email-masked]>, "'Sean P. Turner'" <[email-masked]>
Subject: Re: PKI and S/MIME
From: Simon Josefsson <[email-masked]>
Date: Thu, 14 Aug 2003 01:05:53 +0200
Sender: [email-masked]

Anders, you are right, it doesn't solve all problems.  However, in
some situations all you have is the email address of the recipient,
and in those situations locating the certificate through DNS is
simpler than many alternatives.  The certificate can be located
directly, like RFC 2538, or indirectly using SRV pointers to LDAP or
XKMS servers.  In either case, your ISP could add those DNS records as
yet another step in setting up an email account.

One potential advantage of storing certificates directly in DNS a'la
RFC 2538 would be that if we ever get DNSSEC, the certificate you
receive would be integrity protected.  (Whereas a SRV would only
provide you with a integrity protected name of the LDAP host.)

Regards,
Simon

"Anders Rundgren" <[email-masked]> writes:

> Simon,
> I respect your work with DNS for location but is this really
> universal?  How about my [email-masked] cert
> issued by VeriSign?  Would it be appropriate to require ISPs
> like Telia to maintain a directory pointing to various TTP CAs?
>
> Or should ever domain-owner become a CA?
>
> Anders
>
> ----- Original Message ----- 
> From: "Simon Josefsson" <[email-masked]>
> To: "Blake Ramsdell" <[email-masked]>
> Cc: <[email-masked]>; "'Sean P. Turner'" <[email-masked]>
> Sent: Wednesday, August 13, 2003 09:32
> Subject: Re: PKI and S/MIME
>
>
>
> "Blake Ramsdell" <[email-masked]> writes:
>
>> There have been a number of messages recently about the use of PKI with
>> S/MIME, and the concerns about that.  I like to think that we're all
>> pretty much in agreement that we've established a consistent,
>> interoperable practice for the actual syntax and contents of S/MIME
>> messages, as well as a reasonable cut of a certificate syntax profile
>> for end-entity certificates.
>>
>> Should there be a profile for certificate usage (certificate repository,
>> distribution and revocation checking) that is specific for our problem
>> domain?  That is, select relevant other work and profile it for use in
>> the S/MIME interpersonal messaging domain?  I would imagine that this
>> would be a new draft, start with a summary of the requirements, and
>> progress to profiles of relevant standards.
>>
>> It's also not clear if this is something to discuss in this working
>> group, or somewhere else.
>>
>> Comments?
>
> Since in practice, addressing this problem would help in getting
> "opportunistic S/MIME" to work, I believe it would be useful to
> address it.  ("Opportunistic S/MIME" means to be able to encrypt
> messages to someone you don't have a prior trust relationship with,
> simply to provide encryption of data.  There is a man in the middle
> attack, of course, but in practice the result often isn't worse than
> not using S/MIME.)
>
> A strawman at a requirement:
>
> * Be able to locate a certificate for a Internet user given only her
>   email address.
>
> I should mention that this has been discussed several times before, in
> various fora, for similar applications (e.g., OpenPGP, IPSEC, SSH), so
> there is prior work to look at how to design this.  To do even more
> self-promoting, I'd again like to mention the following draft:
>
> http://josefsson.org/draft-josefsson-pkix-dns.txt
>
> which do discuss it for S/MIME context as well.  I don't have an
> opinion on if this WG is the proper place for it.
>
> Regards,
> Simon

Date: Wed, 13 Aug 2003 15:51:44 -0700
From: [email-masked] (Julien Pierre)
Subject: RE: dissemination of public encryption certificates
To: "Blake Ramsdell" <[email-masked]>
cc: [email-masked]
Organization: Netscape
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms010704000904080802040505
Content-Type: TEXT/PLAIN; CHARSET=us-ascii

Blake,

Sorry for the long delay in response - workload goes in spikes...

Blake Ramsdell wrote on 08/08/2003, 19:41:
 > > My main question is : has any similar scheme been proposed ? I would
 > > rather work with something that exists, but if there is nothing that
 > > fits, I'm open to writing an RFC.
 >
 > Check out PKIX.  They're not taking new drafts, but there may be
 > something useful for you there.  Any work along these lines would most
 > likely be handled by that working group.

Thanks. I joined the PKIX list and will keep an eye on the related drafts.

-- 
I am the dog in dogfood

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

AAAA

--------------ms010704000904080802040505--

From: "Blake Ramsdell" <[email-masked]>
To: "'Anders Rundgren'" <[email-masked]>, "'Simon Josefsson'" <[email-masked]>
Cc: <[email-masked]>, "'Sean P. Turner'" <[email-masked]>
Subject: RE: PKI and S/MIME
Date: Wed, 13 Aug 2003 15:05:49 -0700
Importance: Normal
Sender: [email-masked]

> From: Anders Rundgren [mailto:[email-masked]] 
> Sent: Wednesday, August 13, 2003 10:16 AM
> To: Blake Ramsdell; Simon Josefsson
> Cc: [email-masked]; 'Sean P. Turner'
> Subject: Re: PKI and S/MIME
> 
> I respect your work with DNS for location but is this really
> universal?  How about my [email-masked] cert
> issued by VeriSign?  Would it be appropriate to require ISPs
> like Telia to maintain a directory pointing to various TTP CAs?
> 
> Or should ever domain-owner become a CA?

One thing to keep in mind is that I'm not sure that there is any clear
"universality" for *any* protocol that we might consider -- if there
existed something universal, we'd have a de facto standard that we'd
simply convert to an RFC and be done with it.

If I were going to hazard a guess about widely deployed public
certificate repositories, I would say that there would be a better
argument for LDAP than anything else.  Notice the careful wording here
;).  As much as the attempts to automatically map from an email address
to an LDAP directory containing a certificate for that email address
might not have progressed as well as we might like, I think that there
is some hope of that being addressed through the SRV record which is (as
far as I can tell) widely supported by DNS implementations.

A better question for the DNS distribution of certificates is whether or
not this smells like it would be the most likely thing to get deployed.
My understanding is that you would need DNS servers that supported the
particular record types required for this functionality, as well as
administrative tools to upgrade those records that are different than
typical DNS administration tools.  To me, that doesn't smell as good.

Blake

From: "Anders Rundgren" <[email-masked]>
To: "Blake Ramsdell" <[email-masked]>, "Simon Josefsson" <[email-masked]>
Cc: <[email-masked]>, "'Sean P. Turner'" <[email-masked]>
Subject: Re: PKI and S/MIME
Date: Wed, 13 Aug 2003 19:16:22 +0200
Sender: [email-masked]

Simon,
I respect your work with DNS for location but is this really
universal?  How about my [email-masked] cert
issued by VeriSign?  Would it be appropriate to require ISPs
like Telia to maintain a directory pointing to various TTP CAs?

Or should ever domain-owner become a CA?

Anders

----- Original Message ----- 
From: "Simon Josefsson" <[email-masked]>
To: "Blake Ramsdell" <[email-masked]>
Cc: <[email-masked]>; "'Sean P. Turner'" <[email-masked]>
Sent: Wednesday, August 13, 2003 09:32
Subject: Re: PKI and S/MIME

"Blake Ramsdell" <[email-masked]> writes:

> There have been a number of messages recently about the use of PKI with
> S/MIME, and the concerns about that.  I like to think that we're all
> pretty much in agreement that we've established a consistent,
> interoperable practice for the actual syntax and contents of S/MIME
> messages, as well as a reasonable cut of a certificate syntax profile
> for end-entity certificates.
>
> Should there be a profile for certificate usage (certificate repository,
> distribution and revocation checking) that is specific for our problem
> domain?  That is, select relevant other work and profile it for use in
> the S/MIME interpersonal messaging domain?  I would imagine that this
> would be a new draft, start with a summary of the requirements, and
> progress to profiles of relevant standards.
>
> It's also not clear if this is something to discuss in this working
> group, or somewhere else.
>
> Comments?

Since in practice, addressing this problem would help in getting
"opportunistic S/MIME" to work, I believe it would be useful to
address it.  ("Opportunistic S/MIME" means to be able to encrypt
messages to someone you don't have a prior trust relationship with,
simply to provide encryption of data.  There is a man in the middle
attack, of course, but in practice the result often isn't worse than
not using S/MIME.)

A strawman at a requirement:

* Be able to locate a certificate for a Internet user given only her
  email address.

I should mention that this has been discussed several times before, in
various fora, for similar applications (e.g., OpenPGP, IPSEC, SSH), so
there is prior work to look at how to design this.  To do even more
self-promoting, I'd again like to mention the following draft:

http://josefsson.org/draft-josefsson-pkix-dns.txt

which do discuss it for S/MIME context as well.  I don't have an
opinion on if this WG is the proper place for it.

Regards,
Simon

To: "Blake Ramsdell" <[email-masked]>
Cc: <[email-masked]>, "'Sean P. Turner'" <[email-masked]>
Subject: Re: PKI and S/MIME
From: Simon Josefsson <[email-masked]>
Date: Wed, 13 Aug 2003 09:32:16 +0200
Sender: [email-masked]

"Blake Ramsdell" <[email-masked]> writes:

> There have been a number of messages recently about the use of PKI with
> S/MIME, and the concerns about that.  I like to think that we're all
> pretty much in agreement that we've established a consistent,
> interoperable practice for the actual syntax and contents of S/MIME
> messages, as well as a reasonable cut of a certificate syntax profile
> for end-entity certificates.
>
> Should there be a profile for certificate usage (certificate repository,
> distribution and revocation checking) that is specific for our problem
> domain?  That is, select relevant other work and profile it for use in
> the S/MIME interpersonal messaging domain?  I would imagine that this
> would be a new draft, start with a summary of the requirements, and
> progress to profiles of relevant standards.
>
> It's also not clear if this is something to discuss in this working
> group, or somewhere else.
>
> Comments?

Since in practice, addressing this problem would help in getting
"opportunistic S/MIME" to work, I believe it would be useful to
address it.  ("Opportunistic S/MIME" means to be able to encrypt
messages to someone you don't have a prior trust relationship with,
simply to provide encryption of data.  There is a man in the middle
attack, of course, but in practice the result often isn't worse than
not using S/MIME.)

A strawman at a requirement:

* Be able to locate a certificate for a Internet user given only her
  email address.

I should mention that this has been discussed several times before, in
various fora, for similar applications (e.g., OpenPGP, IPSEC, SSH), so
there is prior work to look at how to design this.  To do even more
self-promoting, I'd again like to mention the following draft:

http://josefsson.org/draft-josefsson-pkix-dns.txt

which do discuss it for S/MIME context as well.  I don't have an
opinion on if this WG is the proper place for it.

Regards,
Simon

From: "Blake Ramsdell" <[email-masked]>
To: <[email-masked]>
Cc: "'Sean P. Turner'" <[email-masked]>
Subject: PKI and S/MIME
Date: Tue, 12 Aug 2003 19:47:28 -0700
Importance: Normal
Sender: [email-masked]

There have been a number of messages recently about the use of PKI with
S/MIME, and the concerns about that.  I like to think that we're all
pretty much in agreement that we've established a consistent,
interoperable practice for the actual syntax and contents of S/MIME
messages, as well as a reasonable cut of a certificate syntax profile
for end-entity certificates.

Should there be a profile for certificate usage (certificate repository,
distribution and revocation checking) that is specific for our problem
domain?  That is, select relevant other work and profile it for use in
the S/MIME interpersonal messaging domain?  I would imagine that this
would be a new draft, start with a summary of the requirements, and
progress to profiles of relevant standards.

It's also not clear if this is something to discuss in this working
group, or somewhere else.

Comments?

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

From: "Anders Rundgren" <[email-masked]>
To: "Julien Pierre" <[email-masked]>, <[email-masked]>
Cc: "Hallam-Baker, Phillip" <[email-masked]>
Subject: Re: dissemination of public encryption certificates
Date: Tue, 12 Aug 2003 18:31:53 +0200
Sender: [email-masked]

Pierre,
It is good to hear somebody bring up this question which is absolutely
vital for successful deployment of encrypted mail.

Personally I don't think that neither the S/MIME WG or XKMS WG
have a solution that at least I would call "acceptable".

XKMS addresses to some extent the enterprise scenario but only
if the enterprise has their own domain and associated CA.  For
truly TTP-based certificates you are out of luck if you are looking
for automated functionality.

I believe that the mail protocol and associated applications
should be augmented with encryption certificate lookup. A
MIME X-extension that you configured in your e-mail client
would do a part of this.  I.e. each time you sent a mail, the
lookup would be transmitted as well.   Also it would be
nice to have an enhanced "mailto:" URL supporting the same
mechanism.

In summary I think that a certificate-independent configuration
of e-mail clients would be more universal than "fishing" in
domains as the user domain and issuer domain may be entirely
disjunct.

Anders

----- Original Message ----- 
From: "Hallam-Baker, Phillip" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Sent: Tuesday, August 12, 2003 01:55
Subject: RE: dissemination of public encryption certificates

Hi,

This issue is one of the main use cases for XKMS. This has
considerable support within the PKI community, VeriSign, Microsoft, RSA,
Entrust and Baltimore have been involved in writing the specification
which is in the final post last call stage in W3C.

The (almost) final spec is to be found at 
http://www.w3.org/2001/XKMS/Drafts/XKMS20030804/xkms-part-1.html
http://www.w3.org/2001/XKMS/Drafts/XKMS20030804/xkms-part-2.html

There will be two further changes to the spec, one to make a
minor tweak to the schema sometime this week, the second to change the
examples to use exclusive C18N.

An XKMS locate service may be advertised in the DNS using the
SRV record. So to send mail to [email-masked] you do an XKMS locate
to _xkms_http._tcp.example.com.
That gives you the XKMS service.

You then do a locate for a certificate to be used with S/MIME.

Phill

> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, August 08, 2003 10:07 PM
> To: [email-masked]
> Subject: dissemination of public encryption certificates
> 
> 
> Hi,
> 
> Since this is my first posting to this mailing list, let me introduce 
> myself :
> 
> I'm a software engineer in AOL / Netscape and one of my 
> responsibilities 
> for several years has been to maintain the open source 
> Netscape Security 
> Services (NSS) library, which is used in the Mozilla browsers, many 
> Netscape and Sun servers, and other internal products. The 
> NSS library 
> contains an implementation of S/MIME v3.
> 
> I was wondering what thoughts you may have on the following problem :
> 
> If I have a keypair and e-mail certificate, and I want to 
> send encrypted 
> e-mail to somebody knowing his e-mail address, what's a 
> systematic way 
> to obtain the recipient's encryption certificate ?
> 
> Traditionally today, signed e-mail messages typically contain the 
> signer's public encryption certificate. However that means one party 
> needs to first send a signed unencrypted, e-mail message to 
> transmit the 
> public encryption certificate before both parties can 
> exchange encrypted 
> messages.
> 
> There are also ways to find recipient certificates today 
> using corporate 
> directory servers, but users must know about them and 
> manually configure 
> them in their applications, and they are typically not widely 
> available 
> on the Internet.
> 
> I'm envisioning some standardized scheme where, by starting with the 
> recipient's email address, it would be possible to locate a public 
> directory server, then find the recipient's certificate by 
> looking it up 
> in that directory server.
> 
> My main question is : has any similar scheme been proposed ? I would 
> rather work with something that exists, but if there is nothing that 
> fits, I'm open to writing an RFC.
> 
> Also, what are the other ways that people locate recipient 
> S/MIME e-mail 
> encryption certificates ?
> 
> Thanks.
> 
> 
> 

To: "Alberto Cozer" <[email-masked]>
Cc: [email-masked] (Julien Pierre), [email-masked]
Subject: Re: dissemination of public encryption certificates
From: Simon Josefsson <[email-masked]>
Date: Tue, 12 Aug 2003 13:26:15 +0200
Sender: [email-masked]

Julien, Alberto,

There is a DNS RR for X.509 certificates (and CRLs), see RFC 2538.

Unfortunately it doesn't include useful RR owner name guidelines to
make it work in practice.  I have made some clarifications for this in

http://josefsson.org/draft-josefsson-pkix-dns.txt

which also includes recommended owner names for S/MIME certificates.

The document has expired on the IETF servers, but if there is interest
in picking up this, let me know.

(The idea has been implemented in experimental environments.  Similar
solutions for OpenPGP are freely available.  I did my master's thesis
on distributing certificate via DNS, to allow for "opportunistic email
encryption".)

Regards,
Simon

"Alberto Cozer" <[email-masked]> writes:

> Julien,
>
> I have seen this idea in the past, but so far no RFC nor any agency 
> officialy documented it. We should have an hierarchical structure for 
> public directories, similar to the DNS hierarchy. Maybe the DNS hierarchy 
> itself could be used for that. We could have a new DNS record type (DRY, 
> from Directory, for instance). Then, as mail servers and clients consult 
> MX record to deliver a message they could check for the DRY record to 
> deliver S/MIME messages. Without this DRY record set in the DNS zone file, 
> must be possible to deliver a signed message but impossible to deliver an 
> encrypted one. 
>
> In my oppinion it is really hard to solve the public keys problem without 
> changing the way people send e-mails. With minor changes in the DNS and 
> E-MAIL RFC's would be possible to have people sending and receiving 
> encrypted mail transparently in a couple of years. 
>
> Best regards,
>
> Alberto Cozer
> Security Outsource Director, Future Technologies Digital Security
> IBM Certified AIX System Specialist
> Checkpoint Certified Security Expert, CCSE NG
> [email-masked]
> http://www.fti.com.br
> Tel / Fax: 55 (21) 2522-5362
>
>
>
>
>
>
> [email-masked] (Julien Pierre)
> Sent by: [email-masked]
> 08/08/2003 23:07
>  
>         To:     [email-masked]
>         cc: 
>         Subject:        dissemination of public encryption certificates
>
>
> Hi,
>
> Since this is my first posting to this mailing list, let me introduce 
> myself :
>
> I'm a software engineer in AOL / Netscape and one of my responsibilities 
> for several years has been to maintain the open source Netscape Security 
> Services (NSS) library, which is used in the Mozilla browsers, many 
> Netscape and Sun servers, and other internal products. The NSS library 
> contains an implementation of S/MIME v3.
>
> I was wondering what thoughts you may have on the following problem :
>
> If I have a keypair and e-mail certificate, and I want to send encrypted 
> e-mail to somebody knowing his e-mail address, what's a systematic way 
> to obtain the recipient's encryption certificate ?
>
> Traditionally today, signed e-mail messages typically contain the 
> signer's public encryption certificate. However that means one party 
> needs to first send a signed unencrypted, e-mail message to transmit the 
> public encryption certificate before both parties can exchange encrypted 
> messages.
>
> There are also ways to find recipient certificates today using corporate 
> directory servers, but users must know about them and manually configure 
> them in their applications, and they are typically not widely available 
> on the Internet.
>
> I'm envisioning some standardized scheme where, by starting with the 
> recipient's email address, it would be possible to locate a public 
> directory server, then find the recipient's certificate by looking it up 
> in that directory server.
>
> My main question is : has any similar scheme been proposed ? I would 
> rather work with something that exists, but if there is nothing that 
> fits, I'm open to writing an RFC.
>
> Also, what are the other ways that people locate recipient S/MIME e-mail 
> encryption certificates ?
>
> Thanks.

From: "Hallam-Baker, Phillip" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, [email-masked]
Subject: RE: dissemination of public encryption certificates
Date: Mon, 11 Aug 2003 16:55:50 -0700
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0034_01C36042.904784A0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi,

	This issue is one of the main use cases for XKMS. This has
considerable support within the PKI community, VeriSign, Microsoft, RSA,
Entrust and Baltimore have been involved in writing the specification
which is in the final post last call stage in W3C.

	The (almost) final spec is to be found at 
	http://www.w3.org/2001/XKMS/Drafts/XKMS20030804/xkms-part-1.html
	http://www.w3.org/2001/XKMS/Drafts/XKMS20030804/xkms-part-2.html

	There will be two further changes to the spec, one to make a
minor tweak to the schema sometime this week, the second to change the
examples to use exclusive C18N.

	An XKMS locate service may be advertised in the DNS using the
SRV record. So to send mail to [email-masked] you do an XKMS locate
to _xkms_http._tcp.example.com.
That gives you the XKMS service.

	You then do a locate for a certificate to be used with S/MIME.

		Phill

> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, August 08, 2003 10:07 PM
> To: [email-masked]
> Subject: dissemination of public encryption certificates
> 
> 
> Hi,
> 
> Since this is my first posting to this mailing list, let me introduce 
> myself :
> 
> I'm a software engineer in AOL / Netscape and one of my 
> responsibilities 
> for several years has been to maintain the open source 
> Netscape Security 
> Services (NSS) library, which is used in the Mozilla browsers, many 
> Netscape and Sun servers, and other internal products. The 
> NSS library 
> contains an implementation of S/MIME v3.
> 
> I was wondering what thoughts you may have on the following problem :
> 
> If I have a keypair and e-mail certificate, and I want to 
> send encrypted 
> e-mail to somebody knowing his e-mail address, what's a 
> systematic way 
> to obtain the recipient's encryption certificate ?
> 
> Traditionally today, signed e-mail messages typically contain the 
> signer's public encryption certificate. However that means one party 
> needs to first send a signed unencrypted, e-mail message to 
> transmit the 
> public encryption certificate before both parties can 
> exchange encrypted 
> messages.
> 
> There are also ways to find recipient certificates today 
> using corporate 
> directory servers, but users must know about them and 
> manually configure 
> them in their applications, and they are typically not widely 
> available 
> on the Internet.
> 
> I'm envisioning some standardized scheme where, by starting with the 
> recipient's email address, it would be possible to locate a public 
> directory server, then find the recipient's certificate by 
> looking it up 
> in that directory server.
> 
> My main question is : has any similar scheme been proposed ? I would 
> rather work with something that exists, but if there is nothing that 
> fits, I'm open to writing an RFC.
> 
> Also, what are the other ways that people locate recipient 
> S/MIME e-mail 
> encryption certificates ?
> 
> Thanks.
> 
> 
> 

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

------=_NextPart_000_0034_01C36042.904784A0--

To: [email-masked] (Julien Pierre)
Cc: [email-masked], [email-masked]
Subject: Re: dissemination of public encryption certificates
From: "Alberto Cozer" <[email-masked]>
Date: Tue, 12 Aug 2003 18:19:00 -0300
Sender: [email-masked]

This is an S/MIME signed message.

---------z2829_boundary_sign
Content-Type: multipart/alternative; boundary="=_alternative 0074EFA583256D7F_="

This is a multipart message in MIME format.
--=_alternative 0074EFA583256D7F_=
Content-Type: text/plain; charset="US-ASCII"

Julien,

I have seen this idea in the past, but so far no RFC nor any agency 
officialy documented it. We should have an hierarchical structure for 
public directories, similar to the DNS hierarchy. Maybe the DNS hierarchy 
itself could be used for that. We could have a new DNS record type (DRY, 
from Directory, for instance). Then, as mail servers and clients consult 
MX record to deliver a message they could check for the DRY record to 
deliver S/MIME messages. Without this DRY record set in the DNS zone file, 
must be possible to deliver a signed message but impossible to deliver an 
encrypted one. 

In my oppinion it is really hard to solve the public keys problem without 
changing the way people send e-mails. With minor changes in the DNS and 
E-MAIL RFC's would be possible to have people sending and receiving 
encrypted mail transparently in a couple of years. 

Best regards,

Alberto Cozer
Security Outsource Director, Future Technologies Digital Security
IBM Certified AIX System Specialist
Checkpoint Certified Security Expert, CCSE NG
[email-masked]
http://www.fti.com.br
Tel / Fax: 55 (21) 2522-5362

[email-masked] (Julien Pierre)
Sent by: [email-masked]
08/08/2003 23:07
 
        To:     [email-masked]
        cc: 
        Subject:        dissemination of public encryption certificates

Hi,

Since this is my first posting to this mailing list, let me introduce 
myself :

I'm a software engineer in AOL / Netscape and one of my responsibilities 
for several years has been to maintain the open source Netscape Security 
Services (NSS) library, which is used in the Mozilla browsers, many 
Netscape and Sun servers, and other internal products. The NSS library 
contains an implementation of S/MIME v3.

I was wondering what thoughts you may have on the following problem :

If I have a keypair and e-mail certificate, and I want to send encrypted 
e-mail to somebody knowing his e-mail address, what's a systematic way 
to obtain the recipient's encryption certificate ?

Traditionally today, signed e-mail messages typically contain the 
signer's public encryption certificate. However that means one party 
needs to first send a signed unencrypted, e-mail message to transmit the 
public encryption certificate before both parties can exchange encrypted 
messages.

There are also ways to find recipient certificates today using corporate 
directory servers, but users must know about them and manually configure 
them in their applications, and they are typically not widely available 
on the Internet.

I'm envisioning some standardized scheme where, by starting with the 
recipient's email address, it would be possible to locate a public 
directory server, then find the recipient's certificate by looking it up 
in that directory server.

My main question is : has any similar scheme been proposed ? I would 
rather work with something that exists, but if there is nothing that 
fits, I'm open to writing an RFC.

Also, what are the other ways that people locate recipient S/MIME e-mail 
encryption certificates ?

Thanks.

--=_alternative 0074EFA583256D7F_=
Content-Type: text/html; charset="US-ASCII"

<br><font size=2 face="sans-serif">Julien,</font>
<br>
<br><font size=2 face="sans-serif">I have seen this idea in the past, but
so far no RFC nor any agency officialy documented it. We should have an
hierarchical structure for public directories, similar to the DNS hierarchy.
Maybe the DNS hierarchy itself could be used for that. We could have a
new DNS record type (DRY, from Directory, for instance). Then, as mail
servers and clients consult MX record to deliver a message they could check
for the DRY record to deliver S/MIME messages. Without this DRY record
set in the DNS zone file, must be possible to deliver a signed message
but impossible to deliver an encrypted one. </font>
<br>
<br><font size=2 face="sans-serif">In my oppinion it is really hard to
solve the public keys problem without changing the way people send e-mails.
With minor changes in the DNS and E-MAIL RFC's would be possible to have
people sending and receiving encrypted mail transparently in a couple of
years. </font>
<br>
<br><font size=2 face="sans-serif">Best regards,</font>
<br>
<br><font size=2 face="sans-serif">Alberto Cozer<br>
Security Outsource Director, Future Technologies Digital Security<br>
IBM Certified AIX System Specialist<br>
Checkpoint Certified Security Expert, CCSE NG<br>
[email-masked]<br>
http://www.fti.com.br<br>
Tel / Fax: 55 (21) 2522-5362<br>
<br>
</font>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td>
<td><font size=1 face="sans-serif"><b>[email-masked] (Julien Pierre)</b></font>
<br><font size=1 face="sans-serif">Sent by: [email-masked]</font>
<p><font size=1 face="sans-serif">08/08/2003 23:07</font>
<td><font size=1 face="Arial">&nbsp; &nbsp; &nbsp; &nbsp; </font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; To:
&nbsp; &nbsp; &nbsp; &nbsp;[email-masked]</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; cc:
&nbsp; &nbsp; &nbsp; &nbsp;</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; Subject:
&nbsp; &nbsp; &nbsp; &nbsp;dissemination of public encryption certificates</font></table>
<br>
<br>
<br><font size=2><tt>Hi,<br>
<br>
Since this is my first posting to this mailing list, let me introduce <br>
myself :<br>
<br>
I'm a software engineer in AOL / Netscape and one of my responsibilities
<br>
for several years has been to maintain the open source Netscape Security
<br>
Services (NSS) library, which is used in the Mozilla browsers, many <br>
Netscape and Sun servers, and other internal products. The NSS library
<br>
contains an implementation of S/MIME v3.<br>
<br>
I was wondering what thoughts you may have on the following problem :<br>
<br>
If I have a keypair and e-mail certificate, and I want to send encrypted
<br>
e-mail to somebody knowing his e-mail address, what's a systematic way
<br>
to obtain the recipient's encryption certificate ?<br>
<br>
Traditionally today, signed e-mail messages typically contain the <br>
signer's public encryption certificate. However that means one party <br>
needs to first send a signed unencrypted, e-mail message to transmit the
<br>
public encryption certificate before both parties can exchange encrypted
<br>
messages.<br>
<br>
There are also ways to find recipient certificates today using corporate
<br>
directory servers, but users must know about them and manually configure
<br>
them in their applications, and they are typically not widely available
<br>
on the Internet.<br>
<br>
I'm envisioning some standardized scheme where, by starting with the <br>
recipient's email address, it would be possible to locate a public <br>
directory server, then find the recipient's certificate by looking it up
<br>
in that directory server.<br>
<br>
My main question is : has any similar scheme been proposed ? I would <br>
rather work with something that exists, but if there is nothing that <br>
fits, I'm open to writing an RFC.<br>
<br>
Also, what are the other ways that people locate recipient S/MIME e-mail
<br>
encryption certificates ?<br>
<br>
Thanks.<br>
<br>
<br>
</tt></font>
<br>
--=_alternative 0074EFA583256D7F_=--

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

---------z2829_boundary_sign--

Reply-To: <[email-masked]>
From: "Jim Schaad" <[email-masked]>
To: "'Blake Ramsdell'" <[email-masked]>, <[email-masked]>, "'Ietf-Smime-Examples'" <[email-masked]>, <[email-masked]>, "'Paul Hoffman / IMC'" <[email-masked]>
Cc: "'Sean P. Turner'" <[email-masked]>
Subject: RE: Draft-11: More complete results
Date: Mon, 11 Aug 2003 11:49:34 -0700
Importance: Normal
Sender: [email-masked]

Blake,

I don't know what I dumped the first time, but I now get the same CEKICV
as you do.

jim

> From: Blake Ramsdell [mailto:[email-masked]] 
> Sent: Saturday, August 09, 2003 1:17 AM
> To: [email-masked]; 'Ietf-Smime-Examples'; 
> [email-masked]; 'Paul Hoffman / IMC'
> Cc: 'Sean P. Turner'
> Subject: RE: Draft-11: More complete results
> 
> 
> > From: Jim Schaad [mailto:[email-masked]]
> > Sent: Wednesday, August 06, 2003 2:30 PM
> > To: 'Ietf-Smime-Examples'; [email-masked]; 'Paul Hoffman / IMC'
> > Cc: 'Sean P. Turner'; Blake Ramsdell
> > Subject: Draft-11: More complete results
> > 
> > 6.11	FAILED
> > 	test vectors are appended below on this message.  I 
> don't know where 
> > I am going wrong and this code worked in the past.
> 
> The bad news is, I can't get this example to work either.  
> The good news is that I have written a new implementation, 
> and it could very well have some kind of problem.  I have 
> only tested my implementation against the test vectors in RFC 3217.
> 
> These are the results that I got with this example, using the 
> terminology from RFC 3217 section 3.2 wherever possible:
> 
> <lotsofboringhexdump>
> wrappedKey = 0x74, 0x31, 0xC0, 0x45, 0x51, 0x4C, 0x3C, 0x2D, 
> 0x2E, 0xDA, 0x63, 0x50, 0x8B, 0xAE, 0xD4, 0xAC, 0x64, 0xCC, 
> 0x95, 0xAE, 0xAF, 0xCD, 0x0F, 0x8C, 0xB6, 0x48, 0x1F, 0x0B, 
> 0x45, 0x12, 0x4D, 0xFB, 0xA4, 0xAB, 0xC7, 0x83, 0x30, 0x4B, 0x69, 0xAD
> 
> TEMP3 = 0xD7, 0x10, 0x66, 0xEE, 0x9A, 0x42, 0xE0, 0x80, 0x62, 
> 0xA3, 0xE5, 0xDE, 0xB5, 0xEF, 0x4E, 0x7E, 0x5F, 0x13, 0x30, 
> 0xB5, 0x13, 0xD3, 0xA8, 0x4F, 0xBE, 0xDC, 0x02, 0xD4, 0x81, 
> 0x27, 0xDB, 0x50, 0xE5, 0xD8, 0x0F, 0xE9, 0x25, 0x38, 0xF1, 0x7B
> 
> TEMP2 = 0x7B, 0xF1, 0x38, 0x25, 0xE9, 0x0F, 0xD8, 0xE5, 0x50, 
> 0xDB, 0x27, 0x81, 0xD4, 0x02, 0xDC, 0xBE, 0x4F, 0xA8, 0xD3, 
> 0x13, 0xB5, 0x30, 0x13, 0x5F, 0x7E, 0x4E, 0xEF, 0xB5, 0xDE, 
> 0xE5, 0xA3, 0x62, 0x80, 0xE0, 0x42, 0x9A, 0xEE, 0x66, 0x10, 0xD7
> 
> TEMP1 = 0x50, 0xDB, 0x27, 0x81, 0xD4, 0x02, 0xDC, 0xBE, 0x4F, 
> 0xA8, 0xD3, 0x13, 0xB5, 0x30, 0x13, 0x5F, 0x7E, 0x4E, 0xEF, 
> 0xB5, 0xDE, 0xE5, 0xA3, 0x62, 0x80, 0xE0, 0x42, 0x9A, 0xEE, 
> 0x66, 0x10, 0xD7
> 
> IV = 0x7B, 0xF1, 0x38, 0x25, 0xE9, 0x0F, 0xD8, 0xE5
> 
> CEKICV = 0x51, 0x1B, 0x27, 0x0E, 0xE8, 0xEA, 0x33, 0x74, 
> 0x37, 0xA5, 0x7D, 0xC7, 0xCC, 0x9B, 0x24, 0xCE, 0x32, 0x41, 
> 0x19, 0x0F, 0x38, 0x47, 0x25, 0x2E, 0xC0, 0xCA, 0x0F, 0x30, 
> 0x3B, 0x86, 0x2E, 0x3D
> 
> CEK = 0x51, 0x1B, 0x27, 0x0E, 0xE8, 0xEA, 0x33, 0x74, 0x37, 
> 0xA5, 0x7D, 0xC7, 0xCC, 0x9B, 0x24, 0xCE, 0x32, 0x41, 0x19, 
> 0x0F, 0x38, 0x47, 0x25, 0x2E
> 
> ICV = 0xC0, 0xCA, 0x0F, 0x30, 0x3B, 0x86, 0x2E, 0x3D
> 
> computedICV = 0x53, 0xFB, 0x3E, 0xCC, 0x8A, 0x06, 0xCC, 0xAF 
> </lotsofboringhexdump>
> 
> Mapping your results onto mine:
> 
> > Wrapped key
> > 0x0012F248  74 31 c0 45 51 4c 3c 2d 2e da 63 50 8b ae d4 ac 
> > t1�EQL<-.�cP.�Ԭ 0x0012F258  64 cc 95 ae af cd 0f 8c b6 48 
> 1f 0b 45 12 
> > 4d fb d�.���..�H..E.M.
> > 0x0012F268  a4 ab c7 83 30 4b 69 ad                         ���.0Ki�
> > 
> > Mail list key
> > 0x00324354  25 5e 0d 1c 07 b6 46 df b3 13 4c c8 43 ba 8a a7 
> > %^...�F߳.L�C�.� 0x00324364  1f 02 5b 7c 08 38 25 1f
> 
> We're on the same page here.  I did not dump my Mail list 
> key, but there are many problems I would have later if these 
> weren't the same. Specifically, the next item would not match.
> 
> > After decrypt #1
> > 0x00324630  d7 10 66 ee 9a 42 e0 80 62 a3 e5 de b5 ef 4e 7e 
> > �.f..B..b�.޵.N~ 0x00324640  5f 13 30 b5 13 d3 a8 4f be dc 
> 02 d4 81 27 
> > db 50 _.0�.ӨO��.�.'�P
> > 0x00324650  e5 d8 0f e9 25 38 f1 7b                         .�..%8.{
> 
> Same as TEMP3 from mine.
> 
> > IV
> > 0x00324630  7b f1 38 25 e9 0f d8 e5                         {.8%..�.
> 
> Same as my IV also.
> 
> > Post Decrypt #2
> > 0x00324630  50 db 27 81 d4 02 dc be 4f a8 d3 13 b5 30 13 5f 
> > P�'.�.ܾO��.�0._ 0x00324640  7e 4e ef b5 de e5 a3 62 80 e0 
> 42 9a ee 66 
> > 10 d7 ~N.��.�b..B..f.�
> 
> This should theoretically be the same as my CEKICV (which is 
> the output of the second decryption), but it's not.  This 
> appears to be the same as my TEMP1 which is the input to the 
> second decryption, not the output.
> 
> > Computed check sum
> > 0x0012EFD8  53 fb 3e cc 8a 06 cc af                         S.>�..̯
> 
> Same as my computedICV above.  What I can't figure out is how 
> we both arrived at the same checksum with such different 
> answers for CEKICV (your "Post Decrypt #2").  My 
> understanding is that it's the first eight bytes of the sha-1 
> digest of the first 24 bytes of my CEKICV and your "Post Decrypt #2".
> 
> > Actual Check sum
> >  80 e0 42 9a ee 66 10 d7
> 
> This does not match my ICV above, but it matches the eight 
> bytes at the end of your "Post Decrypt #2".
> 
> I would hazard a guess that there is an error in one of our 
> implementations where the input and the output of the second 
> decryption step are being mistakenly interchanged.  I have 
> checked mine and run the test vectors from RFC 3217 through 
> it, and I can't see the problem on my side.  Now, I've said 
> this kind of thing before and been wrong, so take it with a 
> grain of salt...
> 
> In any case, in my test, this example is broken also, but 
> unless Jim and I can agree on an answer, it could be the case 
> that both of our implementations are broken.
> 
> Blake
> 

From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: RE: Update of CMS-X.400 Drafts
Date: Mon, 11 Aug 2003 13:15:48 -0400
Sender: [email-masked]

Hi Chris,

Cheers,

Francois

-----Original Message-----
From: Bonatti, Chris [mailto:[email-masked]]
Sent: Saturday, August 09, 2003 11:32 AM
To: [email-masked]
Subject: Update of CMS-X.400 Drafts

Cheers!
Chris

Done.

Done.

Done.

Done.

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-x400transport-09.txt
Date: Mon, 11 Aug 2003 12:29:26 -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		: Transporting S/MIME Objects in X.400
	Author(s)	: P. Hoffman, C. Bonatti
	Filename	: draft-ietf-smime-x400transport-09.txt
	Pages		: 6
	Date		: 2003-8-8
	
This document describes protocol options for conveying CMS-protected
objects associated with S/MIME version 3 over an X.400 message transfer
system.

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

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

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

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-smime-x400transport-09.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-x400wrap-08.txt
Date: Mon, 11 Aug 2003 12:29:22 -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		: Securing X.400 Content with S/MIME
	Author(s)	: P. Hoffman, C. Bonatti, A. Eggen
	Filename	: draft-ietf-smime-x400wrap-08.txt
	Pages		: 11
	Date		: 2003-8-8
	
This document describes a protocol for adding cryptographic signature
and encryption services to X.400 content.

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

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

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

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

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

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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-smime-x400wrap-08.txt

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

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

--OtherAccess--

--NextPart--

From: Alberti Antoine <[email-masked]>
To: "'Julien Pierre'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: trust domains
Date: Mon, 11 Aug 2003 10:50:00 +0200
Sender: [email-masked]

There was such an issue in TLS, solved, from the server point of view, by
sending a list of trusted authorities when requesting a client
authentication. However, this list was so ennoying to use for both sides
that it is now almost always empty, indicating "Send me whatever you want,
we'll see then".
I agree that a work could be done on this topic, but it should done
carefully to avoid this conclusion.
Regards.

-----Message d'origine-----
De : [email-masked]
[mailto:[email-masked]]De la part de Julien Pierre
Envoye : samedi 9 aout 2003 04:43
A : [email-masked]
Objet : trust domains

Hi,

Here is another problem with S/MIME deployment that I'd like to inquire 
about.

Assuming that you have already obtained my public encryption 
certificate, for example by reading this message, there is no way for 
you to be certain what type of certificate I will trust if you send me 
e-mail, in particular what CAs I trust.

If you have multiple certificates from different CAs, which one is the 
most appropriate to use when writing me writing signed and encrypted 
e-mail ?

Nowadays, in Netscape applications (and in the new AOL communicator), 
each user can make a decision of which CAs he trusts for signing each 
type of certificate (SSL server, SSL client, email signing, email 
encryption ...). I call this set of CAs and the trust properties a 
user's "trust domain".

Unlike an email certificate which is typically included in an S/MIME 
message's digital signature, my trust domain is not exposed to you.

The only clue that you have when writing to me is that I probably trust 
the same Thawte freemail CA that issued my own public encryption 
certificate. However, if I had signed this message with my corporate 
certificate (and if my smartcard was working right now:)), you would not 
be able to get a certificate from the same CA, unless you were employed 
by the same company.

One theoretical answer to the problem would be for you to sign your 
message with all the certificates you have, including multiple 
signatures, in the hope I would trust one. Today our mail clients only 
support a single signature, so that wouldn't work. But even if they did 
tomorrow, the software trust policy might be to not trust the message 
unless all its signatures are valid, so having one good signature and n 
bad signatures wouldn't help. You might send your message n times, each 
signed with a different certificate, but I would probably get annoyed.

What I'm getting at is that there is a need to make the user's trust 
domain information available, so that senders get a hint of the proper 
certificate to use.

This is similar to what happens in the SSL protocol when an SSL server 
requests client authentication. The SSL server provides a list of 
trusted CA certificates. The SSL client is then free to choose one to 
use if he has one that chains to a CA the server accepts. Of course the 
problem was easier to solve for SSL, since it is an online protocol, and 
S/MIME is not.

My question is : is there any work going within the IETF to solve this 
problem for the S/MIME protocol ? And how have you been solving this 
problem today ?

From: Alberti Antoine <[email-masked]>
To: "'Julien Pierre'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: dissemination of public encryption certificates
Date: Mon, 11 Aug 2003 10:35:39 +0200
Sender: [email-masked]

I believe some work is being done about this issue and DNS in the PKIX
working group.
Regards.

-----Message d'origine-----
De : [email-masked]
[mailto:[email-masked]]De la part de Julien Pierre
Envoye : samedi 9 aout 2003 04:07
A : [email-masked]
Objet : dissemination of public encryption certificates

Hi,

Since this is my first posting to this mailing list, let me introduce 
myself :

I'm a software engineer in AOL / Netscape and one of my responsibilities 
for several years has been to maintain the open source Netscape Security 
Services (NSS) library, which is used in the Mozilla browsers, many 
Netscape and Sun servers, and other internal products. The NSS library 
contains an implementation of S/MIME v3.

I was wondering what thoughts you may have on the following problem :

If I have a keypair and e-mail certificate, and I want to send encrypted 
e-mail to somebody knowing his e-mail address, what's a systematic way 
to obtain the recipient's encryption certificate ?

Traditionally today, signed e-mail messages typically contain the 
signer's public encryption certificate. However that means one party 
needs to first send a signed unencrypted, e-mail message to transmit the 
public encryption certificate before both parties can exchange encrypted 
messages.

There are also ways to find recipient certificates today using corporate 
directory servers, but users must know about them and manually configure 
them in their applications, and they are typically not widely available 
on the Internet.

I'm envisioning some standardized scheme where, by starting with the 
recipient's email address, it would be possible to locate a public 
directory server, then find the recipient's certificate by looking it up 
in that directory server.

My main question is : has any similar scheme been proposed ? I would 
rather work with something that exists, but if there is nothing that 
fits, I'm open to writing an RFC.

Also, what are the other ways that people locate recipient S/MIME e-mail 
encryption certificates ?

Thanks.

Reply-To: <[email-masked]>
From: "Bonatti, Chris" <[email-masked]>
To: <[email-masked]>
Subject: Update of CMS-X.400 Drafts
Date: Sat, 9 Aug 2003 11:31:33 -0400
Organization: IECA, Inc.
Importance: Normal
Sender: [email-masked]

Cheers!
Chris

Done.

Done.

Done.

Done.

From: "Blake Ramsdell" <[email-masked]>
To: <[email-masked]>, "'Ietf-Smime-Examples'" <[email-masked]>, <[email-masked]>, "'Paul Hoffman / IMC'" <[email-masked]>
Cc: "'Sean P. Turner'" <[email-masked]>
Subject: RE: Draft-11: More complete results
Date: Sat, 9 Aug 2003 01:17:16 -0700
Importance: Normal
Sender: [email-masked]

> From: Jim Schaad [mailto:[email-masked]] 
> Sent: Wednesday, August 06, 2003 2:30 PM
> To: 'Ietf-Smime-Examples'; [email-masked]; 'Paul Hoffman / IMC'
> Cc: 'Sean P. Turner'; Blake Ramsdell
> Subject: Draft-11: More complete results
> 
> 6.11	FAILED
> 	test vectors are appended below on this message.  I don't know
> where I am going wrong and this code worked in the past.

The bad news is, I can't get this example to work either.  The good news
is that I have written a new implementation, and it could very well have
some kind of problem.  I have only tested my implementation against the
test vectors in RFC 3217.

These are the results that I got with this example, using the
terminology from RFC 3217 section 3.2 wherever possible:

<lotsofboringhexdump>
wrappedKey = 0x74, 0x31, 0xC0, 0x45, 0x51, 0x4C, 0x3C, 0x2D, 0x2E, 0xDA,
0x63, 0x50, 0x8B, 0xAE, 0xD4, 0xAC, 0x64, 0xCC, 0x95, 0xAE, 0xAF, 0xCD,
0x0F, 0x8C, 0xB6, 0x48, 0x1F, 0x0B, 0x45, 0x12, 0x4D, 0xFB, 0xA4, 0xAB,
0xC7, 0x83, 0x30, 0x4B, 0x69, 0xAD

TEMP3 = 0xD7, 0x10, 0x66, 0xEE, 0x9A, 0x42, 0xE0, 0x80, 0x62, 0xA3,
0xE5, 0xDE, 0xB5, 0xEF, 0x4E, 0x7E, 0x5F, 0x13, 0x30, 0xB5, 0x13, 0xD3,
0xA8, 0x4F, 0xBE, 0xDC, 0x02, 0xD4, 0x81, 0x27, 0xDB, 0x50, 0xE5, 0xD8,
0x0F, 0xE9, 0x25, 0x38, 0xF1, 0x7B

TEMP2 = 0x7B, 0xF1, 0x38, 0x25, 0xE9, 0x0F, 0xD8, 0xE5, 0x50, 0xDB,
0x27, 0x81, 0xD4, 0x02, 0xDC, 0xBE, 0x4F, 0xA8, 0xD3, 0x13, 0xB5, 0x30,
0x13, 0x5F, 0x7E, 0x4E, 0xEF, 0xB5, 0xDE, 0xE5, 0xA3, 0x62, 0x80, 0xE0,
0x42, 0x9A, 0xEE, 0x66, 0x10, 0xD7

TEMP1 = 0x50, 0xDB, 0x27, 0x81, 0xD4, 0x02, 0xDC, 0xBE, 0x4F, 0xA8,
0xD3, 0x13, 0xB5, 0x30, 0x13, 0x5F, 0x7E, 0x4E, 0xEF, 0xB5, 0xDE, 0xE5,
0xA3, 0x62, 0x80, 0xE0, 0x42, 0x9A, 0xEE, 0x66, 0x10, 0xD7

IV = 0x7B, 0xF1, 0x38, 0x25, 0xE9, 0x0F, 0xD8, 0xE5

CEKICV = 0x51, 0x1B, 0x27, 0x0E, 0xE8, 0xEA, 0x33, 0x74, 0x37, 0xA5,
0x7D, 0xC7, 0xCC, 0x9B, 0x24, 0xCE, 0x32, 0x41, 0x19, 0x0F, 0x38, 0x47,
0x25, 0x2E, 0xC0, 0xCA, 0x0F, 0x30, 0x3B, 0x86, 0x2E, 0x3D

CEK = 0x51, 0x1B, 0x27, 0x0E, 0xE8, 0xEA, 0x33, 0x74, 0x37, 0xA5, 0x7D,
0xC7, 0xCC, 0x9B, 0x24, 0xCE, 0x32, 0x41, 0x19, 0x0F, 0x38, 0x47, 0x25,
0x2E

ICV = 0xC0, 0xCA, 0x0F, 0x30, 0x3B, 0x86, 0x2E, 0x3D

computedICV = 0x53, 0xFB, 0x3E, 0xCC, 0x8A, 0x06, 0xCC, 0xAF
</lotsofboringhexdump>

Mapping your results onto mine:

> Wrapped key
> 0x0012F248  74 31 c0 45 51 4c 3c 2d 2e da 63 50 8b ae d4 ac
> t1�EQL<-.�cP.�Ԭ 0x0012F258  64 cc 95 ae af cd 0f 8c b6 48 1f 0b 45 12
> 4d fb d�.���..�H..E.M.
> 0x0012F268  a4 ab c7 83 30 4b 69 ad                         ���.0Ki�
> 
> Mail list key
> 0x00324354  25 5e 0d 1c 07 b6 46 df b3 13 4c c8 43 ba 8a a7
> %^...�F߳.L�C�.� 0x00324364  1f 02 5b 7c 08 38 25 1f

We're on the same page here.  I did not dump my Mail list key, but there
are many problems I would have later if these weren't the same.
Specifically, the next item would not match.

> After decrypt #1
> 0x00324630  d7 10 66 ee 9a 42 e0 80 62 a3 e5 de b5 ef 4e 7e
> �.f..B..b�.޵.N~ 0x00324640  5f 13 30 b5 13 d3 a8 4f be dc 02 d4 81 27
> db 50 _.0�.ӨO��.�.'�P
> 0x00324650  e5 d8 0f e9 25 38 f1 7b                         .�..%8.{

Same as TEMP3 from mine.

> IV
> 0x00324630  7b f1 38 25 e9 0f d8 e5                         {.8%..�.

Same as my IV also.

> Post Decrypt #2
> 0x00324630  50 db 27 81 d4 02 dc be 4f a8 d3 13 b5 30 13 5f
> P�'.�.ܾO��.�0._ 0x00324640  7e 4e ef b5 de e5 a3 62 80 e0 42 9a ee 66
> 10 d7 ~N.��.�b..B..f.�

This should theoretically be the same as my CEKICV (which is the output
of the second decryption), but it's not.  This appears to be the same as
my TEMP1 which is the input to the second decryption, not the output.

> Computed check sum
> 0x0012EFD8  53 fb 3e cc 8a 06 cc af                         S.>�..̯

Same as my computedICV above.  What I can't figure out is how we both
arrived at the same checksum with such different answers for CEKICV
(your "Post Decrypt #2").  My understanding is that it's the first eight
bytes of the sha-1 digest of the first 24 bytes of my CEKICV and your
"Post Decrypt #2".

> Actual Check sum
>  80 e0 42 9a ee 66 10 d7

This does not match my ICV above, but it matches the eight bytes at the
end of your "Post Decrypt #2".

I would hazard a guess that there is an error in one of our
implementations where the input and the output of the second decryption
step are being mistakenly interchanged.  I have checked mine and run the
test vectors from RFC 3217 through it, and I can't see the problem on my
side.  Now, I've said this kind of thing before and been wrong, so take
it with a grain of salt...

In any case, in my test, this example is broken also, but unless Jim and
I can agree on an answer, it could be the case that both of our
implementations are broken.

Blake

From: "Blake Ramsdell" <[email-masked]>
To: "'Julien Pierre'" <[email-masked]>, <[email-masked]>
Subject: RE: trust domains
Date: Fri, 8 Aug 2003 20:44:36 -0700
Importance: Normal
Sender: [email-masked]

> [mailto:[email-masked]] On Behalf Of Julien Pierre
> Sent: Friday, August 08, 2003 7:43 PM
> To: [email-masked]
> Subject: trust domains
> 
> Assuming that you have already obtained my public encryption 
> certificate, for example by reading this message, there is no way for 
> you to be certain what type of certificate I will trust if 
> you send me 
> e-mail, in particular what CAs I trust.

Yup.

> If you have multiple certificates from different CAs, which 
> one is the 
> most appropriate to use when writing me writing signed and encrypted 
> e-mail ?

This seems to be a question of certificate policies and mapping those to
the content being protected.  That is, if the message being signed is
just casual communication, use one certificate, and if it's a purchase
order, use another one.  Right now, I think that most clients pretty
much allow the user to pick.  Further, I think that a lot of folks just
have one, so you'd better like it.

> One theoretical answer to the problem would be for you to sign your 
> message with all the certificates you have, including multiple 
> signatures, in the hope I would trust one. Today our mail 
> clients only 
> support a single signature, so that wouldn't work. But even 
> if they did 
> tomorrow, the software trust policy might be to not trust the message 
> unless all its signatures are valid, so having one good 
> signature and n 
> bad signatures wouldn't help. You might send your message n 
> times, each 
> signed with a different certificate, but I would probably get annoyed.

Well, I'm not sure that the semantic of multiple SignerInfos is that "if
you verify them, you must verify all of them, and if you don't like any
of them, freak out".  I think it's more along the lines of "these are
all equivalent, so go ahead and choose which one you like and run with
it".

> What I'm getting at is that there is a need to make the user's trust 
> domain information available, so that senders get a hint of 
> the proper 
> certificate to use.

This might be interesting to discuss.  You could make a capabilities
extension where you could identify your roots (off the top of my head,
I'd say using a hash of the certificate would work) and go from there.
One concern is bloat -- I have over 100 roots on my machine configured
with Outlook 2002 and IE6 that are all marked as suitable roots for
"Secure email" (in the "secure email" trust domain, using your terms).
Sending this stack of hashes with every signed message might make the
world a worse place to address this issue.

> This is similar to what happens in the SSL protocol when an 
> SSL server 
> requests client authentication. The SSL server provides a list of 
> trusted CA certificates. The SSL client is then free to choose one to 
> use if he has one that chains to a CA the server accepts. Of 
> course the 
> problem was easier to solve for SSL, since it is an online 
> protocol, and 
> S/MIME is not.

I think the principle is the same, though.  In the case of S/MIME, it's
"sign with all of your certs".  One problem is that you're going to
potentially cart around a large number of certs -- each of your
individual certs as well as the intermediate certs that go with them.
And I'm not sure that there's enough experience with clients handling
multiple signers to tell you what would happen if you used that feature.

> My question is : is there any work going within the IETF to 
> solve this 
> problem for the S/MIME protocol ? And how have you been solving this 
> problem today ?

>From what I can tell, today we solve the problem by having clients
include every root key under the sun, and most certificates of
significant public value are issued under those roots.  Certificates
that aren't issued under those roots are most likely corporate CA
certificates, and typically folks just have to hunt around to find the
right corporate root to install in order to verify the signatures.
Peter Hesse and Sharon Boeyen have recently illustrated this problem on
the PKIX list -- not directly, but by sending signed messages for which
people don't have the root keys.

Blake

Date: Fri, 8 Aug 2003 19:43:03 -0700
From: [email-masked] (Julien Pierre)
Subject: trust domains
To: [email-masked]
Organization: Netscape
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms010704000904080802040505
Content-Type: TEXT/PLAIN; CHARSET=us-ascii

Hi,

Here is another problem with S/MIME deployment that I'd like to inquire 
about.

Assuming that you have already obtained my public encryption 
certificate, for example by reading this message, there is no way for 
you to be certain what type of certificate I will trust if you send me 
e-mail, in particular what CAs I trust.

If you have multiple certificates from different CAs, which one is the 
most appropriate to use when writing me writing signed and encrypted 
e-mail ?

Nowadays, in Netscape applications (and in the new AOL communicator), 
each user can make a decision of which CAs he trusts for signing each 
type of certificate (SSL server, SSL client, email signing, email 
encryption ...). I call this set of CAs and the trust properties a 
user's "trust domain".

Unlike an email certificate which is typically included in an S/MIME 
message's digital signature, my trust domain is not exposed to you.

The only clue that you have when writing to me is that I probably trust 
the same Thawte freemail CA that issued my own public encryption 
certificate. However, if I had signed this message with my corporate 
certificate (and if my smartcard was working right now:)), you would not 
be able to get a certificate from the same CA, unless you were employed 
by the same company.

One theoretical answer to the problem would be for you to sign your 
message with all the certificates you have, including multiple 
signatures, in the hope I would trust one. Today our mail clients only 
support a single signature, so that wouldn't work. But even if they did 
tomorrow, the software trust policy might be to not trust the message 
unless all its signatures are valid, so having one good signature and n 
bad signatures wouldn't help. You might send your message n times, each 
signed with a different certificate, but I would probably get annoyed.

What I'm getting at is that there is a need to make the user's trust 
domain information available, so that senders get a hint of the proper 
certificate to use.

This is similar to what happens in the SSL protocol when an SSL server 
requests client authentication. The SSL server provides a list of 
trusted CA certificates. The SSL client is then free to choose one to 
use if he has one that chains to a CA the server accepts. Of course the 
problem was easier to solve for SSL, since it is an online protocol, and 
S/MIME is not.

My question is : is there any work going within the IETF to solve this 
problem for the S/MIME protocol ? And how have you been solving this 
problem today ?

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

--------------ms010704000904080802040505--

From: "Blake Ramsdell" <[email-masked]>
To: "'Julien Pierre'" <[email-masked]>, <[email-masked]>
Subject: RE: dissemination of public encryption certificates
Date: Fri, 8 Aug 2003 19:41:12 -0700
Importance: Normal
Sender: [email-masked]

> [mailto:[email-masked]] On Behalf Of Julien Pierre
> Sent: Friday, August 08, 2003 7:07 PM
> To: [email-masked]
> Subject: dissemination of public encryption certificates
> 
> If I have a keypair and e-mail certificate, and I want to 
> send encrypted 
> e-mail to somebody knowing his e-mail address, what's a 
> systematic way 
> to obtain the recipient's encryption certificate ?

Systematic is an interesting choice of words ;).

I have seen LDAP work (if properly configured).  For the most part, the
most reliable way I've seen is for an intended recipient to send a
signed message containing their encrypting certificate (which you are
about to point out ;)).

> Traditionally today, signed e-mail messages typically contain the 
> signer's public encryption certificate. However that means one party 
> needs to first send a signed unencrypted, e-mail message to 
> transmit the 
> public encryption certificate before both parties can 
> exchange encrypted 
> messages.

Yup.

> There are also ways to find recipient certificates today 
> using corporate 
> directory servers, but users must know about them and 
> manually configure 
> them in their applications, and they are typically not widely 
> available 
> on the Internet.

Yup.

> I'm envisioning some standardized scheme where, by starting with the 
> recipient's email address, it would be possible to locate a public 
> directory server, then find the recipient's certificate by 
> looking it up 
> in that directory server.

I believe that at least one proposal exists for this in the PKIX working
group -- look at the operational protocols for certificate store access.

> My main question is : has any similar scheme been proposed ? I would 
> rather work with something that exists, but if there is nothing that 
> fits, I'm open to writing an RFC.

Check out PKIX.  They're not taking new drafts, but there may be
something useful for you there.  Any work along these lines would most
likely be handled by that working group.

Blake

Date: Fri, 8 Aug 2003 19:07:24 -0700
From: [email-masked] (Julien Pierre)
Subject: dissemination of public encryption certificates
To: [email-masked]
Organization: Netscape
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms010704000904080802040505
Content-Type: TEXT/PLAIN; CHARSET=us-ascii

Hi,

Since this is my first posting to this mailing list, let me introduce 
myself :

I'm a software engineer in AOL / Netscape and one of my responsibilities 
for several years has been to maintain the open source Netscape Security 
Services (NSS) library, which is used in the Mozilla browsers, many 
Netscape and Sun servers, and other internal products. The NSS library 
contains an implementation of S/MIME v3.

I was wondering what thoughts you may have on the following problem :

If I have a keypair and e-mail certificate, and I want to send encrypted 
e-mail to somebody knowing his e-mail address, what's a systematic way 
to obtain the recipient's encryption certificate ?

Traditionally today, signed e-mail messages typically contain the 
signer's public encryption certificate. However that means one party 
needs to first send a signed unencrypted, e-mail message to transmit the 
public encryption certificate before both parties can exchange encrypted 
messages.

There are also ways to find recipient certificates today using corporate 
directory servers, but users must know about them and manually configure 
them in their applications, and they are typically not widely available 
on the Internet.

I'm envisioning some standardized scheme where, by starting with the 
recipient's email address, it would be possible to locate a public 
directory server, then find the recipient's certificate by looking it up 
in that directory server.

My main question is : has any similar scheme been proposed ? I would 
rather work with something that exists, but if there is nothing that 
fits, I'm open to writing an RFC.

Also, what are the other ways that people locate recipient S/MIME e-mail 
encryption certificates ?

Thanks.

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

--------------ms010704000904080802040505--

Reply-To: <[email-masked]>
From: "Jim Schaad" <[email-masked]>
To: "'Ietf-Smime-Examples'" <[email-masked]>, <[email-masked]>, "'Paul Hoffman / IMC'" <[email-masked]>
Cc: "'Sean P. Turner'" <[email-masked]>, "Blake Ramsdell" <[email-masked]>
Subject: Draft-11: More complete results
Date: Wed, 6 Aug 2003 14:29:47 -0700
Importance: Normal
Sender: [email-masked]

People,

I now have only a couple of examples that I have not checked.  There are
a couple of failures in this set of messages from my perspective.

jim

4.1 	pass
4.2	pass
5.1	pass
5.2	pass
5.3  -- not checked ---
5.4	pass with comments
	1.  certificates are Alice DSS, Carl DSS (root), Alice RSA
5.5	pass
5.6	--- not checked --  - structurally fine - 
		- First Sig checks
		Diane signature unchecked
5.7  	pass
5.8  -- not checked --
	1. I have an assumption that the wrong signature OID is used in
the message. 
5.9  FAILED 
	1. id-dsa is the signature algorithm not id-dsa-with-sha1
	2. Commentary text states that the body part is the same as 5.1
- this is not correct as the signature values and exContent are
different (content is actually "\0xd\0xaThis is some sample content." 
5.10  pass with comments
	1. List of attributes is
		1. content type
		2. message digest
		3. 1.2.5555 (unknown)
		4. content hint
		5. smime capabilities
		6. security label
		7. content reference
		8. encrypt key preference
		9. ML expansion history
		10. Equivalent label
5.11 	pass with comments
	1. Text should be Alice's and Carl's DSS certificates.

6.1 	passed with comments
	1. New commentary to add to replace that at the end of the
message is appended to this message.
6.2	passed
6.3 	passed with comments
	1. RC2/128 for the content encryption algorithm.
6.4	passed
6.5 	passed 
6.6 	-- not checked --
6.7	passed
6.8	-- not checked --
6.9	FAILED
	Recip #1 pass
	Recip #2 pass
	Recip #3 FAIL
	Content hints says the content is 1.2.6.5.4 not id-data
6.10	pass
6.11	FAILED
	test vectors are appended below on this message.  I don't know
where I am going wrong and this code worked in the past.

7.0	pass

8.1	passed
8.2	passed with comment
	Need to specify that this uses the same key value as does 8.1

9	-- checked--

10.1	-- not checked --
10.2	checked

11.1	FAILED
	1. Text states signed with RSA, message signed with DSA
	2. DSA signature OID incorrect
	3. I retract the comments about the receipt request and
AliceRSA.  This is fine.  The only odditity is the the receipt is going
to a non-example address ([email-masked])
11.2	FAILED
	1. I do not get the same value for the msgSigDigest attribute as
this message has.  I am investigating further.
11.3  passed
11.4  passed
11.5  -- not checked -- 
11.6 	-- not checked --

***************************** 6.1 intermediate data for document
**********************

Z

  ae c3 35 7f 90 75 b5 e4 c5 f8 92 6b 9e c5 96 a3
  24 52 9d 85 32 60 7b 8b bd c2 a7 39 63 e9 d6 93
  ad d5 1f 56 8d 91 97 72 a9 c2 f4 83 27 fa 37 3d
  13 12 f3 3b 5c 8d ec ce 6b 2d 4f f1 9b 4c 91 e4
  6d c0 68 1a 2e e0 c4 07 46 c3 f2 90 f4 ae fe c8
  d8 ef dc ca 84 d5 fd 3a 36 ee ba 67 16 18 7f a3
  de f3 df 3b 66 e1 6a 0b 79 bb 6a 50 c2 63 9f 24
  ed 9b 17 d8 c1 b4 4e 8a a1 6a 35 02 d0 81 9c a3

X9.42 Other Info encoding for first hash
  30 61 30 13 06 0b 2a 86 48 86 f7 0d 01 09 10 03 
  06 04 04 00 00 00 01 a0 42 04 40 a9 74 c4 e9 aa 
  79 d3 ce 5c 74 a4 ed a5 db 65 f5 c0 37 d6 81 f1 
  0a 93 5f 24 a1 db 97 96 ee 87 8b 79 db e9 07 11 
  23 ce 70 24 84 30 72 02 83 d5 7d 60 d3 d4 f6 a7 
  4d 4c c2 e0 89 fa cd 59 20 a2 93 a2 06 04 04 00 
  00 00 c0     

Hash Result #1
  5d fa dc ad 89 87 33 7c ec cf af 8a fc e8 fd 56 
  38 d8 89 0c                                     

Hash Result #2
  74 f2 fb f8 2c d7 bd 7a 92 1b 3c 10 df 16 0b a9
  64 08 f2 a5                                    

3DES Key Encryption Key
  5d fb dc ad 89 86 32 7c ec ce ae 8a fd e9 fd 57
  38 d9 89 0d 75 f2 fb f8                        

3DES Content Encryption Key
  92 40 51 b6 43 16 13 52 f7 ad 92 cb f2 57 3e 7f
  a8 ce 02 ba b6 2a cd c2                        

***************************** 6.11 intermediate data from my test
**************** But it fails....

Wrapped key
0x0012F248  74 31 c0 45 51 4c 3c 2d 2e da 63 50 8b ae d4 ac
t1�EQL<-.�cP.�Ԭ 0x0012F258  64 cc 95 ae af cd 0f 8c b6 48 1f 0b 45 12
4d fb d�.���..�H..E.M.
0x0012F268  a4 ab c7 83 30 4b 69 ad                         ���.0Ki�

Mail list key
0x00324354  25 5e 0d 1c 07 b6 46 df b3 13 4c c8 43 ba 8a a7
%^...�F߳.L�C�.� 0x00324364  1f 02 5b 7c 08 38 25 1f

After decrypt #1
0x00324630  d7 10 66 ee 9a 42 e0 80 62 a3 e5 de b5 ef 4e 7e
�.f..B..b�.޵.N~ 0x00324640  5f 13 30 b5 13 d3 a8 4f be dc 02 d4 81 27
db 50 _.0�.ӨO��.�.'�P
0x00324650  e5 d8 0f e9 25 38 f1 7b                         .�..%8.{

IV
0x00324630  7b f1 38 25 e9 0f d8 e5                         {.8%..�.

Post Decrypt #2
0x00324630  50 db 27 81 d4 02 dc be 4f a8 d3 13 b5 30 13 5f
P�'.�.ܾO��.�0._ 0x00324640  7e 4e ef b5 de e5 a3 62 80 e0 42 9a ee 66
10 d7 ~N.��.�b..B..f.�

Computed check sum
0x0012EFD8  53 fb 3e cc 8a 06 cc af                         S.>�..̯

Actual Check sum
 80 e0 42 9a ee 66 10 d7

--- they don't match!!!!!

Date: Thu, 31 Jul 2003 21:54:02 -0400
To: [email-masked], [email-masked]
From: Russ Housley <[email-masked]>
Subject: RE: RFC2632bis and subjectAltName
Sender: [email-masked]

Tony:

Nice suggestion.  I think we should do it.

Russ

>Blake:
>
>The absence of an rfc2822 e-mail address in the certificate should not be
>considered a "failure" since its absence must have been permitted by the
>certificate issuer - and we assume (!) that certificates are issued
>according to issuer policy.
>
>The current text (which you quoted) could be incomplete.  My interpretation*
>of the middle sentence of this paragraph is that the check is only mandatory
>if the address is present (so a comparison to an absent/"blank" field is not
>mandatory).  The following sentence then suggests what action to take if the
>check/comparison fails.  Since if the comparison is not done, it will not
>fail, one could interpret that no indication is required if the address is
>absent from the cert.
>
>The paragraph following the quoted one addresses the display of the signer's
>identity:
>
>A receiving agent SHOULD display a subject name or other certificate
>details when displaying an indication of successful or unsuccessful
>signature verification.
>
>Should this be stronger in cases where the certificate has an absent rfc2822
>field (and no check against the From: header field was done)?
>
>Maybe adding the sentence between these two paragraphs:
>
>"Receiving agents which do not perform the foregoing check due to the
>absence of an address in the certificate MUST display the subject name
>from the certificate when displaying an indication of successful or
>unsuccessful signature verification."
>
>-leaving the following paragraph as a SHOULD, strongly encouraging
>additional information to be displayed in this and all other cases.
>
>Tony
>
>* I interpret the phrase: "if mail addresses are present in the
>Certificate" to be a qualifier for the "MUST" in this sentence.
>
>| -----Original Message-----
>| From: [email-masked]
>| [mailto:[email-masked]] On Behalf Of Blake Ramsdell
>| Sent: July 31, 2003 12:53 AM
>| To: 'Russ Housley'; [email-masked]; [email-masked]
>| Subject: RE: RFC2632bis and subjectAltName
>|
>|
>|
>| > -----Original Message-----
>| > From: Russ Housley [mailto:[email-masked]]
>| > Sent: Tuesday, July 29, 2003 4:36 PM
>| > To: [email-masked]; 'Blake Ramsdell'; [email-masked]
>| > Subject: RE: RFC2632bis and subjectAltName
>| >
>| > I understand that non-email applications of CMS and the
>| > associated MIME
>| > types need other address forms.  But, RFC2632bis does not tell an
>| > implementor what to do fir S/MIME (which is an email
>| > application) if the
>| > certificate does not contain an email address.
>|
>| I'm still not clear whether S/MIME means "secure MIME used
>| anywhere MIME can be used, such as XMPP or BEEP" or S/MIME
>| means "secure MIME used for interpersonal email messaging".
>| Depending on the answer, you will get different answers if
>| it's necessary to clarify any language about the absence of
>| email addresses in the certificate.
>|
>| The relevant text about current processing rules seems to be:
>|
>|
>| Sending agents SHOULD make the address in the From or Sender
>| header in a mail message match an Internet mail address in
>| the signer's certificate. Receiving agents MUST check that
>| the address in the From or Sender header of a mail message
>| matches an Internet mail address, if present, in the signer's
>| certificate, if mail addresses are present in the
>| certificate. A receiving agent SHOULD provide some explicit
>| alternate processing of the message if this comparison fails,
>| which may be to display a message that shows the recipient
>| the addresses in the certificate or other certificate details.
>|
>|
>| So if there are not any email addresses found in the
>| certificate, this is a mismatch (blank from the certificate
>| doesn't match nonblank from the From or Sender), and you
>| should go crazy insane and show a hex dump of the certificate.
>|
>| We could clarify that "failure" includes the case where there
>| are zero email addresses in the certificate...
>|
>| Blake
>|