[Trans] Closing out the SCT encoding discussion

Melinda Shore <melinda.shore@gmail.com> Fri, 13 March 2015 03:21 UTC

Return-Path: <melinda.shore@gmail.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 69F251AC3BE for <trans@ietfa.amsl.com>; Thu, 12 Mar 2015 20:21:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4
X-Spam-Level:
X-Spam-Status: No, score=-4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, GB_I_LETTER=-2, SPF_PASS=-0.001] 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 mRNN8hBFr6UH for <trans@ietfa.amsl.com>; Thu, 12 Mar 2015 20:21:07 -0700 (PDT)
Received: from mail-pd0-x22a.google.com (mail-pd0-x22a.google.com [IPv6:2607:f8b0:400e:c02::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BF151A89FB for <trans@ietf.org>; Thu, 12 Mar 2015 20:21:07 -0700 (PDT)
Received: by pdjz10 with SMTP id z10so25192265pdj.11 for <trans@ietf.org>; Thu, 12 Mar 2015 20:21:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=15y3PKXNtQ0FSMKX9t6/3wE9B5f6DxzYaJ2hrk8Pr+U=; b=n6LIFg8vpD/I5pk6Q0jxONBOwyT50CjqL2jOFX7xwS7NnsJjdLwAU4S0U/N+j9iQ2N 019GYuslDf8f6w7WpL+f9msk5VCxEsCvpiNE9lHpnicU9XiFrEwnoqrQup2jt9qHh2R6 PHeqOkvfhBuEHB3U0F+RxRqDHsDY9n12Zd6oo6wbAWuV6gD0Od8oHr/ZVA77mX1FiPwR f0bHAL2PEQlDDYIuZ3C9hXw2NE4eDfHRo8gQfQbWQXA0tPVQhxKDZgKawcdVDE8rxYfa 8s3wWUxENQ5KOpLOX3kBCRNsI8arHUm4aIaJrsLxT8ZVXVhdT3TKaDnxYJx+RhERy7TW rvLw==
X-Received: by 10.70.130.10 with SMTP id oa10mr67342135pdb.65.1426216866874; Thu, 12 Mar 2015 20:21:06 -0700 (PDT)
Received: from spandex.local (209-193-46-66-rb1.sol.dsl.dynamic.acsalaska.net. [209.193.46.66]) by mx.google.com with ESMTPSA id qh6sm762380pab.34.2015.03.12.20.21.05 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 12 Mar 2015 20:21:06 -0700 (PDT)
Message-ID: <550257A0.8050401@gmail.com>
Date: Thu, 12 Mar 2015 19:21:04 -0800
From: Melinda Shore <melinda.shore@gmail.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: "trans@ietf.org" <trans@ietf.org>, Paul Wouters <paul@nohats.ca>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/trans/R9jM8rSIrGGFOKuZPCUyNXR53aQ>
Subject: [Trans] 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 03:21:08 -0000

Hi, all:

We've been banging away on the SCT encoding issue for a year,
and we really must close it out.  Paul and I have been doing due
diligence on the issue in the background.  We made a concerted effort
to find technical problems with the current text that would exclude the
possibility of allowing it in the -bis document.  Here's what we found:

1) The proposed encoding does not violate the letter of any
   specification that we can find,
2) Peter Gutmann said that it's not a good idea but it isn't
   incorrect,
3) We checked with the authors of several widely-used pieces of
   certificate processing software and in every case that person
   said that the proposed encoding would not cause problems with
   their code, and
4) We verified that the IETF security ADs would not reject the
   encoding during IESG review

Basically, in a nutshell, where we've landed is that while the current
encoding probably isn't the best idea ever, it doesn't violate any
specification that anybody could identify and it doesn't appear to
break anything.  So, it's going to stand.  We will not be revisiting
this issue unless new information is presented.  This includes
discussion at the upcoming meeting in Dallas.

Thanks,

Melinda and Paul