[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Cert Path Validation Bug in pkix-new-part1-00
Stephen,
Thank you for your response. I respectfully disagree with your comment that
my new text prevents parameter inheritance across an "algorithm gap". As
stated in RFC 2459, Section 7.3.1, the RSA algorithm parameter is ASN.1
encoded in the RSAPublicKey SEQUENCE carried in the subjectPublicKeyInfo
subjectPublicKey BIT STRING. Furthermore, the RSA algorithm parameter is
always present in RSAPublicKey (algorithm parameter inheritance is never
used with RSA). The pkix-new-part1-00 cert path validation procedures never
specify that the working_public_key_parameters variable be set to the
algorithm parameter associated with an RSA public key. This is true because
the subjectPublicKeyInfo algorithm field associated with an RSA public key
always contains NULL parameters.
I believe that the section was purposely written in such a manner. I agree
with that strategy since the RSA algorithm parameter is encoded within
RSAPublicKey and is always present. Typically, the cert path verification
software passes the RSAPublicKey SEQUENCE to a low-level crypto library
which decodes the SEQUENCE into the modulus and publicExponent components.
Therefore, the cert path verification software does not need to set the
working_public_key_parameters to the RSA algorithm parameter value, because
the low-level crypto library always has access to the RSA algorithm
parameter in the RSAPublicKey SEQUENCE. Given that assumption, the
pkix-new-part1-00 cert path validation procedures (with my recommended text
included) correctly support parameter inheritance across an "algorithm gap".
This assumption should be included in the definition of
working_public_key_parameters in the pkix-new-part1-00 cert path validation
section.
If people disagree with this assumption, then the pkix-new-part1-00 cert
path validation procedures need to be re-written to specify that the
working_public_key_parameters variable must be set to the RSA algorithm
parameter present in RSAPublicKey. This will cause the procedures to be
algorithm specific (rather than generic).
In your example below, the verification of the RSA signature of cert 3 will
succeed because the cert path verification code knows that the RSA algorithm
parameter is encoded within RSAPublicKey and it ignores the
working_public_key_parameters (set to NULL at that point).
I agree with you that cert 3 in your example is invalid because the DSA
parameters must be present if the cert is signed using RSA. The
verification of cert 4 would fail because working_public_key_parameters
would be set to NULL based on cert 3. I agree with your recommended text:
"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."
-John Pawling
-----Original Message-----
From: Stephen Farrell [mailto:stephen.farrell@baltimore.ie]
Sent: Monday, February 28, 2000 5:59 AM
To: John Pawling; pkix
Cc: xme; RussHousley; TimPolk
Subject: Re: Cert Path Validation Bug in pkix-new-part1-00
John,
Your new text seems to prevent parameter inheritance
across an "algorithm gap", e.g. the following couldn't
verify (because we set the working parms to "null"
during verification of cert 2, so cert 3 will fail):
1: [ top-CA, top-CA, DSA + parms] (self-)signed with DSA/SHA1
2: [ mid-CA, top-CA, RSA + NULL ] signed with DSA/SHA1
3: [ low-CA, mid-CA, DSA (no params) ] signed with RSA
4: [ end-entity, low-CA, whatever] signed with DSA/SHA1
(the notation is [ subject, issuer, subj.public key] signing-alg )
I've no problem with this, but it might not be what an
implementer would do, so should it be made explicit?
One way to do this might be to include a statement like
"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".
This would make cert 3 above non-conformant.
The text could go into section 4.1.2.7 or section 7, or maybe
both.
Regards,
Stephen.
"Pawling, John" wrote:
>
> 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
> john.pawling@wang.com
> ============================================
--
____________________________________________________________
Stephen Farrell
Baltimore Technologies, tel: (direct line) +353 1 647 7406
61 Fitzwilliam Lane, fax: +353 1 647 7499
Dublin 2. mailto:stephen.farrell@baltimore.ie
Ireland http://www.baltimore.com