RE: comments on draft-ietf-pkix-ipki2opp-08.txt

[Sharon Boeyen <sharon.boeyen@xxxxxxxxxxx>]

Hi Alan,

The PKIX WG embarked on this spec well over a year ago with the primary
purpose being to standardize what was predominantly deployed at that time -
LDAPv2 for use to access PKI repositories. A minimum subset of the LDAPv2
protocol was profiled, in order to enable relying party and certification
authority systems to be able to access LDAP server PKI repositories without
needing all the code a typical LDAP client would have. We were not
attempting to standardize server to server communications, only a protocol
for clients (relying parties and CAs) to use to access the repository. 

While I personally agree with some of your views about the more
comprehensive functionality that can be provided in an X.500 based
distributed systems environment, that wasn't the task we undertook. 

As the work on LDAPv2 dragged on and on and on we qestioned several times
within the WG whether to drop this activity and concentrate instead on a
more 'modern' directory technology such as LDAPv3, but every time this was
raised, the PKIX WG agreed to proceed with the LDAPv2 specs and get them
progressed since this is still a very widely deployed protocol, even though
there is plenty of interest in LDAPv3 as well. The LDAPv2 protocol profile
completed PKIX WG last call in January and the schema spec just a short time
ago. No changes have been made to the protocol spec, the only reason it was
re-issued was because it was about to expire becasue the schema spec
(required for IESG approval of the protocol profile) took so long.

I hope this answers your questions on 'why' the LDAP activity. 
Sharon 


  
> ----------
> From: 	Alan Lloyd[SMTP:Alan.Lloyd@OpenDirectory.com.au]
> Sent: 	September 27, 1998 6:24 PM
> To: 	'ietf-pkix@imc.org'
> Subject: 	comments on draft-ietf-pkix-ipki2opp-08.txt
> 
> Comments: Internet X.509 Public Key Infrastructure 
>                             Operational Protocols - LDAPv2
> 
> Sorry for being my usual self. But what does this document do or solve.
> 
> All it states is use LDAP V2 to a PKI repository? and highlights the
> major failings of LDAP encoding when dealing with certificate attributes
> with multiple values. ie. In that the client gets the lot (every
> certificate - regardless) --  and if the client goes for CRLs as well  -
> and they are multi values of a CRL attribute - the client will get the
> lot as well.
> 
> Lets do some rough sums. A cert = 600 - 2k bytes average 1kb, 5-10 certs
> per user, 3 certs in a path.. transfer = 20- 30kb just to verify a
> signature. In addition CRLs - bad sites, and they could get large.
> And LDAP  accesses for the certs could be via referrals. Lets say that
> we could be looking at optimistically  at 10-30 seconds of validation
> time.
> I would be happy to be corrected here..
> 
> 
> Fundamental Problems with LDAP
> 
> LDAP servers are "string based" and non distributed - hence the need to
> use X.500 and migrate these LDAP servers to a distributed architecture.
> Not all certificates one wishes to deal with will be in your local ldap
> server - they will be in the directory system that one cooperates with.
> 
> X.500 has certficate matching rules to enable selection of certificates
> within a multi value attribute.
> 
> I am not sure what cert matching rules LDAP servers have or even if they
> support multi valued att matching or if they are compatible with X.500.
> Again the encoding restrictions in LDAP could imply the non use of
> these.
> 
> It is obvious to most that LDAP is not very good generally and in the
> case of PKI / certficate issues over a wider scale, totally unusable.
> 
> In addition the process one builds into an LDAP client to deal with
> referrals and LDAP certficate servers has to be lot larger and therefore
> problematic, than that that uses distributed directories with sound
> matching rules.
> 
> ie. the best it can get depends on the tools to hand.
> 
> I therefore beg why the document is being put forward because IMHO - it
> promotes systems to be built that will not provide the business utility
> demanded by companies using large scale EC/509 technologies. The result
> can only be commercial disasters and pain for both suppliers and the
> poor customer.
> 
> Oh well - 
> 
> regards alan
>    
>