Re: [pkix] Signature Verification and DER requirements

It appears for me that the Japanese comment should be rejected. I will bring
that up on our own list, as that is the decision making list for X.509.

The Japanese comment implies (as I read it), as you do not whether a
received cert is DER or non-DER encoded, you need to decode it and encode it
in DER before checking the signature. In a constrained environment this
seems an unnecessary burden to put on an RP.

Jeff write that you could reject a cert because it is non-DER encoded. How
do detect that without analysing the cert in details. If you do minimum
processing, you will just discover the signature validation failed.

I brought the issue up on this list due to the level of expertise on this
list and because a thread was going on this issue.

Kind regards,

Erik

-----Oprindelig meddelelse-----
Fra: Santosh Chokhani [mailto:schokhani@cygnacom.com] 
Sendt: 15 May 2015 22:45
Til: noloader@gmail.com; Erik Andersen
Cc: IETF PKIX
Emne: RE: [pkix] Signature Verification and DER requirements

+1

-----Original Message-----
From: pkix [mailto:pkix-bounces@ietf.org] On Behalf Of Jeffrey Walton
Sent: Friday, May 15, 2015 3:40 PM
To: Erik Andersen
Cc: IETF PKIX
Subject: Re: [pkix] Signature Verification and DER requirements

On Fri, May 15, 2015 at 10:12 AM, Erik Andersen <era@x500.eu> wrote:
> As Peter states. It is confusing, and I am not sure how to get it right.
>
> ...
> I am interested in comments.
>
Maybe the easiest course is to side-step the issue altogether. The issue
here is verification, so focus on it.

Leave things the way they are related to encoding the certificate and
signing the certificate (or more correctly, tbsCertificate).

Then be explicit about how to verify it. That is, explicitly state bits
should be verified as they are received; and they should not be rearranged
to comply with anything because that will usually (always?) invalidate the
signature.

Allowing the bits to be rearranged during verification just seems wrong. It
effectively creates a potential for a DoS when there's no need for one to
exist. The security goals were met earlier, when the identity was bound to
the public key.

I also think you should give an implementation a choice during
verification: they can choose to reject a non-DER encoded certificate
because that's how things are written. But they should reject for the proper
reason: reject because its no-DER encoded; and not becuase they re-arranged
bits that caused a signature failure.

Allowing a receiver to rearrange bits and then claim the signature
verification failed is just plain wrong. They may as well have performed
'certificate[0] XOR 0x01' and claimed the certificate was tampered. There's
no difference.

Jeff

_______________________________________________
pkix mailing list
pkix@ietf.org
https://www.ietf.org/mailman/listinfo/pkix