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

Comments on I-D requirement document

Carl,

Some comments on your Requirements I-D. These are intended
to perhaps motivate improvement in the understandability of
the model described, when read by a professional
security industry reader, or when referred to
by a legal professional. The provision of comments
has no other purpose or meaning.

The analysis is based on the assumption that
an SPKI system contains no third party certificate
issuers, or positive/negative status issuers.

If this contribution seems useful (and doesn't get
flamed to bits) I can continue with additional
sections and chapters with a view to indicating
where one might do more to produce
a watertight definition of all security 
properties.

I personally hope to join the WG in Memphis to help
advance this text and the peer-peer security model
which it seems to embody. (This is not a joke.)

Im happy to accept the data structure format and
encodings technologies as they are (or are evolving).
I'm going to leave X.509 to its fate; as a standard
its already done its political job, for my purposes.

Peter.




   "The SPKI team directly addressed the issue of <name,key> bindings and
   realized that such certificates are of extremely limited use for
   trust management. "

One might note that this was also recognised by ITU/IETF when
they defined the standard certificatePolicies extensions
and mappings, in their format of certificate. This occurred
historically prior to SPKI formation. As with SPKI (apparently),
such signals have no relation to names, but exist
in their own right to signal and organize models
of trust relationships between parties in 
peer-peer or third party environments.

   "The problem is that the original telephone
   directory model is inappropriate for a public key infrastructure
   [PKI]."

The practicing TLS and S/MIME community could agree with this,
and it is not a feature of one format, or model, over another.
Use of SPKI certs in TLS is not a problem in principle;
the protocol is format independent.

In other environments, the listing of certificates will
be crucial using any suitable listing model which the
users can navigate and search over. real
people will need friendly cues.


	"On the other hand, the announced purpose of
   a PKI is to give someone the information needed to permit the
   extending of trust without resorting to on-line exchanges. "

The nature of the original SDSI model was that status checking
takes place via an inherently online process. Decommissioning
the "extension of trust" is surely as important and its commission, if 
not more so. I find this in need of harmonization with SDSI
principles.

Who announced this definition of a PKI? Perhaps reference it.

	"The
   telephone book model does not satisfy that announced purpose.  The
   more global the directory, the more ambiguous its names become and
   therefore the less well it performs."

names in listing service, versus names for identifier
are different notions. The ambiguity properties
you cite are different for each. You may wish
to clarify your statement, or embrace both notions. If SPKI
certs are to be listed in any environment for human-use, they
will need a human-friendly listing and searching model.

"A user of a certificate needs to know
    whether a given keyholder has been granted..."

This text language seems to suggest that a third party performs
the act of granting a foo to the keyholder.

 
Does SPKI do POP (to ask the recent PKIX question)?

Surely the absence of third-parties means that all SPKI-based
operational protocols must themselves engender the properties
of POP, if the SPKI cert has any enforcement value which
relies upon a party possessing the private key for use.

-----

I note that "The main purpose of an SPKI certificate is to authorize some
action,
   give permission, grant a capability, etc."

earlier text had suggested (through
some convoluted logic) that a major use of the SPKI
cert is to "engage in trust management" though says that
"for.. many areas of trust management a person's name is irrelevant."

which areas is the name relevant?

Is the term "person" referring to human entities, or a generic
 principal notion, here?

" The SPKI certificate should be designed to encourage key holders never
   to share their private keys. "

I hate mandatory private key escrow with covert
access as much as the next person, but
is SPKI saying that *any* escrow support would constitute a
security violation of the protocols which use SPKI
certs?

What is the SPKI design principle which is affected by, or influences,
the sharing of private keys?

(i.e. is the statement technical, or a political act?)

" Therefore, a certificate holder should
   be able "

what is a certificate holder?


"Although we humans are fond of our common names"

The requirements mandate support for nicknames, seemingly
contained in the cert. Why is a nickname not a suitable common
name, used in adjunct with the public key value to name a unique
identifier which the standard seems to be requiring
exist as a notion distinct from the public key?

Is it intended that the cert issuer legally attest
to the uniqueness of the public key value, and or
the unique id?

" An SPKI certificate, like any other, should be able to carry a
   validity period: dates within which it is valid."

remove: like any other...

Define valid.

"The same information can be delivered in a positive statement: a
   periodic revalidation of a certificate or a key. "

what is the difference between validity of a cert and a key?

how does the positive scheme, in the absence of third parties
which SPKI outlaws, handle urgent compromise notification
for keying material?

Does one separate compromise of system integrity due
to private key compromise from withdrawal of the authorization
or other form of privilege grant to oneself?

What status does a failure to periodically revalidate place upon
signatures of previously validated and accepted
signed email (if any) when supported by a SDSI cert?

" It must be possible to specify, for each certificate, not only
   activity dates"

what is "activity dates"?

Is is a period (like validity period), and what is
the controlled activity?

"but also conditions which must be tested"

is this alluding to a statement by the keyholder than
a using party must, or may, confirm status by testing?

what is the status if a party does not confirm status
according to rules?

perhaps status as a notion should be defined.

End.
Follow-Ups: