Subject: PKI and S/MIME

From: "Blake Ramsdell" <[email-masked]>
Date: Tue, 12 Aug 2003 19:47:28 -0700

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: Simon Josefsson <[email-masked]>
Date: Wed, 13 Aug 2003 09:32:16 +0200

> group, or somewhere else.

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: "Anders Rundgren" <[email-masked]>
Date: Wed, 13 Aug 2003 19:16:22 +0200

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

Regards,
Simon

---

From: "Blake Ramsdell" <[email-masked]>
Date: Wed, 13 Aug 2003 15:05:49 -0700

> -----Original Message-----
> 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'

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: Simon Josefsson <[email-masked]>
Date: Thu, 14 Aug 2003 01:05:53 +0200

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

---

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

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

> 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

---

From: "Blake Ramsdell" <[email-masked]>
Date: Wed, 13 Aug 2003 17:05:24 -0700

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

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.

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

> 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

---

From: Steve Hole <[email-masked]>
Date: Thu, 14 Aug 2003 10:34:47 -0700

> 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

---

From: Steve Hole <[email-masked]>
Date: Thu, 14 Aug 2003 10:42:02 -0700

> 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

---

From: Steve Hole <[email-masked]>
Date: Thu, 14 Aug 2003 10:45:45 -0700

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

> required to administer the certificate directory, which I'm not sure

Yes.

Cheers.

---
Steve Hole

---

From: "Blake Ramsdell" <[email-masked]>
Date: Thu, 14 Aug 2003 14:25:04 -0700

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

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: Simon Josefsson <[email-masked]>
Date: Fri, 15 Aug 2003 00:28:48 +0200

> get the relationship set up with the domain registration service.   Not 

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. 

> CSP for the Windows twins and a module in the new Netscape/Mozilla 

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]>
Date: Thu, 14 Aug 2003 15:40:51 -0700

> Sent: Thursday, August 14, 2003 3:29 PM
> To: Steve Hole
> Cc: Blake Ramsdell; [email-masked]

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.

> 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

---

From: Steve Hole <[email-masked]>
Date: Thu, 14 Aug 2003 16:54:21 -0700

Yes.
 
> 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

---

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

> 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: Fri, 15 Aug 2003 09:50:02 -0700

> 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

---

From: "Blake Ramsdell" <[email-masked]>
Date: Fri, 15 Aug 2003 16:09:16 -0700

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Steve Hole
> Sent: Friday, August 15, 2003 9:50 AM
> To: Simon Josefsson
> Cc: [email-masked]

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