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

From: "Andris Berzins" <[email-masked]>
Date: Tue, 13 Nov 2012 11:29:06 +0200

While the original idea might have been that one wanted to support
ambiguous AlgId parameters that would have needed integrity protection,

Why would integrity of AlgId parameters matter?
If using arbitrary AlgId parameters would allow to forge signature, then forger could just put AlgId he needs under the forged signature.

---

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

> Why would integrity of AlgId parameters matter?

I honestly don't know.  I was just plain guessing at what might have
been the original motivation behind the addition of this useless
baggage to TBSCertificate.  As I wrote, I believe that MUST in
section 4.1.2.3 of rfc3280, and its successor rfc5280 is silly.

>
> If using arbitrary AlgId parameters would allow to forge signature,
> then forger could just put AlgId he needs under the forged signature.
 
Probably.

-Martin

---

From: "Kemp, David P." <[email-masked]>
Date: Tue, 13 Nov 2012 23:18:41 +0000

See RFC 6211

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Martin Rex
Sent: Tuesday, November 13, 2012 5:59 PM
To: Andris Berzins
Cc: [email-masked]
Subject: Re: [pkix] redundant AlgorithmIdentifier in X.509 certificates

> Why would integrity of AlgId parameters matter?

I honestly don't know.  I was just plain guessing at what might have been the original motivation behind the addition of this useless baggage to TBSCertificate.  As I wrote, I believe that MUST in section 4.1.2.3 of rfc3280, and its successor rfc5280 is silly.

Probably.

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

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 14 Nov 2012 10:04:06 +0100

Martin,

Let's separate this.

On 11/13/12 11:59 PM, "Martin Rex" <[email-masked]> wrote:

>As I wrote, I believe that MUST in

Yes, the original design to include the AlgID twice is kind of silly.
Clearly an early redundant design.
However, this is what it is now and it does not really hurt that much
either.

But the MUST in 5280 is NOT silly, because we don't know what we might
break if we don't put it in there.

/Stefan

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 14 Nov 2012 09:29:35 +0000

> Clearly an early redundant design.

I forget the details and so may be wrong, but early versions
of X.509 (1988 maybe) were based on X.400's ASN.1 macro named
"SIGNED" which adds the outer alg id along with the signature.
At some point someone noticed that some hash-alg attacks might
be allowed by that and the inner alg id was added.

S.

---

From: David Chadwick <[email-masked]>
Date: Wed, 14 Nov 2012 09:43:31 +0000

I thought it was the opposite. That no-one noticed that the Signed macro 
added the alg id as well as the signature, and thought it only added the 
signature, therefore put the alg id within the package to be signed.

David

---

From: Johannes Merkle <[email-masked]>
Date: Wed, 14 Nov 2012 10:49:36 +0100

> be allowed by that and the inner alg id was added.

While I doubt the usefulness of the inner AlgID, the outer one can be needed when signature algorithms with message
recovery are used. Although these are not common (among other reasons, due to IPR), but that might not have been
anticipated in the early X.509 day.

-- 
Johannes

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 14 Nov 2012 09:54:02 +0000

On 11/14/2012 09:49 AM, Johannes Merkle wrote:
> While I doubt the usefulness of the inner AlgID, 

Yep.

> the outer one can be needed when signature algorithms with message

You're right, but I don't recall that being raised then.
I think it was literally just down to reusing the ASN.1
macro in the spec. (Prosaic variant wins, almost every
time;-)

S.

---

From: "Erik Andersen" <[email-masked]>
Date: Wed, 14 Nov 2012 18:06:55 +0100

For your information, the 2012 edition of X.509 has updated the signature
field to:

The signature field contains the algorithm identifier for the algorithm and
hash function used by the CA in signing the certificate (e.g.,
md5WithRSAEncryption, sha-1WithRSAEncryption, id-dsa-with-sha1, etc.). It
shall be the same value as used in the algorithmIdentifier component of the
SIGNATURE data type when signing the public-key certificate.
NOTE 2 – This field is redundant except possibly for its participation in
matching certificates (see 11.3.2).

-----Oprindelig meddelelse-----
Fra: [email-masked] [mailto:[email-masked]] På vegne af David
Chadwick
Sendt: 14. november 2012 10:44
Til: Stephen Farrell
Cc: Stefan Santesson; [email-masked]
Emne: Re: [pkix] redundant AlgorithmIdentifier in X.509 certificates

David

On 14/11/2012 09:29, Stephen Farrell wrote:
> I forget the details and so may be wrong, but early versions of X.509 
> (1988 maybe) were based on X.400's ASN.1 macro named "SIGNED" which 
> adds the outer alg id along with the signature.
> At some point someone noticed that some hash-alg attacks might be 
> allowed by that and the inner alg id was added.
>
> S.

---

From: [email-masked] (Martin Rex)
Date: Wed, 14 Nov 2012 18:22:10 +0100 (CET)

> matching certificates (see 11.3.2).

One thing that I do not like about some of the requirements in
PKIX (rfc5280 and predecessors) and X.509, is the lack of distinction
at which party a requirement is directed.

My rule of thumb: if it is not explicitly listed as a seperate item
in the basic path validation, then it is directed at conforming CAs,
not RPs doing certificate path validation.

Requiring that the signatureAlgorithm field within TBSCertificate and
on the outer signature element are the same is perfectly valid for
conforming CAs upon issuing certs.  But I consider it silly with
respect to RPs to consciously compare the values of these fields
during certificate path validation.  (as indicated by the note,
such a comparision may be implicit by comparison of a certificate hash
or certificate blob).

-Martin