Re: ldapv2-schema and CA Certificates

["Simonetti David" <simonetti_david@xxxxxxx>]

Sharon,

I agree that throwing stones will not help solve this issue, but Mr.
Horvath and Dr. Chokhani have provided technical reasons to support an
alternative approach which you have readily refuted.  I ask that you
please consider the merits of this approach.  This method for path
generation is documented in the profile that I recently distributed.

Dave S.

Sharon Boeyen wrote:
> 
> Hi Dave,
> 
> I'm disappointed that you feel the way you do and hope we can discuss this
> professionally, eliminating any further personal insinuations. Feel free to
> verify the following status information with Hoyt Kesterson the X.500
> Rapporteur and official liason from that group to the IETF, or with any
> other participant in the meetings, including some of your colleagues. I'm
> sure Hoyt would be willing to provide you with the attendance list from the
> meetings, or if you prefer I can provide some names to you in a private
> email.
> 
> First let me clarify the defect origination, resolution and current status:
> 
> I did NOT, as you suggest, create this defect report. Although defect
> reports don't carry the name of the individual who reported them,  defect
> reports which were generated by me over the years are included in those
> which are sourced "Canada" as they were  processed through the Canadian
> national ISO and ITU-T standards processes prior to submission
> internationally.  This defect report is not one of those and the report
> itself lists the ISO Rapporteur as the source. I was however,  an active
> participant in the discussion during both meetings and did draft some
> proposed text for the group to consider, which was revised as a result of
> discussion among participants at the January 1998 meeting. That revised text
> is what is currently contained in the PKIX draft.
> 
> As for the availability of X.509 defect report information, Hoyt Kesterson
> maintains an ftp resource on the Bull server and there is a folder there
> containing defect report information. Unfortunately, it isn't completely up
> to date and the last time I checked, didn't contain this particular
> resolution. However versions of the Directory Implementors Guide dating back
> to early 1997 have listed this as an outstanding defect since that time and
> those have been publicly available. There is also a file on Hoyt's server
> which, for some reason, I cannot seem to unzip but I suspect it might also
> contain a copy of the original defect report.
> 
> The status of the resolution to the defect is that text was agreed at the
> January meeting to go out for ISO ballot as a Draft Technical Corrigendum
> (DTC). Comments can be submitted in response to the ballot, (I don't believe
> this one has started yet), and would be considered by the defect editing
> group prior to progressing a resolution to Technical Corrigenum state (TC).
> Just as with the progression of the version 3 certificate, I believe the 509
> group greatly values input from the PKIX WG and doesn't want to have
> differing standards. From a formal standpoint, Hoyt Kesterson is the ISO
> official liaison to the IETF and Harald Alvestrand is the IETF official to
> the X.500 group.
> 
> Having clarified the defect status (I hope) can we work to resolve this
> current PKIX issue on technical grounds rather than political ones?
> 
> The primary technical rationale for the current resolution to the defect is,
> I believe, that it provides a single point from which a client system can
> retrieve the certificates necessary to build a certification path,
> independent of the trust model, PKI architecture or relationships among the
> various entities involved.
> 
> I don't disagree that efficiencies in path building in specific environments
> may also be possible, however I think that the potential for efficiency can
> be dependent on other factors than internal versus external, such as the
> application itself or relevant certificate policies, and therefore a
> solution to the "preferred path" scenario should be more general. Perhaps an
> additional optional attribute might be an appropriate solution, I'm sure
> there are alternative approaches as well that need to be considered.  The
> attached posting to the PKIX list by Ed Reed of Novell was one of the
> reasons I started thinking about this "preferred" scenario a bit more
> generally.
> 
>  <<E Reed message.txt>>
> 
> Also, let's remember that the IETF PKIX schema draft says, as does the X.509
> defect resolution, that these attributes "MAY" be used as described not that
> they must.
> 
> Sharon
> 
> > ----------
> > From:         Simonetti David[SMTP:simonetti_david@bah.com]
> > Sent:         August 12, 1998 4:07 PM
> > To:   Sharon Boeyen
> > Cc:   'Dave Horvath'; 'Carlisle Adams'; 'Santosh Chokhani';
> > ietf-pkix@imc.org; kpcm
> > Subject:      Re: ldapv2-schema and CA Certificates
> >
> > Sharon,
> >
> > Sharon Boeyen wrote:
> > <snip>
> > > 5.  I am NOT proposing, as you imply, that the semantics of ANY
> > attribute be
> > > changed. Rather I am requesting that the PKIX specification REMAIN
> > aligned
> > > with the semantics as defined for X.509.  The PKIX spec is currently
> > aligned
> > > with the X.509 resolution of the associated defect report.
> >
> > I wonder how many people on this list had an opportunity to review the
> > defect report or had an opportunity to contribute to its resolution.
> > And if the Internet community does not agree with the resolution of this
> > "defect", how do we go about revising it?  I guess it wouldn't be the
> > first time PKIX strayed from X.509 (I recall a little something about a
> > CRL Distribution Points extension).
> >
> > I mean this with all respect, but (I believe) you created the defect
> > report and recommended its resolution.  It's no wonder that it meets
> > your needs.  It's disappointing that such "defects" are not more widely
> > published before they are resolved.
> >
> > Dave S.
> >
> 
>   ------------------------------------------------------------------------
> 
>    E Reed message.txt   Name: E Reed message.txt
>                         Type: Plain Text (text/plain)

-- 
David Simonetti, Booz·Allen & Hamilton Inc.