Dear all,
I think that X.500 addresses have their use but thats mainly
to interact with X.500 addresses. The binding is unsatisfactory for the
following reasons :
1) An X.509 certificate is informaly described as a declaration by
the issuer that the subject posseses a public key
This is actually imprecise, the strongest statement to be made is
that there is an authenticated assertion from the issuer that any
entity which can provide information authenticated by the key
information is the subject.
2) There is no mechanism for providing qualifications on the assertion.
This is part of what X.509v3 is about. There should be provision to link to
the certificate revocation service.
Here, lets stop the thinking that goes "if we put the facility in to
allow online checking of certificates we have moved to an entirely online
scheme". I have an online system and want to take advantage of the
capaboilities that affords. Someone who does not have access to the
network will always be at a disadvantage. Tough!
3) The structure of the namespace reflects mailing addresses which are
geographical in nature.
Again this is problematic. People respond to logos rather than ascii
names. The X.509 specification is also centered on a latin alphabet
which is particularly bad. Or to be precise it tries to evade this
problem by leaving it open to implementations.
The principal difficulty with X.400 and X.500 addresses in general
is that they do not provide the strong cognitive associations to an
identity that is required. This is easily demonstrated using the
psychology principle of 7 items +- 2. The brain has limited short
term recall. Distinguished names exceed the buffer length.
A secondary difficulty is that our net persona is effectively our
email address attempts to duplicate that identity leads to dissonance,
the brain must remember two things and correlate them. This introduces
the possibility (probability) of error.
4) In PEM, the certificate is opaque.
Certificates carry vital information, the information which is most
needed to be read by the user. Why then use ASN.1 for this purpose?
While HTTP is headed for binary transport modes in general, certificates
are the IMHO one exception where the movement should be in the opposite
direction.
Unless there is a substantial readership who have both base64
and ASN.1 decoding abilities in the brain and can use both at once
then this is not "the right thing".
None of the above does not mean that X.509v3 is critically important
to the internet community. The lawyers can discuss semantics. We should
reserve syntax for ourselves. Thus we might define a certificate :-
Content-Type: application/certificate; content-boundary=signature-boundary
----signature-boundary
URI: URN:org/frobble/certificates/certmaster/tim/1
Issuer-Name: certmaster(_at_)frobble(_dot_)org
Subject-Name: tim(_at_)frobble(_dot_)org
Expires: date
Disclaimer: Not a valid contract unless accompanied by valid order form
Disclaimer: Only for use by frobble.org personel.
Revocation-Service: crlp://crl.frobble.org/; policy=required
Public-Key: RSA-1024, [two-big-numbers]
----Signature-boundary
Signature: [cybercrud]
-----Signature-boundary
[Or some such, I don't compose MIME messages by hand]
CRLP is the Certificate Revocation List Protocol I have just thought
up. It could equally be via a URN.
Comments???
Phill Hallam-Baker.