[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Comments on the 25 March 1997 draft
(1) I, too, think that an issuer needs to make statements about a subject
without the subject's cooperation. It would, for example, make it difficult
for a cooperating group of people to make a library of spammers whose mail
would be summarily rejected if the spammers had to agree.
(2) Blind signatures should be allowed with any public key algorithm that
can make them.
(3) I prefer no colons. They don't put my knickers in a twist, though.
(4) Lumping key, hash, and pad into one name is ultimately making a
three-field aggregate that is hard to parse. Best to be explicit.
(5) Delegation should be an integer. Yeah, there are relatively few cases
where the delegation count is going to be more than one, but as sure as it
becomes a boolean, then someone will think of a good reason for it having a
value of 2. Best to just make it an integer from the start.
(6) I think that case-sensitivity is bad. Case-remembered is just fine. I
don't mind either, if we specify case-remembered, but that names are forced
to lower case when compared. I think this satisfies all the comments I've
seen on this list.
(7) One auth per cert is fine, but we've been thinking here at PGP that we
want to be able to make a certificate over a list of auths (or in our
language, an assertion over a list of attributes). This has some value for
the issuer, as it allows the issuer to force disclosure of some piece of
information. For example, "I assert that you're over 21, but you have to
disclose your email address, too." If there's an <auth>-type that specifies
a list of other certificates, then it satifies our desire, and doesn't
require that any cert hold multiple auths.
(8) I think that if we limit the specification of the online check, then
someone will curse us for it in five years. Right now, it seems that
validiy checks are useful, and I'm hard pressed to think of others, but I
cringe at limiting it.
(9) Defining a bunch of them seems useful, but I wouldn't want to hold up
development of SPKI on it. Can that be a separate document?
(10) I think that depends on the cert. For example: "XYZcorp asserts that a
document signed with any of these keys (K1, ... Kn) is an official policy
of XYZcorp." Obviously, this cert is different than one that specifies that
a document signed by *all* of those keys is an official policy.
(11) No, that seems silly. Imagine if XYZcorp asserts that some document is
policy, and that document declares that some other document (identified by
hash) is not a policy. What problem are we trying to solve? Is it one that
can't be solved by making a cert that is a list?
(15) I think it should be possible to put the object there.
(16) If we do, it should be possible to use other algorithms other than
RSA, too.
(18) There doesn't appear to be an issue #18.
(19) The Lisp-hacker in me likes (display-type) and it's potentially better
for implementation. But I do understand that it's not as pretty as [xxx].
Either way is fine.
(20) If there is only one spelling, then it should be a (potentially) long
name. I concur that ease of reading is more important than ease of typing.
I think that picking pithy names is important, but being easy to read is
most important. I don't object to having multiple names for a type, but I
note that here be dragons.
(21) Here at PGP, we are planning on subsuming SPKI's features into our new
"metacertificate" format. We even see it as a good thing to merge PGP with
SPKI. However, if we can't do everything we need with SPKI, then we're
content to be a superset of it.
(23) It could be seen as encroaching on PICS, but I think it's desirable.
Jon
-----
Jon Callas jon@pgp.com
Senior Security Architect 555 Twin Dolphin Drive
Pretty Good Privacy, Inc. Suite 570
(415) 596-1960 Redwood Shores, CA 94065