RE: ldapv2-schema and CA Certificates

[Santosh Chokhani <chokhani@xxxxxxxxxxxx>]

Sharon:

I think that the current X.509 resolution impedes efficient path
development.

	-----Original Message-----
	From:	Sharon Boeyen [SMTP:sharon.boeyen@entrust.com]
	Sent:	Wednesday, August 12, 1998 5:57 PM
	To:	Sharon Boeyen; 'Simonetti David'
	Cc:	'Dave Horvath'; 'Carlisle Adams'; 'Santosh Chokhani';
ietf-pkix@imc.org; kpcm; 'Hoyt Kesterson'
	Subject:	RE: ldapv2-schema and CA Certificates

	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.
	>  << File: E Reed message.txt >>