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

Re: comments on client auth

Carl Ellison wrote:
> 
> Peter,
> 
>         I'm glad to see you discount X.509 and ASN.1 as mere data formats
> which can be avoided at will. :)

of course. note, I also claim no essential difference between the current SPKI
proposals and the X.509 stuff. 


> 
>         X.509v1 could be just (name,key).  However, we've identified
> (attribute,key,validity) as the minimal cert.

great.  Now we are getting to notions, and needs.

> 
>         Of course, we could use marvelous ASN.1 and X.509's generality to
> add the attribute field (what I call Meaning or Authority) -- and much of
> this thinking was taken from actual uses of X.509 certs -- but it is a Very
> Good Thing to limit certificates to required fields and only a few -- and to
> limit the definition of the cert to less than one page of C (or PASCAL)
> structures.

Very Good Things are too subjective a design tack; they
also often feature commercial-biases which one only discovers
several years after the otherwise apparently open process.

So far, Ive heard generic requirements and idea-based
reasoning for the following notions, as a basis for
a simple, non-control-oriented, security infrastructure:

intended-use, authority, id/authoirization, lack-of
distinction between CA and user,

and

telephone-system management domains, as the organizational principle.

None of this do I have a problem with. (It reminds me
of the AT&T monolothic-system X.400 days, to be honest.)
  
Missing, are commercial relevant notions such as accountability,
audit, assurnace and privacy.

Missing is analysis based on a threat perspective.

The former is the most worrying. I always found
it very hard to design a key management system
in the absence of knowledge of what security
function it is supposed to support the
enforcement of.

Then next notion missing is one of recovering from
disaster, such as key compromise, and whether
there is any assumption that asymmetric key will not/never
be shared?

How also, should we handle any need to distinguish
the purpose of SDSI/SPKI keys belong to one principle, given any
algorithmic properties which inherently limit their utility?

Peter.