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

From: Stephen Farrell <[email-masked]>
Date: Wed, 01 Mar 2000 10:34:26 +0000

Santosh Chokhani wrote:
> Please note that there is no such thing as parameters in the RSA.  

That's entirely correct from an arithmetic point of view. However,
there is a parameter in the ASN.1 representation, which (using the
PKCS OIDS) always has the same value - the encoding of an ASN.1 
NULL (i.e. the two bytes '0500'H). Hence the discussion of RSA
parameters. 

BTW: I've no idea why this was put in - maybe someone misunderstand
ASN.1 OPTIONAL way back then. Or something else?

In any case, if you replace "RSA", with "ECDSA", in the
previous mails in the thread, you get the same effect, so its
not entirely nit-picking.

Stephen.

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) +353 1 647 7406
61 Fitzwilliam Lane,                    fax: +353 1 647 7499
Dublin 2.                mailto:[email-masked]
Ireland                             http://www.baltimore.com

---

From: Tim Polk <[email-masked]>
Date: Wed, 01 Mar 2000 12:19:53 -0500

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