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

My two pennies

-----BEGIN PGP SIGNED MESSAGE-----


Many, many issues to discuss.  I'll try to refer to an issue number form
the draft as I make my points...

(1) Certs should not be required to be signed by their subject.  People
should not be restricted to making assertions about me (or my key) that I
agree with.  Carl's point that a delegation of authority is also an
acceptance of responsibility doesn't have to be made explicit.
Responsibility is implicitly accepted when the subject acts with the
delegated authority.  Also, consider certs where the subject is a group or
some non-principal object.  Subject-signing can be impractical or
impossible in such situations.

(3) Drop the : on object names.

(4) I'm in favor of not lumping key/hash/padding alg names together.  I
like the modularity of not lumping, and the management of lumped names
would be just one more hassle (unless someone else is already doing it
anyway).  I think lumping would slow the adoption of new algorithms.

(5) I find myself liking boolean delegation.  It makes it easier to keep
track of things, and I find it difficult to think of a situation that
can't be handled with boolean delegation.  Can anyone come up with a need
for integer delegation?  Why not just specify the delegation parm to be an
integer with values 0 or 1?  Then if the need for longer delegation chains
arises the spec can be easily tweaked.

(6) Object names should be case-insensitive.  Case is never a good way to
distinguish distinct objects.

(7) One <auth> per cert is fine.  It makes management easier, in that if
you want to revoke one <auth> you only have to revoke one cert.

(8) Online tests should be for certificate validity only ("tell me if this
cert is valid").  I can't think of any other kind of test that would be of
interest.

(10 & 11) It really depends on the <auth> in the cert, no?

(12) Not if we want to keep things simple!

(13) Using URIs still comes down to some string that identifies an
algorithm (unless the intention is to allow the algorithm to be retrieved
vie the URI, which is a whole other kettle of fish).  Why not just stick
with IANA-defined names?

(18) I say an <issuer> can only be one key, not even a group name.  This
keeps things simple.

(19) I like the [] display-info syntax.  I don't think a display-info tag
should have it's own display-info tag.  It would be nice for the Chinese
programmer to define his own tags in Chinese, but I don't thinks that
problem can be solved at this point in time.  Although, I suppose we could
make the tags UTF8-encoded strings.  I think ASCII is enough, though.

(20) I vote for only one form of object names, and I suggest that we use
names that are at most (only?) 6 characters long (an arbitrary choice, but
I think it's a reasonable compromise).

(21) Perhaps such info would be better-handled by another document of set
of documents, although SDSI's case might be special since it and SPKI are
being so closely tied together.

(22) I don't understand the issue here.  If we're letting users define
their own object types (which is different from defining an <auth> type)
then I guess we should use local dictionaries.  Am I making sense?

(23) If we do this, we should define a specific <auth> or set of <auth>s
for when this is the case, and also explicitly state that May-delegate
MUST be 0.  This, of course, complicates things.  What, exactly, is the
meaning when a non-key object is the subject of a cert?

(25) It's always better to state things as clearly as possible.  I say put
the statement in the document.

Finally, two syntactical points about the draft.

- - For dates (4.1.18), don't make any fields optional.  It could make for
  interoperability problems, especially WRT hashing.  Also, make an
  explicit definition for midnight.

- - <valid> is defined as:
	<valid>:: <not-before>? <not-after>? <online-test>? ;
  Should it not be:
	<valid>:: ( <not-before> | <not-after> ) | <online-test> ;

Whew!

		Marc

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: noconv

iQB1AwUBMz7TxFrdFXNdDxPlAQFI6QL/fCVwEvCFFEQ9SJF7goZ9Ez0/pTAAp9U6
+h3DFkGPTEheyhYkMZdOPrhioy60ly7rogIBXVRfogP35Z61Hx6MgJqJwamxRdTO
Gy76Kipx3ax/txvAx272G0d5EwcHc+iQ
=cHwa
-----END PGP SIGNATURE-----
Follow-Ups: References: