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

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

>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 field 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?

---

From: Russ Housley <[email-masked]>
Date: Mon, 12 Nov 2012 12:26:48 -0500

One is protected by the signature itself, and the other is not.

Russ

On Nov 12, 2012, at 12:18 PM, Andris Berzins wrote:

> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix

---

From: [email-masked] (Martin Rex)
Date: Tue, 13 Nov 2012 04:19:13 +0100 (CET)

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 field 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?

That looks like a historic artifact (=useless baggage) from an
early X.509 design.  In practice, many implementations completely ignore
the signatureAlgorithm field inside the Certificate ToBeSigned and
use the outer (unsigned) AlgId, i.e. ignoring that silly
MUST in rfc3280 section 4.1.2.3.

While the original idea might have been that one wanted to support
ambiguous AlgId parameters that would have needed integrity protection,
this option was killed by Certificate being the only signed object
that contains a signatureAlgorithm property within the signed data.

There is no such protection for the signatureAlgorithm AlgId
in X.509 CRLs, nor in OCSP, nor in PKCS#7 / CMS.  So it would
probably amount to shooting oneself in the foot when creating
AlgId parameters that need to be protected, because none such
protection exists in other essential protocol PDUs that are
typically used with X.509 certs.

-Martin

---

From: Dan Brown <[email-masked]>
Date: Wed, 14 Nov 2012 15:33:55 +0000

Hi Andris,

Burt Kaliski prepared some slides explain the security motivation, and the inefficacy, of "hash firewalls":

http://www.rsa.com/rsalabs/staff/bios/bkaliski/publications/hash-firewalls/kaliski-hash-firewalls-ct-rsa-2002.ppt

I suspect that the inner signature-alg-id in the TBSCertificate is similarly ineffective, but I am not totally sure.

Best regards,

Daniel Brown
Research In Motion Limited

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Andris Berzins
> Sent: Monday, November 12, 2012 12:19 PM
> To: [email-masked]
> Subject: [pkix] redundant AlgorithmIdentifier in X.509 certificates
> 
> From RFC 3280:
> "This field MUST contain the same algorithm identifier as the signature
> field in the sequence tbsCertificate (section 4.1.2.3)."
> 

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

---

From: "Erik Andersen" <[email-masked]>
Date: Thu, 15 Nov 2012 16:28:03 +0100

Hi Martin,

A CRL has a signature field in X.509 and so has attribute certificate, so
X.509 is consistent.

Erik

-----Oprindelig meddelelse-----
Fra: [email-masked] [mailto:[email-masked]] På vegne af Martin
Rex
Sendt: 13. november 2012 04:19
Til: Andris Berzins
Cc: [email-masked]
Emne: Re: [pkix] redundant AlgorithmIdentifier in X.509 certificates

> then why the spec has been designed to include it twice?

That looks like a historic artifact (=useless baggage) from an early X.509
design.  In practice, many implementations completely ignore the
signatureAlgorithm field inside the Certificate ToBeSigned and use the outer
(unsigned) AlgId, i.e. ignoring that silly MUST in rfc3280 section 4.1.2.3.

While the original idea might have been that one wanted to support ambiguous
AlgId parameters that would have needed integrity protection, this option
was killed by Certificate being the only signed object that contains a
signatureAlgorithm property within the signed data.

There is no such protection for the signatureAlgorithm AlgId in X.509 CRLs,
nor in OCSP, nor in PKCS#7 / CMS.  So it would probably amount to shooting
oneself in the foot when creating AlgId parameters that need to be
protected, because none such protection exists in other essential protocol
PDUs that are typically used with X.509 certs.

-Martin

---

From: [email-masked] (Martin Rex)
Date: Fri, 16 Nov 2012 13:22:33 +0100 (CET)

> A CRL has a signature field in X.509 and so has attribute certificate, so
 
Ooops, you're correct.  I'm sorry.

I don't know why I failed to see it the last time I checked that.

  http://tools.ietf.org/html/rfc5280#section-5.1.1.2

But still, I don't see any security value in that structure member
and consider it useless bloat.

However, since one doesn't know which particular AlgId the implementation
used by RPs will be looking at, the CAs must ensure that the use
the exact same value in both places when issuing certs and CRLs.

Finding a different AlgId with special parameters that will verify
the exact same sequence of octets may be academically interesting,
but security-wise is entirely irrelevant.

What would be relevant security-wise, is a good signature under
a **different** sequence of octets.  The assumption that an attacker
could "easily change other parts to his liking, but would have
difficulties to also change the inner signature algorithm parameters
seems awkward to me, and would IMHO indicate a general design flaw
in the signature scheme (ore more likely the hash used by that scheme).

-Martin