[Trans] Clarification needed

Rick Andrews <Rick_Andrews@symantec.com> Tue, 05 August 2014 21:11 UTC

Return-Path: <Rick_Andrews@symantec.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 118BE1B2BEB for <trans@ietfa.amsl.com>; Tue, 5 Aug 2014 14:11:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 wt4R1GZHdgOQ for <trans@ietfa.amsl.com>; Tue, 5 Aug 2014 14:11:04 -0700 (PDT)
Received: from ecl1mtaoutpex01.symantec.com (ecl1mtaoutpex01.symantec.com [166.98.1.209]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0FC01B2BE7 for <trans@ietf.org>; Tue, 5 Aug 2014 14:11:04 -0700 (PDT)
X-AuditID: a66201d1-f795e6d000005a37-d2-53e14867cd65
Received: from ecl1mtahubpin02.ges.symantec.com (ecl1mtahubpin02.ges.symantec.com [10.48.69.202]) by ecl1mtaoutpex01.symantec.com (Symantec Brightmail Gateway out) with SMTP id 96.FB.23095.76841E35; Tue, 5 Aug 2014 21:11:03 +0000 (GMT)
Received: from [155.64.220.137] (helo=TUS1XCHHUBPIN01.SYMC.SYMANTEC.COM) by ecl1mtahubpin02.ges.symantec.com with esmtp (Exim 4.76) (envelope-from <Rick_Andrews@symantec.com>) id 1XEm0d-0007tP-8v for trans@ietf.org; Tue, 05 Aug 2014 17:11:03 -0400
Received: from TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM ([155.64.220.146]) by TUS1XCHHUBPIN01.SYMC.SYMANTEC.COM ([155.64.220.137]) with mapi; Tue, 5 Aug 2014 14:10:46 -0700
From: Rick Andrews <Rick_Andrews@symantec.com>
To: "trans@ietf.org" <trans@ietf.org>
Date: Tue, 05 Aug 2014 14:10:45 -0700
Thread-Topic: Clarification needed
Thread-Index: Ac+w8Q6BDNq+SoPyQ4Cie8Jig6hMyA==
Message-ID: <544B0DD62A64C1448B2DA253C011414607CE9B9971@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_544B0DD62A64C1448B2DA253C011414607CE9B9971TUS1XCHEVSPIN_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpjkeLIzCtJLcpLzFFi42LhMnA9pZvu8TDYYP5XJYu1jy+yODB6LFny kymAMYrLJiU1J7MstUjfLoEr48uEN8wF09Uqnv5dx9bAeEa+i5GTQ0LARKLry31WCFtM4sK9 9WxdjFwcQgLvGCXOnLkP5fxnlDjePJUVwlnJKPFsZTszSAubgJ7ElsdX2EFsEQFVic/3W5hA bBYBFYkNU4+BxYUFZCVm9f4AauYAqlGSmDa9BKJcT2LW1U1gY3gFoiROLHrJBmIzAl3x/dQa sDHMAuISt57MZ4K4TkBiyZ7zzBC2qMTLx/9YIepFJe60r2eEqM+XuHr0CDvETEGJkzOfsExg FJ6FZNQsJGWzkJRBxHUkFuz+xAZha0ssW/iaGcY+c+AxE7L4Akb2VYwyqck5hrklifmlJQWp FQaGesWVuYnAuEnWS87P3cQIjJ1lSYwXdzBeOKx7iFGAg1GJh7dB52GwEGtiGVDlIUYJDmYl EV722w+ChXhTEiurUovy44tKc1KLDzFKc7AoifN+tL0ZLCSQnliSmp2aWpBaBJNl4uCUamAU 1/nKHfmsnzuAS+P/idjPP5JFBDYLK76br3x9KVf41L4zZxQWGAevuCOTv7g8NZLDMd4qne+U +JLaA5F2L8M2d4rtq+jYtvlPZfEV5UXNeR1nrz7KfnSeR46trD9vwQaT/6fildi1hO8t+K41 xVFu+c2bl4Oy33eKpv1/ry6cJ/G48Vm3rKgSS3FGoqEWc1FxIgAMxT0imQIAAA==
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/t6H5d_RxhtLS9JaElrBdtLe8GZE
Subject: [Trans] Clarification needed
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: Tue, 05 Aug 2014 21:11:11 -0000

In thinking about how log servers should behave, I came up with two cases that should probably be addressed in the -bis so that all log servers behave the same way.

1) Let's say I've issued a cert and embedded the SCTs in the cert. Now I (or someone else) send the cert to log servers using the add-chain command. What happens? Should the log server see if one of the SCTs is from itself, and if so just return that SCT? Or should it generate a new SCT?

Rob Stradling helped me understand that the SCTs in the cert would have a "entry_type" of "precert_entry", so the log server shouldn't just return that. Instead, it seems that it should create a new SCT with an "entry_type" of "x509_entry". But it's worth clarifying that this new SCT would contain a hash over the entire cert, including the existing SCTs, even if one of those embedded SCTs originated from that same log server.

2) Finally, is it worth clarifying that while anyone can invoke the add-chain command, only CAs are expected to invoke the add-pre-chain command? Should log servers return an error if the pre-cert presented in the add-pre-chain command does not contain the poison extension?

Finally, it might be worth clarifying Section 4.2, Add PreCertChain to Log, where the input is described as "An array of base64-encoded Precertificates", which seems to imply that the CA can send multiple pre-certs and chains in a single command. The rest of the description makes it clear that the log server expects only one chain, the first cert in the chain is the pre-cert and the following certs are the (non-pre-cert) certs in the chain.



It's not clear to me if I should create issues in the tracker for these. I thought I would get some initial feedback first.

-Rick