RE: PKI and S/MIME
"Hallam-Baker, Phillip" <pbaker@verisign.com> Thu, 14 August 2003 12:59 UTC
Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08589 for <smime-archive@lists.ietf.org>; Thu, 14 Aug 2003 08:59:44 -0400 (EDT)
Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7ECUkqt084607 for <ietf-smime-bks@above.proper.com>; Thu, 14 Aug 2003 05:30:46 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7ECUk0x084605 for ietf-smime-bks; Thu, 14 Aug 2003 05:30:46 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f
Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7ECUiqt084596 for <ietf-smime@imc.org>; Thu, 14 Aug 2003 05:30:44 -0700 (PDT) (envelope-from pbaker@verisign.com)
Received: from MOU1WNEXC03.verisign.com (verisign.com [65.205.251.57]) by peacock.verisign.com (8.12.9/) with ESMTP id h7ECUZil017013; Thu, 14 Aug 2003 05:30:35 -0700 (PDT)
Received: by mou1wnexc03.verisign.com with Internet Mail Service (5.5.2653.19) id <QY8R7KKB>; Thu, 14 Aug 2003 05:30:35 -0700
Message-ID: <2A1D4C86842EE14CA9BC80474919782E01113011@mou1wnexm02.verisign.com>
From: "Hallam-Baker, Phillip" <pbaker@verisign.com>
To: 'Anders Rundgren' <anders.rundgren@telia.com>, Blake Ramsdell <blake@brutesquadlabs.com>, Simon Josefsson <jas@extundo.com>
Cc: ietf-smime@imc.org, "'Sean P. Turner'" <turners@ieca.com>
Subject: RE: PKI and S/MIME
Date: Thu, 14 Aug 2003 05:30:34 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: owner-ietf-smime@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe>
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 > -----Original Message----- > From: Anders Rundgren [mailto:anders.rundgren@telia.com] > Sent: Wednesday, August 13, 2003 1:16 PM > To: Blake Ramsdell; Simon Josefsson > Cc: ietf-smime@imc.org; '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 anders.rundgren@telia.com 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" <jas@extundo.com> > To: "Blake Ramsdell" <blake@brutesquadlabs.com> > Cc: <ietf-smime@imc.org>; "'Sean P. Turner'" <turners@ieca.com> > Sent: Wednesday, August 13, 2003 09:32 > Subject: Re: PKI and S/MIME > > > > "Blake Ramsdell" <blake@brutesquadlabs.com> 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 >
- PKI and S/MIME Blake Ramsdell
- Re: PKI and S/MIME Simon Josefsson
- Re: PKI and S/MIME Anders Rundgren
- RE: PKI and S/MIME Blake Ramsdell
- Re: PKI and S/MIME Simon Josefsson
- Re: PKI and S/MIME Simon Josefsson
- DNS CERT vs. LDAP (was: RE: PKI and S/MIME) Blake Ramsdell
- RE: PKI and S/MIME Hallam-Baker, Phillip
- Re: PKI and S/MIME Steve Hole
- RE: PKI and S/MIME Steve Hole
- Re: PKI and S/MIME Steve Hole
- RE: PKI and S/MIME Steve Hole
- RE: PKI and S/MIME Hallam-Baker, Phillip
- RE: PKI and S/MIME Blake Ramsdell
- Re: PKI and S/MIME Simon Josefsson
- RE: PKI and S/MIME Blake Ramsdell
- Re: PKI and S/MIME Steve Hole
- Re: PKI and S/MIME Simon Josefsson
- Re: PKI and S/MIME Steve Hole
- RE: PKI and S/MIME Blake Ramsdell
- Re: PKI and S/MIME Denis Pinkas
- RE: PKI and S/MIME Hallam-Baker, Phillip
- Re: PKI and S/MIME Denis Pinkas