[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 |
+--------------------------------------------------------------------------+
Follow-Ups: