[Trans] comments on draft-zhang-trans-ct-binary-codes-01

Benjamin Kaduk <kaduk@MIT.EDU> Mon, 23 March 2015 03:04 UTC

Return-Path: <kaduk@mit.edu>
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 EC3991A8798 for <trans@ietfa.amsl.com>; Sun, 22 Mar 2015 20:04:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level:
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 fF1LMh6UmQCr for <trans@ietfa.amsl.com>; Sun, 22 Mar 2015 20:04:50 -0700 (PDT)
Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 833F61A8791 for <trans@ietf.org>; Sun, 22 Mar 2015 20:04:50 -0700 (PDT)
X-AuditID: 12074425-f79ca6d000000e5e-48-550f82d11dc6
Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id C7.05.03678.1D28F055; Sun, 22 Mar 2015 23:04:49 -0400 (EDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id t2N34mgl005710 for <trans@ietf.org>; Sun, 22 Mar 2015 23:04:49 -0400
Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t2N34lVk032566 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <trans@ietf.org>; Sun, 22 Mar 2015 23:04:48 -0400
Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t2N34kl2016497; Sun, 22 Mar 2015 23:04:46 -0400 (EDT)
Date: Sun, 22 Mar 2015 23:04:46 -0400
From: Benjamin Kaduk <kaduk@MIT.EDU>
To: trans@ietf.org
Message-ID: <alpine.GSO.1.10.1503222259320.22210@multics.mit.edu>
User-Agent: Alpine 1.10 (GSO 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrDIsWRmVeSWpSXmKPExsUixCmqrHuxiT/U4MF8cYu1jy+yODB6LFny kymAMYrLJiU1J7MstUjfLoEr4/ya/4wFk9kr2nfeZ21gfMvaxcjJISFgIjH30DEmCFtM4sK9 9WxdjFwcQgKLmSSenP/OCuEcY5Q4u7SVGcK5ziRx4ct+KKeBUeLy5z4WkH4WAW2JCR2/2EFs NgEViZlvNrKB2CICQhKtJ16C7RAWsJR4f/IdM4jNK+AosfzqfzBbVEBHYvX+KSwQcUGJkzOf gNnMAloSy6dvY5nAyDcLSWoWktQCRqZVjLIpuVW6uYmZOcWpybrFyYl5ealFuhZ6uZkleqkp pZsYQQHF7qK6g3HCIaVDjAIcjEo8vBUB/KFCrIllxZW5hxglOZiURHm97YBCfEn5KZUZicUZ 8UWlOanFhxglOJiVRHhj7YFyvCmJlVWpRfkwKWkOFiVx3k0/+EKEBNITS1KzU1MLUotgsjIc HEoSvJMagRoFi1LTUyvSMnNKENJMHJwgw3mAht8FqeEtLkjMLc5Mh8ifYtTluDPl/yImIZa8 /LxUKXHeWpAiAZCijNI8uDmwRPCKURzoLWFeQ5AqHmASgZv0CmgJE9CSc/l8IEtKEhFSUg2M +5Sr+9T80w/8c2BxvBW+668s18WZjL9msaxxWub7/dOE7Ikrbhhnds0/codtnxKHxpniHV+2 ayn4f3lu8fhM2x632ztvVqZkcik+SdqnteWL4C3u5awWPUlBb1dqbvbbw8iZWuHSv7crWO39 uzcW7D+snVdsFtTSNg7K5mLfHX41qM3Xq2y2EktxRqKhFnNRcSIA49gLWN8CAAA=
Archived-At: <http://mailarchive.ietf.org/arch/msg/trans/pUfvjRq-sIpl1xX5kJCf0s_ac5Y>
Subject: [Trans] comments on draft-zhang-trans-ct-binary-codes-01
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: Mon, 23 Mar 2015 03:04:52 -0000

Please specify what data description and interchange formats are being
used.  E.g., sections 4.1 and 4.2 are presumably using TLS syntax, and
section 5.1 should specify that both input and output are JSON structures.

In section 5.1, in the description of the 'extensions' field, we see that
"Logs should set this to the empty string.  Clients should decode the
base64-encoded data and include it in the SCT".  Should these be RFC 2119
"SHOULD"s?  Also, what "the base64-encoded data" is could probably be more
clear, i.e., saying something about if the server sets extensions to
something other than the empty string, it MUST be base64-encoded data, and
if the client receives something which is non-empty, then it does the
decoding and includes it in the CtExtensions portion of the
SignedCertificateTimestamp.  (Hmm, I don't see it explicitly mentioned
that that's what SCT means, either.)

-Ben