Subject: I-D ACTION:draft-ietf-pkix-ldap-schema-00.txt

From: [email-masked]
Date: Wed, 12 Jul 2000 06:32:11 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.

	Title		: Internet X.509 Public Key Infrastructure Additional 
                          LDAP Schema for PKIs and PMIs
	Author(s)	: D. Chadwick
	Filename	: draft-ietf-pkix-ldap-schema-00.txt
	Pages		: 11
	Date		: 11-Jul-00
	
This document describes LDAP schema features in addition to RFC 2587 
that are needed to support a Privilege Management Infrastructure and 
a Public Key Infrastructure.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-ldap-schema-00.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-ldap-schema-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-ldap-schema-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Sean Mullan <[email-masked]>
Date: Wed, 12 Jul 2000 19:31:31 +0100

Hi David,

Some comments on the draft below.

>         Filename        : draft-ietf-pkix-ldap-schema-00.txt

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. 

  * you should be able to match on more than the subject alt name type. 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.

  * you should be able to match on the subject public key as well as the subject public
    key algorithm OID.

  * 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.

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.

Other comments:

  * What RFC format are you using for the encoding of DNs - 1779? This should be referenced.

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.

--Sean

---

From: Sean Mullan <[email-masked]>
Date: Wed, 12 Jul 2000 19:40:47 +0100

One other comment - I have mentioned this previously when
commenting on RFC 2587, but as of yet no changes have
been made. 

Building certification paths in a 'reverse'
direction (from trust anchor to EE) is a valid way to build
certification paths. However, RFC 2587 (PKIX LDAPv2 schema) specifies
that the storage of cross certificates in the reverse component of
the crossCertificatePair is optional. It is not possible to efficiently
build a certification path in a 'reverse' direction unless the 
certificates are populated in the reverse component of the crossCertificatePair
attribute. Specifying that this feature is optional makes it
difficult to build paths in a reverse direction in a trust model
where lots of cross certificates and multiple directories
are involved and you don't know if the CAs support
the optional storage.

I would like to suggest that RFC 2587 be amended/updated
to make storage of cross certificates in the reverse component of the
crossCertificatePair attribute mandatory.

Thanks,
Sean

---

From: "David Chadwick" <[email-masked]>
Date: Thu, 13 Jul 2000 15:02:42 +0100

Date sent:      	Wed, 12 Jul 2000 19:31:31 +0100
From:           	Sean Mullan <[email-masked]>
To:             	[email-masked]
Copies to:      	[email-masked], [email-masked]
Subject:        	Re: I-D ACTION:draft-ietf-pkix-ldap-schema-00.txt

> Some comments on the draft below.

Sean, replies intersperced below

> 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.
> 
>     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

you can match on the subject key identifier (3rd component)

>     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.

>   * What RFC format are you using for the encoding of DNs - 1779? This

It should be 2253 for LDAPv3.

> 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 [email-masked]
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

***************************************************

---

From: "David Chadwick" <[email-masked]>
Date: Thu, 13 Jul 2000 15:26:31 +0100

Date sent:      	Wed, 12 Jul 2000 19:40:47 +0100
From:           	Sean Mullan <[email-masked]>
To:             	[email-masked], [email-masked], [email-masked]
Subject:        	Re: I-D ACTION:draft-ietf-pkix-ldap-schema-00.txt

Sean 
this thread should be opened up to the whole PKIX list. I am happy 
to put this into the LDAPv3 schema if that is what is wanted, but 
there must have been some earlier discussion as to why it is 
optional and not mandatory.
David

> that the storage of cross certificates in the reverse component of the
> crossCertificatePair is optional. It is not possible to efficiently
> certificates are populated in the reverse component of the
> crossCertificatePair attribute. Specifying that this feature is
> optional makes it difficult to build paths in a reverse direction in a
> trust model where lots of cross certificates and multiple directories
> are involved and you don't know if the CAs support the optional
> storage.
> 

David Chadwick

---

From: Sean Turner <[email-masked]>
Date: Thu, 13 Jul 2000 18:44:05 -0400

Reverse path is building is a valid option, but I think the premise when we mandated the forward
element was to build the path from the EE cert up because you'd at a minimum have the signer's
certificate (or a pointer to it).  You'd then verify down the chain you built.

Sean - are you suggesting mandating the reverse element instead of the forward element or in
addition to it?

spt

---

From: Sean Mullan <[email-masked]>
Date: Fri, 14 Jul 2000 10:21:55 +0100

> Sean - are you suggesting mandating the reverse element instead of the forward element or in

In addition. Making it optional doesn't help much for those clients that need or want to
build paths in the reverse direction.

--Sean

-- 
************************************************************
Sean Mullan			  
Java Security & Networking      http://java.sun.com/security
Sun Microsystems                        tel: +353 1 819 9176
East Point Business Park                fax: +353 1 819 9262
Dublin 3                          mailto:[email-masked]
Ireland
************************************************************

---

From: Sean Mullan <[email-masked]>
Date: Fri, 14 Jul 2000 11:23:10 +0100

David,

> name presented should be allowed to have a cert path created to it)

Yes, but I think this is a bit more complex. I think ideally you should
be able to define in one matching rule all the selection criteria for
a certificate. So if a certificate contains more than one alt name, the matching rule
should allow you to match on more than one alt name. For ex, in one search I
would like to get all the certs issued by some DN that allow a path to be 
built to the subject altnames of "cn=mullan,o=sun,c=us" and "[email-masked]".
If I break this into 2 searches, I am likely to get duplicate certs or
certs that allows paths to be built to one of the names but not both.
Specifying 2 matching rules in one search would have similar problems.

> I would favour the former route myself.

I agree - if it doesn't take too long.

> Steven Legg has been doing this for me.

The X.509 certificateAssertion only allows you to match on the alt name type -
that's the problem I was referring to - that should be fixed.

> multiple searches with a single name in each search.

See comment above why I think this is more complex.

> you can match on the subject key identifier (3rd component)

but not the subject public key itself.

> anyway as the syntax is the same for both ACs and PKCs. This is

Sounds good but I think there might be an issue.

What happens if you want to define a matching rule to only retrieve certs
that contain a specific basic constraints value AND a certain issuer name? In
this case, you would define 2 matching rules and specify both of them in
the valuesReturnFilter control. But then you would get all certs with the
requested issuer name and any basic constraints value and all certs with
any issuer name and the requested basic constraints value. That's not
what you wanted. I think we may want to enhance the valuesReturnFilter
control (through a flag, perhaps) to allow the user to apply all of the 
elements of the filter to each attribute value. Let's discuss this more 
offline, if you like.
 
> needed and instead we should have a bunch of simple attributes in

I'll have to go back and read Bruce's draft but I agree with your responses
to Bruce in an earlier message. Comments later ...

Thanks,
Sean