Re: I-D ACTION:draft-ietf-pkix-ldap-schema-00.txt
"David Chadwick" <d.w.chadwick@salford.ac.uk> Thu, 13 July 2000 14:05 UTC
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19729 for <pkix-archive@odin.ietf.org>; Thu, 13 Jul 2000 10:05:30 -0400 (EDT)
Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA24836; Thu, 13 Jul 2000 07:02:43 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Thu, 13 Jul 2000 07:02:03 -0700
Received: from mta01-svc.ntlworld.com (mta01-svc.ntlworld.com [62.253.162.41]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA24800 for <ietf-pkix@imc.org>; Thu, 13 Jul 2000 07:02:02 -0700 (PDT)
Received: from dwc-acer ([62.252.104.255]) by mta01-svc.ntlworld.com (InterMail vM.4.01.02.27 201-229-119-110) with ESMTP id <20000713140401.PWPE26680.mta01-svc.ntlworld.com@dwc-acer>; Thu, 13 Jul 2000 15:04:01 +0100
From: David Chadwick <d.w.chadwick@salford.ac.uk>
Organization: University of Salford
To: Sean Mullan <sean.mullan@sun.com>, ietf-pkix@imc.org, ietf-ldapext@netscape.com
Date: Thu, 13 Jul 2000 15:02:42 +0100
MIME-Version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Subject: Re: I-D ACTION:draft-ietf-pkix-ldap-schema-00.txt
Reply-to: d.w.chadwick@salford.ac.uk
CC: Boeyen@entrust.com
Message-ID: <396DDA12.874.862330B@localhost>
Priority: normal
In-reply-to: <396CB983.81DC54B3@sun.com>
X-mailer: Pegasus Mail for Win32 (v3.12c)
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe
Content-Transfer-Encoding: 7bit
Date sent: Wed, 12 Jul 2000 19:31:31 +0100 From: Sean Mullan <sean.mullan@sun.com> To: d.w.chadwick@salford.ac.uk Copies to: ietf-pkix@imc.org, ietf-ldapext@netscape.com Subject: Re: I-D ACTION:draft-ietf-pkix-ldap-schema-00.txt > Hi David, > > Some comments on the draft below. Sean, replies intersperced below > Section 3.2 Certificate Match > > I think the X.509 certificate matching rules are missing some > essential and important fields in the certificateAssertion structure > for filtering on certificates. We may want to consider defining a > superset. I submitted these comments to the X.509 editors but > apparently it was too late to integrate them into the 2000 update. > > * you should be able to match on more than one pathToName and on > non-X500 > name types. This is inconsistent with name constraints which allow > you to constrain to more than one name and different name types. > I agree that alternative name types should be allowed. But maybe it is not necessary to have multiple names, since you can do several Searches providing one name for each search (remember that the name presented should be allowed to have a cert path created to it) How do we want to handle this: i) issue a defect on X.509 (Sharon can you comment on this) ii) let the LDAP matching rule be a superset of the X.509 one? I would favour the former route myself. > * you should be able to match on more than the subject alt name > type. Agreed. This is a lack of clarity in the ID. It is intended that the whole name can be presented along with the type. The text is ambiguous in this respect and I will fix it. It will also be clearer when version 1 is published that contains BNF for each of the fields. Steven Legg has been doing this for me. > You > should also be able to match on the subject alt name itself, and > specify more than one subject alt name as certificates can contain > more than one. > Concerning multiple names, I think this can be solved by performing multiple searches with a single name in each search. > * you should be able to match on the subject public key as well as > the subject public > key algorithm OID. > you can match on the subject key identifier (3rd component) > * you should be able to match on the basic constraints extension, > especially the > maxPathLen value. This is useful for finding potential > certificates when building certification paths from the target to > the most-trusted CA. For ex, if a partial path has been built, any > candidate certificate must have a maxPathLen value greater than or > equal to the number of certificates in the partial path. > Interestingly this has been defined for attribute certificates and not pk certs. I actually think that the way matching for ACs has been handled is far superior than for PKcerts. ie. a separate matching rule for each extension, rather than one long complex rule for pk certs. However, there would be nothing to stop an implementation dynamically attaching the basicAttConstraintsMatch to public key certs. In fact this matching rule could be renamed the basicConstraintsMatch anyway as the syntax is the same for both ACs and PKCs. This is my preferred approach. > I think it is very important to include the Certificate pair matching > rules, as these are very useful when building certification paths and > trying to discover which of many cross certificates satisfy various > validation constraints, and eliminating those that do not. > OK, this can be done. It is just time consuming and I wanted to know if there was a demand first. > Other comments: > > * What RFC format are you using for the encoding of DNs - 1779? This > should be referenced. It should be 2253 for LDAPv3. > > Section 4.2 Certificate List Match > > There is an error in the CertificateListAssertion definition in X.509 > 2000. The authorityKeyIdentifier component should be marked OPTIONAL. > This probably doesn't affect your definition, but I just wanted to > make you aware of it. Agreed, Sharon, can you make a note of this defect David p.s. what do you think about Bruce's assertion that none of this is needed and instead we should have a bunch of simple attributes in the LDAP entry David > *************************************************** David Chadwick IS Institute, University of Salford, Salford M5 4WT Tel +44 161 295 5351 Fax +44 161 745 8169 Mobile +44 790 167 0359 Email D.W.Chadwick@salford.ac.uk Home Page http://www.salford.ac.uk/its024/chadwick.htm Understanding X.500 http://www.salford.ac.uk/its024/X500.htm X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm Entrust key validation string MLJ9-DU5T-HV8J ***************************************************
- I-D ACTION:draft-ietf-pkix-ldap-schema-00.txt Internet-Drafts
- Re: I-D ACTION:draft-ietf-pkix-ldap-schema-00.txt Sean Mullan
- Re: I-D ACTION:draft-ietf-pkix-ldap-schema-00.txt Sean Mullan
- Re: I-D ACTION:draft-ietf-pkix-ldap-schema-00.txt David Chadwick
- Reverse paths David Chadwick
- Re: Reverse paths Sean Turner
- Re: Reverse paths Sean Mullan
- Re: I-D ACTION:draft-ietf-pkix-ldap-schema-00.txt Sean Mullan