Subject: [pkix] purpose of LDAP in PKI

From: Peter Gutmann <[email-masked]>
Date: Mon, 18 Feb 2013 13:38:35 +0000

Andris Berzins <[email-masked]> writes:

>What could be the reason why end user certificates should be stored in LDAP
>by the CA and made publicly available?

There isn't one.  It's (ancient) historical baggage based on X.509's origins
in X.500, and some of the people writing the standards haven't realised yet
that HTTP won.

Peter.

---

From: "Andris Berzins" <[email-masked]>
Date: Mon, 18 Feb 2013 15:53:11 +0200

Quoting Peter Gutmann <[email-masked]>:

When I apply for ID-card having authentication and qualified signature certificate on it,
I have to checkbox whether I want my certificates to be published in LDAP.
I get no clear answer how could I benefit from my certificates being published.

Peter.
_______________________________________________
pkix mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pkix

---

From: Denis Pinkas <[email-masked]>
Date: Mon, 18 Feb 2013 15:00:12 +0100

Andris,

Making certificates publicly available may only be done with the 
agreement of the end-user.

There are no benefits for certificates being used for authentication or 
non repudiation, but only inconveniences: .
in particular : lack of privacy, and ability to know how many customers 
the CAs has.

Denis

>
>
>
> Quoting *Peter Gutmann <[email-masked]> 
> <mailto:[email-masked]>*:
>

---

From: Bilal Ashraf <[email-masked]>
Date: Mon, 18 Feb 2013 19:05:15 +0500

One possible use case could be that others can use your certificate 
(from LDAP) for encryption e.g. sending encrypted emails or encrypted 
documents to you.

The other possible use case could be SSL client authentication where 
certificates are presented by client and matched by applications against 
user certificates published at LDAP.

Regards,
Bilal.

---

From: "Goulet, Walter" <[email-masked]>
Date: Mon, 18 Feb 2013 09:08:35 -0500

>I get no clear answer how could I benefit from my certificates being published.

In enterprise or other private PKI deployments publishing certificates to LDAP stores can be very useful for applications such as S/MIME where a sender's mail client can fetch a recipient's certificate from a centralized LDAP directory service. Basically, exposing your certificate via LDAP makes it *much* easier for other applications to actually use your certificate.

The benefits of publishing your certificate publicly (i.e. over Internet accessible LDAP directory store) are less clear to me. 

Peter.

---

From: Joel Kazin <[email-masked]>
Date: Mon, 18 Feb 2013 09:18:21 -0500

When an enterprise is issuing certificates to its employees and 
contractors there can be a need to make the encryption certificate 
publicly available for traffic from external parties to individuals at 
that enterprise.

Joel

---

From: "Erik Andersen" <[email-masked]>
Date: Mon, 18 Feb 2013 17:10:13 +0100

Hi Peter

LDAP is a primarily an application protocol. HTTP is a communication
protocol. Comparing a application protocol with a communication protocol is
noncense. HTTP could in principle also be used to access a directory, such
as LDAP. Most X.500 implementation have a Web (HTTP) interface.

Erik

-----Oprindelig meddelelse-----
Fra: [email-masked] [mailto:[email-masked]] På vegne af Peter
Gutmann
Sendt: 18. februar 2013 14:39
Til: [email-masked]
Emne: [pkix] purpose of LDAP in PKI

Andris Berzins <[email-masked]> writes:

>What could be the reason why end user certificates should be stored in 
>LDAP by the CA and made publicly available?

Peter.

---

From: Michael StJohns <[email-masked]>
Date: Mon, 18 Feb 2013 12:12:43 -0500

At 11:10 AM 2/18/2013, Erik Andersen wrote:
>protocol. 

Um...  

HTTP runs directly over TCP
LDAP runs directly over TCP

HTTP can be used to query for data.
LDAP can be used to query for data

HTTP can be used to store data
LDAP can be used to store data

HTTP can return data in multiple formats (HTML, octet streams, etc)
LDAP can return data in multiple formats 

 From a protocol point of view, the two have pretty similar data store/retrieval mechanism.  It's when you get to the server side that things get interesting.  For example, it's perfectly possible to build web pages of nothing but "ldap:" links and access them from a browser - where the contents of the ldap store are say HTML web pages.   It's also perfectly possible to build an HTTP web server that serves up nothing but ldap'ish data blobs.  That doesn't change the protocol.

So I reject your reality and substitute my own.  They really are both application protocols.:-) 

>Comparing a application protocol with a communication protocol is
>as LDAP. 

Yup - this is usually hidden though in the machinations of the web server rather than being a direct mapping.  But it's really not a protocol difference, but a difference in how the server you're talking to interprets the query.   (E.g. yes, the semantics of LDAP and HTTP are different, but they accomplish almost the same thing with HTTP being a bit more extensible).

Mike

>Most X.500 implementation have a Web (HTTP) interface.
>
>Erik
>

---

From: "Kemp, David P." <[email-masked]>
Date: Tue, 19 Feb 2013 14:25:25 +0000

Mike,

That misses the point.  LDAP defines an application protocol that supports transactions with known semantics, allowing M2M communications based on published standards rather than bespoke specifications.   HTTP does not define application semantics -- HTML, SOAP, REST, etc perform that function in the HTTP space.

It would be trivial to specify certificate search, retrieval, update transactions over HTTP, but the set of such transactions has not been standardized.  Every Internet-connected device has a DNS resolver that allows machines to manage and exchange resource data without human intervention.  Certificates could be managed as DNS resources (in theory - there is resistance to that idea in practice) using only TCP/UDP and the published DNS specs.  LDAP can do that with just the published TCP and LDAP specs.  

If a set of DNS-over-HTTP or directory-over-HTTP transactions were defined, HTTP could support M2M management and distribution of DNS and certificate resources.  But those transactions aren't standardized, so HTTP alone cannot be considered an "application protocol" with respect to DNS resources, SQL databases, or directories.

Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Michael StJohns
Sent: Monday, February 18, 2013 12:13 PM
To: Erik Andersen; [email-masked]
Subject: Re: [pkix] purpose of LDAP in PKI

Um...  

HTTP can return data in multiple formats (HTML, octet streams, etc) LDAP can return data in multiple formats 

>noncense. HTTP could in principle also be used to access a directory, 
>such as LDAP.

Mike

>Fra: [email-masked] [mailto:[email-masked]] På vegne af 
>Peter Gutmann
>There isn't one.  It's (ancient) historical baggage based on X.509's 
>origins in X.500, and some of the people writing the standards haven't 
>realised yet that HTTP won.
>
>Peter.

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 19 Feb 2013 07:16:15 -0800

On Feb 19, 2013, at 6:25 AM, "Kemp, David P." <[email-masked]> wrote:

> It would be trivial to specify certificate search, retrieval, update transactions over HTTP, but the set of such transactions has not been standardized.

*cough* RFC 2585 *cough* (To be honest, I wouldn't have remembered it unless I had be co-author.)

>  Every Internet-connected device has a DNS resolver that allows machines to manage and exchange resource data without human intervention.  Certificates could be managed as DNS resources (in theory - there is resistance to that idea in practice) using only TCP/UDP and the published DNS specs.  LDAP can do that with just the published TCP and LDAP specs.  
> 

What is not specified is a single URL patter to find a particular certificate.

--Paul Hoffman

---

From: "Piyush Jain" <[email-masked]>
Date: Tue, 19 Feb 2013 08:13:28 -0800

> unless I had be co-author.)
 :)

> What is not specified is a single URL patter to find a particular
certificate.

http://www.rfc-editor.org/rfc/rfc4387.txt authored by our own Dr. Peter
Gutmann.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 20 Feb 2013 08:42:47 -0500

On Tue, Feb 19, 2013 at 10:16 AM, Paul Hoffman <[email-masked]>wrote:

> > That misses the point.  LDAP defines an application protocol that
> supports transactions with known semantics, allowing M2M communications
> based on published standards rather than bespoke specifications.   HTTP
> does not define application semantics -- HTML, SOAP, REST, etc perform that
> function in the HTTP space.
> >
> > It would be trivial to specify certificate search, retrieval, update
> transactions over HTTP, but the set of such transactions has not been
> standardized.
>
> >  Every Internet-connected device has a DNS resolver that allows machines
> to manage and exchange resource data without human intervention.
>  Certificates could be managed as DNS resources (in theory - there is
> resistance to that idea in practice) using only TCP/UDP and the published
> DNS specs.  LDAP can do that with just the published TCP and LDAP specs.
> >
> > If a set of DNS-over-HTTP or directory-over-HTTP transactions were
> defined, HTTP could support M2M management and distribution of DNS and
> certificate resources.  But those transactions aren't standardized, so HTTP
> alone cannot be considered an "application protocol" with respect to DNS
> resources, SQL databases, or directories.
>

What was never finished was the one mechanism that a client can apply to
translate an SMTP email recipient address to the corresponding S/MIME
configuration (including cert).

Sharon Boyen and myself tried to do this a while back but got no uptake.
Possibly because of the lack of a decent DNS API on the platforms.

I have found LDAP to be nothing more than a waste of time and an
opportunity for enterprise IT department empire building. People can spend
months or years designing a directory deployment and the result works no
better than a HTTP repository does.

As for HTTP not being an application protocol or incomplete. That is
nonsense. Neither LDAP nor HTTP can be applied to the problem without
additional configuration choices being made. In the case of HTTP the
choices do not matter in the slightest except that they not be completely
crazy and that someone actually makes a choice so that there is one way to
do it. In the case of LDAP the DIT arc has implications that are far from
simple and has to be configured on a site by site basis.

-- 
Website: http://hallambaker.com/