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

RE: Any more comments on the whois++ SPKI proposalette?

At 09:04 PM 4/20/96 -0700, Simon Spero wrote:

>I figured that was a first draft :-) My general feeling is that  the 
>requirements for an SPKI are more or less implied by the name - 
>It's gotta be as simple as possible; if the requirements are too 
>complicated, then X.509 is indicated. 
>A quick cut at making the requirements more explicit
>1) The SPKI must be easier to implemnt than X.509
>2) The SPKI certificate format must allow abitrary fields to be signed for.
>3) The SPKI certificate format must allow arbitrary fields to be 
>   signed/not-signed. 

There are better solutions to this problem than a list of fields.
For simplicity, I would strongly suggest that a certificate be the signed thing,
with no possibility of signing a subset.  Among other things, if you can
sign subsets, then you get into the X.509-like nonsense of having to
re-encode the certificate fields before you check signatures -- allowing for
errors in re-encoding to defeat signature verification.

>4) The SPKI format should allow certain fields to be designated 
>   mandatory; the certificate must be rejected if these fields are not 
>   supported. (ala v3)
>5) The SPKI must define attribute types for embedded public keys;
>   pre-defined types should be defined for RSA, DSS, and DH keys 
>6) The SPKI should be useable with at least one standards track directory
>   protocol. 

What do you mean by (6)?

>7) The SPK should allow multiple parties to sign a single certificate

No problem.

>8) It should be possible to transfer SPKI certificates through electronic 
>   mail,  either through the use os a mail safe format or through 
>   definition of a new mime type
>9) SPKI signatures should support fixed term validity periods
>10) SPKI should support online CRLS
>11) SPKI should upport offline CRLS

You misses two of the most important points, IMHO:

-1) SPKI certs should sign keys instead of names
0) SPKI certs must contain a Meaning field, describing the meaning of the
cert (e.g., the permission being granted by that cert).

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