Subject: Issues in LDAP schema IDs

From: David Chadwick <[email-masked]>
Date: Thu, 17 Jul 2003 13:27:10 +0100

Dear All

Peter and I have resolved all the issues described at the PKIX meeting
today, apart from one, which is what should be the attribute type to be
used to hold the X.509 DER encoded attribute. Should it be the original
attribute type name e.g. userCertificate or a new attribute whose schema
says it must be single valued. Comments please to the list to help us
resolve this final issue.

Concerning the resolved issues, the object classes of the newly created
child entries will be created with one abstract class for the
certificate/CRL (all derived from x509base) plus appropriate structural
ocs (as now) and then additional auxiliary object classes to cater for
X.509/PKIX profile defined extensions, other PKIX defined extensions
like qualified cert extensions etc. New auxiliary object classes and
attribute types can be created by people as needed. We will define in
the current IDs auxiliary classes and attributes for X.509 standard
extensions, and some from the certificate profile (RFC 3280). Other
ones, eg. for qualified certs, may make it into these IDs are may not,
depending upon our time. We now have a proper oc structure which can be
easily and intuitively extended as required.

Regards

David

-- 
*********************************************************

Leaders of the world's richest nations meet in Cancun on September 10th
2003. Oxfam is presenting them with a petition to make trade fair. Be
sure your voice is heard. Sign the 'Big Noise' petition to make trade
fair at:

http://www.maketradefair.com/go/join/?p=omf1 

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

David W. Chadwick, BSc PhD
Professor of Information Systems Security
IS Institute, University of Salford, Salford M5 4WT
Tel: +44 161 295 5351  Fax +44 01484 532930
Mobile: +44 77 96 44 7184
Email: [email-masked]
Home Page:  http://www.salford.ac.uk/its024/chadwick.htm
Research Web site: http://sec.isi.salford.ac.uk
Seminars: http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5

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

---

From: Michael Ströder <[email-masked]>
Date: Thu, 17 Jul 2003 16:24:35 +0200

David Chadwick wrote:
> says it must be single valued.

I'd strongly argue for back-wards compability with existing clients
=> userCertificate

Off course there should be a directory profiling note stating that there 
MUST NOT more than one attribute value to be compliant. The caveat is 
off-course that the directory can't enforce the SINGLE-VALUE restriction by 
schema definition.

Ciao, Michael.

---

From: "Wen-Cheng Wang" <[email-masked]>
Date: Fri, 18 Jul 2003 09:50:03 +0800

> off-course that the directory can't enforce the SINGLE-VALUE restriction by
My concern is a CA may support dual key pairs for a single EE. One key pair
is for digital signature usage; the other key pair is for encipherment usage. A
CA
may even support triple key pairs for a single EE if non-repudiation usage is to
be
separated from digital signature usage. Therefore, a CA may issues two or three
certificates to an EE at a time. If the attribute is restricted to be single
valued, how
do these certificates be stored in the directory?

-----
Wen-Cheng Wang
Project Researcher
Telecommunication Laboratories
Chunghwa Telecom Co., Ltd

---

From: Antonio Lioy <[email-masked]>
Date: Fri, 18 Jul 2003 09:12:37 +0200

> do these certificates be stored in the directory?

I can confirm that this is actually happening in Italy, where many 
legal-value CAs are giving to their customers three certs:
- one for non-repudiation
- one for authentication
- one for encryption

So support for multiple certs per each user should be added to the schema.

Cheers,

Antonio Lioy

---

From: Michael Ströder <[email-masked]>
Date: Fri, 18 Jul 2003 11:21:37 +0200

Antonio Lioy wrote:
> 
> Wen-Cheng Wang wrote:
> 
>> My concern is a CA may support dual key pairs for a single EE.
 >

I'd suggest to read the draft. Hint: Multi-valued attributes are not the 
only way to store multiple certificates per user.

Ciao, Michael.

---

From: Massimiliano Pala <[email-masked]>
Date: Fri, 18 Jul 2003 18:11:27 +0200

> resolve this final issue.

[...]

If no issue is expected to arise from the adoption of the old name I am in
favour of the userCertificate.

-- 

C'you,

	Massimiliano Pala

--o-------------------------------------------------------------------------
Massimiliano Pala [OpenCA Project Manager]                [email-masked]
                                                  Tel.:   +39 (0)59  270  094
http://www.openca.org                            Fax:    +39   178  221 8225
http://openca.sourceforge.net                    Mobile: +39 (0)347 7222 365

---

From: David Chadwick <[email-masked]>
Date: Mon, 21 Jul 2003 16:20:08 +0100

> So support for multiple certs per each user should be added to the schema.

This has always been there. This is not the issue. It is whether the
newly created per certificate entry should use a multivalued attribute
or define a new one.

regards

David

---

From: Peter Gietz <[email-masked]>
Date: Tue, 29 Jul 2003 15:57:08 +0200

Just to make it clear and prevent misunderstandings:

Our schema specifies the storage of each certificate in a separate 
directory entry. Those entries can be stored either below a person entry 
or in a certificate only repository

1.) below Person entry:

                         cn=person name
                           (mail=emailadress, etc.)
                         /       |       \
                        /        |        \
                   cn=cert1     cn=cert2   cn=cert3

2.) below CA cert repository:

                         o=CA Name
                           |
                           |
                    cn=certificate repository
                         /       |          \
                        /        |           \
                   cn=cert1     cn=cert2 ...  cn=cert1008

Hope this helps.

Cheers,

Peter

-- 
_______________________________________________________________________

Peter Gietz (CEO)
DAASI International GmbH                phone: +49 7071 2970336
Wilhelmstr. 106                         Fax:   +49 7071 295114
D-72074 Tübingen                        email: [email-masked]
Germany                                 Web:   www.daasi.de

Directory Applications for Advanced Security and Information Management
_______________________________________________________________________