[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Any more comments ...
I have to say that this is both the most reasonable and reasonably
complete suggestion I have seen on this list to date.
(The editor I'm using doesn't automatically insert angle brackets on each
line of quoted text, so I'll indicate your original with a single bracket at the
beginning of each paragraph. BTW, I'm also not sure whether this editor
automatically limits lines to a reasonable length, so someone tell me if
they are too long.)
>>> Simon Spero <ses@tipper.oit.unc.edu> 04/20/96 10:04pm >>>
... >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.
I agree strongly, at least assuming that no one has identified a
requirement that X.509 positively can't handle. I'm not aware of any
having been so identified to date.
>A quick cut at making the requirements more explicit
>1) The SPKI must be easier to implement than X.509
This would seem to be THE fundamental assumption. I would say that it
must be have to be much, much easier to implement than X.509 to make it
worth the bother of having two standards.
>2) The SPKI certificate format must allow arbitrary fields to be signed
for.
I assume that you are postulating a mechanism such as X.509's private
extensions, to allow growth.
>3) The SPKI certificate format must allow arbitrary fields to be
signed/not-signed.
The inclusion of information within the certificate that isn't signed would
allow that information to be modified or deleted without detection, which
seems to violate the basic reason for having a certificate in the first
place, so I would oppose this requirement as stated.
However, although I may not understand your intent, I will surmise that
you are talking about a capability that has been discussed within the
ABA Digital Signature Guidelines committee, called Non-verified
Subscriber Information (NSI). NSI information is contributed by the
subscriber (the entity identified in the certificate, or at least the entity to
whom The certificate is issued), but which has not been independently
verified by the CA. THE CA therefore takes no responsibility/liability for
the information, but simply passes it on in good faith. Although there has
been a lot of argument back and forth on this subject by a lot of
respected players in the field (including myself - I've changed my position
for what I said originally on this subject), I do believe that this is important
as a means of minimizing the CAs liability while extending the utility of
certificates. Unfortunately, this is one capability that would not be that
easy to add to the existing X.509 v3/DAM -- it would be nice if we could
tag any given attribute with the NSI indicator, just as an attribute can be
tagged as Critical or not. But that would require a change to the basic
extension mechanism, and that may not be achievable within The existing
standards framework.
>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)
Agreed. However, while we were working on the SEPP specification,
we sometimes tripped over the difference between mandatory and
Critical. For certain applications, support of fields that are designated as
noncritical within X.509 may be mandatory if the system is to work as
required. I would therefore suggest that we stick to the Critical/ vs.
Noncritical terminology.
>5) The SPKI must define attribute types for embedded public keys;
pre-defined types should be defined for RSA, DSS, and DH keys
You haven't addressed it elsewhere, and this will be a political hot
potato, but the issue of key escrow has to be addressed one way or the
other. Regardless of what one thinks about the notion of key escrow,
and I can wax as wroth as anyone else on the notion of forced escrow
a la Clipper, the fact of the matter is that for export purposes we either
have to use very weak keys (40 bits), or we have to adopt something
like the Lotus Notes solution where N-40 bits are escrowed. Counties like
France, Russia, Korea, and others (strange bedfellows, n'est pa?) may
also insist on such escrow provisions for _import_. In addition, some
companies have adopted the seemingly reasonable position that they
want to ensure the survivability of the company in the event of the death
or incapacitation (or blackmail?) of an individual, and they therefore insist
on escrowing all encryption keys generated or used on their equipment.
Given that this trend may be almost inevitable, at least within certain
communities, the least that we can do is to require that any certificate
that is generated that contains a public key which corresponds to a
private key which has been escrowed should provide an indication to
that effect. Some people may refuse to communicate securely with
anyone whose key is so marked, and some applications may refuse to
securely communicate with anyone whose key is NOT so marked (if the
import/export policy so dictates), but at least the user community will be
clear as to what is going on. I'd eventually like to see consumer
protection-style legislation passed that would make it a crime to escrow
a key without so indicating that fact in the certificate, but it may suffice to
place a positive duty on the subscriber to protect the secrecy of his
keys, and to inform the CA if a key is required to be escrowed.
>6) The SPKI should be useable with at least one standards track
directory
protocol.
Yes.
>7) The SPK should allow multiple parties to sign a single certificate
Is that really what you mean? If so, are both signers making precisely the
same claims as to having validated or not validated the contents of the
certificate? Do both parties have the same Policy as to how, and under
what circumstances, a certificate will be signed? You haven't mentioned
a requirement for a policy at all, but if a Policy is not identified, at least by
an OID, then any relying party is pretty well in the dark as to what a
certificate means, and therefore what degree of trust should be
associated with any signed document. The ability to have multiple
signatures on a certificate is (arguably) part of X.509, but there are a lot
of these kinds of details that would have to be sorted out if anyone were
to seriously propose such a usage.
Somewhat tangential to this discussion, I would also add a requirement
to be able to specify the intended use(s) of a key, and to provide a
means of restricting keys to those particular uses and/or as specified in
the Policy, a la the X.509 v3 keyUsageRestriction.
>8) It should be possible to transfer SPKI certificates through electronic
mail, either through the use of a mail safe format or through
definition of a new mime type
Yes
>9) SPKI signatures should support fixed term validity periods
Yes. And for heavens' sake, let's use a date format such as Generalized
time, so we won't perpetuate the year 2000 problem.
>10) SPKI should support online CRLs
>11) SPKI should support offline CRLs
A question of clarification. Are you talking about the transport mechanism
used to access the traditional type of CRL list? Or are you talking (in the
online CRL case) about the kind of mechanism I have suggested as a
means of avoiding all of the complexity of trust third parties and
non-repudiation, i.e, having the CA counter-sign the digital signature as
valid, either at the time the signature is created (by the originator), or
immediately after receipt by the relying party?
>Simon
Bob Jueneman