Subject: RE: Cert Path Validation Bug in pkix-new-part1-00

From: Santosh Chokhani <[email-masked]>
Date: Wed, 1 Mar 2000 13:02:39 -0500

I been meaning to respond to Steve with exactly what Tim said.  The
parameters should not be inherited across algorithms and across
certificates.

-----Original Message-----
From: Tim Polk [mailto:[email-masked]]
Sent: Wednesday, March 01, 2000 12:20 PM
To: [email-masked]; [email-masked]; pkix
Subject: RE: Cert Path Validation Bug in pkix-new-part1-00

John and Steve -

I believe that the algorithm has *two* bugs in it. However, I see different
bugs!

The path validation algorithm was not intended to permit algorithm
inheritance across an "algorithm gap".  We meant to support parameter
inheritance only when the subject and issuer share the same parameters!
So, the key in the certificate and the key used to sign would have to be
for the same algorithm.

I read through the Steve's scenario (with the 4 certificate chain) several
times. I don't think we should support this type of chain for a couple of
reasons.  If we don't have a hierarchy, this is a recipe for disaster.  If
another "top-ca" issues a certificate to the "mid-ca", it probably won't
have the right DSA parameters.  (It might not even sign with DSA!) So,
"mid-ca" is forced to include the parameters in the "low-ca" certificate if
they want it to be useful...

That means this is only useful in a strictly hierarchical PKI.  If we have
enough organizational control to implement a strict hierarchy, are we
likely to mix algorithms at different levels in the tree?

There is another possibility that is even worse - but it is only a
possibility 'cause I can barely spell crypto.  What if the top-ca rekeys
with new parameters?  It issues a new certificate to mid-ca with it's old
key in it.  What happens?  You use the wrong parameters to verify the
signature on the fourth certificate.

Could this lead to a vulnerability?  It seems somewhat analgous to the
parameter substitution attack Santosh described when you use parameters
that were not protected by the certificate signature!  While you can't make
the subsitution yourself, couldn't some combinations of keys and parameters
be unsafe???

It seems like permitting an algorithm gap is living on the edge - and I'm
getting too old for that!

I believe that the parameter inheritance needs to be re-worked so that
parameters are inherited only when the issuer and subject share the
parameters.  I believe that will require changes in both the body and
wrap-up procedure.  I would like to gain consensus on the list before I
rework it, though.

Thanks,

Tim

---

From: Peter Williams <[email-masked]>
Date: Thu, 2 Mar 2000 15:22:54 -0800

Here are no parameters with RSA "for the
IETF-specified RSA algorithm" only. PKIX
conforming CA are not limited to IETF's RSA-based
digital signature algorithms, remember. Some
of the bio-enhanced RSA signing processes will
use parameters to help mix the hash, quite properly.

-----Original Message-----
From: Tim Polk [mailto:[email-masked]]
Sent: Thursday, March 02, 2000 2:54 PM
To: pkix; Pawling, John
Subject: RE: Cert Path Validation Bug in pkix-new-part1-00

John,

I'm glad we're in agreement.  It was a rather stimulating dicussion and
ensured I review this text exhaustively - both good things.  I see I have
some clean-up work to perform on that section, including your changes to
the wrap-up procedure.  They were needed either way.

Thanks!

Tim

At 01:41 PM 03/02/2000 -0500, you wrote:
>Tim/Santosh,
>
>I apologize for the confusion caused by my reply to Stephen's message.  I
>misinterpreted Stephen's use of the term "algorithm gap".  I strongly agree
>that algorithm parameter inheritance MUST NOT occur across an "algorithm
>gap" as defined in Stephen's and Tim's messages.  I strongly agree that
>parameter inheritance may only occur when the subject and issuer share the
>same parameters.  Recommend that sentence should be added to the first
>paragraph in section 7.3, Subject Public Key Algorithms.
>
>Stephen's recommended text enforces the rule that algorithm parameter
>inheritance must not occur across an "algorithm gap".  He recommended: "if
>the signing algorithm and subject public key algorithms in a certificate
>differ, then the issuer MUST include all algorithm parameters in the
>subjectPublicKeyInfo as parameter inheritance is not supported in such
>cases". Recommend that Stephen's text should be included in the first
>paragraph in section 7.3.  Recommend adding "(if applicable)" after "all
>algorithm parameters" in the above sentence.
>
>I agree with Santosh's statement that there is no such thing as parameters
>in the RSA.  However, I still believe that the pkix-new-part1-00 cert path
>validation procedures need to be clarified.  Recommend that the following
>text be added to the description of the working_public_key_parameters
>variable in section 6.1.2, bullet (i): "Note: There are no algorithm
>parameters associated with an RSA public key; therefore, the certification
>path validation procedures described in this section specify that the
>working_public_key_parameters variable is set to NULL when associated with
>an RSA working_public_key."  
>
>I stand by my original comment documented in the attached message that
>started this message exchange.
>
>-John
>
>
>-------------------- Original Message -------------------------------
>
>From:	Pawling, John [[email-masked]]
>Sent:	Friday, February 25, 2000 5:08 PM
>To:	[email-masked]
>Subject:	Cert Path Validation Bug in pkix-new-part1-00 
>
>All,
>
>There is a bug in the certification path validation Wrap-up procedures
>section (6.1.5) in the October 22, 1999 PKIX Certificate and CRL Profile
><draft-ietf-pkix-new-part1-00.txt>.  If an issuer cert containing a DSS
>public key is used to verify an end-entity cert containing an RSA public
>key, then the current Wrap-up procedure does not properly set the
>working_public_key_parameters variable to NULL.  With the current
procedure,
>the working_public_key_parameters is still set to the issuer's DSS
algorithm
>parameters.  Recommend the following change to section 6.1.5:
>
>OLD:  (d) If the subjectPublicKeyInfo field of the certificate contains an
>algorithm field with non-null parameters, assign the parameters to the
>working_public_key_parameters variable.
>
>NEW:  (d) If the subjectPublicKeyInfo field of the certificate contains an
>algorithm field with non-null parameters, assign the parameters to the
>working_public_key_parameters variable.  If the subjectPublicKeyInfo field
>of the certificate contains an algorithm field with null parameters,
compare
>the certificate subjectPublicKey algorithm to the
>working_public_key_algorithm.  If the certificate subjectPublicKey
algorithm
>and the working_public_key_algorithm are different, set the
>working_public_key_parameters to null.
>
>============================================
>John Pawling, Director - Systems Engineering
>J.G. Van Dyke & Associates, Inc;
>a Wang Government Services Company
>[email-masked]
>============================================ 
>
>

---

From: "Pawling, John" <[email-masked]>
Date: Fri, 3 Mar 2000 10:00:30 -0500

Peter,

Are those parameters associated with the "bio-enhanced" RSA signature value
or with the RSA public key? 

-John