IETF Logo Mail Archive

Re: [Trans] Bad Technical Decision: Closing out the SCT encoding discussion

Rob Stradling <rob.stradling@comodo.com> Fri, 13 March 2015 20:58 UTC

Return-Path: <rob.stradling@comodo.com>
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E24A1A879E for <trans@ietfa.amsl.com>; Fri, 13 Mar 2015 13:58:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 46Ez5lAnbXUc for <trans@ietfa.amsl.com>; Fri, 13 Mar 2015 13:58:53 -0700 (PDT)
Received: from mmextmx2.mcr.colo.comodoca.net (mmextmx2.mcr.colo.comodoca.net [IPv6:2a02:1788:402:c00::c0a8:9cd6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69A8F1A037D for <trans@ietf.org>; Fri, 13 Mar 2015 13:58:53 -0700 (PDT)
Received: (qmail 15138 invoked by uid 1004); 13 Mar 2015 20:58:51 -0000
Received: from ian.brad.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.202) by mmextmx2.mcr.colo.comodoca.net (qpsmtpd/0.84) with ESMTP; Fri, 13 Mar 2015 20:58:51 +0000
Received: (qmail 21678 invoked by uid 1000); 13 Mar 2015 20:58:51 -0000
Received: from and0004.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (AES128-SHA encrypted) ESMTPSA; Fri, 13 Mar 2015 20:58:51 +0000
Message-ID: <55034F89.4060501@comodo.com>
Date: Fri, 13 Mar 2015 20:58:49 +0000
From: Rob Stradling <rob.stradling@comodo.com>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>, Russ Housley <housley@vigilsec.com>
References: <550257A0.8050401@gmail.com> <B87AFA6C-2B9F-474C-AE0F-BF07829CD139@vigilsec.com> <550347A0.6070005@cs.tcd.ie>
In-Reply-To: <550347A0.6070005@cs.tcd.ie>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/trans/XhjoPY7TpAekx37N6PhHRnuY0V8>
Cc: Paul Wouters <paul@nohats.ca>, trans@ietf.org, Melinda Shore <melinda.shore@gmail.com>
Subject: Re: [Trans] Bad Technical Decision: Closing out the SCT encoding discussion
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Public Notary Transparency working group discussion list <trans.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/trans>, <mailto:trans-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/trans/>
List-Post: <mailto:trans@ietf.org>
List-Help: <mailto:trans-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/trans>, <mailto:trans-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Mar 2015 20:58:56 -0000

On 13/03/15 20:25, Stephen Farrell wrote:
<snip>
> And if we interpret 5280 strictly and conclude that is still a
> good plan then the question would be what to do about the SCT
> encoding, which could be to do something hacky like prepending
> another OCTET STRING tag and a length I suppose,

Stephen, RFC6962 does precisely that, and the current 6962-bis text aims 
to do the same.

Adding yet another OCTET STRING would turn it into an OCTET STRING 
inside an OCTET STRING inside an OCTET STRING!

I'd be surprised if Russ or Steve Kent would consider that to be any 
better than the current plan (an OCTET STRING inside an OCTET STRING).

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

v2.23.0 | Report a Bug | By Email