[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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.
>
From: Ed Reed[SMTP:ED#032#REED@novell.com]
Sent: August 5, 1998 12:46 PM
To: ietf-pkix@imc.org
Subject: Query about storing certificate chains in the directory...
As we are building on our own PKI base set of services, the question of
how client software obtains the complete chain of certificates needed
to validate a certificate has been raised by our developers. The process
of requiring a client application to "walk the directory tree", reading
CA certificates one at a time to construct the complete path seems
arduous, given the practice of sending the complete chain in the
form of a PKCS#7 blob with the messages to which it applies.
That suggests that there would be value in having a network service
which constructs certificate chains into blobs for client apps, so the
client can retrieve them all at once.
But, does it make any sense, as some have proposed, to store
those blobs in the directory, either with the certificates which they
support, or as separate attributes, perhaps on the CA?
I'd like to hear from anyone else who's considered doing this, or
would be interested in seeing this done. I'm worried about the ovious
duplication of data...but think that might be relieved if each CA
stores the chain of certificates which serve to validate it's own certificate,
together with its own certificate, for clients to use - sort of one-stop
shopping, rather than a walk through the tree...
Thank you,
Ed
-------------------
Ed Reed, Technologist
Novell, Inc.
+1 801 861 3320
-------------------
Ed Reed, Technologist
Novell, Inc.
+1 801 861 3320
-------------------
Ed Reed, Technologist
Novell, Inc.
+1 801 861 3320