[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Binary vs. ASCII for certificates

At 21:51 2/24/96, Ron Rivest wrote:
>A few small comments:
>
>(1) I can imagine certificates containing intrinsically non-textual data
>    (most particularly, it might be nice to have an image of the person
>    whose key it is).

...or a hash of and URL for one.

I could also imagine a self-signed certificate of the form:

-----BEGIN PGP SIGNED MESSAGE-----

Certifying-Key: 0x7362BE39: 61 E2 DE 7F CB 9D 79 84  E9 C8 04 8B A6 32 21 A2
Signed-Key: 0x7362BE39: 61 E2 DE 7F CB 9D 79 84  E9 C8 04 8B A6 32 21 A2
Validity: 19960224,19990224
Meaning:  The following GIF field is a picture of me taken on 2/24/96 and I
    don't expect to become unrecognizable in the next 3 years :)
GIF: R0lGODdhXQB3APcAAAUFBDB8pHcdB6V7UXJMGSQ+SKG3xJxOD6qdij4PBXRgYMR+
     RHRiNwojEKR9dYZOHqBhUEIkCzReZM2cglYkDXA3EIJ9ZNm4qI44D0pAIAQqPCwI
     BqmLaSokDqiMeoZQL7Z8YHFCGKBlKX6drnZQNotjMAsTCFRCRNKslbZzVFJPLkA0
     EsHT1rqbiFk2EGd/lCszGYtvRsq3qmBAHLiMeG9DJqR8Y59wQYtpVRUUC7mtnMWL
     eJ9yUtrf4YhaMickHXNXKYhYI1d7j4llRLmio96bjseUf7d9d0AsEXJZPIlyXOWv
     [...]  {portions removed to shorten this e-mail}
     Tf2FhjVTTghTA1iEJiCGU6iHPPCYZ+CApzyNJ/2c/eSQEuBRaTAqbqoNeLXX2tDT
     uljSleiFcdAY/eKANWgGImiBTVgFZs2FrMyFbIhWaWXYhvXUX3hYOUDTX0gFVEAF
     ZDjVdnCADswDyYSCS2DV03ACNoAKMzEqmimBrqWZbiKA5NBTHlUHSeLRQxEBROmt
     KUhUefiHVwiAAMjKrNzOSQjaoSXaTdXUM/0FezAGpiWGQDCE8vOAcz3c12NVqtAY
     +VM8PdUgihJQcaIZOpBZHtVTPY1ZvzRUrnkGI4CFSOCGQ8gEVrrFzm3YBmjNW2vg
     273V1BKVg0LgBkEgBmKwhHWQzMjkwFXVBpHTlskaK8sNzuxpUB6lGRhCJmkZgHFI
     XssdAvwyVHaQTH74h9Gd20zIBFL40oRd3YAAADs=

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBMS/rilQXJENzYr45AQHKywP/YqYRhStrMsJ1R1zXOgwGlAcNrDiEErT6
ow2+7ajO5XFh6rwvYkzc07/t9OW+nr3XCJYtiUdvOTXgdeLylkAxyk8IDIG+LkZX
q2XRUo0U45V8GqpfaiiqqmqDIWSQcjw4ejd6E3wXvlboDobQygNcrqy22DNImSrT
oS8yL6BhTVc=
=My6P
-----END PGP SIGNATURE-----

As a separate optional certificate, it holds down the size of any cert
chain which gets passed along with messages -- available offline for
those who wish to check photos.  It is self-signed because in the
certificate semantics I've been proposing, the person being certified is
"whoever owns the private key for the indicated public key".  The model I
prefer is a generalization of the ATM card model:  you hold the card and
know the PIN, and that combination gives you permission to move money.
The user derives no security attributes or permissions by looking a certain way
or having a certain name or using a certain e-mail address.  To get and
exercise permissions or attributes, he must have posession of the
private key and know its PIN or passphrase.  He, defined that way, is the
sole authority over the name he answers to, the e-mail or SNail address
where he receives mail, etc.  That is the main departure I suggest we
make from identity-based certificates.

As for a signature on the picture, he can pretend to look like Charlton
Heston, if he wants, and post the appropriate self-signed picture -- but
it's his problem if he ever induces someone to believe him and if he
then has to meet that person in the flesh.  There might be appearance
authorities [e.g., commercial, on-line singles' clubs] who take a fee
for certifying that the picture is accurate and does, in fact, belong to
the person who demonstrates an ability to sign a random challenge with
the private key corresponding to the signed public key.  Single women
looking for hunks would rapidly learn to trust that authority and not a
self-signed cert... :)  How long until someone sets up such an authority
as a small business?  It could measure height and weight and note those
in the cert also.

>(3) It perhaps should not be overlooked that ASN.1 does not necessarily
>    require "binary" encodings.  It would be a simple matter to define
>    "AER" (Ascii encoding rules) for ASN.1 that might be preferable for
>    some purposes to the BER/DER encodings.  However, such encodings would,
>    if they are in the true spirit of ASN.1, still be missing the mnemonic
>    labels identifying the parts, and might still be rather complicated
>    to parse.  Still, some such encoding rule might be a useful adjunct to the
>    X.509 certificate procedures.

It's the parsing complication and the ASN.1 habit of seducing structure
designers into unnecessary generality that make ASN.1 such a pain to
work with for implementors.  The (tag,value) syntax tends to avoid that.

>    A related question is whether the ASCII certificate that is non intended
>    to be a representation of some X.509 certificate is nonetheless
>    representable in a satisfactory manner (and more strongly, automatically
>    transformable into) some "equivalent" X.509 certificate.  (And, of
>    course, whether this is wanted...)

It is my impression that X.509 would go up in a puff of smoke if one eliminated
names and especially Distinguished Names from certificates.  I seriously
propose eliminating names from certificates -- replacing them with
cryptographic hashes of the public keys involved in the cert -- allowing
human names back in with optional, self-signed certs by which a person
can announce the name to which he answers.

>(4) One must be careful to define what bytes are actually "present" in an
>    ASCII encoding, since the contents will be digitally signed.  The
>    treatment of whitespace, etc., needs to be carefully specified.

Yes -- this is very important.

 - Carl

+--------------------------------------------------------------------------+
|Carl M. Ellison          cme@cybercash.com   http://www.clark.net/pub/cme |
|CyberCash, Inc., Suite 430                   http://www.cybercash.com/    |
|2100 Reston Parkway           PGP 2.6.2: 61E2DE7FCB9D7984E9C8048BA63221A2 |
|Reston, VA 22091      Tel: (703) 620-4200                                 |
+--------------------------------------------------------------------------+
Follow-Ups: