CERT records

[Edward Lewis <lewis@tislabs.com>]

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: lewis@tislabs.com

"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 namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.