Subject: Re: [pkix] redundant AlgorithmIdentifier in X.509 certificates

From: "Andris Berzins" <[email-masked]>
Date: Mon, 12 Nov 2012 19:31:18 +0200

Why does the signatureAlgorithm field has to be protected by signature itself? Does it prevent some attacks?

Why to include also non-protected duplicate?

Quoting "Russ Housley" <[email-masked]>:
> One is protected by the signature itself, and the other is not.
> 
> Russ
> 
> 
> On Nov 12, 2012, at 12:18 PM, Andris Berzins wrote:
> 
>> From RFC 3280:
>> "The signatureAlgorithm field contains the identifier for the cryptographic 
>>algorithm used by the CA to sign this certificate."
>> "This field MUST contain the same algorithm identifier as the signature fiel
>>d in the sequence tbsCertificate (section 4.1.2.3)."
>> 
>> If "signatureAlgorithm" and "signature" field has the same meaning, then why
>> the spec has been designed to include it twice?
>> 
>> _______________________________________________
>> pkix mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/pkix

---

From: Santosh Chokhani <[email-masked]>
Date: Mon, 12 Nov 2012 12:35:32 -0500

While I cannot answer your question, the term "protected" is a bit too strong.  I would use the term, one is used in signature computation and the other is not.

Specifically, when EC and Discrete Log type algorithms are involved, you should not use parameters from either location.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Andris Berzins
Sent: Monday, November 12, 2012 12:31 PM
To: Russ Housley
Cc: [email-masked]
Subject: Re: [pkix] redundant AlgorithmIdentifier in X.509 certificates

Quoting "Russ Housley" <[email-masked]>:
>> "The signatureAlgorithm field contains the identifier for the 
>>cryptographic algorithm used by the CA to sign this certificate."
>> "This field MUST contain the same algorithm identifier as the 
>>signature fiel d in the sequence tbsCertificate (section 4.1.2.3)."
>> 
>> If "signatureAlgorithm" and "signature" field has the same meaning, 
>> then why the spec has been designed to include it twice?
>>