Subject: Re: new version of draft on additional x509certificateschema for LDAP

From: "Peter Gietz" <[email-masked]>
Date: Mon, 18 Nov 2002 21:47:54 +0100 (CET)

>  "Kurt D. Zeilenga" wrote:
>
>>  To paraphrase the subclassing restrictions:
>>    A structural class cannot subclass an auxiliary class.
>>    An auxiliary class cannot subclass a structural class.
>>    An abstract class cannot subsclass an auxiliary class.
>>    An abstract class cannot subsclass a structural class.
>>
>  This is definately paraphrasing, and most of us would agree that
> these restrictions are sensible, but I repeat, you cannot find
> sentences in X.501 that catagorically state the above, and you can
> find statements in X.501 that appear to allow some of the above.
>
>
>>  If consensus is to go the STRUCTURAL route, I suggest defining one
>> abstract class and two structural classes.
>>
>>  If consensus is to go the AUXILIARY route, I suggest defining one
>> abstract class and two auxiliary classes.
>>
>
>  I was suggesting an alternative: one AUXILIARY (for packaging) and
> two (unrelated) STRUCTURALs for certificate objects (CAs and Users).
> But I think we should hold the discussion until we have the schemas
> for CRLs and ACs. We will then see some common packaging needs (e.g.
> issuer and serial number) that is not in the existing proposed
> schemas, and so we might want to have different object classes.
>

Before this discussion has taken place I will propose the following
 (following Kurt's proposal):

an ABSTRACT x509Certificate objectclass
and the two STRUCTURAL object classes:
x509userCertificate and x509caCertificate as defined by Kurt.

I don't yet think that there is a need for similiar AUXILIARY object
classes. The whole idea behind our draft is to have an entry for each
certificate, thus the thing that this entry is all about is the
certificate, thus a typical use case for STRUCTURAL. Even if there will
be the need in future to add additional data to such an entry, it can
be done with auxiliary objectclasses sticked to these structural ones.

Does the latter conflict with your idea of packaging, David?

BTW: my first hesitance to define an ABSTRACT class, was that this is
not done very often (in fact it will be the first one after top). But
since it is a perfect means to prevent an instantiation without the
certificate, why not go for it.

Cheers,

Peter

---

From: [email-masked]
Date: Wed, 20 Nov 2002 13:55:20 -0000

Date sent:      	Mon, 18 Nov 2002 21:47:54 +0100 (CET)
Subject:        	Re: new version of draft on additional x509certificateschema for LDAP
From:           	"Peter Gietz" <[email-masked]>
To:             	<[email-masked]>

> Does the latter conflict with your idea of packaging, David?

Yes. We already have a requirement for a common object class for all X.509 
attributes. (You can read this in our detailed design submitted to Terena at the 
end of last week). We need to search for all X.509 entries subordinate to a 
user's entry. Whilst it is true that we could search for multiple object classes 
(and update the code when new ones are defined), having a common object 
class containing common attributes, makes it easier and hopefully future proof. 
That's why I would like to hold off the final decision until we have published our 
Attribute Cert and CRL schema IDs

> not done very often (in fact it will be the first one after top).

Actually I did this a few years ago when I defined Families of Entries

David

> But

---

From: Peter Gietz <[email-masked]>
Date: Wed, 20 Nov 2002 19:06:11 +0100

> Attribute Cert and CRL schema IDs

Ok. My statement started with "until that discussion takes place" 
anyway. Looking forward to reading those IDs.

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
_______________________________________________________________________