Subject: Re: new version of draft on additional x509 certificate schema for LDAP

From: Peter Gietz <[email-masked]>
Date: Fri, 08 Nov 2002 11:47:26 +0100

I agree with Kurt's and Russ's proposals. It is better to define the 
MUSTs inside the object class and attribute definitions. Everything else 
is not easily enforcable.

Thus I intend to do something like the following in the next version of 
the draft:

( x.x.x.x NAME 'x509userCert'
   EQUALITY certificateExactMatch
   SYNTAX 1.3.6.1.4.1.1466.115.121.1.8 SINGLE-VALUE )

( x.x.x.x NAME 'x509cACert'
   EQUALITY certificateExactMatch
   SYNTAX 1.3.6.1.4.1.1466.115.121.1.8 SINGLE-VALUE )

( x.x.x.x NAME 'x509certificate' ABSTRACT
  MUST ( x509serialNumber $ x509signatureAlgorithm
    $ x509issuer $ x509validityNotBefore $ x509validityNotAfter
    $ PublicKeyInfoAlgorithm )
  MAY ( mail $ x509authorityKeyIdentifier $ x509authorityCertIssuer
    $ x509authorityCertSerialNumber $ x509subjectKeyIdentifier
    $ x509keyUsage $ x509policyInformationIdentifier
    $ x509subjectAltNameRfc822Name $ x509subjectAltNameDnsName
    $ x509subjectAltNameDirectoryName $ x509subjectAltNameURI
    $ x509subjectAltNameIpAddress $ x509subjectAltNameRegisteredID
    $ x509isssuerAltNameRfc822Name $ x509isssuerAltNameDnsName
    $ x509isssuerAltNameDirectoryName $ x509isssuerAltNameURI
    $ x509isssuerAltNameIpAddress $ x509isssuerAltNameRegisteredID
    $ x509extKeyUsage $ x509cRLDistributionPoint
    $ x509certHolder) )

( x.x.x.x NAME 'x509userCertificate' SUP x509certificate
    MUST x509userCert
    MAY x509subject )

( x.x.x.x NAME 'x509cACertificate' SUP x509certificate
    MUST x509cACert $ x509subject )

BTW: I changed the name of the attribute x509certificateHolder to 
x509certHolder to prevent the same name for an attribute and an 
objectclass, following a suggestion by Michael Stroeder.

I am not yet sure, why Kurt proposes an ABSRACT object class for 
x509certificate instead of a STRUCTURAL derived from top.

Cheers,

Peter

> Kurt D. Zeilenga wrote:
> At 01:23 PM 2002-11-07, Housley, Russ wrote:
> 
> If we take your approach, with two different classes, we can impose the requirement that CAs have x509subject.
> 
> 
> Yes, we could.
> 
> Another section 4.4 requirement which concerns me is:
>   For the purpose of this specification, each entry with a   structural objectclass of x509certificate MUST have one
>   and only one value of the userCertificate attribute or
>   caCertificate attribute, respectively.
> This single-valued requirement should be enforced by schema
> by defining one or two (depending on whether a user/ca
> distinction is desired) new singled-valued x509 attribute
> types of certificate syntax and having the objectclass(es)
> require their presence.
> 
> That is, use schema rules to express requirements upon the
> representation of the information.
> 
> Kurt

[...]
-- 
_______________________________________________________________________

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
_______________________________________________________________________
____

---

From: Norbert Klasen <[email-masked]>
Date: Fri, 08 Nov 2002 14:42:01 +0100

> x509certificate instead of a STRUCTURAL derived from top.

If x509certificate would be STRUCTURAL, one could create entries with 
x509certificate as the "structural object class of the entry". When is is 
made ABSTRACT, such entries are not allowed. This will enforce the 
requirement that an entry must contain the binary blob of the certifate as 
only the STRUCTURAL object classes x509cACertificate and 
x509userCertificate may be instantiated.

Norbert

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 08 Nov 2002 07:09:46 -0800

At 02:47 AM 2002-11-08, Peter Gietz wrote:
>I am not yet sure, why Kurt proposes an ABSRACT object class for x509certificate instead of a STRUCTURAL derived from top.

To prevent instantiation without a certificate.

Kurt

---

From: Camile Howe <[email-masked]>
Date: Sun, 10 Nov 2002 00:59:34 -0800 (PST)

Kurt... Believe though that the opposite is true if
you permit ABSTRACT from the top down.
Don't you mean "derived", but we'd still retain the
"binary blob of the certifate as only the STRUCTURAL
object classes x509cACertificate".

Camile

> x509userCertificate may be instantiated.

__________________________________________________
Do you Yahoo!?
U2 on LAUNCH - Exclusive greatest hits videos
http://launch.yahoo.com/u2

---

From: David Chadwick <[email-masked]>
Date: Thu, 14 Nov 2002 20:57:25 +0000

> To prevent instantiation without a certificate.

then it should be an AUXILIARY object class

David

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

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 Projects: http://sec.isi.salford.ac.uk
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
PGP Key ID is 0xBC238DE5

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

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 14 Nov 2002 13:31:57 -0800

>then it should be an AUXILIARY object class

Then it's subclasses could not be STRUCTURAL.

I do believe ABSTRACT for the super class of the two STRUCTURAL
classes, each requiring a different certificate attribute, is
appropriate here to disallow the super class from being the
structural object class of an entry.  Now, if someone wanted
to allow attribute types of this ABSTRACT to be present in
entries of arbitrary structural classes, then AUXILIARY classes
could be defined (each hopefully requiring a certificate
attribute) to support this.

But, being ABSTRACT, this class cannot be instatiated by
itself.  That is, an ABSTRACT class can only be instatiated
as a side-effect of instatiation of a (direct or in-direct)
non-ABSTRACT subclass of this class.

Kurt

---

From: David Chadwick <[email-masked]>
Date: Thu, 14 Nov 2002 22:30:32 +0000

> Then it's subclasses could not be STRUCTURAL.

Firstly I am not sure this is the case. I have read X501 again, and
there does not seem to be anything to stop a chain of

top>auxiliary>structural object class. Although I admit it is rather
unusual.

However, you can just as easily define STRUCTURAL object classes for
certificate entries, that are subordinate to Top, and have the
x509certificate as an auxiliary object class. I believe this is a better
approach, then the x509certificate object class, being auxiliary, can be
attached to any type of entry that needs the package of attributes that
it defines

David

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 14 Nov 2002 15:18:18 -0800

>top>auxiliary>structural object class. Although I admit it is rather

That's invalid per X.501.  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.

>attached to any type of entry that needs the package of attributes that

Well, as I noted before, one **could** have

     structX509user, structX509ca
AND
     auxX509user, auxX509ca

all inheriting from abstractX509.  abstractX509 would require/allow
attributes common to all four classes.  But userCertificate would
only be MUSTed in structX509user and auxX509user and caCertificate
would be MUSTed in structX509ca and auxX509ca.

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 am not prepared, at this time, to make a STRUCTURAL v AUXILIARY
recommendation.

---

From: David Chadwick <[email-masked]>
Date: Fri, 15 Nov 2002 13:44:07 +0000

"Kurt D. Zeilenga" wrote:

> To paraphrase the subclassing restrictions:

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.

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

David

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 15 Nov 2002 09:21:28 -0800

At 05:44 AM 2002-11-15, David Chadwick wrote:
>X.501 that catagorically state the above,

Yes.  I was confused by more explicit statements in LDAPBIS I-Ds.
I'm glad we agree they are sensible.  Those who disagree should
raise a concern to LDAPBIS.

Kurt