Re: [pkix] a question of cert (and OCSP) extension syntax

Peter Gutmann <pgut001@cs.auckland.ac.nz> Wed, 18 March 2015 03:29 UTC

Return-Path: <pgut001@cs.auckland.ac.nz>
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 4D83E1A8A57 for <pkix@ietfa.amsl.com>; Tue, 17 Mar 2015 20:29:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level:
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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 yD4zJvucp2Kw for <pkix@ietfa.amsl.com>; Tue, 17 Mar 2015 20:29:01 -0700 (PDT)
Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 768E71A8A3E for <pkix@ietf.org>; Tue, 17 Mar 2015 20:29:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1426649342; x=1458185342; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=BBXeNQ7CFrpAqFfP8GKNqdLcvk+i1hBRmtNnpE/QTAk=; b=ko4bWDdLgFiG8xT+6/Csn/Q9SHEirSSfZfjYGJFgQpq/u7YXhYoiP/vM dXIQuEDMvFOAVm6TQJ5fL2V86SCd+kR2LiYLDh0OGXYI1hta6pH+7x6Lw VeAGKpghLPu7Gmgw8CywqZ+Rzx1OqBjdbUsIR0oXqsUDDOGBb0sFLsKnq U=;
X-IronPort-AV: E=Sophos;i="5.11,419,1422874800"; d="scan'208";a="314647499"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 130.216.4.171 - Outgoing - Outgoing
Received: from uxchange10-fe4.uoa.auckland.ac.nz ([130.216.4.171]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 18 Mar 2015 16:28:58 +1300
Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.82]) by uxchange10-fe4.UoA.auckland.ac.nz ([169.254.109.63]) with mapi id 14.03.0174.001; Wed, 18 Mar 2015 16:28:57 +1300
From: Peter Gutmann <pgut001@cs.auckland.ac.nz>
To: IETF PKIX <pkix@ietf.org>
Thread-Topic: [pkix] a question of cert (and OCSP) extension syntax
Thread-Index: AdBhK6rotK8zApXUQlOU4LeONLj1JQ==
Date: Wed, 18 Mar 2015 03:28:57 +0000
Message-ID: <9A043F3CF02CD34C8E74AC1594475C73AAFB4AEE@uxcn10-5.UoA.auckland.ac.nz>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [130.216.158.4]
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/n4B_Z0HNCLE1JaKTv0iVdTSQoT0>
Subject: Re: [pkix] a question of cert (and OCSP) extension syntax
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: Wed, 18 Mar 2015 03:29:05 -0000

Stephen Kent <kent@bbn.com> writes:

>Since the bulk of the data items have an obvious ASN.1 representation, and
>the certificate or TBS certificate are native ASN.1 structures, we feel that
>the decision to stuff all of the data items into an OCTET STRING is
>inappropriate, and that it sets a bad precedent for others developing
>certificate (and OCSP) extensions in the future

I'd already discussed this in private with some of the folks involved, my
reasoning was exactly the same as yours, if you want this to be able to be
processed by anything that uses certs then it has to be compatible with
standard PKI software, which means encoding it in a form that PKI software can
work with it.  Their response was that it was only intended for use in TLS so
having it as an opaque (outside of TLS) blob wasn't a problem.  I didn't agree
with that because it's either going to fail and sink without a trace, or
succeed and end up being used in lots of places that aren't TLS, neither of
which are compatible with the TLS-only view.

The impression I got was that the decision to use the TLS encoding was a
foregone conclusion and there wasn't much chance of changing it.

Peter.