[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Validity periods can be handled more explicitly
There are some aspects of public key cryptography that are so obvious
that they never get mentioned. I think a key step in simplification
is to make those things more explicit.
Here is my first "obvious" fact:
A signature (traditional or digital) signs either an assertion or a
request/command. [[The only difference between a request and a command
is the level of expectation of compliance - so we can just call the
latter a "request".]]
In other words a signature either
turns a proposition into an assertion
turns an imperative statement into a request
[Does everyone agree with this? If there are other possibilities I'd
be interested. If you think that messages can be signed without any
implied assertion or request then it might be worth discussing it
off-line at first rather than on the list since I'm pretty sure that
when you look at the reason for signing you'll find the assertion or
request in there.]
In the computer world the assertion is often implicit. In particular
certificates are assertions about public keys. It seems to me that
the best route to simplification is to make all assertions completely
explicit in a language suitable for expressing assertions. S-expressions
are good because they are the traditional way of expressing assertions
in the AI community.
With written signatures in the real world it is often common for a
signature on a form to act in a dual role: asserting the truth of the
information supplied on the form being signed as well as making some
request to the authority to which the form is being given. This is
something to avoid in the digital world. The thing signed should be
either an assertion or a request, not some combination. This requires
care but I believe will be very beneficial.
Validity periods on certificates cause big problems. They are clearly
meant to modify the assertion being made, but it is not clear in what
way. In the X.509 world of identity certificates, people trying to use
them aren't clear what the validity period means. Does it limit the
a. The public key
b. The identity
c. The link between them
d. Does it assert that any of the above is definitely invalid outside
the specified period, or just not defined?
I guess we all think that only (c) applies, but there is a lot of
confusion out there.
It is important to see that a signature on an assertion defines an
assertion that is valid throughout all space-time, NOT an assertion
whose truth varies through time. Consider the SPKI-style certificate
The owner of public key PK1 is allowed to access resource R
during the period P
This assertion is true throughout time. For example we can come back
after period P and, using the truth of this assertion, check that some
earlier access was valid.
So my simplification is to remove the validity period from the certificate.
Instead define a sufficiently powerful assertion language that allows the
validity period to be explicitly expressed in the assertion about the
public key that constitutes the SPKI certificate.
While this really only moves the complexity to a different place, it moves
it to the right place, and thus makes it easier for the people writing
and using software that uses certificates to understand exactly what they
are meant to mean.
Bob.Smart@cmis.csiro.au Distributed Systems
CSIRO Mathematical and Information Sciences phone: +61 3 9282 2625
723 Swanston St, Carlton VIC 3053, Australia fax: +61 3 9282 2600