-----Original Message-----
From: Denis Pinkas [mailto:Denis(_dot_)Pinkas(_at_)bull(_dot_)net]
Sent: Monday, July 06, 1998 5:35 PM
To: Jim Schaad (Exchange)
Cc: ietf-smime(_at_)imc(_dot_)org
Subject: Re: SigningCertificate and IssuerAndSerialNumber.
Jim,
I took me some time to dig your E-mail too. In order to ease
the reading
I have reformatted the exchanges, placing a J (for Jim) and a D (for
Denis) in front of the previous exchanges.
Reading again the E-mail I now understand what the
misunderstanding is.
It is however rather fundamental as I will attempt to explain it
hereafter.
J> Denis,
J> I somehow got lost on this message, my apologies that
J> I did not reply sooner.
J> Comments mixed in below
J> -----Original Message-----
J> From: Denis Pinkas [mailto:Denis(_dot_)Pinkas(_at_)bull(_dot_)net]
J> Sent: Monday, May 18, 1998 2:25 PM
J> To: Jim Schaad (Exchange)
J> Cc: ietf-smime(_at_)imc(_dot_)org
J> Subject: Re: SigningCertificate and IssuerAndSerialNumber.
D> Jim,
D> Thank you for your detailed response. Unfortunately there are
D> several points I do not agree with. :-(
D> I am addressing the non-certificate identification issues
D> in this message.
D> These issues will be addressed separately to keep the
D> threads separate
D>-----Original Message-----
D>From: Denis Pinkas [mailto:Denis(_dot_)Pinkas(_at_)bull(_dot_)net]
D>A. In section 2. Re-issue of Certificate.
D> Either I do not see this as a problem or I do not understand
D> your problem.
D> Cross certificates can be revoked. So if the CA wishes to
D> re-issue a certificate it simply revokes it before and
D> may use different policies in the new issued certificate.
D> Where is the problem ?
J> I did not make myself clear here. The attack that I was
J> looking at on this point had to do with a CA re-issuing
J> its own root certificate.
D> There is an important issue here. This question was raised
D> in a recent E-mail from Francois Rousseau. Unless the security
D> policy to be applied for verification is itself signed,
D> you are open to many attacks, as the one you mention.
I was referring to an E-mail from Francois Rousseau
(f(_dot_)rousseau(_at_)adga(_dot_)ca)
from Thu, 30 Apr 1998 with the following subject : Reference to
Applicable Attribute Certificate(s) within the CMS.
The sentences I was referring were at the end of his E-mail:
" (...) This implies there are currently no mean within CMS
to convey to the Verifier which Attribute Certificate MUST be
used for each Claimant.
Should not considerations be given within CMS to use the
authenticatedAttributes field under each per-signer SignerInfo
to specify through new CRITICAL attributes, the applicable
claimant's Attribute Certificate and the applicable Control policy
that the Verifier MUST use to validate the message?"
... "and the applicable Control policy that the Verifier MUST use to
validate the message" is the important sentence.
The "applicable Control policy" (that I called simply
"security policy")
defines the rules to be applied for the verification of the digital
signatures. That security policy will indicate what are the
various root
CAs that are usable and the name constraints that are to be used for
each of them.
D> So a security policy identifier (e.g. an OID) should be
D> part of the signature. If you have a single trust point
D> (which is a very specific case) then you could replace the OID
D> by a self-signed certificate. Under that case there will be no
D> ambiguity about what to use for verification. Note the IDUP,
D> which is an API covering non-repudiation already incorportates
D> 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.
See the reference above.
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.
I am referring a security policy that is a signed attribute, but not
part of the message.
3. If you are refering to the ability to verify the verification
code (or at least 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.
I had not envisaged that meaning. :-)
J> The change I would expect would be in the CPS however I will
J> give and example of name constraints here. If a CA re-issues
J> its CA certificate and specifically constrains my certificate
J> out of the set of legal DNs, I may sign my message with a valid
J> chain (I have the original root certificate) and you may fail
J> the validation because you have the new root certificate.
D> The threat you mention can be countered by the inclusion of
D> the security policy as an "authenticated attribute"; I would
D> 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.
If I use a real example, SET (Secure Electronic Transaction) does
restrict the set of roots to be used in certificate validation. Any
application should do the same. It is not the choice of the
verifier to
use the roots of its choice, but the choice of the signer. A "simple"
way to indicate its choice is to use a security policy OID. Now the
choice may or may not be acceptable to the verifier. If not, then the
signature is simply discarded.
J> What I was trying to point out in the second paragraph is
J> that a similar problem already exists with cross-certificates.
J> When CA2 issues the cross certificate for CA1, it may add or
J> remove extensions from the CA1 certificate. Thus it could put
J> in the same name constraints extension that I postulated above
J> on the CA root certificate re-issue.
J> This means that my signature was valid when I sent it, as
J> I trusted the CA1 root directly, but you will fail the signature
J> validation as the name constrained imposed by CA2 on CA1 causes
J> my certificate to be invalid.
We are tackling the heart of the problem here. What you would
like is, I
believe, the following: a signature that was valid when it was sent
should be recognized as valid at the time it is received.
The bad news is the following : when using only the current
specification this is quite impossible. :-(
The good news is the following : when using S/MIME in
combination with a
time stamp from a Time Stamping Authority, this is possible.
The reason is fairly simple: if you want the same result, you
should use
the same input parameters to the verification process, i.e. the
parameters that were valid at the time of the signature. So you must
securely know the time of the signature, hence the reason for the time
stamp. If any certificate is changing, this is not a problem since you
will use what was valid at the time of the signature. Without a time
stamp you may (and will) get spurious results.
I now see some value to consider different levels: at the level 3,
we could cover the case of a verification without a time stamp.
At a level 4, we could consider the case of a verification with
an additional time stamp.
D> For the case of CAs which are "below" this is not a problem as
D> I mentionned it in my previous E-mail.
D> The discussion and explanations about the need for the hash
D> mentioned in the discussion above should be added.
J> I am waiting for a consensus to develop on this issue
J> before making this change.
D> Well, since your paper is supposed to be a discussion
paper, I do not
D> see why we should not address the problem there. There is not yet a
D> consensus on the other issues. :-)
D> C. In the Open Issues section. The inclusion for a complete
D> chain of certificates would have some advantages (I do not claim
D> it is necessary in all the cases). It allows the signer to specify
D> its own belief for the verification process. If the verifier wants
D> to use a different chain, this is fine for him, but then under his
D> own risk.
D> The "rollover" argument is not a problem since anyway it is
D> important to capture all the certificates that were valid
D> at the time the signature was created, but this is a minor detail.
In fact, I know believe that this is major argument !
J> I agree that this might be a useful extension to have, but
J> I would argue that this is not the correct attribute to place
J> that information in. This attribute will change the validity of
J> the signature based on the match or non-match of the specified
J> certificate to the certificate used in the signature validation
J> process.
But this is a way to get stable and non ambiguous results.
D> It only changes the validity of the signature based on which
D> security policy you are using.
D> Finally I could not understand the issue expressed in the
D> last paragraph of "B. Open Issues". A different wording
D> might be necessary.
J> I will attempt to express the issue again in new wording
J> and hope that I do better this time.
J> From a pure cryptographic (i.e. mathematical sense) a
J> signature is created by using a private key and verified by
J> using a public key. In this world there is no such thing as
J> a certificate and one does not worry about how the public key
J> is obtained.
D> Correct.
J> In the next level of abstraction up, a certificate comes
J> into being.
D> More generally I would say a way to relate the public key to
D> the identity of the signer. For this a certificate may or may
D> not be used.
J> All a certificate provides from a mathematical sense is a way
J> of providing a public key in a cryptographically secure manner.
J> In this sense it does not matter what certificate one uses to find
J> the public key to verify a signature as long as one finds some
J> certificate with the correct public key.
D> I respectfully disagree with you on this issue. I would
take again my
D> favorite example with a CA from the Barracuda Banana Republic. This
CA
D> for 1.000 $ may be willing to issue me a certificate with the same
D> public key value like yours (without performing POP, ie. Proof op
D> Private key possession). If that CA appears to be in your
trust tree,
D> then you may be fooled. So it does matter that the signer indicates
D> which certificate shall 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.
When the reference of the certificate to be used is a signed
attribute
placed by the signer, there is no ambiguity.
J> This means that if I have two certificates, both containing
J> the same public key, it does not matter which of these
certificates
J> you use in validating the signature as both are equally viable
J> from a mathematical sense.
D> No. it does matter instead. As I do not agree on your
second level, I
D> also respectfully disagree with the next level.
How is the signature different on a mathematics level?
The verification process is not purely mathematical. You MUST also
verify that the certificate that you use for the verification is
the one indicated in the signed attributes.
As you say I will verify using the phony signature.
The step you want to place is added in the next level.
J> The final level of abstraction that I add is the level of
J> protocol of signing. At this level I care about which of the
J> different certificates I use in the validation process as
J> certificates carry different information about the signer and
J> the ways in which signing may occur.
J> This information is carried as extension on the certificate and
J> these need to be validated as part of the process of validating
J> the original signature.
Which extension(s) are you refering to ?
J> Those people who don't go all the way to the final protocol
J> level we are providing don't like what this draft does, so far
J> I have found two sets of people who tend to stop at level 2 and
J> not go to level 3.
J> The PGP community and those people who come out of that community
J> live at level two. I believe that this is because they don't have
J> the authoritative CA to do the binding and add additional protocol
J> information.
Reading again your previous exchanges, I am confused about your
sentence "have the authoritative CA to do the binding and add
additional protocol information".
J> They tend to be individuals who make statements only
J> about identity and it does not matter what identity you use as
J> they mean the same person (as the private key must be the same).
J> The second set is represented by Dave Solo who state that
J> everything which needs to be an important part of the signature
J> ought to be in the document being signed and the extra information
J> provided by the certificate extensions is of less importance that
J> what is in the document.
Maybe I am close to Dave Solo, but in a third set. :-)
I would state that everything which needs to be an important part
of the signature ought to be in the signed attributes in addition
to the document being signed. This includes the security policy
to be used by the verifier and an unambiguous reference to the
certificate of the signer to be used by the verifier. The extra
information provided by the certificate extensions cannot overide
the previous signed attributes.
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