Subject: CERT records

From: Edward Lewis <[email-masked]>
Date: Fri, 3 Nov 2000 08:15:35 -0500

Refering to RFC 2538, is it worth proposing a new "certificate type value"
for a PKIX X509 CRL?

There is a value (1) for X509 PKIX certificates.  It could be argued that
this value should be used for CRLs.

The reason I am floating this is because of a decidedly non-protocol issue.
In Java there are classes for X509Certificate and X509CRL.  Becuase of the
language's inheritence model [1], the two cannot be treated as the other
safely.  Ergo, when I get bits from DNS, I have to know ahead of time
whether the bits are a Certificate or a CRL[2].  Knowing ahead of time
could be made easy through a new certificate type value.

[1] X509Certificate extends Certificate, X509CRL extends CRL, and no
multiple inheritence is allowed.  The downside is that the two X509'ers
share some common fields and semantics which cannot share the same code. [3]

[2] Yeah, I could try casting as one, getting an exception/error/failure
and then try the other.  But this is an unelegant solution, and it would be
nice idf the "protocol" didn't foster ugly programming tricks.

[3] I don't want to turn this thread into a Java debate.  I'm not a Java
expert, I just write demo code, so perhaps I'm missing an obvious good
solution.  (Private email help is always welcome.)  Please restrict
responses to whether there should be a *proposal* to allocate another
number.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                NAI Labs
Phone: +1 443-259-2352                      Email: [email-masked]

"It takes years of training to know when to do nothing" - Dogbert

Opinions expressed are property of my evil twin, not my employer.

to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.

---

From: <[email-masked]>
Date: Fri, 3 Nov 2000 18:23:20 +0100 (CET)

> this value should be used for CRLs.

The certificate section of PKIX CERT records should start with a OID
length byte and then a X.500 OID specifying the content of the CERT
RR.  Among others, section 2.3 of rfc 2538 mention two OIDs that look
relevant:

    id-at-userCertificate
        = { joint-iso-ccitt(2) ds(5) at(4) 36 }
           == 0x 03 55 04 24

    id-at-certificateRevocationList
        = { joint-iso-ccitt(2) ds(5) at(4) 39 }
           == 0x 03 55 04 27

> could be made easy through a new certificate type value.

To my understanding it would be possible to use the OIDs for this.

Hope this helps.

---

From: "Stefan Kelm" <[email-masked]>
Date: Tue, 14 Nov 2000 19:38:59 +0100

Ed,

> could be made easy through a new certificate type value.

this makes a lot of sense, esp. since CRLs tend to grow very large in
real-life environments. However, we need to be careful to avoid
ambiguities since RFC 2538 allows for both certificates and CRLs to
be carried inside a CERT RR. So, someone who implements only RFC 2538
might not be able to check a new CRL RR. Maybe an OID could indeed
be used.

Cheers,

	Stefan.

-------------------------------------------------------
Dipl.-Inform. Stefan Kelm
Security Consultant

Secorvo Security Consulting GmbH
Albert-Nestler-Strasse 9, D-76131 Karlsruhe

Tel. +49 721 6105-461, Fax +49 721 6105-455
E-Mail [email-masked], http://www.secorvo.de
-------------------------------------------------------
PGP Fingerprint 87AE E858 CCBC C3A2 E633 D139 B0D9 212B

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 23 Nov 2000 15:48:16 +0100

I'd like to know if there are any interest in adding new CERT types
for S/MIME, WAP TLS and/or other PKIX-derived certificate formats.

One argument is that the "PKIX" certificate type is very general.
Several certificate flavours are based on PKIX, and more are likely to
be defined in the future.  S/MIME and WAP TLS certificates are the two
I've been working with.  This suggest that the number of certificates
attached to a specific domain name will grow once more flavours gain
acceptance -- and clients will

        1) waste bandwidth by retrieving all PKIX certificates for a
domain, and

        2) waste time to parse through all certificates to find a
S/MIME, WAP TLS etc certificate.

this would cause quite some complexity in a client.

Another argument for this is that there are several MIME types defined
for various PKIX derived certificates. `application/x-x509-user-cert'
and `application/vnd.wap.wtls-user-cert' are two.  Also, S/MIME
certificates may be transfered under the `application/pkcs7-mime'
type.  I'm not sure how good this argument is, a comparison between
MIME types and CERT types might be flawed.

Thanks in advance

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 24 Nov 2000 13:39:10 +0100

>this would cause quite some complexity in a client.

one answer is to define new RR types for each type of cert.
This is highly inflexible.

another answer is to define _ domains - find the S/MIME cert of 
[email-masked] under _smime.harald.alvestrand.no, for instance.
this is doable, but will double the domaincount *again*.

a third answer is to define the URL RR, and put a pointer to the relevant 
LDAP directory entry in it, where new types are a lot cheaper than in the DNS.

no lack of answers. lack of clue about picking one (and lack of clue-by-4 
to make the pick stick).

--
Harald Tveit Alvestrand, [email-masked]
+47 41 44 29 94
Personal email: [email-masked]

---

From: Patrik Fältström <[email-masked]>
Date: Fri, 24 Nov 2000 15:41:25 +0100

>LDAP directory entry in it, where new types are a lot cheaper than in the DNS.

Or (re-)use NAPTR for this, as NAPTR rewrites can result in URI's 
(one example is RFC 2916).

   paf

--

---

From: Edward Lewis <[email-masked]>
Date: Fri, 24 Nov 2000 13:31:09 -0500

>        1) waste bandwidth by retrieving all PKIX certificates for a

Not to dispute the desire for more CERT type-value definitions, but
defining different values wouldn't reduce the bandwidth - all things being
equal.

E.g.:

owner.domain.name  CERT PKIX-1 <<cert>> ; yes, I omitted the key args
                   CERT PKIX-1 <<cert>>
                   CERT PKIX-2 <<cert>>

Even if I just wanted PKIX-2 (e.g. WAP TLS) I would be getting all three.
The different numbers fo make it easier to throw away the two unwanted
(PKIX-1) CERTs though.

To cut down on the bandwidth you could do this:

pkix-1.owner.domainname CERT PKIX-1 <<cert>> ; again, omitting key args
                        CERT PKIX-1 <<cert>>
pkix-2.owner.domainname CERT PKIX-2 <<cert>>

In the latter case you'd get just the one desired - saving bandwidth at the
cost of more domain names (more an issuer for the client than the server).