Subject: RE: draft-ietf-pkix-ldap-*-schema WG LC comments

From: "Stefan Santesson" <[email-masked]>
Date: Mon, 29 Nov 2004 18:19:51 -0000

I would also like to state, within this last call period, that I oppose
these documents being published as a product of the PKIX WG.

The approach may provide some values with respect to shortcomings of
current implementations, but the larger issue is whether the approach
embodies the intended and desired path to the future. It seems to me
that creation of separate additional entries for each certificate (or
CRL) is not the appropriate architectural approach.

I agree that publication of these drafts as a product of this WG sends
the wrong message (even if not standards track) since there is an
obvious risk that they will be interpreted as this WGs view of the path
forward.

Stefan Santesson
Microsoft Security Center of Excellence (SCOE)

> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Kurt D. Zeilenga
> Sent: den 29 november 2004 14:27
> To: [email-masked]
> Subject: draft-ietf-pkix-ldap-*-schema WG LC comments
> 
> 
> It was my understanding after previous discussions (involving
> the authors, chairs, ADs, myself, and others) that these I-Ds
> would be individually submitted to the RFC Editor for
> consideration.  I am a bit surprised that they are now being
> last called in PKIX WG as I was under the impression that the
> WG has already reached consensus that these I-Ds would not be
> progressed as products of the PKIX WG.
> 
> If these had been submitted directly to the RFC Editor, I
> would have recommended to the IESG that an "IESG note" be
> added to each I-D that clearly stated the I-D was not a
> product of the IETF, provided an alternative to a standard
> track approach, and that the standard track approach
> should be favored by implementors and deployers.
> 
> However, as these I-Ds have been submitted to the PKIX WG
> for consideration, the PXIX WG must reach consensus that the
> I-Ds are technical sound and appropriate for publication as
> a products of this WG.  I seriously doubt this WG will now
> reach consensus that these I-Ds should be published as
> products of the PKIX WG.
> 
> I do not believe the value extraction approach to be sound as
> it doesn't actually address the key problem: matching against
> arbitrary component values of a certificate (or other complex
> structures).  For instance, say the application wanted to match
> all person objects containing a certificate whose subject DN
> contained an RDN containing an AVA with a common name of X.  This
> schema simply doesn't support that kind of matching because only
> select values of the certificate, some of which are themselves
> complex structures, have been extracted AND, even if they had
> been, the operation would not find the person object holding
> the certificate, but a certificate object.
> 
> I believe the existing standard track approach more than
> adequately addresses application needs in this area, and that
> it can and will be implemented.  Not only are there two
> existing implementations today, one is open source (and available
> for reuse under non-restrictive terms).  While I cannot speak for
> the plans of other vendors, I can say that I have been contacted
> by a number of vendors who made it clear to me that they intend
> to put implementation of the standard track approach into their
> product plans.
> 
> Hence, I oppose progression of the I-Ds as products of the PKIX
> WG (regardless of track).  I encourage the authors to withdraw
> the I-Ds from IETF consideration and to submit them directly to
> the RFC Editor for consideration.
> 
> I note that I found a number of other issues in the I-Ds.  I will
> separately provide the WG with my review notes.
> 
> Regards, Kurt