Jim,
Thank you for your detailed response. Unfortunately there are several
points I do not agree with. :-(
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.
There is an important issue here. This question was raised in a recent
E-mail from Francois Rousseau. Unless the security policy to be applied
for verification is itself signed, you are open to many attacks, as the
one you mention. So a security policy identifier (e.g. an OID) should be
part of the signature. If you have a single trust point (which is a very
specific case) then you could replace the OID by a self-signed
certificate. Under that case there will be no ambiguity about what to
use for verification. Note the IDUP, which is an API covering
non-repudiation already incorportates this major concept.
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.
The threat you mention can be countered by the inclusion of the security
policy as an "authenticated attribute"; I would prefer to call it a
"signed attribute" :-)
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.
For the case of CAs which are "below" this is not a problem as I
mentionned it in my previous E-mail.
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.
Well, since your paper is supposed to be a discussion paper, I do not
see why we should not address the problem there. There is not yet a
consensus on the other issues. :-)
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.
It only changes the validity of the signature based on which security
policy you are using.
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.
Correct.
In the next level of abstraction up, a certificate comes into being.
More generally I would say a way to relate the public key to the
identity of the signer. For this a certificate may or mot not be used.
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.
I respectfully disagree with you on this issue. I would take again my
favorite example with a CA from the Barracuda Banana Republic. This CA
for 1.000 $ may be willing to issue me a certificate with the same
public key value like yours (without performing POP, ie. Proof op
Private key possession). If that CA appears to be in your trust tree,
then you may be fooled. So it does matter that the signer indicates
which certificate sahll be used for verification. It is not *any*.
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.
No. it does matter instead. As I do not agree on your second level, I
also respectfully disagree with the next level.
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.
Jim
Denis
--
Denis Pinkas Bull S.A.
mailto:Denis(_dot_)Pinkas(_at_)bull(_dot_)net
Rue Jean Jaures B.P. 68 Phone : 33 - 1 30 80 34 87
78340 Les Clayes sous Bois. FRANCE Fax : 33 - 1 30 80 33 21