IETF Logo Mail Archive

Re: [pkix] Signature Verification and DER requirements

Santosh Chokhani <schokhani@cygnacom.com> Fri, 15 May 2015 20:45 UTC

Return-Path: <schokhani@cygnacom.com>
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8F911A86E0 for <pkix@ietfa.amsl.com>; Fri, 15 May 2015 13:45:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level:
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o_3sSWECZVlt for <pkix@ietfa.amsl.com>; Fri, 15 May 2015 13:45:35 -0700 (PDT)
Received: from ipesa2.cygnacom.com (ipesa2.cygnacom.com [65.242.48.201]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49DEC1A8889 for <pkix@ietf.org>; Fri, 15 May 2015 13:45:31 -0700 (PDT)
Received: from unknown (HELO svaexch1.cygnacom.com) ([10.60.50.216]) by ipesa2.cygnacom.com with ESMTP; 15 May 2015 16:45:31 -0400
Received: from svaexch1.cygnacom.com (10.60.50.216) by svaexch1.cygnacom.com (10.60.50.216) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Fri, 15 May 2015 16:45:29 -0400
Received: from svaexch1.cygnacom.com ([fe80::b53e:f4f1:9071:563e]) by svaexch1.cygnacom.com ([fe80::b53e:f4f1:9071:563e%12]) with mapi id 15.00.1076.000; Fri, 15 May 2015 16:45:29 -0400
From: Santosh Chokhani <schokhani@cygnacom.com>
To: "noloader@gmail.com" <noloader@gmail.com>, Erik Andersen <era@x500.eu>
Thread-Topic: [pkix] Signature Verification and DER requirements
Thread-Index: AdCOb3U8X23f7gRRfkS72hCxt/Rc8QAy0DgAAAtwrAAABoLxQA==
Date: Fri, 15 May 2015 20:45:29 +0000
Message-ID: <25f0ef53824f44589e5e2b36fa40a8d6@svaexch1.cygnacom.com>
References: <9A043F3CF02CD34C8E74AC1594475C73AB020EBB@uxcn10-tdc05.UoA.auckland.ac.nz> <000001d08f19$3210caa0$96325fe0$@x500.eu> <CAH8yC8m6V1=PtSua5q5ZWXFY+WnUwdiV_cyoyXyMDeT0iByH_g@mail.gmail.com>
In-Reply-To: <CAH8yC8m6V1=PtSua5q5ZWXFY+WnUwdiV_cyoyXyMDeT0iByH_g@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.60.117.7]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/pkix/ciegaOREMn7nPV7oKF_GU03bC8w>
Cc: IETF PKIX <pkix@ietf.org>
Subject: Re: [pkix] Signature Verification and DER requirements
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: PKIX Working Group <pkix.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pkix>, <mailto:pkix-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pkix/>
List-Post: <mailto:pkix@ietf.org>
List-Help: <mailto:pkix-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pkix>, <mailto:pkix-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 15 May 2015 20:45:36 -0000

+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

v2.23.0 | Report a Bug | By Email