I am addressing the non-certificate identification issues in this message.
These issues will be addressed separately to keep the threads separate
-----Original Message-----
From: Denis Pinkas [mailto:Denis(_dot_)Pinkas(_at_)bull(_dot_)net]
A. In section 2. Re-issue of Certificate.
Either I do not see this as a problem or I do not understand your
problem.
Cross certificates can be revoked. So if the CA wishes to re-issue a
certificate it simply revokes it before and may use different policies
in the new issued certificate. Where is the problem ?
I did not make myself clear here. The attack that I was looking at on this
point had to do with a CA re-issuing its own root certificate. The change I
would expect would be in the CPS however I will give and example of name
constraints here. If a CA re-issues its CA certificate and specifically
constrains my certificate out of the set of legal DNs, I may sign my message
with a valid chain (I have the original root certificate) and you may fail
the validation because you have the new root certificate.
What I was trying to point out in the second paragraph is that a similar
problem already exists with cross-certificates. When CA2 issues the cross
certificate for CA1, it may add or remove extensions from the CA1
certificate. Thus it could put in the same name constraints extension that
I postulated above on the CA root certificate re-issue. This means that my
signature was valid when I sent it, as I trusted the CA1 root directly, but
you will fail the signature validation as the name constrained imposed by
CA2 on CA1 causes my certificate to be invalid.
B. The discussion and explanations about the need for the hash
mentioned in the discussion above should be added.
I am waiting for a consensus to develop on this issue before making this
change.
C. In the Open Issues section. The inclusion for a complete chain of
certificates would have some advantages (I do not claim it is
necessary
in all the cases). It allows the signer to specify its own belief for
the verification process. If the verifier wants to use a different
chain, this is fine for him, but then under his own risk.
The "rollover" argument is not a problem since anyway it is
important to
capture all the certificates that were valid at the time the signature
was created, but this is a minor detail.
I agree that this might be a useful extension to have, but I would argue
that this is not the correct attribute to place that information in. This
attribute will change the validity of the signature based on the match or
non-match of the specified certificate to the certificate used in the
signature validation process.
Finally I could not understand the issue expressed in the
last paragraph
of "B. Open Issues". A different wording might be necessary.
I will attempt to express the issue again in new wording and hope that I do
better this time.
From a pure cryptographic (i.e. mathematical sense) a signature is created
by using a private key and verified by using a public key. In this world
there is no such thing as a certificate and one does not worry about how the
public key is obtained.
In the next level of abstraction up, a certificate comes into being. All a
certificate provides from a mathematical sense is a way of providing a
public key in a cryptographically secure manner. In this sense it does not
matter what certificate one uses to find the public key to verify a
signature as long as one finds some certificate with the correct public key.
This means that if I have two certificates, both containing the same public
key, it does not matter which of these certificates you use in validating
the signature as both are equally viable from a mathematical sense.
The final level of abstraction that I add is the level of protocol of
signing. At this level I care about which of the different certificates I
use in the validation process as certificates carry different information
about the signer and the ways in which signing may occur. This information
is carried as extension on the certificate and these need to be validated as
part of the process of validating the original signature.
Those people who don't go all the way to the final protocol level we are
providing don't like what this draft does, so far I have found two sets of
people who tend to stop at level 2 and not go to level 3. The PGP community
and those people who come out of that community live at level two. I
believe that this is because they don't have the authoritative CA to do the
binding and add additional protocol information. They tend to be
individuals who make statements only about identity and it does not matter
what identity you use as they mean the same person (as the private key must
be the same). The second set is represented by Dave Solo who state that
everything which needs to be an important part of the signature ought to be
in the document being signed and the extra information provided by the
certificate extensions is of less importance that what is in the document.
Denis
Jim