[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Any more comments on the whois++ SPKI proposalette?
Interesting... methinks different notions of requirements are in
operation here.
I was thinking of things like the needs of the previous set of
applications that I sent out, and the LA IETF WG meeting where I thought
I heard that the requirements were to be application driven. (I'm not
necessarily saying I disagree with your list of requirements -- just
that I don't connect them to what is needed for some particular
application, and don't know if they will satisfy the needs of any
particular set of applications that we think are important, or if there
are more requirements than are needed for our applications, so some
could be cut to make the design simpler...)
So my quick cut at a more detailed set of requirements would be (for
each of the applications in my previous list) things like:
1. Who/what are the principals to be identified? E.g., people for mail,
people and processes for client/server,...
2. Who is going to certify the principals? What criteria are they going
to use? What does this mean is for the content of the certificate?
3. Are the parties being certified in direct communication? Can they
access a certificate store or CRL?
4. Is trust to be established by a program, or a user? At what level --
once per communication, by an "introduction", or the first time
communication happens, or...?
5. What performance level can you assume the communications links to be?
Is the service interactive or background? (I.e., can you afford to send
the certificate when establishing communication, or will communicants
need to be able to cache certificates because the link is too slow for
good response time if it sent every time.)
Also some comments on your requirements:
I don't understand numbers 2 & 3. See the meta-comment below.
Why is number four necessary? Why wouldn't an application that needed
certain fields just look at the certificate and reject it if it didn't
have them?
And a meta-comment: what's the difference between a certificate and an
arbitrary signed document? If an SPKI cert is a arbitrary list of
attribute-value pairs, some signed, some not, is there a real difference
(other than a bit more structure)? Or should certificates do something
simpler: provide a way to distribute the keys that are needed to sign
other documents?
Paul
>----------
>From: Simon Spero[SMTP:ses@tipper.oit.unc.edu]
>Sent: Saturday, April 20, 1996 9:04 PM
>To: Paul Leach
>Cc: Paul Leach; 'spki@c2.org'
>Subject: RE: Any more comments on the whois++ SPKI proposalette?
>
>On Sat, 20 Apr 1996, Paul Leach wrote:
>
>> Too fast on the send button. I meant to say -- it seemed like there
>> were a number of people, myself included, who wanted to see the
>> requirements doc first. This was also stated explicitly at the WG
>> meeting in LA.
>
>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.
>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.
>7) The SPK should allow multiple parties to sign a single certificate
>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
>
>Simon
> ---
>They say in online country So which side are you on boys
>There is no middle way Which side are you on
>You'll either be a Usenet man Which side are you on boys
>Or a thug for the CDA Which side are you on?
> National Union of Computer Operatives; Hackers, local 37 APL-CPIO
>
>