Denis,
I somehow got lost on this message, my apologies that I did not reply
sooner.
Comments mixed in below
-----Original Message-----
From: Denis Pinkas [mailto:Denis(_dot_)Pinkas(_at_)bull(_dot_)net]
Sent: Monday, May 18, 1998 2:25 PM
To: Jim Schaad (Exchange)
Cc: ietf-smime(_at_)imc(_dot_)org
Subject: Re: SigningCertificate and IssuerAndSerialNumber.
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.
I just got very lost reading the previous paragraph. I think the issues I
don't understand boil down to:
1. Which message are you refering to? The ones that I can find deal with
attribute certificates and not with CA certificates. I am afraid that I
don't see the connection between these issues.
2. What security policy identifier are you refering to here? If the
security policy is that of the message, it is already signed in its own
attribute. If the security policy is part of the certificate, it should
also be signed under the certificate signature.
3. If you are refering to the ability to verify the verification code (or
atleast some input data to it) then I would have to say that I think this is
beyond the scope of the problems that I can even hope to address in an IETF
draft as it would be very implementation dependent.
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" :-)
How does the inclusion of a security policy (I assume in the SignerInfo
object being verified) alter the fact that we have different root
certificates and thus different input to the problem of doing the
certificate validation? Even operating under the same security policy
(unless the policy itself has the roots hard coded into it) would not
address this issue. I don't expect most security policies to restrict the
set of roots to be used in certificate validation.
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*.
You are correct in one sense and incorrect in another. You are quite
correct that I will be fooled into believing that you did the signature
since the public keys are the same. From a pure mathematical standpoint
there is no way for me to know which certificate is correct. It is from the
addition of a protocol that I understand some certificates are trusted and
others are not trusted. There is no mathematical basis to make this
determination.
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.
How is the signature different on a mathematics level? As you say I will
verify using the phony signature. The step you want to place is added in
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