From vaclav.jirovsky@gmail.com Mon Feb 4 02:09:49 2019 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E428130E3F for ; Mon, 4 Feb 2019 02:09:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.02 X-Spam-Level: X-Spam-Status: No, score=-1.02 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, FROM_EXCESS_BASE64=0.979, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 ua22PyghWzwk for ; Mon, 4 Feb 2019 02:09:47 -0800 (PST) Received: from mail-ot1-x32c.google.com (mail-ot1-x32c.google.com [IPv6:2607:f8b0:4864:20::32c]) (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 4765B130E2E for ; Mon, 4 Feb 2019 02:09:47 -0800 (PST) Received: by mail-ot1-x32c.google.com with SMTP id v23so11988814otk.9 for ; Mon, 04 Feb 2019 02:09:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=tumspwJwX2LVH2wqZoxGuEilOHYixxHuzg3nYtY72fQ=; b=l9vOEuBQ4/t3fCCSbUZ1lCnSLBs4wQPqhcxJuqpxqnWY42dUXKpPCX7F/Nt4dZkQiq eZmggyDvvDz0T+F8fZUETpZK97R7TX5Y7H1N64Ln+d+AvtB6+LergibIosSh66TElx0P 0tCKmeCyq9+2EHazunGEK85r+XwvgMjM4RMJBbiR7a1ADo+uCDsaM9neazvUvIJaNaFK YLqf6XvbEZldeXba2TdgLfQcEoXNvBdWpWdzTACYAqAGb5Q8DOdY7Zd9ZVeMDAKphK/i yFOgznR9Hqz2m+F0NXMud240NJa0/1KjGaObz5266fK4m8baIql6e9XssKPX2jSDA6Dw /lJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=tumspwJwX2LVH2wqZoxGuEilOHYixxHuzg3nYtY72fQ=; b=MI2NK10d3rjjNifoxL1iv5rhG5uMih5hmRJ8TWULU7PYwQ0ONcuwf44TK0EU1XMlZx sJlIQzOAC5eRZX0JtOqhM7PW/E0R99yD2PKk8Cq2Pymx5SoLvFtbgQb6W39dO+cPz8uB uQ1DKs7FXDJXiO8cexXv6TwNl0VNoRqKcIq0FrDYbSVA0UJ+J1Cpj/ckz0LnK3dQGGaI uiPec4x1bGUSG+7q3cLO6xbioiR8pNbUnWp3/BT4Q1Xmq5ut4yNfnEyouJrTLSbN0RNX FNg9PuVmzaYBgg6P7dI9gEJXTiJimuGkvEGshIj8+YDuvY8XVSd71r+ygwb3AMLcJQk8 Hfrg== X-Gm-Message-State: AJcUukdFD+tcmqlSJFBu2BPTfaH9dJk8yNhxXS7XXvZOvhu+WjM5p+wD epGkKw9mq0opKtvX+cG3GDJX3w2ti/uxsuQQWLzv6G/z X-Google-Smtp-Source: ALg8bN5ck81styF/aXclIaPUoLBqTzCfZG1Gks1NCpDkX9HX3CltnTs5/Jrn0r+iIvXMAUJz4plaIMyi1IdKUuxe134= X-Received: by 2002:aca:f553:: with SMTP id t80mr26658661oih.358.1549274986024; Mon, 04 Feb 2019 02:09:46 -0800 (PST) MIME-Version: 1.0 From: =?UTF-8?B?VsOhY2xhdiBKaXJvdnNrw70=?= Date: Mon, 4 Feb 2019 11:09:35 +0100 Message-ID: To: trans@ietf.org Content-Type: multipart/alternative; boundary="0000000000003395e005810eb1c1" Archived-At: Subject: [Trans] Add get_entries_max_limit attribute to get-sth request X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2019 10:18:51 -0000 --0000000000003395e005810eb1c1 Content-Type: text/plain; charset="UTF-8" Hello all, I would like to propose modification Retrieve Latest Signed Tree Head section of RFC6962 - adding new attribute *get_entries_max_limit.* Reason for this change - 4.6 section actual version: * Logs MAY restrict the number of entries that can be retrieved per "get-entries" request. If a client requests more than the permitted number of entries, the log SHALL return the maximum number of entries permissible. These entries SHALL be sequential beginning with the entry specified by "start". * If you want to download all entries from CT server, you don't what number of entries will server return to you by request - so you have to process, count real number of returned entries and after that, you can do another request. This is not efficient, you could do these request in parallel, if you would have garanteed number of returned entries. *Proposed modification:* 4.3 . Retrieve Latest Signed Tree Head GET https:///ct/v1/get-sth No inputs. Outputs: tree_size: The size of the tree, in entries, in decimal. timestamp: The timestamp, in decimal. sha256_root_hash: The Merkle Tree Hash of the tree, in base64. * get_entries_max_limit: Maximum entries count provided by server get-entries method.* tree_head_signature: A TreeHeadSignature for the above data. 4.6 . Retrieve Entries from Log GET https:///ct/v1/get-entries Inputs: start: 0-based index of first entry to retrieve, in decimal. end: 0-based index of last entry to retrieve, in decimal. ..... Logs MAY restrict the number of entries that can be retrieved per "get-entries" request. *If a client requests more than the permitted number of entries ("get_entries_max_limit" output of "get-sth" request),* * the log SHALL return the maximum number of entries permissible. If a client requests less or equal than the permitted number of entries ("get_entries_max_limit" output of "get-sth" request), the log MUST return the maximum number of entries permissible. * These entries SHALL be sequential beginning with the entry specified by "start". Best, Vaclav Jirovsky --0000000000003395e005810eb1c1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello all,=C2= =A0

I would like to propose modification=C2=A0Retrieve Latest Signe= d Tree Head section o= f=C2=A0RFC6962=C2=A0- adding=C2=A0new attribute=C2=A0ge= t_entries_max_limit.

Reason for this ch= ange - 4.6 section actual version:
 Logs MAY restrict the number of entries that can =
be retrieved per
   "get-entries" request.  If a client requests more than the per=
mitted
   number of entries, the log SHALL return the maximum number of entries
   permissible.  These entries SHALL be sequential beginning with the
   entry specified by "start".

If you want to download all entries fro= m CT server, you don't what number of entries will server return to you= by request - so you have to process, count real number of returned=C2=A0en= tries and after that, you can do another request. This is not efficient, yo= u could do these request in parallel, if you would have garanteed number of= returned entries.

Proposed modification:


4.3.  Retrieve=
 Latest Signed Tree Head


GET https://<log server>/ct/v1/get-sth
No inputs.

Ou=
tputs:
      t=
ree_size:  The size of the tree, in entries, in decimal.
      timestamp:  The timestamp, in decimal.
      sha256_root_hash:  The Merkle Tree Hash of the tree, in base64.
=

      get_entries_max_limit: Maximum entries count provided =
by server get-entries method.

      tree_head_signature:  A TreeHeadSignature for the above data.




4.6.  Retrieve =
Entries from Log


GET https://<log server>/ct/v1=
/get-entries

Inputs:
      start:  0-based index of first entry to retrieve, in decimal.
      end:  0-based index of last entry to retrieve, in decimal.
=
.....

   Logs MAY restrict the numb=
er of entries that can be retrieved per
   "get-entries" request.  If a client requests more than the =
permitted
   number of entries ("get_entries_max_limit" output of "get=
-sth" request),
   the =
log SHALL return the maximum number of entries
   permissible. If a client requests less or equal than the permitted=20
   number of entries ("get_entries_max_limit" output of "get=
-sth" request),
   the log MUST return the maximum number of entries permissible. 
   These entries SHALL be sequential beginning with the
   entry specified by "start".


Best,
Vaclav Jirovsky

--0000000000003395e005810eb1c1-- From nobody Mon Feb 4 04:02:11 2019 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9FD712875B for ; Mon, 4 Feb 2019 04:02:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.142 X-Spam-Level: X-Spam-Status: No, score=-17.142 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 A-u_m_qr8mAt for ; Mon, 4 Feb 2019 04:02:03 -0800 (PST) Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [IPv6:2a00:1450:4864:20::52e]) (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 7F150130DE4 for ; Mon, 4 Feb 2019 04:02:02 -0800 (PST) Received: by mail-ed1-x52e.google.com with SMTP id g22so10997806edr.7 for ; Mon, 04 Feb 2019 04:02:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sPnbV9qIfmhmOk88hrP0I/Q3CaxbN5jws0MBe5Sp6Cg=; b=iAeR2YcFZNn1Z5Kd05/yn0oGisrd2OHHMX5Mof9vndEMo520bEnddWtpZQP2u6EkAE 8K00xALks2tTuA4kbmXigcaCZY3r6LZ3Rb70PdiKE0PbEVGHQRPh9Y8+iOWxg02+evvJ sYTuMV+WNvIKtcpsf0L7IAb+98KvFL+wnnf7e7ao9a7LogDYiflqZ2WcBU0RcGdRXfgl wvZdQxqF25s3/ufeBuay8AQLg+57IvaSBvIIYvGzwfi0KCrVqD0MpXlVwn72mMwjfPz7 /hIYgmpOvu5SMTXiuuwYJSwC8ER5uiUW6Dt6wHpLhqv7fMIMDX0sCHICG7S+tFoJExhT 2vFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=sPnbV9qIfmhmOk88hrP0I/Q3CaxbN5jws0MBe5Sp6Cg=; b=qlT6ZC4bbp5BcYKSS0vvJ2Tq6Ta0N5ngFwv8gQTzttga+PFkoH9o1QCxYxluwooAZ/ 3fOb6zwxhsWnnqIORQMlu1y2AdNuS/8T6lihDBePLPsPZXVieVs+pd6z+EcUovcKYXaF b/yBvKawAiQX44CJMH2rMKDe2+NLsdOxjsC3f4SoRj80w8B4u3uPqSJwCeUmfDRt4NoW /7DTWUoJsp9gvq+TM3X0FCXpCPYPcsyYHAKpAqVP0bZZCy+/kUc9i8QMda5UwXqjZt7x 8UcMvHfMk6msyz5rm2oUaLU2oRb9u9t5teneP5IhK8VWGsbKjYhbOqnrNUzNHt48kE3w Zb7A== X-Gm-Message-State: AJcUukc4gAUQZCZ107a30M6Es17y1MeRmDPXlNw7Lko0hj77pL+XULAj IFJnrlWHjLXuebF9yAcdJqml+Iip4D+CELfO6azc3A== X-Google-Smtp-Source: ALg8bN5+pS8eW/yS6a00NaplLOBYeLdV3x1VEc/k1nUz2JEyevYkKAEi/d+KidHeDckUxIQFhCmn3HtWklXw/sPn1XE= X-Received: by 2002:a17:906:3e48:: with SMTP id t8mr37643845eji.149.1549281720547; Mon, 04 Feb 2019 04:02:00 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Al Cutter Date: Mon, 4 Feb 2019 12:01:46 +0000 Message-ID: To: =?UTF-8?B?VsOhY2xhdiBKaXJvdnNrw70=?= Cc: Trans Content-Type: multipart/alternative; boundary="0000000000009cbfe605811042c8" Archived-At: Subject: Re: [Trans] Add get_entries_max_limit attribute to get-sth request X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2019 12:02:10 -0000 --0000000000009cbfe605811042c8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Vaclav, I think there might be other ways of achieving what you're after. On Mon, 4 Feb 2019, 10:19 V=C3=A1clav Jirovsk=C3=BD, wrote: > Hello all, > > I would like to propose modification Retrieve Latest Signed Tree Head sec= tion > of RFC6962 - adding new attribute *get_entries_max_limit.* > > Reason for this change - 4.6 section actual version: > > * Logs MAY restrict the number of entries that can be retrieved per > "get-entries" request. If a client requests more than the permitted > number of entries, the log SHALL return the maximum number of entries > permissible. These entries SHALL be sequential beginning with the > entry specified by "start". > * > > > If you want to download all entries from CT server, you don't what number > of entries will server return to you by request - so you have to process, > count real number of returned entries and after that, you can do another > request. This is not efficient, you could do these request in parallel, i= f > you would have garanteed number of returned entries. > Perhaps you could call get-sth to learn the current tree size, then divide the range from what you currently have to the log's actual tree size into N subranges, start N workers each repeatedly calling get-entries always with start=3Dfirst entry they don't yet have for their subrange, and end=3Dlimit= of their allocated subrange until they have fetched all of their allocated entries? That seems like it might give you the parallelism you're after? > *Proposed modification:* > > > 4.3 . Retrieve Latest S= igned Tree Head > > GET https:///ct/v1/get-sth > No inputs. > > Outputs: > > tree_size: The size of the tree, in entries, in decimal. > timestamp: The timestamp, in decimal. > sha256_root_hash: The Merkle Tree Hash of the tree, in base64. > > * get_entries_max_limit: Maximum entries count provided by server ge= t-entries method.* > > tree_head_signature: A TreeHeadSignature for the above data. > > > 4.6 . Retrieve Entries = from Log > > GET https:///ct/v1/get-entries > > > Inputs: > start: 0-based index of first entry to retrieve, in decimal. > end: 0-based index of last entry to retrieve, in decimal. > > > ..... > > > Logs MAY restrict the number of entries that can be retrieved per > "get-entries" request. *If a client requests more than the permitted > number of entries ("get_entries_max_limit" output of "get-sth" request= ),* > > * the log SHALL return the maximum number of entries > permissible. If a client requests less or equal than the permitted > number of entries ("get_entries_max_limit" output of "get-sth" request= ), > the log MUST return the maximum number of entries permissible. * > These entries SHALL be sequential beginning with the > > entry specified by "start". > > It seems like you're optimising for a very specific use case - if I just want to inspect one entry (e.g. a monitor tells me "hey, there's a cert for your domain at entry X) I might have to download 1000s of certs just to fetch the one I'm interested in? Also, what happens when I just want to request the last few entries from the tree? (Perhaps there's a typo in your proposal?) Just because I happen to have an STH with a given "get_entries_max_limit" it doesn't mean that the log didn't change that limit between when the STH was created and when I make a request so I'd have to have logic to cope anyway - log operators may wish to adjust this limit dynamically/from time to time in order to react to usage patterns or resource consumption/availability etc. Cheers, Al. > > Best, > > Vaclav Jirovsky > > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > --0000000000009cbfe605811042c8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Vaclav,

I think there might be other ways of achieving what you're af= ter.

On Mon, 4 Feb 2019, 10:19 V=C3=A1clav Jirovsk=C3=BD, <vaclav.jirovsky@gmail.com>= ; wrote:
Hello all,=C2=A0

I w= ould like to propose modification=C2=A0Retrieve Latest Signed Tree Head section of=C2=A0RFC6962=C2=A0- adding=C2=A0new attribute=C2=A0get_entries_max_limit.<= /div>

Reason for this change - 4.6 section actual= version:
 Logs MAY restrict the number of entries that can be =
retrieved per
   "get-entries" request.  If a client requests more than the per=
mitted
   number of entries, the log SHALL return the maximum number of entries
   permissible.  These entries SHALL be sequential beginning with the
   entry specified by "start".

If you want to download all entries fro= m CT server, you don't what number of entries will server return to you= by request - so you have to process, count real number of returned=C2=A0en= tries and after that, you can do another request. This is not efficient, yo= u could do these request in parallel, if you would have garanteed number of= returned entries.

Perhaps you could call get-sth to learn the= current tree size, then divide the range from what you currently have to t= he log's actual tree size into N subranges, start N workers each repeat= edly calling get-entries always with start=3Dfirst entry they don't yet= have for their subrange, and end=3Dlimit of their allocated subrange until= they have fetched all of their allocated entries?

That seems like it might give y= ou the parallelism you're after?



Proposed modification:


4.3.  Retrieve Latest Signed Tree Head


GET https://<log server>/ct/v1/get-sth
No inputs.

Outputs:
      tree_size:=
  The size of the tree, in entries, in decimal.
      timestamp:  The timestamp, in decimal.
      sha256_root_hash:  The Merkle Tree Hash of the tree, in base64.
=

<=
pre class=3D"m_-7912409933788908707gmail-newpage" style=3D"font-size:13.333=
3px;margin-top:0px;margin-bottom:0px;break-before:page">      get_entrie=
s_max_limit: Maximum entries count provided by server get-entries method.

      tree_head_signature:  A TreeHeadSignature for the above data.


4.6.  Retrieve Entries from Log


GET https://&l=
t;log server>/ct/v1/get-entries

Inputs:
      start:  0-based index of first entry to retrieve, in decimal.
      end:  0-based index of last entry to retrieve, in decimal.
=

.....

   Logs MAY rest=
rict the number of entries that can be retrieved per
   "get-entries" request.  If a client requests more than the =
permitted
   number of entries ("get_entries_max_limit" output of "get=
-sth" request),
   the log SHALL return the maximum number of entries
   permissible. If a client requests less or equal than the permitted=20
   number of entries ("get_entries_max_limit" output of "get=
-sth" request),
   the log MUST return the maximum number of entries permissible. 
   These entries SHALL be sequential beginning with the
   entry specified by "=
start".

It seems lik=
e you're optimising for a very specific use case - if I just want to in=
spect one entry (e.g. a monitor tells me "hey, there's a cert for =
your domain at entry X) I might have to download 1000s of certs just to fet=
ch the one I'm interested in? Also, what happens when I just want to re=
quest the last few entries from the tree?
(Perhaps t=
here's a typo in your proposal?)

Just because I happen to have an STH with a given "get_en=
tries_max_limit" it doesn't mean that the log didn't change th=
at limit between when the STH was created and when I make a request so I=
9;d have to have logic to cope anyway - log operators may wish to adjust th=
is limit dynamically/from time to time in order to react to usage patterns =
or resource consumption/availability etc.

=

Cheers,
Al.


<=
div dir=3D"ltr">


Best=
,
Vaclav Jiro=
vsky


_______________________________________________

Trans mailing list

Tran=
s@ietf.org

https://www.ietf.org/mailman/listinfo/trans




--0000000000009cbfe605811042c8--


From nobody Mon Feb  4 04:48:59 2019
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1F261294D0 for ; Mon,  4 Feb 2019 04:48:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.02
X-Spam-Level: 
X-Spam-Status: No, score=-1.02 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, FROM_EXCESS_BASE64=0.979, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 3v-NsZc3VtoU for ; Mon,  4 Feb 2019 04:48:55 -0800 (PST)
Received: from mail-ot1-x32b.google.com (mail-ot1-x32b.google.com [IPv6:2607:f8b0:4864:20::32b]) (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 359F512896A for ; Mon,  4 Feb 2019 04:48:55 -0800 (PST)
Received: by mail-ot1-x32b.google.com with SMTP id w25so12641484otm.13 for ; Mon, 04 Feb 2019 04:48:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9yD5nXcjgbVMvhddtt1XWcJGhM/rg1I52h8syx0pGKE=; b=f6fGC4nlgy0L2L0kKQckmlobZDxqIsNownvSFNQ9aXrklv0OPcHNFFoKEgFarcolbx zbEKjGkcRUkqpFZwfAQ3RLF4JboKJ8r8oQVuYghFep0Ed9Ipp7zcRf2xZd5VbS6CfFuN V79eMrI5SWMX1bfCxAaVajaMBN8ZShj54qNab1mhDR3PiJtikXgH8wuRg9CSO4EnsYlS 5MQT3N8dcHwRMRoP2I24dV4rKW2UgZUwSyhh2GRA1aEpSFljz1xQNUGzBTYS+xliHSHU yUj+HOjJV71Llfg8/MMBTVRQHWgytJg1c0/WRTB38xAgXA9MhPFtMY8XJXRy6/LjnWDL Knyw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=9yD5nXcjgbVMvhddtt1XWcJGhM/rg1I52h8syx0pGKE=; b=EQG4968XlAXWp/Tj20DvPjGmx90f0Ljam9lmxH5Elm6UDDMi840l0WWce/vfeYbnwq i2a1SkrnqfBtZWZEutyCm/2Zh/T5FoUePdLb1csK03KhbDluUEtGNdPh98VJkSEmeoWl V8rlS7XC9RUkhSrMGM5TlpruRSarTP23JrXA+82bXCLrVy9WlArG4cNYUSrJkMfwbQng vnmKZYQuAW8eqIQfL+eHvuTGx2ML4AwY8qJ7r12C965WdiQJXT69PMfe/W5wU1OcZmcZ w3SyD+nEfhMG1MHHpCuUILM+CLJtDVO41jhB/Wwdycpf+87H+QbnsuvEkPp3Qz0DGqS2 KeSw==
X-Gm-Message-State: AHQUAubPtWr/uAiLN1cwo36gdiDu22UwCW50HUsmMHhcE7w+USbP9gtg r/0zKWYxtvG5BQKtXoIfe3IhEVkQkGG6qqVZqwYWXdjX
X-Google-Smtp-Source: ALg8bN5xvtYHgNhKvEqVWld//iRJR5vgeJSUwqDvrBUkhGvfelWl8k7JsdOQgGYoGBE5/IZOr4xDpxA8KEZwG7jz82c=
X-Received: by 2002:aca:3d4:: with SMTP id 203mr24960542oid.315.1549284534092;  Mon, 04 Feb 2019 04:48:54 -0800 (PST)
MIME-Version: 1.0
References:  
In-Reply-To: 
From: =?UTF-8?B?VsOhY2xhdiBKaXJvdnNrw70=?= 
Date: Mon, 4 Feb 2019 13:48:42 +0100
Message-ID: 
To: Al Cutter 
Cc: Trans 
Content-Type: multipart/alternative; boundary="0000000000004f8ac4058110ea79"
Archived-At: 
Subject: Re: [Trans] Add get_entries_max_limit attribute to get-sth request
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Public Notary Transparency working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 04 Feb 2019 12:48:58 -0000

--0000000000004f8ac4058110ea79
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hello Al,

thanks for your response.

*"Perhaps you could call get-sth to learn the current tree size, then
divide the range from what you currently have to the log's actual tree size
into N subranges, start N workers each repeatedly calling get-entries
always with start=3Dfirst entry they don't yet have for their subrange, and
end=3Dlimit of their allocated subrange until they have fetched all of thei=
r
allocated entries?"*

*This solution still doesn't solve the problem - I don't know, what is good
constant value (treesize/value) to split to N subranges (for current server
- one server returns 1024, google's mostly 256). So I would have to perform
some "test entry downloads", to recognize what is the best limit to
download entries: , and in case that server just
throttled (reduced) entries count, I would have to perform calling
get-entries in missing areas (as you describe).*


*"It seems like you're optimising for a very specific use case - if I just
want to inspect one entry (e.g. a monitor tells me "hey, there's a cert for
your domain at entry X) I might have to download 1000s of certs just to
fetch the one I'm interested in? Also, what happens when I just want to
request the last few entries from the tree?*
*(Perhaps there's a typo in your proposal?)*

*It's optimalization for (I think common) use case - I want to have my app
to be in sync with all log servers and process all entries. And some
servers (for example Google Argon 2019) are so quick into pushing new
entries, but output is sometimes limited to smaller number than increase (i
mean from previous run, where I called get-entries and process them). If I
would have constant split value - I would be able to split sth to N
subranges and download and process it in parallel much easier.*

*You are right, there is **typo, it should be:*

>  Logs MAY restrict the number of entries that can be retrieved per
>    "get-entries" request.  If a client requests more than the permitted
>    number of entries ("get_entries_max_limit" output of "get-sth" request=
),
>
>    the log SHALL return the maximum number of entries
>    permissible. If a client requests less or equal than the permitted
>    number of entries ("get_entries_max_limit" output of "get-sth" request=
),
>    the log MUST return the *requested *number of entries permissible.
>    These entries SHALL be sequential beginning with the
>
>    entry specified by "start".
>
>


*Just because I happen to have an STH with a given "get_entries_max_limit"
it doesn't mean that the log didn't change that limit between when the STH
was created and when I make a request so I'd have to have logic to cope
anyway - log operators may wish to adjust this limit dynamically/from time
to time in order to react to usage patterns or resource
consumption/availability etc."*

*I understand your arguments - I don't have solution at the moment, but I
think this would be possible to solve.*

Best,
Vaclav



On Mon, Feb 4, 2019 at 1:02 PM Al Cutter  wrote:

> Hi Vaclav,
>
> I think there might be other ways of achieving what you're after.
>
> On Mon, 4 Feb 2019, 10:19 V=C3=A1clav Jirovsk=C3=BD, 
> wrote:
>
>> Hello all,
>>
>> I would like to propose modification Retrieve Latest Signed Tree Head se=
ction
>> of RFC6962 - adding new attribute *get_entries_max_limit.*
>>
>> Reason for this change - 4.6 section actual version:
>>
>> * Logs MAY restrict the number of entries that can be retrieved per
>>    "get-entries" request.  If a client requests more than the permitted
>>    number of entries, the log SHALL return the maximum number of entries
>>    permissible.  These entries SHALL be sequential beginning with the
>>    entry specified by "start".
>> *
>>
>>
>> If you want to download all entries from CT server, you don't what numbe=
r
>> of entries will server return to you by request - so you have to process=
,
>> count real number of returned entries and after that, you can do another
>> request. This is not efficient, you could do these request in parallel, =
if
>> you would have garanteed number of returned entries.
>>
>
> Perhaps you could call get-sth to learn the current tree size, then divid=
e
> the range from what you currently have to the log's actual tree size into=
 N
> subranges, start N workers each repeatedly calling get-entries always wit=
h
> start=3Dfirst entry they don't yet have for their subrange, and end=3Dlim=
it of
> their allocated subrange until they have fetched all of their allocated
> entries?
>
> That seems like it might give you the parallelism you're after?
>
>
>
>> *Proposed modification:*
>>
>>
>> 4.3 .  Retrieve Latest =
Signed Tree Head
>>
>> GET https:///ct/v1/get-sth
>> No inputs.
>>
>> Outputs:
>>
>>       tree_size:  The size of the tree, in entries, in decimal.
>>       timestamp:  The timestamp, in decimal.
>>       sha256_root_hash:  The Merkle Tree Hash of the tree, in base64.
>>
>> *      get_entries_max_limit: Maximum entries count provided by server g=
et-entries method.*
>>
>> tree_head_signature: A TreeHeadSignature for the above data.
>>
>>
>> 4.6 .  Retrieve Entries=
 from Log
>>
>> GET https:///ct/v1/get-entries
>>
>>
>> Inputs:
>>       start:  0-based index of first entry to retrieve, in decimal.
>>       end:  0-based index of last entry to retrieve, in decimal.
>>
>>
>> .....
>>
>>
>>    Logs MAY restrict the number of entries that can be retrieved per
>>    "get-entries" request.  *If a client requests more than the permitted
>>    number of entries ("get_entries_max_limit" output of "get-sth" reques=
t),*
>>
>> *   the log SHALL return the maximum number of entries
>>    permissible. If a client requests less or equal than the permitted
>>    number of entries ("get_entries_max_limit" output of "get-sth" reques=
t),
>>    the log MUST return the maximum number of entries permissible. *
>>    These entries SHALL be sequential beginning with the
>>
>>    entry specified by "start".
>>
>>
> It seems like you're optimising for a very specific use case - if I just
> want to inspect one entry (e.g. a monitor tells me "hey, there's a cert f=
or
> your domain at entry X) I might have to download 1000s of certs just to
> fetch the one I'm interested in? Also, what happens when I just want to
> request the last few entries from the tree?
> (Perhaps there's a typo in your proposal?)
>
> Just because I happen to have an STH with a given "get_entries_max_limit"
> it doesn't mean that the log didn't change that limit between when the ST=
H
> was created and when I make a request so I'd have to have logic to cope
> anyway - log operators may wish to adjust this limit dynamically/from tim=
e
> to time in order to react to usage patterns or resource
> consumption/availability etc.
>
> Cheers,
> Al.
>
>
>
>>
>> Best,
>>
>> Vaclav Jirovsky
>>
>>
>> _______________________________________________
>> Trans mailing list
>> Trans@ietf.org
>> https://www.ietf.org/mailman/listinfo/trans
>>
>

--=20
V=C3=A1clav Jirovsk=C3=BD
email: vaclav.jirovsky@gmail.com

--0000000000004f8ac4058110ea79
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable



Hello A=
l,

thanks for your response.

"Perhaps you could call get-sth to l=
earn the current tree size, then divide the range from what you currently h=
ave to the log's actual tree size into N subranges, start N workers eac=
h repeatedly calling get-entries always with start=3Dfirst entry they don&#=
39;t yet have for their subrange, and end=3Dlimit of their allocated subran=
ge until they have fetched all of their allocated entries?"

This solution still doesn't solve the problem -=
 I don't know, what is good constant value (treesize/value) to split to=
 N subranges (for current server - one server returns 1024, google's mo=
stly 256). So I would have to perform some "test entry downloads"=
, to recognize what is the best limit to download entries: <start, start=
+limit>, and in case that server just throttled (reduced) entries count,=
 I would have to perform calling get-entries in missing areas (as you descr=
ibe).


&quo=
t;It seems like you're optimising for a very specific use case - if I j=
ust want to inspect one entry (e.g. a monitor tells me "hey, there'=
;s a cert for your domain at entry X) I might have to download 1000s of cer=
ts just to fetch the one I'm interested in? Also, what happens when I j=
ust want to request the last few entries from the tree?
(Perhaps there's a typo in your proposal?)

It's optimalization for (I t=
hink common) use case - I want to have my app to be in sync with all log se=
rvers and process all entries. And some servers (for example Google Argon 2=
019) are so quick into pushing new entries, but output is sometimes limited=
 to smaller number than increase (i mean from previous run, where I called =
get-entries and process them). If I would have constant split value - I wou=
ld be able to split sth to N subranges and download and process it in paral=
lel much easier.

You are =
right, there is=C2=A0typo, it should be:
=

 Logs MAY restrict the number of entries that can be retrieved p=
er
   "get-entries" request.  If a client requests more than the per=
mitted
   number of entries ("get_entries_max_limit" output of "get=
-sth" request),
   the log SHALL return the maximum nu=
mber of entries
   permissible. If a client requests less or equal than the permitted=20
   number of entries ("get_entries_max_limit" output of "get=
-sth" request),
   the log MUST return the requested number of entries permissible.<=
b> 
   These entries SHALL be sequential beginning with the
   entry specified by "start".
=


Just because I happen to have an STH with a giv=
en "get_entries_max_limit" it doesn't mean that the log didn&=
#39;t change that limit between when the STH was created and when I make a =
request so I'd have to have logic to cope anyway - log operators may wi=
sh to adjust this limit dynamically/from time to time in order to react to =
usage patterns or resource consumption/availability etc."

I understand your arguments -=
 I don't have solution at the moment, but I think this would be possibl=
e to solve.

Best,
Vaclav
<=
br>


On Mon, Feb 4, 2019 at 1:02 PM Al=
 Cutter <al@google.com> wrote:
Hi Vaclav,

I think=
 there might be other ways of achieving what you're after.

On=
 Mon, 4 Feb 2019, 10:19 V=C3=A1clav Jirovsk=C3=BD, <vaclav.jirovsky@gmail.com>=
; wrote:
Hello all,=C2=A0
=

I would like to propose modification=C2=A0Retrieve Latest Signed Tree H=
ead section of=C2=A0<=
/span>RFC6962=C2=A0- adding=C2=A0new attribute=C2=A0get_entrie=
s_max_limit.

Reason for this change - 4=
.6 section actual version:
 Logs MA=
Y restrict the number of entries that can be retrieved per
   "get-entries" request.  If a client requests more than the per=
mitted
   number of entries, the log SHALL return the maximum number of entries
   permissible.  These entries SHALL be sequential beginning with the
   entry specified by "start".


If you want to download all entries fro=
m CT server, you don't what number of entries will server return to you=
 by request - so you have to process, count real number of returned=C2=A0en=
tries and after that, you can do another request. This is not efficient, yo=
u could do these request in parallel, if you would have garanteed number of=
 returned entries.

Perhaps you could call get-sth to learn the=
 current tree size, then divide the range from what you currently have to t=
he log's actual tree size into N subranges, start N workers each repeat=
edly calling get-entries always with start=3Dfirst entry they don't yet=
 have for their subrange, and end=3Dlimit of their allocated subrange until=
 they have fetched all of their allocated entries?

That seems like it might give y=
ou the parallelism you're after?



Proposed modification:


4.3.  Retrieve Latest Signed Tree Head


GET https://<log server>/ct/v1/get-sth
No inputs.

Outputs:
      t=
ree_size:  The size of the tree, in entries, in decimal.
      timestamp:  The timestamp, in decimal.
      sha256_root_hash:  The Merkle Tree Hash of the tree, in base64.
=

      get_entries_max_limit: Maximu=
m entries count provided by server get-entries method.

      tree_head_signature:  A TreeHeadSignature for the above data.




4.6.  R=
etrieve Entries from Log


GET https://<log server>/ct/v1/get-entries
=

Inputs:
      start:  0-based index of first entry to retrieve, in decimal.
      end:  0-based index of last entry to retrieve, in decimal.
=


..=
...

   Logs MAY restrict the number of entries that can b=
e retrieved per
   "get-entries" request.  If a client requests more than the =
permitted
   number of entries ("get_entries_max_limit" output of "get=
-sth" request),
   the log SHALL return the maxi=
mum number of entries
   permissible. If a client requests less or equal than the permitted=20
   number of entries ("get_entries_max_limit" output of "get=
-sth" request),
   the log MUST return the maximum number of entries permissible. 
   These entries SHALL be sequential beginning with the
   entry specified by "start".
=


It seems like you're optimi=
sing for a very specific use case - if I just want to inspect one entry (e.=
g. a monitor tells me "hey, there's a cert for your domain at entr=
y X) I might have to download 1000s of certs just to fetch the one I'm =
interested in? Also, what happens when I just want to request the last few =
entries from the tree?
(Perhaps there's a typo i=
n your proposal?)

Just b=
ecause I happen to have an STH with a given "get_entries_max_limit&quo=
t; it doesn't mean that the log didn't change that limit between wh=
en the STH was created and when I make a request so I'd have to have lo=
gic to cope anyway - log operators may wish to adjust this limit dynamicall=
y/from time to time in order to react to usage patterns or resource consump=
tion/availability etc.

C=
heers,
Al.


<=
div dir=3D"ltr">


Best,
Vaclav Jirovsky
=



_______________________________________________

Trans mailing list

Tran=
s@ietf.org

https://www.ietf.org/mailman/listinfo/trans




-- 
V=C3=A1clav Jirovsk=C3=BD
email: vaclav.jirovsky@gmail.co=
m



--0000000000004f8ac4058110ea79--


From nobody Mon Feb  4 05:41:55 2019
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E37F128CF3 for ; Mon,  4 Feb 2019 05:41:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.142
X-Spam-Level: 
X-Spam-Status: No, score=-17.142 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
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 3LNTCnJgvxU4 for ; Mon,  4 Feb 2019 05:41:50 -0800 (PST)
Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [IPv6:2a00:1450:4864:20::52f]) (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 188E3130E0A for ; Mon,  4 Feb 2019 05:41:50 -0800 (PST)
Received: by mail-ed1-x52f.google.com with SMTP id f23so11298650edb.3 for ; Mon, 04 Feb 2019 05:41:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=WMrfVcKq/PYTL2p8ksCHiDaDoAWbxoEadosoVqW3VZM=; b=kWyEGmIVVSLzYkuFk6suNp4zNdlLFAnXzg58OXjLwrxukmihYOBrK/6cW6zU28lRXO jEfUGnoyBO0largwSINFsiMGEpvH/Rjmcy9noEiq21PBd0vauPm4gv/khI10LtfQqrM0 je5YB1EXaRDyLAjaLelw7VFRnr3iPw+pD2v3BITeQ9ujiOBvopMOMGIn7WCqbc4wwcZ6 PMlJDQY145LVmGn6c6uCI+j3ZtELBLeYRK3qaiq/UaRuynz2+lEmocxlivKUFAkrqqEG XkmPzK8Ti7xZbmREdjRxjDEVQUj2+Jrs6NIzYc854zRgCNw8WqXcoikmoI7p9zSHX3fZ 0o8w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=WMrfVcKq/PYTL2p8ksCHiDaDoAWbxoEadosoVqW3VZM=; b=LnrQS+SmYH8Z8iIFm3n/AdRXw6OCLVkQF6g0MwpomJCxKicbbx5l42gPX/NsJTZcJN 72c++sR68bvd52TPgU2p+80an5PCRsvi8eVc2O+KgNVfSU7P8gDnAQcEuss45Jhv4Ngi UubH/Mr8wPPLKWwavjuwvfbhpM8UP3ccu3qOL1JmxlWn+xhgovd4P6H/0QbW3Q5SLdx7 hidyuBpduEtsz/vbm34Vw6gHYtBcNeHtGN1pp/yGtZApREg0pCDYKWMjg+XPlnoRnaYi 977EL/Ra0YQPn4nhauft3+KLSsfLWUflJDhJpfT8jHci8RrYdTnfOqmmioeqEJGLha1K anqQ==
X-Gm-Message-State: AJcUukf9nJWsrNLgacRUqT3G1j+O7u0pRUPRxi30T1F6TOgF85YtqIJO zxht2nznEBFaX4wHw+4x3bwaAUhWo8nzHkVLTEJPFQ==
X-Google-Smtp-Source: ALg8bN4qN3hqKkG7onSKdJdLT15gvxBKur/P5ELAFSvTDoeDb5RCpQwl9dNSFsuo6RFOEMvCTacHOJG8NM+klg8/bHo=
X-Received: by 2002:a50:c252:: with SMTP id t18mr49982801edf.57.1549287708279;  Mon, 04 Feb 2019 05:41:48 -0800 (PST)
MIME-Version: 1.0
References:   
In-Reply-To: 
From: Al Cutter 
Date: Mon, 4 Feb 2019 13:40:49 +0000
Message-ID: 
To: =?UTF-8?B?VsOhY2xhdiBKaXJvdnNrw70=?= 
Cc: Trans 
Content-Type: multipart/alternative; boundary="00000000000082404a058111a7e5"
Archived-At: 
Subject: Re: [Trans] Add get_entries_max_limit attribute to get-sth request
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Public Notary Transparency working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 04 Feb 2019 13:41:54 -0000

--00000000000082404a058111a7e5
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi V=C3=A1clav,

On Mon, Feb 4, 2019 at 12:48 PM V=C3=A1clav Jirovsk=C3=BD 
wrote:

> Hello Al,
>
> thanks for your response.
>
> *"Perhaps you could call get-sth to learn the current tree size, then
> divide the range from what you currently have to the log's actual tree si=
ze
> into N subranges, start N workers each repeatedly calling get-entries
> always with start=3Dfirst entry they don't yet have for their subrange, a=
nd
> end=3Dlimit of their allocated subrange until they have fetched all of th=
eir
> allocated entries?"*
>
> *This solution still doesn't solve the problem - I don't know, what is
> good constant value (treesize/value) to split to N subranges (for current
> server - one server returns 1024, google's mostly 256). So I would have t=
o
> perform some "test entry downloads", to recognize what is the best limit =
to
> download entries: , and in case that server just
> throttled (reduced) entries count, I would have to perform calling
> get-entries in missing areas (as you describe).*
>

This is essentially the approach we use for mirroring/ingesting logs, it
seems to work well enough for our purposes at least.

IRL there are other nuances to consider too - e.g. many log operators will
act to protect their logs from high levels of traffic, so you may find that
the throughput you can actually achieve is not entirely in your hands
anyway.


>
> *"It seems like you're optimising for a very specific use case - if I jus=
t
> want to inspect one entry (e.g. a monitor tells me "hey, there's a cert f=
or
> your domain at entry X) I might have to download 1000s of certs just to
> fetch the one I'm interested in? Also, what happens when I just want to
> request the last few entries from the tree?*
> *(Perhaps there's a typo in your proposal?)*
>
> *It's optimalization for (I think common) use case - I want to have my ap=
p
> to be in sync with all log servers and process all entries. And some
> servers (for example Google Argon 2019) are so quick into pushing new
> entries, but output is sometimes limited to smaller number than increase =
(i
> mean from previous run, where I called get-entries and process them). If =
I
> would have constant split value - I would be able to split sth to N
> subranges and download and process it in parallel much easier.*
>
> *You are right, there is **typo, it should be:*
>
>>  Logs MAY restrict the number of entries that can be retrieved per
>>    "get-entries" request.  If a client requests more than the permitted
>>    number of entries ("get_entries_max_limit" output of "get-sth" reques=
t),
>>
>>    the log SHALL return the maximum number of entries
>>    permissible. If a client requests less or equal than the permitted
>>    number of entries ("get_entries_max_limit" output of "get-sth" reques=
t),
>>    the log MUST return the *requested *number of entries permissible.
>>    These entries SHALL be sequential beginning with the
>>
>>    entry specified by "start".
>>
>>
>
>
> *Just because I happen to have an STH with a given "get_entries_max_limit=
"
> it doesn't mean that the log didn't change that limit between when the ST=
H
> was created and when I make a request so I'd have to have logic to cope
> anyway - log operators may wish to adjust this limit dynamically/from tim=
e
> to time in order to react to usage patterns or resource
> consumption/availability etc."*
>
> *I understand your arguments - I don't have solution at the moment, but I
> think this would be possible to solve.*
>
> Best,
> Vaclav
>
>
>
> On Mon, Feb 4, 2019 at 1:02 PM Al Cutter  wrote:
>
>> Hi Vaclav,
>>
>> I think there might be other ways of achieving what you're after.
>>
>> On Mon, 4 Feb 2019, 10:19 V=C3=A1clav Jirovsk=C3=BD, 
>> wrote:
>>
>>> Hello all,
>>>
>>> I would like to propose modification Retrieve Latest Signed Tree Head s=
ection
>>> of RFC6962 - adding new attribute *get_entries_max_limit.*
>>>
>>> Reason for this change - 4.6 section actual version:
>>>
>>> * Logs MAY restrict the number of entries that can be retrieved per
>>>    "get-entries" request.  If a client requests more than the permitted
>>>    number of entries, the log SHALL return the maximum number of entrie=
s
>>>    permissible.  These entries SHALL be sequential beginning with the
>>>    entry specified by "start".
>>> *
>>>
>>>
>>> If you want to download all entries from CT server, you don't what
>>> number of entries will server return to you by request - so you have to
>>> process, count real number of returned entries and after that, you can =
do
>>> another request. This is not efficient, you could do these request in
>>> parallel, if you would have garanteed number of returned entries.
>>>
>>
>> Perhaps you could call get-sth to learn the current tree size, then
>> divide the range from what you currently have to the log's actual tree s=
ize
>> into N subranges, start N workers each repeatedly calling get-entries
>> always with start=3Dfirst entry they don't yet have for their subrange, =
and
>> end=3Dlimit of their allocated subrange until they have fetched all of t=
heir
>> allocated entries?
>>
>> That seems like it might give you the parallelism you're after?
>>
>>
>>
>>> *Proposed modification:*
>>>
>>>
>>> 4.3 .  Retrieve Latest=
 Signed Tree Head
>>>
>>> GET https:///ct/v1/get-sth
>>> No inputs.
>>>
>>> Outputs:
>>>
>>>       tree_size:  The size of the tree, in entries, in decimal.
>>>       timestamp:  The timestamp, in decimal.
>>>       sha256_root_hash:  The Merkle Tree Hash of the tree, in base64.
>>>
>>> *      get_entries_max_limit: Maximum entries count provided by server =
get-entries method.*
>>>
>>> tree_head_signature: A TreeHeadSignature for the above data.
>>>
>>>
>>> 4.6 .  Retrieve Entrie=
s from Log
>>>
>>> GET https:///ct/v1/get-entries
>>>
>>>
>>> Inputs:
>>>       start:  0-based index of first entry to retrieve, in decimal.
>>>       end:  0-based index of last entry to retrieve, in decimal.
>>>
>>>
>>> .....
>>>
>>>
>>>    Logs MAY restrict the number of entries that can be retrieved per
>>>    "get-entries" request.  *If a client requests more than the permitte=
d
>>>    number of entries ("get_entries_max_limit" output of "get-sth" reque=
st),*
>>>
>>> *   the log SHALL return the maximum number of entries
>>>    permissible. If a client requests less or equal than the permitted
>>>    number of entries ("get_entries_max_limit" output of "get-sth" reque=
st),
>>>    the log MUST return the maximum number of entries permissible. *
>>>    These entries SHALL be sequential beginning with the
>>>
>>>    entry specified by "start".
>>>
>>>
>> It seems like you're optimising for a very specific use case - if I just
>> want to inspect one entry (e.g. a monitor tells me "hey, there's a cert =
for
>> your domain at entry X) I might have to download 1000s of certs just to
>> fetch the one I'm interested in? Also, what happens when I just want to
>> request the last few entries from the tree?
>> (Perhaps there's a typo in your proposal?)
>>
>> Just because I happen to have an STH with a given "get_entries_max_limit=
"
>> it doesn't mean that the log didn't change that limit between when the S=
TH
>> was created and when I make a request so I'd have to have logic to cope
>> anyway - log operators may wish to adjust this limit dynamically/from ti=
me
>> to time in order to react to usage patterns or resource
>> consumption/availability etc.
>>
>> Cheers,
>> Al.
>>
>>
>>
>>>
>>> Best,
>>>
>>> Vaclav Jirovsky
>>>
>>>
>>> _______________________________________________
>>> Trans mailing list
>>> Trans@ietf.org
>>> https://www.ietf.org/mailman/listinfo/trans
>>>
>>
>
> --
> V=C3=A1clav Jirovsk=C3=BD
> email: vaclav.jirovsky@gmail.com
>
>

--00000000000082404a058111a7e5
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi V=C3=A1clav,

<=
div dir=3D"ltr" class=3D"gmail_attr">On Mon, Feb 4, 2019 at 12:48 PM V=C3=
=A1clav Jirovsk=C3=BD <vacl=
av.jirovsky@gmail.com> wrote:
Hello Al,

thanks for your response.
<=
div>
"Perhaps you co=
uld call get-sth to learn the current tree size, then divide the range from=
 what you currently have to the log's actual tree size into N subranges=
, start N workers each repeatedly calling get-entries always with start=3Df=
irst entry they don't yet have for their subrange, and end=3Dlimit of t=
heir allocated subrange until they have fetched all of their allocated entr=
ies?"

This solution still doesn'=
t solve the problem - I don't know, what is good constant value (treesi=
ze/value) to split to N subranges (for current server - one server returns =
1024, google's mostly 256). So I would have to perform some "test =
entry downloads", to recognize what is the best limit to download entr=
ies: <start, start+limit>, and in case that server just throttled (re=
duced) entries count, I would have to perform calling get-entries in missin=
g areas (as you describe).

This is essentially the approach we use for mirroring/ing=
esting logs, it seems to work well enough for our purposes at least.
<=
div>
IRL there are other nuances to consider too - e.g. many =
log operators will act to protect their logs from high levels of traffic, s=
o you may find that the throughput you can actually achieve is not entirely=
 in your hands anyway.



"It=
 seems like you're optimising for a very specific use case - if I just =
want to inspect one entry (e.g. a monitor tells me "hey, there's a=
 cert for your domain at entry X) I might have to download 1000s of certs j=
ust to fetch the one I'm interested in? Also, what happens when I just =
want to request the last few entries from the tree?
(Perhaps there's a typo in your proposal?)

It's optimalization for (I think c=
ommon) use case - I want to have my app to be in sync with all log servers =
and process all entries. And some servers (for example Google Argon 2019) a=
re so quick into pushing new entries, but output is sometimes limited to sm=
aller number than increase (i mean from previous run, where I called get-en=
tries and process them). If I would have constant split value - I would be =
able to split sth to N subranges and download and process it in parallel mu=
ch easier.

You are right,=
 there is=C2=A0typo, it should be:
<=
div dir=3D"ltr">
 Logs MAY rest=
rict the number of entries that can be retrieved per
   "get-entries" request.  If a client requests more than the per=
mitted
   number of entries ("get_entries_max_limit" output of "get=
-sth" request),
   the log=
 SHALL return the maximum number of entries
   permissible. If a client requests less or equal than the permitted=20
   number of entries ("get_entries_max_limit" output of "get=
-sth" request),
   the log MUST return the requested number of entries permissible.<=
b> 
   These entries SHALL be sequential beginning with the
   entry specified by "start".
=

=



=


Just because I happen to have an STH wi=
th a given "get_entries_max_limit" it doesn't mean that the l=
og didn't change that limit between when the STH was created and when I=
 make a request so I'd have to have logic to cope anyway - log operator=
s may wish to adjust this limit dynamically/from time to time in order to r=
eact to usage patterns or resource consumption/availability etc."<=
/div>

I understand your arg=
uments - I don't have solution at the moment, but I think this would be=
 possible to solve.

Best,
Vaclav



On Mon, Feb 4, 2019 at 1:=
02 PM Al Cutter <al@g=
oogle.com> wrote:
Hi Vaclav,

I think there might be other ways of achieving what yo=
u're after.

On Mon, 4 Feb 2019, 10:19 V=C3=A1clav Jirovsk=C3=
=BD, <vac=
lav.jirovsky@gmail.com> wrote:
Hello all,=C2=A0

I would like to propose modifi=
cation=C2=A0Retrieve Latest Signed Tree Head section of=C2=A0RFC6962=C2=A0- adding=C2=A0ne=
w attribute=C2=A0get_entries_max_limit.

<=
div>Reason for this change - 4.6 section actual version:
 Logs MAY restrict the nu=
mber of entries that can be retrieved per
   "get-entries" request.  If a client requests more than the per=
mitted
   number of entries, the log SHALL return the maximum number of entries
   permissible.  These entries SHALL be sequential beginning with the
   entry specified by "start".


If you want to download all entries fro=
m CT server, you don't what number of entries will server return to you=
 by request - so you have to process, count real number of returned=C2=A0en=
tries and after that, you can do another request. This is not efficient, yo=
u could do these request in parallel, if you would have garanteed number of=
 returned entries.

Perhaps you could call get-sth to learn the=
 current tree size, then divide the range from what you currently have to t=
he log's actual tree size into N subranges, start N workers each repeat=
edly calling get-entries always with start=3Dfirst entry they don't yet=
 have for their subrange, and end=3Dlimit of their allocated subrange until=
 they have fetched all of their allocated entries?

That seems like it might give y=
ou the parallelism you're after?



Proposed modification:


4.3.  Retrieve Latest Signed Tree Head


GET https://<log server>/ct/v1/get-sth
No inputs.

Outputs:
      get_entries_max_limit: Maximum entries count pro=
vided by server get-entries method.

      tree_head_signature:  A TreeHeadSignature for the above data.




<=
h3 style=3D"line-height:0pt;display:inline;font-size:1em">4.6.  Retrieve Entries from Log

GET https://<log server>/ct=
/v1/get-entries

Inp=
uts:
      start:  0-based index of first entry to retrieve, in decimal.
      end:  0-based index of last entry to retrieve, in decimal.
=


.....

   Logs MAY restr=
ict the number of entries that can be retrieved per
   "get-entries" request.  If a client requests more than the =
permitted
   number of entries ("get_entries_max_limit" output of "get=
-sth" request),
   t=
he log SHALL return the maximum number of entries
   permissible. If a client requests less or equal than the permitted=20
   number of entries ("get_entries_max_limit" output of "get=
-sth" request),
   the log MUST return the maximum number of entries permissible. 
   These entries SHALL be sequential beginning with the
   entry specified by "start".
<=
pre class=3D"gmail-m_-4975664592832225315gmail-m_-4470630296089466200m_-791=
2409933788908707gmail-newpage" style=3D"font-size:13.3333px;margin-top:0px;=
margin-bottom:0px;break-before:page">

=

It seems like you're optimising for a very spec=
ific use case - if I just want to inspect one entry (e.g. a monitor tells m=
e "hey, there's a cert for your domain at entry X) I might have to=
 download 1000s of certs just to fetch the one I'm interested in? Also,=
 what happens when I just want to request the last few entries from the tre=
e?
(Perhaps there's a typo in your proposal?)

Just because I happen to h=
ave an STH with a given "get_entries_max_limit" it doesn't me=
an that the log didn't change that limit between when the STH was creat=
ed and when I make a request so I'd have to have logic to cope anyway -=
 log operators may wish to adjust this limit dynamically/from time to time =
in order to react to usage patterns or resource consumption/availability et=
c.

Cheers,
Al.


=



Best,
Vaclav Jirovsky


_______________________________________________

Trans mailing list

Tran=
s@ietf.org

https://www.ietf.org/mailman/listinfo/trans






-- 
V=C3=A1clav Jirovsk=
=C3=BD
email: vaclav.jirovsky@gmail.com




--00000000000082404a058111a7e5--


From nobody Fri Feb 22 06:41:29 2019
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B60AF12D4EA; Fri, 22 Feb 2019 06:41:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=comodoca.onmicrosoft.com
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 EQIm55je13va; Fri, 22 Feb 2019 06:41:16 -0800 (PST)
Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-eopbgr790072.outbound.protection.outlook.com [40.107.79.72]) (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 BDCC2129A87; Fri, 22 Feb 2019 06:41:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comodoca.onmicrosoft.com; s=selector1-sectigo-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=dtdpZt18ulNDdZhdWhYoiozG5U55OdMlKHJHi/8JOWo=; b=Fh1cjUzg8ypfXfdVQjmkdQZjlzohE1N60akw4XX3ZQAJzkOaNnGYmu95wBKWdnhUOHFsrXPCb7JzatbB/cHl2bhY63yiv1KjVmvmyWuw4DSstYhYlDEGxQxgkvl6x6ODzDeAbYDeVNrWpRyfU4OS+sKbb+1vkhsjyFIS3yu7Izc=
Received: from DM6PR17MB2716.namprd17.prod.outlook.com (20.178.224.155) by DM6PR17MB2236.namprd17.prod.outlook.com (20.176.92.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1643.15; Fri, 22 Feb 2019 14:41:12 +0000
Received: from DM6PR17MB2716.namprd17.prod.outlook.com ([fe80::80e1:4c3b:1fac:22b9]) by DM6PR17MB2716.namprd17.prod.outlook.com ([fe80::80e1:4c3b:1fac:22b9%6]) with mapi id 15.20.1643.014; Fri, 22 Feb 2019 14:41:12 +0000
From: Rob Stradling 
To: Eric Rescorla , Martin Thomson , Trans 
CC: "" 
Thread-Topic: [TLS] ct_compliant cached info field
Thread-Index: AQHUng4AiTlMjhjKyU+rxTv7bjD+jKWYYcaAgACOqgCAU0y3AA==
Date: Fri, 22 Feb 2019 14:41:12 +0000
Message-ID: <1f481215-9a30-dd91-7039-8e2ac5351cbe@sectigo.com>
References:  <1546236377.2848619.1621803360.25FE2839@webmail.messagingengine.com> 
In-Reply-To: 
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-clientproxiedby: LO2P265CA0175.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:a::19) To DM6PR17MB2716.namprd17.prod.outlook.com (2603:10b6:5:122::27)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=rob@sectigo.com; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [2a02:1788:4ff:1000:f68e:38ff:fe7a:a226]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: dc975829-0780-4e6d-36d2-08d698d3ca94
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:DM6PR17MB2236; 
x-ms-traffictypediagnostic: DM6PR17MB2236:
x-ms-exchange-purlcount: 3
x-microsoft-antispam-prvs: 
x-forefront-prvs: 09565527D6
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(136003)(366004)(396003)(39850400004)(376002)(189003)(199004)(81166006)(53546011)(386003)(6506007)(446003)(102836004)(99286004)(36756003)(71200400001)(31696002)(4326008)(6116002)(46003)(6436002)(305945005)(8936002)(86362001)(106356001)(476003)(68736007)(2616005)(486006)(11346002)(105586002)(186003)(6246003)(31686004)(71190400001)(6306002)(6486002)(6512007)(76176011)(2906002)(53936002)(110136005)(97736004)(7736002)(14444005)(256004)(8676002)(316002)(52116002)(478600001)(966005)(25786009)(81156014)(5660300002)(14454004)(229853002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM6PR17MB2236; H:DM6PR17MB2716.namprd17.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: sectigo.com does not designate permitted sender hosts)
x-microsoft-exchange-diagnostics: =?utf-8?B?MTtETTZQUjE3TUIyMjM2OzIzOlVMaDR6VkIyVzZ0QTBzdGFYSm0rdnlpcDVk?= =?utf-8?B?K2F0bjBjendvaVY1dG8xcVNMMUJjc3JweEYwZk85azdSY3FDd3dmU1lJMUdY?= =?utf-8?B?K3EyMndHdFdwWVpyTkVBVlBhZHhTWjJBRnRESzZlMTV5RVJ6U1pKd2gzOXhZ?= =?utf-8?B?TDRGUUdORGt2UWFhVy8vTUxpRW5zZ3lPYWZxampDcVNsSmhEV1QyTFBsalRS?= =?utf-8?B?eU5ocmlOUGJibldlRU5tY0JxSnp4RmxrM2J3bldUV1A5cGlyenYya3g3Wm5w?= =?utf-8?B?S01tTm9IVVJRQWJCc0ExQ1l0MG9XL1hndnNNZzFBNlZlMkJIa0MrWWZUbkR5?= =?utf-8?B?VEc1SDFkQWZKVERrTnIzUkswcXdoQnRhY3NLMm1iRzZ6RzlBUW9YWHZESDUv?= =?utf-8?B?ajNTNndmSmcvRkNBN0QzeEppT3c2cE0wVEw1QWl4ZytiQWdGYWl4OGRFdTZo?= =?utf-8?B?YmFjdkxwZExORVY0RWV4WTRsbzgyWFRjS3BWUjBBMHFZM2YvWE4vUWVjM0JD?= =?utf-8?B?ZndaSHlwWlNYVUdjU2xydjRyaTdBVjBBOWlmeEhwZFMrOVZQeEhueUJld1pC?= =?utf-8?B?R05KeFBkVXpucTRVWFRhcFRBT2lnTE5Zak5BcEh0Nk0xS0VHRThLRHVVZDJE?= =?utf-8?B?RXV4ZkFrOUU2SnVCNHV0QmREWGlOUS9OMnlybWkxS0pXTFJ3a2k3U0FoUDVF?= =?utf-8?B?NU5qSFZDWnB5bmNvQmVuMU9ybXIvbXVsSFFtZXVnZTBBQ3JlRHRSL2NPMVpz?= =?utf-8?B?WnBnWFNMcmQ1OCtoWlZKbU5kUTk4ZGJCeFovb29OdnZpR2ZKcW9DQUwrYndG?= =?utf-8?B?dURJME9QdGM0cUYzWHZZam01RnBOSHp5N0ppZmkxVXk1QUNNaDhBSnUyV1RB?= =?utf-8?B?NHdyZG1WeXd1aElBSy85Qk9VRGNyMHpPMkdtUHF0NmpnYUZpaHJENzNRYVFD?= =?utf-8?B?eVVtMTZwWjYxcGtsOXQxT1R5bjQ3WW5HZ2hLa05EK3pLWndXeXZyM3ZibExy?= =?utf-8?B?UllRQjNqKzJQV3dVcHRCaUhxL0pvNStNaUsxaDN2QXA1YUpaNjVkRFR2WkF5?= =?utf-8?B?dWxER0NNZDhMZjA1T0N4Rjc5cVBXN3ZSV1RRUzFvaDFBdGgwTkVVZHZUUmpS?= =?utf-8?B?T0l3cjd6dnkvMWpaU1NHZU1mb0pmdHNNMXdkd1lOWURqWCtsQW9vWHZTcjJu?= =?utf-8?B?cUUrMUJYTzN3b0wvS0M1dnl2TFYrZWN6dVkxdnIxb0t0MHBiZmM3MlU0eDR5?= =?utf-8?B?WEFXcWhKaktDOUExWDBiTDdvZW12cS8vbmUxU2JvTEJYNE0rbldRY2UzOVFN?= =?utf-8?B?dVVNQ3RpcVlVbWRFT0ZXSU9IVERFNDdxV3dJUFd3UGZsM1JGNjNOUlB1RzFm?= =?utf-8?B?ZTc2UEp0RkV6Y25yU0RqNlllR1h0THF0d3plL0N1WnROUFRvSk1ndlFJck9C?= =?utf-8?B?Y1BmVEVlcjZwWWJQMnp4Q1FDNnU4dURERVNTalEwZVVobmRBWVlkMzQ5ck9G?= =?utf-8?B?MERWa1VSWlozOEM3MFJUQXJHTXJ5QXlEQmYrd1NTbEdRYnFvWnl5STRUZHhV?= =?utf-8?B?QjNoTnNBYVk2dmcyNURVeE5GSkRXeUU4d05rcDRyaG9tUUE5TkZ5ZzNUU3dx?= =?utf-8?B?OTVXNnE2UGtJdXhJWXhPTEc0ZklFdEtaZWt1QjNOKzBzbVdlSm9obmcyc1Er?= =?utf-8?Q?DBGSyNxB8cP2ManYElCnpKzMILIxwbUMqbmEmjl?=
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: pM5u8O96LXC9RRUQIZg+g7KeGV8ckREqQvYAr0REs2/TSo3lXTBqSf/uQ+knnOlia9fkJwqBVgU4OvBCoJ/tyjj98TR785v2faR8kV/UGwkuTNar9I4k8fgsnDZ4qSoi4yfraHJPQwXc7qPQaapju1wviB79hp+tY56LqOIgQs1Fx/ahZ4sGouUUAYWAdnqUMdfrAxnAGW/PGSCkmVjnuGUJ+PApx9tbTILhz25sJzh5t9cCNPumDRPZeLBf6RZHVdFszlq2wSi1oq6X4/9JDSxe0jRtz/4Fqu03lOHUpLsF6446I/BdOHK9lSEA3G60DrxMF0Nh9YFThZgrKR8ey1oK2Nwz/dCdAa9aU5AhwK+fpCfXFlv+NQscEwbJSc/eMuAFqyvORFzi7f8PVmcd5/O8mzAe4aCDVpauOUSWBw0=
Content-Type: text/plain; charset="utf-8"
Content-ID: <47AE95E7F813554DA8AF5141AB2216D6@namprd17.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: sectigo.com
X-MS-Exchange-CrossTenant-Network-Message-Id: dc975829-0780-4e6d-36d2-08d698d3ca94
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Feb 2019 14:41:10.7124 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-id: 0e9c4894-6caa-465d-9660-4b6968b49fb7
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR17MB2236
Archived-At: 
Subject: Re: [Trans] [TLS] ct_compliant cached info field
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Public Notary Transparency working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Feb 2019 14:41:19 -0000

RUtSLCBNYXJ0aW4sDQoNCkhpLCBhbmQgc29ycnkgZm9yIHRoZSBsb25nIGRlbGF5IGluIHJlcGx5
aW5nLg0KDQpUaGlzIG9yaWdpbmF0ZWQgaW4gWzFdIGFuZCB3YXMgYWRkZWQgdG8gNjk2Mi1iaXMg
aW4gWzJdLiAgVGhlIG1vdGl2YXRpb24gDQp3YXMgdG8gcHJvdmlkZSBhIG1lY2hhbmlzbSB0byBw
ZXJtaXQgYSBUTFMgc2VydmVyIHRvIGF2b2lkIHNlbmRpbmcgQ1QgDQphcnRpZmFjdHMgKFNDVHMs
IFNUSHMsIGluY2x1c2lvbiBwcm9vZnMpIHRoYXQgaXQga25vd3MgdGhlIFRMUyBjbGllbnQgDQph
bHJlYWR5IGhhcyBvciBkb2Vzbid0IG5lZWQsIHRoZXJlYnkgcmVkdWNpbmcgYnl0ZXMgb24gdGhl
IHdpcmUgZm9yIA0KY29uc3RyYWluZWQgYW5kIGhpZ2gtdm9sdW1lIGVudmlyb25tZW50cy4NCg0K
VGhlIGFwcHJvYWNoIGVudmlzYWdlZCBieSBSRkM3OTI0IHNlZW1zIHRvIGJlOiAiaGVyZSdzIGEg
bGlzdCBvZiBUTFMgDQptZXNzYWdlIGZpbmdlcnByaW50cyBJJ3ZlIHJlY2VpdmVkIHByZXZpb3Vz
bHk7IHBsZWFzZSBkb24ndCBzZW5kIHRoZXNlIA0KZXhhY3QgbWVzc2FnZXMgdG8gbWUgYWdhaW4i
LiAgVGhpcyB3b3JrcyBmb3Igc3RhbmQtYWxvbmUgbWVzc2FnZXMgdGhhdCANCmNvbnRhaW4gb25l
IGl0ZW0sIHN1Y2ggYXMgdGhlIHNlcnZlcidzIENlcnRpZmljYXRlIG1lc3NhZ2UgKHdoaWNoIA0K
Y29udGFpbnMgMSBzZXJ2ZXIgY2VydGlmaWNhdGUgY2hhaW4pLg0KDQpIb3dldmVyLCBpbiA2OTYy
LWJpcydzIGNhc2UsIFNDVHMgYW5kIGluY2x1c2lvbiBwcm9vZnMgYXJlIG5vdCANCnN0YW5kLWFs
b25lIGl0ZW1zOyBpbnN0ZWFkLCB0aGV5IGNvcnJlc3BvbmQgdG8gcGFydGljdWxhciBjZXJ0aWZp
Y2F0ZXMuIA0KRWFjaCByZWxldmFudCBUTFMgbWVzc2FnZSB3aWxsIGNvbnRhaW4gYSBUcmFuc0l0
ZW1MaXN0LCB3aGljaCB3aWxsIA0KcHJvYmFibHkgY29udGFpbiBhdCBsZWFzdCBhIHNldCBvZiBz
ZXZlcmFsIFNDVHM7IGFuZCB3aGlsc3QgZWFjaCBTQ1QgaXMgDQpzdGF0aWMsIHRoZSBzZXQgKGFu
ZCB0aGUgb3JkZXIgd2l0aGluIHRoZSBzZXQpIGlzIG5vdC4gIFRoZXJlZm9yZSwgdGhlIA0KYXBw
cm9hY2ggb2YgY2FjaGluZyBUTFMgbWVzc2FnZXMgYnkgZmluZ2VycHJpbnQgZGlkbid0IGxvb2sg
bGlrZSBpdCANCndvdWxkIHdvcmsgZm9yIHVzLg0KDQpXZSBjb25jbHVkZWQgdGhhdCBpdCB3b3Vs
ZCBtYWtlIG1vcmUgc2Vuc2UgZm9yIHRoZSBjbGllbnQgdG8gbWFrZSBhIG1vcmUgDQpoaWdoLWxl
dmVsIHN0YXRlbWVudDogImhlcmUncyBhIGxpc3Qgb2YgY2VydGlmaWNhdGUgZmluZ2VycHJpbnRz
IHRoYXQgDQpJJ3ZlIHJlY2VpdmVkIHByZXZpb3VzbHkgYW5kIHRoYXQgSSBhbHJlYWR5IHJlZ2Fy
ZCBhcyBiZWluZyBDVC1jb21wbGlhbnQiLg0KDQpUaGlzIGlzbid0IGFuIGVzc2VudGlhbCBwYXJ0
IG9mIDY5NjItYmlzLiAgT3RoZXIgdGhhbiBCZW4gTCdzICJTb3VuZHMgDQpsaWtlIGEgZ29vZCBp
ZGVhIiBjb21tZW50IGluIFsxXSwgSSBkb24ndCByZWNhbGwgYW55b25lIGNvbW1lbnRpbmcgb24g
aXQgDQp1bnRpbCBFS1Igc3RhcnRlZCB0aGlzIHRocmVhZC4NCg0KSSBwcm9wb3NlIHRvIHJlbW92
ZSB0aGlzIGNhY2hlZC1pbmZvIG1lY2hhbmlzbSBmcm9tIDY5NjItYmlzLCBpZiBub2JvZHkgDQpv
YmplY3RzLiAgKEl0IGNvdWxkIG9mIGNvdXJzZSBiZSByZXZpc2l0ZWQgaW4gc29tZSBmdXR1cmUg
ZG9jdW1lbnQsIGlmIA0KdGhlcmUncyBpbnRlcmVzdCkuDQoNCg0KWzFdIGh0dHBzOi8vdHJhYy5p
ZXRmLm9yZy90cmFjL3RyYW5zL3RpY2tldC8xMTENCg0KWzJdIGh0dHBzOi8vZ2l0aHViLmNvbS9n
b29nbGUvY2VydGlmaWNhdGUtdHJhbnNwYXJlbmN5LXJmY3MvcHVsbC8xODYNCg0KT24gMzEvMTIv
MjAxOCAxNDozNiwgRXJpYyBSZXNjb3JsYSB3cm90ZToNCj4gKyB0cmFucw0KPiANCj4gT24gU3Vu
LCBEZWMgMzAsIDIwMTggYXQgMTA6MDYgUE0gTWFydGluIFRob21zb24gPG10QGxvd2VudHJvcHku
bmV0IA0KPiA8bWFpbHRvOm10QGxvd2VudHJvcHkubmV0Pj4gd3JvdGU6DQo+IA0KPiANCj4gICAg
IE9uIEZyaSwgRGVjIDI4LCAyMDE4LCBhdCAwNDo1OCwgRXJpYyBSZXNjb3JsYSB3cm90ZToNCj4g
ICAgICA+IFBsZWFzZSB0YWtlIGEgbG9vayBhdA0KPiAgICAgID4NCj4gICAgIGh0dHBzOi8vdG9v
bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXRyYW5zLXJmYzY5NjItYmlzLTMwI3NlY3Rpb24t
Ni41DQo+IA0KPiAgICAgQXQgYSBtaW5pbXVtLCB0aGlzIHdvdWxkIHNlZW0gdG8gdXBkYXRlIGNh
Y2hlZF9pbmZvLg0KPiANCj4gICAgIFRoZXJlJ3Mgbm90IGEgbG90IG9mIG1lYXQgb24gdGhpcyB0
ZXh0LsKgIEl0IHNlZW1zIHRvIGJlIHNheWluZyB0aGF0DQo+ICAgICBpZiB5b3UgYXJlIHByb3Zp
ZGluZyB0cmFuc3BhcmVuY3lfaW5mbywgdGhlbiB5b3UgY2FuIHByb3ZpZGUgYQ0KPiAgICAgY2Vy
dGlmaWNhdGUgb3RoZXIgdGhhbiBhbnkgb2YgdGhlIGNlcnRpZmljYXRlcyB0aGF0IHRoZSBjbGll
bnQNCj4gICAgIGJlbGlldmVzIHRvIGJlIENUIGNvbXBsaWFudC7CoCBBbHNvLCB5b3UgZG9uJ3Qg
cHJvdmlkZSAieDUwOV9zY3RfdjIiDQo+ICAgICBvciAicHJlY2VydF9zY3RfdjIiIGluIHRyYW5z
cGFyZW5jeV9pbmZvLg0KPiANCj4gICAgIEhvdyBpcyB0aGUgY2xpZW50IHRoZW4gYWJsZSB0byBk
ZXRlcm1pbmUgdGhhdCB0aGlzIG5ldyBjZXJ0aWZpY2F0ZQ0KPiAgICAgaXMgQ1QgY29tcGxpYW50
P8KgIFVzaW5nwqAgImluY2x1c2lvbl9wcm9vZl92MiIgYW5kDQo+ICAgICAic2lnbmVkX3RyZWVf
aGVhZF92MiIgKG9yIG9uZSBvciBvdGhlcik/wqAgSWYgc28sIHRoZSB0ZXh0IGRvZXNuJ3QNCj4g
ICAgIHBvaW50IGluIHRoYXQgZGlyZWN0aW9uLg0KPiANCj4gICAgIFRoZXJlJ3MgYSBsb3Qgb2Yg
IndoeSIgbWlzc2luZyBpbiB0aGlzIGRvY3VtZW50LsKgIFdoeSB3b3VsZCBhIGNsaWVudA0KPiAg
ICAgY2hvb3NlIHRvIGluZGljYXRlICJjdF9jb21wbGlhbnQiP8KgIFdoeSBpcyBjYWNoZWRfaW5m
byBiZWluZw0KPiAgICAgZXh0ZW5kZWQgaW4gdGhpcyB3YXk/DQo+IA0KPiAgICAgSSBtaWdodCBn
dWVzcyB0aGF0IHRoZSByZWFzb24gaGVyZSBpcyB0aGF0IHRoZSBkcmFmdCBhaW1zIHRvIGF2b2lk
DQo+ICAgICBpbmNsdWRpbmcgaW5mb3JtYXRpb24gdGhhdCBtaWdodCBjaGFuZ2Ugb3ZlciB0aW1l
LCB3aGljaCB3b3VsZA0KPiAgICAgcmVuZGVyIGNhY2hlcyBpbnZhbGlkLsKgIElzbid0IHRoYXQg
bW90aXZhdGlvbiB0byByZWNvbW1lbmQgYW4gU0NUDQo+ICAgICBvdmVyIGFuIFNUSD8NCj4gDQo+
ICAgICBTZXBhcmF0ZWx5LCB3aHkgZG9lcyB0aGlzIGVzdGFibGlzaCBhIG5ldyByZWdpc3RyeSBm
b3Igc2lnbmF0dXJlDQo+ICAgICBzY2hlbWVzP8KgIEl0IGlzIG9idmlvdXNseSB0cnlpbmcgdG8g
a2VlcCBUTFMgY29tcGF0aWJpbGl0eSwgYmFzZWQgb24NCj4gICAgIHRoZSBjb2RlcG9pbnRzLCBi
dXQgZm9ya2luZyB0aGUgcmVnaXN0cnkgaXMgYSBncmVhdCB3YXkgdG8gY3JlYXRlDQo+ICAgICBw
cm9ibGVtcy4NCg0KLS0gDQpSb2IgU3RyYWRsaW5nDQpTZW5pb3IgUmVzZWFyY2ggJiBEZXZlbG9w
bWVudCBTY2llbnRpc3QNCkVtYWlsOiByb2JAc2VjdGlnby5jb20NCg0K


From nobody Fri Feb 22 06:52:11 2019
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A91B0130ED6 for ; Fri, 22 Feb 2019 06:52:05 -0800 (PST)
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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com
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 L9CIy_IdJJ1J for ; Fri, 22 Feb 2019 06:52:02 -0800 (PST)
Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) (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 7E6A5130DD6 for ; Fri, 22 Feb 2019 06:52:01 -0800 (PST)
Received: by mail-lf1-x12f.google.com with SMTP id p1so1894359lfk.9 for ; Fri, 22 Feb 2019 06:52:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=b03JlfeVyCL3hcPcYAX5nPdn+BsL77mHYkSh3SYhyX0=; b=esrzi+fxUqWgD82yjqw4v9wPlZZ5CQJWwHE7+gbj8Eepx8TIl2fEfFPKmzf9Y+L8ow xEPaLr5SrYnGprFHoqfAfYUUHbYbqnbWc6c2UTBpc0ZdzoYdBPzBXWW2wcssN5VXdtkJ Q/j91dbUdi7yPytMCF1N6A/hFm5kjLzc5JydN8Z84fu6/zoc4hX+sUZmq2F4Iyz69lK3 WXe4uw0Dg+1MlUsgQqowVFwIVMyQrjYv9WJ6TkwmlPcMFTdrl7nKHIkR8bNv//14XGPR 8L0d0bv0e54W3d6h0EwKkZOTuTRR2BRcuzotlu1Pi3IFqGNXHCpH+fDB7HsmJ2cD786x P9/g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=b03JlfeVyCL3hcPcYAX5nPdn+BsL77mHYkSh3SYhyX0=; b=Ow/WGKGtA6Ib5YblbAB/SzH+srFm9Udw6EXnw8q6Ne9KgMiqb7Qa6grIM3xeYT4x5R 96rBKdaeSE8iN1aoUniB67YX0tlOCexEdk1yPi9LSRhGFjnmVK+uuT0Golifx1yic4Qi inXFGivmyygVdcYMB22M8+VbMd65WQso3+NCJEcOYCfDb2Hwb5k787P2JtV0x9cPdGIU /nk2h0fh94nWK6tfge5khCiRUhpzOxVHFNrBDMS21j6VLvcS5MI2iS9qhuCUf/rYkpXW XgLNUJALYJdSEGeWj0zFLdDnRdx+bUoVVBWGDGTXrLQRvUkkbVnQy5Uv20JaIR+MCEnG 9fJw==
X-Gm-Message-State: AHQUAuZ8TplW2QxYF07oRh+gZwZVmExsjq9IOGxmbiL6ayqXEhfI+guQ qRIrJS6kd5pE1u7M6HaUo0FtzOWNZ3+s91H5cdBvMQ==
X-Google-Smtp-Source: AHgI3Ib/1DB8FPtUxnOp4aoU9Uj+JA+R94VZPcOaiCjLwm2Ludg/pQnU/UIfrYe8J3/ky4vxtw3RBFImFU+V0GQBxZE=
X-Received: by 2002:ac2:4191:: with SMTP id z17mr2063267lfh.78.1550847119565;  Fri, 22 Feb 2019 06:51:59 -0800 (PST)
MIME-Version: 1.0
References:  <1546236377.2848619.1621803360.25FE2839@webmail.messagingengine.com>  <1f481215-9a30-dd91-7039-8e2ac5351cbe@sectigo.com>
In-Reply-To: <1f481215-9a30-dd91-7039-8e2ac5351cbe@sectigo.com>
From: Eric Rescorla 
Date: Fri, 22 Feb 2019 06:51:20 -0800
Message-ID: 
To: Rob Stradling 
Cc: Martin Thomson , Trans , "" 
Content-Type: multipart/alternative; boundary="000000000000a9bc5805827cbbe8"
Archived-At: 
Subject: Re: [Trans] [TLS] ct_compliant cached info field
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Public Notary Transparency working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Feb 2019 14:52:10 -0000

--000000000000a9bc5805827cbbe8
Content-Type: text/plain; charset="UTF-8"

That works for me

-Ekr


On Fri, Feb 22, 2019 at 6:41 AM Rob Stradling  wrote:

> EKR, Martin,
>
> Hi, and sorry for the long delay in replying.
>
> This originated in [1] and was added to 6962-bis in [2].  The motivation
> was to provide a mechanism to permit a TLS server to avoid sending CT
> artifacts (SCTs, STHs, inclusion proofs) that it knows the TLS client
> already has or doesn't need, thereby reducing bytes on the wire for
> constrained and high-volume environments.
>
> The approach envisaged by RFC7924 seems to be: "here's a list of TLS
> message fingerprints I've received previously; please don't send these
> exact messages to me again".  This works for stand-alone messages that
> contain one item, such as the server's Certificate message (which
> contains 1 server certificate chain).
>
> However, in 6962-bis's case, SCTs and inclusion proofs are not
> stand-alone items; instead, they correspond to particular certificates.
> Each relevant TLS message will contain a TransItemList, which will
> probably contain at least a set of several SCTs; and whilst each SCT is
> static, the set (and the order within the set) is not.  Therefore, the
> approach of caching TLS messages by fingerprint didn't look like it
> would work for us.
>
> We concluded that it would make more sense for the client to make a more
> high-level statement: "here's a list of certificate fingerprints that
> I've received previously and that I already regard as being CT-compliant".
>
> This isn't an essential part of 6962-bis.  Other than Ben L's "Sounds
> like a good idea" comment in [1], I don't recall anyone commenting on it
> until EKR started this thread.
>
> I propose to remove this cached-info mechanism from 6962-bis, if nobody
> objects.  (It could of course be revisited in some future document, if
> there's interest).
>
>
> [1] https://trac.ietf.org/trac/trans/ticket/111
>
> [2] https://github.com/google/certificate-transparency-rfcs/pull/186
>
> On 31/12/2018 14:36, Eric Rescorla wrote:
> > + trans
> >
> > On Sun, Dec 30, 2018 at 10:06 PM Martin Thomson  > > wrote:
> >
> >
> >     On Fri, Dec 28, 2018, at 04:58, Eric Rescorla wrote:
> >      > Please take a look at
> >      >
> >
> https://tools.ietf.org/html/draft-ietf-trans-rfc6962-bis-30#section-6.5
> >
> >     At a minimum, this would seem to update cached_info.
> >
> >     There's not a lot of meat on this text.  It seems to be saying that
> >     if you are providing transparency_info, then you can provide a
> >     certificate other than any of the certificates that the client
> >     believes to be CT compliant.  Also, you don't provide "x509_sct_v2"
> >     or "precert_sct_v2" in transparency_info.
> >
> >     How is the client then able to determine that this new certificate
> >     is CT compliant?  Using  "inclusion_proof_v2" and
> >     "signed_tree_head_v2" (or one or other)?  If so, the text doesn't
> >     point in that direction.
> >
> >     There's a lot of "why" missing in this document.  Why would a client
> >     choose to indicate "ct_compliant"?  Why is cached_info being
> >     extended in this way?
> >
> >     I might guess that the reason here is that the draft aims to avoid
> >     including information that might change over time, which would
> >     render caches invalid.  Isn't that motivation to recommend an SCT
> >     over an STH?
> >
> >     Separately, why does this establish a new registry for signature
> >     schemes?  It is obviously trying to keep TLS compatibility, based on
> >     the codepoints, but forking the registry is a great way to create
> >     problems.
>
> --
> Rob Stradling
> Senior Research & Development Scientist
> Email: rob@sectigo.com
>
>

--000000000000a9bc5805827cbbe8
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


That works for me

-Ekr
=



On Fri, Feb 22, 2019 at 6:41 AM Rob Stradling <rob@sectigo.com> wrote:
EKR, Martin,



Hi, and sorry for the long delay in replying.



This originated in [1] and was added to 6962-bis in [2].=C2=A0 The motivati=
on 

was to provide a mechanism to permit a TLS server to avoid sending CT 

artifacts (SCTs, STHs, inclusion proofs) that it knows the TLS client 

already has or doesn't need, thereby reducing bytes on the wire for 
constrained and high-volume environments.



The approach envisaged by RFC7924 seems to be: "here's a list of T=
LS 

message fingerprints I've received previously; please don't send th=
ese 

exact messages to me again".=C2=A0 This works for stand-alone messages=
 that 

contain one item, such as the server's Certificate message (which 

contains 1 server certificate chain).



However, in 6962-bis's case, SCTs and inclusion proofs are not 

stand-alone items; instead, they correspond to particular certificates. 
Each relevant TLS message will contain a TransItemList, which will 

probably contain at least a set of several SCTs; and whilst each SCT is 
static, the set (and the order within the set) is not.=C2=A0 Therefore, the=
 

approach of caching TLS messages by fingerprint didn't look like it 
would work for us.



We concluded that it would make more sense for the client to make a more 
high-level statement: "here's a list of certificate fingerprints t=
hat 

I've received previously and that I already regard as being CT-complian=
t".



This isn't an essential part of 6962-bis.=C2=A0 Other than Ben L's =
"Sounds 

like a good idea" comment in [1], I don't recall anyone commenting=
 on it 

until EKR started this thread.



I propose to remove this cached-info mechanism from 6962-bis, if nobody 
objects.=C2=A0 (It could of course be revisited in some future document, if=
 

there's interest).





[1] https://trac.ietf.org/trac/trans/ticket/111



[2] https://github.com/google/certif=
icate-transparency-rfcs/pull/186



On 31/12/2018 14:36, Eric Rescorla wrote:

> + trans

> 

> On Sun, Dec 30, 2018 at 10:06 PM Martin Thomson <mt@lowentropy.net 

> <mailto:mt@l=
owentropy.net>> wrote:

> 

> 

>=C2=A0 =C2=A0 =C2=A0On Fri, Dec 28, 2018, at 04:58, Eric Rescorla wrote=
:

>=C2=A0 =C2=A0 =C2=A0 > Please take a look at

>=C2=A0 =C2=A0 =C2=A0 >

>=C2=A0 =C2=A0 =C2=A0https=
://tools.ietf.org/html/draft-ietf-trans-rfc6962-bis-30#section-6.5

> 

>=C2=A0 =C2=A0 =C2=A0At a minimum, this would seem to update cached_info=
.

> 

>=C2=A0 =C2=A0 =C2=A0There's not a lot of meat on this text.=C2=A0 I=
t seems to be saying that

>=C2=A0 =C2=A0 =C2=A0if you are providing transparency_info, then you ca=
n provide a

>=C2=A0 =C2=A0 =C2=A0certificate other than any of the certificates that=
 the client

>=C2=A0 =C2=A0 =C2=A0believes to be CT compliant.=C2=A0 Also, you don=
9;t provide "x509_sct_v2"

>=C2=A0 =C2=A0 =C2=A0or "precert_sct_v2" in transparency_info.=


> 

>=C2=A0 =C2=A0 =C2=A0How is the client then able to determine that this =
new certificate

>=C2=A0 =C2=A0 =C2=A0is CT compliant?=C2=A0 Using=C2=A0 "inclusion_=
proof_v2" and

>=C2=A0 =C2=A0 =C2=A0"signed_tree_head_v2" (or one or other)?=
=C2=A0 If so, the text doesn't

>=C2=A0 =C2=A0 =C2=A0point in that direction.

> 

>=C2=A0 =C2=A0 =C2=A0There's a lot of "why" missing in thi=
s document.=C2=A0 Why would a client

>=C2=A0 =C2=A0 =C2=A0choose to indicate "ct_compliant"?=C2=A0 =
Why is cached_info being

>=C2=A0 =C2=A0 =C2=A0extended in this way?

> 

>=C2=A0 =C2=A0 =C2=A0I might guess that the reason here is that the draf=
t aims to avoid

>=C2=A0 =C2=A0 =C2=A0including information that might change over time, =
which would

>=C2=A0 =C2=A0 =C2=A0render caches invalid.=C2=A0 Isn't that motivat=
ion to recommend an SCT

>=C2=A0 =C2=A0 =C2=A0over an STH?

> 

>=C2=A0 =C2=A0 =C2=A0Separately, why does this establish a new registry =
for signature

>=C2=A0 =C2=A0 =C2=A0schemes?=C2=A0 It is obviously trying to keep TLS c=
ompatibility, based on

>=C2=A0 =C2=A0 =C2=A0the codepoints, but forking the registry is a great=
 way to create

>=C2=A0 =C2=A0 =C2=A0problems.



-- 

Rob Stradling

Senior Research & Development Scientist

Email: rob@sectigo.com=







--000000000000a9bc5805827cbbe8--


From nobody Fri Feb 22 07:12:34 2019
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A765130DC4 for ; Fri, 22 Feb 2019 07:12:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca
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 NLdKX_OEPGar for ; Fri, 22 Feb 2019 07:12:26 -0800 (PST)
Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (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 2DCCC130DC2 for ; Fri, 22 Feb 2019 07:12:26 -0800 (PST)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 445ZZb6gQSzJhv; Fri, 22 Feb 2019 16:12:23 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1550848343; bh=MV2q4gO2sYXADi9iI1XOc60nRXYs81ks6RLu9fnhdxY=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=kW7FHLHfrhaPderTfyW9qc6Iy8NK/g9PcpvD85M/BZGkecmCu4+6taPdgclwNlQAK UzeQjQuy2y2R8cRDVJMNCiIpFyzlRKgQsC1KXFeC+bWiuhn8ZjUKSC0jCU/qixvtxR 4hs7LUGqqgp6H2EMcHbdt4oS43Vx8aC4iaeL2yys=
X-Virus-Scanned: amavisd-new at mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id 6J-eqDENIFOb; Fri, 22 Feb 2019 16:12:22 +0100 (CET)
Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Fri, 22 Feb 2019 16:12:21 +0100 (CET)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id 02EE9379D; Fri, 22 Feb 2019 10:12:20 -0500 (EST)
DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 02EE9379D
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id EB4A540D358A; Fri, 22 Feb 2019 10:12:20 -0500 (EST)
Date: Fri, 22 Feb 2019 10:12:20 -0500 (EST)
From: Paul Wouters 
To: =?ISO-8859-15?Q?V=E1clav_Jirovsk=FD?= 
cc: trans@ietf.org
In-Reply-To: 
Message-ID: 
References: 
User-Agent: Alpine 2.21 (LRH 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8BIT
Archived-At: 
Subject: Re: [Trans] Add get_entries_max_limit attribute to get-sth request
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Public Notary Transparency working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Feb 2019 15:12:28 -0000

On Mon, 4 Feb 2019, Václav Jirovský wrote:

[chair hat on]

We are in the final stages of the bis document, so changing anything
at this point requires a high bar. I haven't seen anyone replying to
this, so that would suggst to me that this is not an item that is that
important to fix right now. If you disagree, please speak out.
Especially those who are implementing this document.

Paul

> Date: Mon, 4 Feb 2019 05:09:35
> From: Václav Jirovský 
> To: trans@ietf.org
> Subject: [Trans] Add get_entries_max_limit attribute to get-sth request
> 
> Hello all, 
> I would like to propose modification Retrieve Latest Signed Tree Head section of RFC6962 - adding new attribute get_entries_max_limit.
> 
> Reason for this change - 4.6 section actual version:
>
>  Logs MAY restrict the number of entries that can be retrieved per
>    "get-entries" request.  If a client requests more than the permitted
>    number of entries, the log SHALL return the maximum number of entries
>    permissible.  These entries SHALL be sequential beginning with the
>    entry specified by "start".
> 
> If you want to download all entries from CT server, you don't what number of entries will server return to you by request - so you have to
> process, count real number of returned entries and after that, you can do another request. This is not efficient, you could do these request
> in parallel, if you would have garanteed number of returned entries.
> 
> Proposed modification:
> 
> 4.3.  Retrieve Latest Signed Tree Head
> 
> 
> GET https:///ct/v1/get-sth
> No inputs.
> 
> Outputs:
>       tree_size:  The size of the tree, in entries, in decimal.
>       timestamp:  The timestamp, in decimal.
>       sha256_root_hash:  The Merkle Tree Hash of the tree, in base64.
>       get_entries_max_limit: Maximum entries count provided by server get-entries method.
>       tree_head_signature:  A TreeHeadSignature for the above data.
> 
> 4.6.  Retrieve Entries from Log
> 
> GET https:///ct/v1/get-entries
> Inputs:
>       start:  0-based index of first entry to retrieve, in decimal.
>       end:  0-based index of last entry to retrieve, in decimal.
> .....
>
>    Logs MAY restrict the number of entries that can be retrieved per
>    "get-entries" request.  If a client requests more than the permitted
>    number of entries ("get_entries_max_limit" output of "get-sth" request),
>    the log SHALL return the maximum number of entries
>    permissible. If a client requests less or equal than the permitted
>    number of entries ("get_entries_max_limit" output of "get-sth" request),
>    the log MUST return the maximum number of entries permissible.
>    These entries SHALL be sequential beginning with the
>    entry specified by "start".
> Best,
> Vaclav Jirovsky
> 
> 
>


From nobody Fri Feb 22 07:24:32 2019
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD777130E3F for ; Fri, 22 Feb 2019 07:24:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca
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 QaIdgJRMc_JK for ; Fri, 22 Feb 2019 07:24:29 -0800 (PST)
Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (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 343A7130E27 for ; Fri, 22 Feb 2019 07:24:29 -0800 (PST)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 445ZrV4mBLzJhv for ; Fri, 22 Feb 2019 16:24:26 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1550849066; bh=EHXI/rA8l0ZZr5KaGDySufdXoCAAa/ILr93J5oE0h80=; h=Date:From:To:Subject; b=bYlPnYXl1ZfQdLxF1qdV7RupogT3dvO8dhyS1PxCJRlWnyft4D2VFAVoL/CVQZGBK uA+frCkGUoMOBzi4PHhQJwtr7ITs1M3zneKebA/cj2WAOi7CoYcqClSfmRoFX9lRRy dPq39yjN2aufdGzblZooP/IAxb5zLlppObuYC+GQ=
X-Virus-Scanned: amavisd-new at mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id eBxFAyBmi0C3 for ; Fri, 22 Feb 2019 16:24:24 +0100 (CET)
Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS for ; Fri, 22 Feb 2019 16:24:24 +0100 (CET)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id 614CE379D; Fri, 22 Feb 2019 10:24:23 -0500 (EST)
DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 614CE379D
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 54F6C40D358A for ; Fri, 22 Feb 2019 10:24:23 -0500 (EST)
Date: Fri, 22 Feb 2019 10:24:23 -0500 (EST)
From: Paul Wouters 
To: Trans 
Message-ID: 
User-Agent: Alpine 2.21 (LRH 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
Archived-At: 
Subject: [Trans] 6962bis and signed_certificate_timestamp issue
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Public Notary Transparency working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Feb 2019 15:24:31 -0000

This issue is still open:

 	TLS 1.3 (https://tools.ietf.org/html/rfc8446) has several mentions of
 	the RFC6962 signed_certificate_timestamp TLS extension.  Since 6962-bis
 	intends to obsolete RFC6962 and replace signed_certificate_timestamp
 	with a new TLS extension (transparency_info), should we also add a
 	sentence to the 6962-bis Abstract along these lines...
 	   "This document also specifies new requirements for TLS 1.0, 1.1, 1.2
 	    and 1.3 implementations."
 	?

 	Do we even need to mark 6962-bis as Updating RFC8446?

 	(Can an Experimental RFC update a Standards Track RFC?)



From nobody Fri Feb 22 07:34:52 2019
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B66FD130F55 for ; Fri, 22 Feb 2019 07:34:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=comodoca.onmicrosoft.com
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 uodYus1m4szE for ; Fri, 22 Feb 2019 07:34:43 -0800 (PST)
Received: from NAM05-DM3-obe.outbound.protection.outlook.com (mail-eopbgr730073.outbound.protection.outlook.com [40.107.73.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26AA2130F01 for ; Fri, 22 Feb 2019 07:34:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comodoca.onmicrosoft.com; s=selector1-sectigo-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=4cyJFkWLLWAGHUcb/DqWV4jnTSZi5nvyN7qoy/8jsdY=; b=iJLja1D4TAeHBWrlFmx9Hs9mifomqDY/kzC1p0PiCa7w8sqXI5Ks773nWJUc9u5VIK7KijosyXDEBVHJoZhvYqQlUt1uP22NwswACKJ2IdXnMXGOFDwGrOccr6D4JjXZv8Cm8e8jMTUaCxEHp3MwLA+bMof10+0m0d7QYBvkxN0=
Received: from DM6PR17MB2716.namprd17.prod.outlook.com (20.178.224.155) by DM6PR17MB2123.namprd17.prod.outlook.com (20.176.92.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1643.18; Fri, 22 Feb 2019 15:34:40 +0000
Received: from DM6PR17MB2716.namprd17.prod.outlook.com ([fe80::80e1:4c3b:1fac:22b9]) by DM6PR17MB2716.namprd17.prod.outlook.com ([fe80::80e1:4c3b:1fac:22b9%6]) with mapi id 15.20.1643.014; Fri, 22 Feb 2019 15:34:40 +0000
From: Rob Stradling 
To: Paul Wouters , Trans 
Thread-Topic: [Trans] 6962bis and signed_certificate_timestamp issue
Thread-Index: AQHUysK86ImzxnrBI0uWnUixf87NQ6Xr8q+A
Date: Fri, 22 Feb 2019 15:34:40 +0000
Message-ID: <95dbc6ef-1817-b1cc-1e7b-54c4e0052a2d@sectigo.com>
References: 
In-Reply-To: 
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-clientproxiedby: LO2P265CA0346.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:d::22) To DM6PR17MB2716.namprd17.prod.outlook.com (2603:10b6:5:122::27)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=rob@sectigo.com; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [2a02:1788:4ff:1000:f68e:38ff:fe7a:a226]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 0c418eaf-5b7e-4c6c-a469-08d698db42bb
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600110)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:DM6PR17MB2123; 
x-ms-traffictypediagnostic: DM6PR17MB2123:
x-ms-exchange-purlcount: 4
x-microsoft-antispam-prvs: 
x-forefront-prvs: 09565527D6
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(346002)(376002)(396003)(39850400004)(366004)(199004)(189003)(6306002)(6512007)(14444005)(99286004)(36756003)(486006)(25786009)(68736007)(97736004)(86362001)(2906002)(8676002)(256004)(5660300002)(6246003)(81166006)(81156014)(31696002)(8936002)(478600001)(229853002)(6116002)(53546011)(6506007)(76176011)(386003)(102836004)(52116002)(14454004)(966005)(186003)(110136005)(31686004)(476003)(11346002)(6486002)(105586002)(305945005)(2616005)(46003)(53936002)(106356001)(446003)(316002)(6436002)(7736002)(71190400001)(71200400001); DIR:OUT; SFP:1101; SCL:1; SRVR:DM6PR17MB2123; H:DM6PR17MB2716.namprd17.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
received-spf: None (protection.outlook.com: sectigo.com does not designate permitted sender hosts)
x-microsoft-exchange-diagnostics: =?utf-8?B?MTtETTZQUjE3TUIyMTIzOzIzOlFhdmY1NFF6WUxwdnBJamxFY1NNUllZUldC?= =?utf-8?B?VGJDZjE1S1dTZktNU2JlWk1lbmxQWFRBMmppNnBwak5WckJrVWlOUjQrVUZO?= =?utf-8?B?MTAvKzlkbU44VHU5OEREak5rYUhDeGIxYW5kWStLeXdGQktNV2NQaHEzT1JZ?= =?utf-8?B?cWF5clV6cDRrRjRGaXFtYkFBYnZpUTE4Y2NXenBaQXhlck1PeVl3VEJLR24z?= =?utf-8?B?UmNBWWtHWkNxVDhJZUNWZThvdG00RHdQbUZBMzJSWU1DcnpqQ3VoSTZHME5G?= =?utf-8?B?R1habkJwZ3JNSHU2VWZXakNzT1cxM3dhcWlNR0VmUElRVzRvQ0ozQldnLzB1?= =?utf-8?B?aFFDMGFwbjNlQ0FmOGRiS0VpUS9xcElaYU1waVY5ZVNITU03Mks4UmtzUnhY?= =?utf-8?B?ZTA3Y2E5dDFyeHBKamdVc1AzOW0wUFdmWE8rSU0xVG44WEhCT0pPQ0duMXRt?= =?utf-8?B?S3NCcjNiMVlid3R2cTNleHdhYklXRi9JekRKdUo4MzFiaVN2WEg2dHY0Tnh4?= =?utf-8?B?RTl4amZjck84bTlMdi90Y0FRMlBVN1JTNEF2UjI2S2hjRXRKbGZDWXRQY1Rz?= =?utf-8?B?ZHB3UTVhZHg5dnIybkpSNUk1NkdxUTJNcDl0V3V4OXR6cFluMWx5K1NKQ2FB?= =?utf-8?B?TU1KNVRlU1RKdFVWa1l6VDFUcUpOYXBScGxMUTVYK0h5WlJDaWVjOU9KUVdI?= =?utf-8?B?OVBRZVM5VjZ2dnIwc1FEdmN6U1hTUmhUUGF3OEFPaTRxQkszUkk2SlFVZHBD?= =?utf-8?B?OHkyYnBETlR2R0pLNWNZSi9LdEZQNkUyUDdhV3JZdnQwc0xBRzJPSWRDNkV6?= =?utf-8?B?MHlSakNrZkRWcnBwSndCYUVoUHZ0Qy8xNXcwRW9PblZqczR1MUR1Ny9SVE1U?= =?utf-8?B?b1N1NmgzbGhmeDlYM1h6RUNnSGtNR28zbGNjTjFDOU16VzlZeXhuRWlwRzBD?= =?utf-8?B?TzhndGZmN2Y3RlZKbzlyaThHNXd5QVFuTjc5MXlMck96ODRZQ05CZjhtNUU4?= =?utf-8?B?WkZ6K0ExMTNiQk5aWHV3UjZSaDBRazh4L3RjSDVlZUtvbHdrUDVxR3h6blRJ?= =?utf-8?B?SG1xNmY2RDZPOSt2OGtyODZreDZodGZaVjJDNS9BUDBBeXB1Vm0ycWh2aVdk?= =?utf-8?B?clRmdnYrRVVNNDRHcWtwMnIxTHVtYVBQNndRMGRxK1hCQnhLZVlEU0ZCNnM5?= =?utf-8?B?S0p3dVRrTkFMRDhNLzMwMWxNeXNmMWZzNlBZaXpvMldUMkVmMkwyaDFVRnoz?= =?utf-8?B?YmljOTdLaEdRSHBMS1VjNmhYTk5qMUR6YTdQajFXczlEODZYOG1jaUpEc29q?= =?utf-8?B?OEhNZGw0akNXblZFMjlnQWdiRlI5cXVYR1JoT1Q1ZGRrZ2MxNnlXZFZPWWYz?= =?utf-8?B?OHFqV1AxSTdnZ0hiTDI3K0pRd1RrYi9LQ2prSXhDQ2RMai8waFhkVWUyZDU5?= =?utf-8?B?bHJQRjlZNEwrcS9uS3ZoZVRVbTRPSVI2Kzc5VUNtZ1ZtQ0RZeUgvc2NMY0VT?= =?utf-8?B?eTNUZ0lpZVBjSThLRnFLNFNNNVhFOTVrUCt5TXgrM3RLTU9VQmcySVhKaXo0?= =?utf-8?B?ekd0ODdvN2JHZUc0V1dWY0duNnBUSlREZDdMazFNZE85TERPVVhYL2dHZ2pE?= =?utf-8?B?Mm44ZGcrYkJ1ZGx0R2g1cEEvc2E4bW1QQW9EQTRyWWZpSlBLeUJlWnl5SCs5?= =?utf-8?Q?dJhp4E45LRv1Rt7n9Q=3D?=
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: AgU1MccTifbIKvh/5+8B3z/3fmxvXMG9DcQxLHj+x0I9hRVQKnCf/By+56w4hmYv2q226rGnvN96rddLyMgwuk5q87ktvKEUV6ThY+wG7NUipb22+jLaAqPl3Os4syMOQSy4fCAfc2hd7g/fLzOrmZJ0lKZwGn6HKYSbborTGpzoB5XD9c7oAjt9D/Zj8JADCQSpbUFuE/2MT2cdEs5c4wvl1WFX/7hbuYC4JVuzom0zew+9RX9ZjnptzCiwkPEGZm7erWqGk6Ra7Mi12iAMypQRpQht/fQLpalh/u9q6hXNpgEdakfwhmkRx4aFE3vGxStPZtYcqYDVs+HPVjo4xDFDb78QE9I1jRXm2doNise1I+SAqCHDSVnB7f+0K+5DByHzrCl2DKV4axIJ6QpWlwCkC14GDrlKdfpfOevQBV0=
Content-Type: text/plain; charset="utf-8"
Content-ID: <589275CAA16DF14FA93943E440D7ADA2@namprd17.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: sectigo.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 0c418eaf-5b7e-4c6c-a469-08d698db42bb
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Feb 2019 15:34:39.3268 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-id: 0e9c4894-6caa-465d-9660-4b6968b49fb7
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR17MB2123
Archived-At: 
Subject: Re: [Trans] 6962bis and signed_certificate_timestamp issue
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Public Notary Transparency working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Feb 2019 15:34:51 -0000

SGkgUGF1bC4gIFRoYXQgaXNzdWUgaXMgZnJvbSBhbiBvZmZsaW5lIGRpc2N1c3Npb24gYmV0d2Vl
biB0aGUgQS1EcywgdGhlIA0KVFJBTlMgV0cgQ2hhaXJzLCBhbmQgdGhlIDY5NjItYmlzIGF1dGhv
cnMuICBCZW4gSyBhbnN3ZXJlZCB0aG9zZSANCnF1ZXN0aW9ucyAob24gM3JkIE5vdiAyMDE4KSBh
cyBmb2xsb3dzOg0KDQoNCiI+IERvIHdlIGV2ZW4gbmVlZCB0byBtYXJrIDY5NjItYmlzIGFzIFVw
ZGF0aW5nIFJGQzg0NDY/DQoNCkNyZWF0aW5nIGEgbmV3IFRMUyBleHRlbnNpb24gZG9lcyBub3Qg
cmVxdWlyZSB1cHRhZGluZyB0aGUgY29yZSBUTFMgc3BlYy4NCkJ1dCB0aGUgc3VnZ2VzdGVkIHRl
eHQgYWJvdXQgIm5ldyByZXF1aXJlbWVudHMgZm9yIFsuLi5dIFRMUw0KaW1wbGVtZW50YXRpb25z
IiBpcyBub3QgZ29vZDsgYmV0dGVyIHRvIHRhbGsgYWJvdXQgZGVmaW5pbmcgYW4gZXh0ZW5zaW9u
DQp0aGF0IGlzIHVzZWQgZm9yIFtzdHVmZl0uDQoNCiA+IChDYW4gYW4gRXhwZXJpbWVudGFsIFJG
QyB1cGRhdGUgYSBTdGFuZGFyZHMgVHJhY2sgUkZDPykNCg0KTm8uIg0KDQoNCkkgYWRkcmVzc2Vk
IHRoaXMgaW4gUFIjMzAyIFsxXSBieSBhZGRpbmcgWzJdIHRoZSBmb2xsb3dpbmcgdGV4dCB0byB0
aGUgDQpBYnN0cmFjdDoNCg0KIkl0IGFsc28gc3BlY2lmaWVzIGEgbmV3IFRMUyBleHRlbnNpb24g
dGhhdCBpcyB1c2VkIHRvIHNlbmQgdmFyaW91cyBDVCANCmxvZyBhcnRpZmFjdHMuIg0KDQoNClsx
XSBodHRwczovL2dpdGh1Yi5jb20vZ29vZ2xlL2NlcnRpZmljYXRlLXRyYW5zcGFyZW5jeS1yZmNz
L3B1bGwvMzAyDQoNClsyXSANCmh0dHBzOi8vZ2l0aHViLmNvbS9nb29nbGUvY2VydGlmaWNhdGUt
dHJhbnNwYXJlbmN5LXJmY3MvY29tbWl0L2UxODMyMjIzNWM0MDliZjcxNTBlYjBiODYzODRmYmRk
YWVjYzk2NjANCg0KT24gMjIvMDIvMjAxOSAxNToyNCwgUGF1bCBXb3V0ZXJzIHdyb3RlOg0KPiAN
Cj4gVGhpcyBpc3N1ZSBpcyBzdGlsbCBvcGVuOg0KPiANCj4gIMKgwqDCoMKgVExTIDEuMyAoaHR0
cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzg0NDYpIGhhcyBzZXZlcmFsIG1lbnRpb25zIG9m
DQo+ICDCoMKgwqDCoHRoZSBSRkM2OTYyIHNpZ25lZF9jZXJ0aWZpY2F0ZV90aW1lc3RhbXAgVExT
IGV4dGVuc2lvbi7CoCBTaW5jZSANCj4gNjk2Mi1iaXMNCj4gIMKgwqDCoMKgaW50ZW5kcyB0byBv
YnNvbGV0ZSBSRkM2OTYyIGFuZCByZXBsYWNlIHNpZ25lZF9jZXJ0aWZpY2F0ZV90aW1lc3RhbXAN
Cj4gIMKgwqDCoMKgd2l0aCBhIG5ldyBUTFMgZXh0ZW5zaW9uICh0cmFuc3BhcmVuY3lfaW5mbyks
IHNob3VsZCB3ZSBhbHNvIGFkZCBhDQo+ICDCoMKgwqDCoHNlbnRlbmNlIHRvIHRoZSA2OTYyLWJp
cyBBYnN0cmFjdCBhbG9uZyB0aGVzZSBsaW5lcy4uLg0KPiAgwqDCoMKgwqDCoMKgICJUaGlzIGRv
Y3VtZW50IGFsc28gc3BlY2lmaWVzIG5ldyByZXF1aXJlbWVudHMgZm9yIFRMUyAxLjAsIDEuMSwg
DQo+IDEuMg0KPiAgwqDCoMKgwqDCoMKgwqAgYW5kIDEuMyBpbXBsZW1lbnRhdGlvbnMuIg0KPiAg
wqDCoMKgwqA/DQo+IA0KPiAgwqDCoMKgwqBEbyB3ZSBldmVuIG5lZWQgdG8gbWFyayA2OTYyLWJp
cyBhcyBVcGRhdGluZyBSRkM4NDQ2Pw0KPiANCj4gIMKgwqDCoMKgKENhbiBhbiBFeHBlcmltZW50
YWwgUkZDIHVwZGF0ZSBhIFN0YW5kYXJkcyBUcmFjayBSRkM/KQ0KPiANCj4gDQo+IF9fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IFRyYW5zIG1haWxpbmcg
bGlzdA0KPiBUcmFuc0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp
c3RpbmZvL3RyYW5zDQoNCi0tIA0KUm9iIFN0cmFkbGluZw0KU2VuaW9yIFJlc2VhcmNoICYgRGV2
ZWxvcG1lbnQgU2NpZW50aXN0DQpFbWFpbDogcm9iQHNlY3RpZ28uY29tDQpCcmFkZm9yZCwgVUsN
Ck9mZmljZTogKzQ0MTI3NDAyNDcwNw0KU2VjdGlnbyBMaW1pdGVkDQoNClRoaXMgbWVzc2FnZSBh
bmQgYW55IGZpbGVzIGFzc29jaWF0ZWQgd2l0aCBpdCBtYXkgY29udGFpbiBsZWdhbGx5IA0KcHJp
dmlsZWdlZCwgY29uZmlkZW50aWFsLCBvciBwcm9wcmlldGFyeSBpbmZvcm1hdGlvbi4gSWYgeW91
IGFyZSBub3QgdGhlIA0KaW50ZW5kZWQgcmVjaXBpZW50LCB5b3UgYXJlIG5vdCBwZXJtaXR0ZWQg
dG8gdXNlLCBjb3B5LCBvciBmb3J3YXJkIGl0LCANCmluIHdob2xlIG9yIGluIHBhcnQgd2l0aG91
dCB0aGUgZXhwcmVzcyBjb25zZW50IG9mIHRoZSBzZW5kZXIuIFBsZWFzZSANCm5vdGlmeSB0aGUg
c2VuZGVyIGJ5IHJlcGx5IGVtYWlsLCBkaXNyZWdhcmQgdGhlIGZvcmVnb2luZyBtZXNzYWdlcywg
YW5kIA0KZGVsZXRlIGl0IGltbWVkaWF0ZWx5Lg0K


From nobody Fri Feb 22 08:42:07 2019
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5EC9129741 for ; Fri, 22 Feb 2019 08:42:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca
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 D1BUZVT2QSkA for ; Fri, 22 Feb 2019 08:42:05 -0800 (PST)
Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (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 CF46E129284 for ; Fri, 22 Feb 2019 08:42:04 -0800 (PST)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 445cZ172TXzJhy; Fri, 22 Feb 2019 17:42:01 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1550853721; bh=2qxB7LIUU3M9YTreMIiI02RKk9eKXdHtjmNYC9FqITo=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=JY6woaB+E0bTH2ld/JD3MqqsY9EZ545ZMvcbEkZZ4k1+dNrwDqdlWVWJaOHBXdnCm 85+8y0/ATxLgIs0rG9ZXdYQpz3PhjV79i+goTxR8jTc3/fov/JWBsdwvQ9HMy/Utze cE34bfQb7oB9PBUczSSrYFSRIMW8gRMIr4nhbrUQ=
X-Virus-Scanned: amavisd-new at mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id FVKWjhuJqY_0; Fri, 22 Feb 2019 17:42:00 +0100 (CET)
Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Fri, 22 Feb 2019 17:42:00 +0100 (CET)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id 0CDC0379D; Fri, 22 Feb 2019 11:41:59 -0500 (EST)
DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 0CDC0379D
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id F3DAC40D358A; Fri, 22 Feb 2019 11:41:59 -0500 (EST)
Date: Fri, 22 Feb 2019 11:41:59 -0500 (EST)
From: Paul Wouters 
To: Rob Stradling 
cc: Trans 
In-Reply-To: <95dbc6ef-1817-b1cc-1e7b-54c4e0052a2d@sectigo.com>
Message-ID: 
References:  <95dbc6ef-1817-b1cc-1e7b-54c4e0052a2d@sectigo.com>
User-Agent: Alpine 2.21 (LRH 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
Archived-At: 
Subject: Re: [Trans] 6962bis and signed_certificate_timestamp issue
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Public Notary Transparency working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Feb 2019 16:42:06 -0000

On Fri, 22 Feb 2019, Rob Stradling wrote:

> Hi Paul.  That issue is from an offline discussion between the A-Ds, the
> TRANS WG Chairs, and the 6962-bis authors.  Ben K answered those
> questions (on 3rd Nov 2018) as follows:

ah thanks. I thought it was a followup to the pull request and never saw
an answer. So this is covered in -30 then.

Paul


From nobody Mon Feb 25 03:43:37 2019
Return-Path: 
X-Original-To: trans@ietf.org
Delivered-To: trans@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9697A130ED7; Mon, 25 Feb 2019 03:43:30 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: trans@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.91.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: trans@ietf.org
Message-ID: <155109501056.3501.11990067845465028731@ietfa.amsl.com>
Date: Mon, 25 Feb 2019 03:43:30 -0800
Archived-At: 
Subject: [Trans] I-D Action: draft-ietf-trans-rfc6962-bis-31.txt
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Public Notary Transparency working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Feb 2019 11:43:31 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Public Notary Transparency WG of the IETF.

        Title           : Certificate Transparency Version 2.0
        Authors         : Ben Laurie
                          Adam Langley
                          Emilia Kasper
                          Eran Messeri
                          Rob Stradling
	Filename        : draft-ietf-trans-rfc6962-bis-31.txt
	Pages           : 54
	Date            : 2019-02-25

Abstract:
   This document describes version 2.0 of the Certificate Transparency
   (CT) protocol for publicly logging the existence of Transport Layer
   Security (TLS) server certificates as they are issued or observed, in
   a manner that allows anyone to audit certification authority (CA)
   activity and notice the issuance of suspect certificates as well as
   to audit the certificate logs themselves.  The intent is that
   eventually clients would refuse to honor certificates that do not
   appear in a log, effectively forcing CAs to add all issued
   certificates to the logs.

   This document obsoletes RFC 6962.  It also specifies a new TLS
   extension that is used to send various CT log artifacts.

   Logs are network services that implement the protocol operations for
   submissions and queries that are defined in this document.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-trans-rfc6962-bis/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-trans-rfc6962-bis-31
https://datatracker.ietf.org/doc/html/draft-ietf-trans-rfc6962-bis-31

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-trans-rfc6962-bis-31


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Mon Feb 25 03:46:11 2019
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F17D1200B3; Mon, 25 Feb 2019 03:46:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=comodoca.onmicrosoft.com
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 uM28D5vpM0Ba; Mon, 25 Feb 2019 03:46:06 -0800 (PST)
Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-eopbgr810085.outbound.protection.outlook.com [40.107.81.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8B1312F295; Mon, 25 Feb 2019 03:46:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comodoca.onmicrosoft.com; s=selector1-sectigo-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3NXJgYh27jB3nGh5Si6tq5Qu3fQkteCyWDvJdsn1PSE=; b=httSwaLQH9JZg04wOslflPPWE/IoQYVDbAzkVCl93K2PtN2xZNWNaLDlGTgJCVqyZ0QF0aHB2g2ClZ/ZSq5FGbYJ9zVE0JkJvZma7QJHpYJIBzU4AlbYNr2p3Pj39g4wVXIHFSFYPBq1rzFpCF7mRZ8NoSgeAobCzyYzOUQFBUM=
Received: from DM6PR17MB2716.namprd17.prod.outlook.com (20.178.224.155) by DM6PR17MB3355.namprd17.prod.outlook.com (20.176.127.28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1643.14; Mon, 25 Feb 2019 11:46:04 +0000
Received: from DM6PR17MB2716.namprd17.prod.outlook.com ([fe80::80e1:4c3b:1fac:22b9]) by DM6PR17MB2716.namprd17.prod.outlook.com ([fe80::80e1:4c3b:1fac:22b9%6]) with mapi id 15.20.1643.019; Mon, 25 Feb 2019 11:46:04 +0000
From: Rob Stradling 
To: Eric Rescorla 
CC: Martin Thomson , Trans , "" 
Thread-Topic: [TLS] ct_compliant cached info field
Thread-Index: AQHUng4AiTlMjhjKyU+rxTv7bjD+jKWYYcaAgACOqgCAU0y3AIAAAuEAgASDJ4A=
Date: Mon, 25 Feb 2019 11:46:03 +0000
Message-ID: <6bf40eed-54f1-c04c-6e60-8bf67503036a@sectigo.com>
References:  <1546236377.2848619.1621803360.25FE2839@webmail.messagingengine.com>  <1f481215-9a30-dd91-7039-8e2ac5351cbe@sectigo.com> 
In-Reply-To: 
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-clientproxiedby: LO2P265CA0451.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:e::31) To DM6PR17MB2716.namprd17.prod.outlook.com (2603:10b6:5:122::27)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=rob@sectigo.com; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [2a02:1788:4ff:1000:f68e:38ff:fe7a:a226]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 4bd16097-ff7f-4f48-62e1-08d69b16d205
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:DM6PR17MB3355; 
x-ms-traffictypediagnostic: DM6PR17MB3355:
x-ms-exchange-purlcount: 4
x-microsoft-antispam-prvs: 
x-forefront-prvs: 095972DF2F
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(346002)(39850400004)(366004)(396003)(376002)(189003)(199004)(81166006)(2616005)(54906003)(8676002)(476003)(256004)(6116002)(14444005)(71190400001)(71200400001)(93886005)(6246003)(186003)(6916009)(305945005)(316002)(25786009)(229853002)(7736002)(97736004)(11346002)(4326008)(86362001)(5660300002)(486006)(81156014)(46003)(386003)(53546011)(31686004)(6506007)(68736007)(6512007)(6306002)(478600001)(53936002)(14454004)(6486002)(76176011)(99286004)(52116002)(105586002)(106356001)(8936002)(36756003)(966005)(2906002)(446003)(102836004)(31696002)(6436002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM6PR17MB3355; H:DM6PR17MB2716.namprd17.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: sectigo.com does not designate permitted sender hosts)
x-microsoft-exchange-diagnostics: =?utf-8?B?MTtETTZQUjE3TUIzMzU1OzIzOlYvbHZ3SmdvTnRUOVoxamsrMENXWEdhYkNp?= =?utf-8?B?a1c0RmlSNUJjVU8rVFY4a3Rid2Z2VmJWVW1rM0tzN2lZM3dPSlBBbHJxWU1R?= =?utf-8?B?SklZQ0lpRmNvbDZ5VmUweEM1TkR5b2dQT1pXcnIvamdwZmRNdk5zV1dVR056?= =?utf-8?B?NTFGSXpzd2pqSmIrcnB0cTRNVDdvaFNtWVlMT09ZNStrU0lNVFVBdnhiVXl3?= =?utf-8?B?MU5NSThjbjNlbTZQVktBNXNoUFROdHNZZktGOHppZDdIYTlUbUlseXo4ejkv?= =?utf-8?B?YitNWGlyT3ZCQ2VrYWtRNTlrbnQxeEMxL29uVGpPNUhKUW1RS3dvOW9BMStX?= =?utf-8?B?VXo3U0gwK0ViZUU4Q3VHMU1SSWFKandCTmhtMitEcVpxNkVFQm5wYXpZcCsx?= =?utf-8?B?bXFZdWJIVXlTZ1UrWjYwalh4RVRMNmhvSFExU3hyTWpLaFFtMnRSQStrRWxF?= =?utf-8?B?ZFArOHlaMXpHU3dIbm9MZmpFcmQzak54SCtZMVE3TkoxOE84T0lwaEFPSWdI?= =?utf-8?B?NzNFOGtoWDdKODd1eElyd2lpcjMvbFNkdHh2S05aVUFpM2pJQUtmOVRxUExK?= =?utf-8?B?WkYvclVrMGxpRGV4R1ZwQlc0TWxnV3FLbXhFUVo4dWxFczlNMVJ4UWNTRmRZ?= =?utf-8?B?R3pkYXJsenI2eVM4Q1RxNEVWa1g3UzlUaWxMbXJuZTgyejJxMmZyUjdrSkVp?= =?utf-8?B?RzZzdlEvTlBZN2Y4WDQ0aU9RWC8rVEtaTUZWSFhQa1NwbWQyeEYvUEhwRmZJ?= =?utf-8?B?UHlZRnZEQnh0bG9VVjU0QUZqWG9KbUdMcXlwVTlLM3Q2VCtEVGRpN2ZEa01r?= =?utf-8?B?b1lGRnlTWDdKZDgraUdkMldGVzVhS1dNS2xRRDRFZ25memw4Z1ZSRi9NQlB4?= =?utf-8?B?YlMrbHRnc2g0SXF4RmxjNkU4aWppSjBlb2VwL3VxU281eDNxdk9zeU02UzNN?= =?utf-8?B?NTRrbVBRaC8ycyttc043K0hxS1VZMUgzZXh3MmJjUmFzYVl2cWJwRUdFeWVK?= =?utf-8?B?M1BwRjBaTm83b1lSdWRCMTU2OFdQTWx0MDhrcG9QQkt1TWJyVzRzK3E0TmRG?= =?utf-8?B?bzJLMFplYnlHaW42R0hISlkwRmp3L1djeHJ5TUxQc25RaGZ4Qnk0OGVRV09U?= =?utf-8?B?WUgyTGZMZCttWFRRNTIzTjMrS2cvdWJid0FSVkRuTlVmaEtSRFRLWkJhNklh?= =?utf-8?B?WTltdTFoMWlJNnZyVXRJeFNwM3NwV1ZSZkdxZGxGb0ZUTGk1TWcwNFRoV3lq?= =?utf-8?B?WDBNY2t5UE8xRUlXOWFmeWo5NDBMWmpMTlJ2ei82ZWUyMUU2M0drWXgyZUo5?= =?utf-8?B?OUNOZjh1NFNobThSbkdzdjhWTTFyOEFmc0tEUjAwMFV2WGdrdUV4dktSUWFh?= =?utf-8?B?aStUM0NqbUorOEU4b25xemh3dEZvbzRWTFgvSGQ0OUdraCtMOE1yZnBualBH?= =?utf-8?B?WVhCTUpZdEFBTnJ2U29OcUZKY05GTlVaU3Nna2RJMWc0RGR4d2FKNThQcStm?= =?utf-8?B?OUZhWXlLMmxNaWovaWt0WEg5TWhTUGdqRHNKVjdLemwrOWpsRG5paU03U2dU?= =?utf-8?B?alNBYS9HV08vaXg0YmhlMVhPT0Z2VTZWR3hPamZ6Y3BKN1hkdWVpSm0vdzZP?= =?utf-8?B?elhNOWtJY2xab1NrMlF4MFZIWng4bFZGcE1YbnVCbmJ2WVBJbGd4NDh2MWZD?= =?utf-8?B?bVRJNEY3dUg0RkFERmhkS3cwQ0FxcklTVExXdnRBNHpZMWRCZVFWSHFZR3pa?= =?utf-8?Q?1uQDMTTHB9UlKtLcdYtBwe0cFNWSP4Zp3qaag=3D?=
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: tU3gJ8tFy/KfjPPD3iimrgifF7YqxA+VQ/hyPQLAWSMxMuG5jrsLajDVYaorn3Jdsyiht4aZaCudN3SgTulKEYT1j3NOoLWeWrKydM9p3sTt3il+rj7m3pVLoTajEafuNnyp3jcZhRJ7X5tg433HIy4i7xdd5IpyDdpf5j8tK3HTooLMYET3fVYYaQ2O5ufZ7/bSpumCbThCgIWdACd/4+kP8z6Z6N9T/xmBbxlmse48RKy7PjAfCqr1d4q2g06hDk7O3mYDH0DGu3w2any4CBzVI1nUNbWrSzj8dqM2hWo5/D8kYR2FeLdcf6ZG7aBQac1mNclfxu0CP+K44W8VXTI8v6dMIsgFa9YELSIppCQToBsGZZPa3S5jAvCsfXpiNu6Sb2YdCZpa+fLtHeReuaCrOIZnTaodHkKY+F7E4B0=
Content-Type: text/plain; charset="utf-8"
Content-ID: <665BF445716C274299E47C4D3C87F282@namprd17.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: sectigo.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 4bd16097-ff7f-4f48-62e1-08d69b16d205
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Feb 2019 11:46:01.8056 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-id: 0e9c4894-6caa-465d-9660-4b6968b49fb7
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR17MB3355
Archived-At: 
Subject: Re: [Trans] [TLS] ct_compliant cached info field
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Public Notary Transparency working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Feb 2019 11:46:10 -0000

VGhhbmtzIEVLUi4NCg0KRG9uZSwgaW4gaHR0cHM6Ly9naXRodWIuY29tL2dvb2dsZS9jZXJ0aWZp
Y2F0ZS10cmFuc3BhcmVuY3ktcmZjcy9wdWxsLzMwNw0KDQpPbiAyMi8wMi8yMDE5IDE0OjUxLCBF
cmljIFJlc2NvcmxhIHdyb3RlOg0KPiBUaGF0IHdvcmtzIGZvciBtZQ0KPiANCj4gLUVrcg0KPiAN
Cj4gDQo+IE9uIEZyaSwgRmViIDIyLCAyMDE5IGF0IDY6NDEgQU0gUm9iIFN0cmFkbGluZyA8cm9i
QHNlY3RpZ28uY29tIA0KPiA8bWFpbHRvOnJvYkBzZWN0aWdvLmNvbT4+IHdyb3RlOg0KPiANCj4g
ICAgIEVLUiwgTWFydGluLA0KPiANCj4gICAgIEhpLCBhbmQgc29ycnkgZm9yIHRoZSBsb25nIGRl
bGF5IGluIHJlcGx5aW5nLg0KPiANCj4gICAgIFRoaXMgb3JpZ2luYXRlZCBpbiBbMV0gYW5kIHdh
cyBhZGRlZCB0byA2OTYyLWJpcyBpbiBbMl0uwqAgVGhlDQo+ICAgICBtb3RpdmF0aW9uDQo+ICAg
ICB3YXMgdG8gcHJvdmlkZSBhIG1lY2hhbmlzbSB0byBwZXJtaXQgYSBUTFMgc2VydmVyIHRvIGF2
b2lkIHNlbmRpbmcgQ1QNCj4gICAgIGFydGlmYWN0cyAoU0NUcywgU1RIcywgaW5jbHVzaW9uIHBy
b29mcykgdGhhdCBpdCBrbm93cyB0aGUgVExTIGNsaWVudA0KPiAgICAgYWxyZWFkeSBoYXMgb3Ig
ZG9lc24ndCBuZWVkLCB0aGVyZWJ5IHJlZHVjaW5nIGJ5dGVzIG9uIHRoZSB3aXJlIGZvcg0KPiAg
ICAgY29uc3RyYWluZWQgYW5kIGhpZ2gtdm9sdW1lIGVudmlyb25tZW50cy4NCj4gDQo+ICAgICBU
aGUgYXBwcm9hY2ggZW52aXNhZ2VkIGJ5IFJGQzc5MjQgc2VlbXMgdG8gYmU6ICJoZXJlJ3MgYSBs
aXN0IG9mIFRMUw0KPiAgICAgbWVzc2FnZSBmaW5nZXJwcmludHMgSSd2ZSByZWNlaXZlZCBwcmV2
aW91c2x5OyBwbGVhc2UgZG9uJ3Qgc2VuZCB0aGVzZQ0KPiAgICAgZXhhY3QgbWVzc2FnZXMgdG8g
bWUgYWdhaW4iLsKgIFRoaXMgd29ya3MgZm9yIHN0YW5kLWFsb25lIG1lc3NhZ2VzIHRoYXQNCj4g
ICAgIGNvbnRhaW4gb25lIGl0ZW0sIHN1Y2ggYXMgdGhlIHNlcnZlcidzIENlcnRpZmljYXRlIG1l
c3NhZ2UgKHdoaWNoDQo+ICAgICBjb250YWlucyAxIHNlcnZlciBjZXJ0aWZpY2F0ZSBjaGFpbiku
DQo+IA0KPiAgICAgSG93ZXZlciwgaW4gNjk2Mi1iaXMncyBjYXNlLCBTQ1RzIGFuZCBpbmNsdXNp
b24gcHJvb2ZzIGFyZSBub3QNCj4gICAgIHN0YW5kLWFsb25lIGl0ZW1zOyBpbnN0ZWFkLCB0aGV5
IGNvcnJlc3BvbmQgdG8gcGFydGljdWxhciBjZXJ0aWZpY2F0ZXMuDQo+ICAgICBFYWNoIHJlbGV2
YW50IFRMUyBtZXNzYWdlIHdpbGwgY29udGFpbiBhIFRyYW5zSXRlbUxpc3QsIHdoaWNoIHdpbGwN
Cj4gICAgIHByb2JhYmx5IGNvbnRhaW4gYXQgbGVhc3QgYSBzZXQgb2Ygc2V2ZXJhbCBTQ1RzOyBh
bmQgd2hpbHN0IGVhY2ggU0NUIGlzDQo+ICAgICBzdGF0aWMsIHRoZSBzZXQgKGFuZCB0aGUgb3Jk
ZXIgd2l0aGluIHRoZSBzZXQpIGlzIG5vdC7CoCBUaGVyZWZvcmUsIHRoZQ0KPiAgICAgYXBwcm9h
Y2ggb2YgY2FjaGluZyBUTFMgbWVzc2FnZXMgYnkgZmluZ2VycHJpbnQgZGlkbid0IGxvb2sgbGlr
ZSBpdA0KPiAgICAgd291bGQgd29yayBmb3IgdXMuDQo+IA0KPiAgICAgV2UgY29uY2x1ZGVkIHRo
YXQgaXQgd291bGQgbWFrZSBtb3JlIHNlbnNlIGZvciB0aGUgY2xpZW50IHRvIG1ha2UgYQ0KPiAg
ICAgbW9yZQ0KPiAgICAgaGlnaC1sZXZlbCBzdGF0ZW1lbnQ6ICJoZXJlJ3MgYSBsaXN0IG9mIGNl
cnRpZmljYXRlIGZpbmdlcnByaW50cyB0aGF0DQo+ICAgICBJJ3ZlIHJlY2VpdmVkIHByZXZpb3Vz
bHkgYW5kIHRoYXQgSSBhbHJlYWR5IHJlZ2FyZCBhcyBiZWluZw0KPiAgICAgQ1QtY29tcGxpYW50
Ii4NCj4gDQo+ICAgICBUaGlzIGlzbid0IGFuIGVzc2VudGlhbCBwYXJ0IG9mIDY5NjItYmlzLsKg
IE90aGVyIHRoYW4gQmVuIEwncyAiU291bmRzDQo+ICAgICBsaWtlIGEgZ29vZCBpZGVhIiBjb21t
ZW50IGluIFsxXSwgSSBkb24ndCByZWNhbGwgYW55b25lIGNvbW1lbnRpbmcNCj4gICAgIG9uIGl0
DQo+ICAgICB1bnRpbCBFS1Igc3RhcnRlZCB0aGlzIHRocmVhZC4NCj4gDQo+ICAgICBJIHByb3Bv
c2UgdG8gcmVtb3ZlIHRoaXMgY2FjaGVkLWluZm8gbWVjaGFuaXNtIGZyb20gNjk2Mi1iaXMsIGlm
IG5vYm9keQ0KPiAgICAgb2JqZWN0cy7CoCAoSXQgY291bGQgb2YgY291cnNlIGJlIHJldmlzaXRl
ZCBpbiBzb21lIGZ1dHVyZSBkb2N1bWVudCwgaWYNCj4gICAgIHRoZXJlJ3MgaW50ZXJlc3QpLg0K
PiANCj4gDQo+ICAgICBbMV0gaHR0cHM6Ly90cmFjLmlldGYub3JnL3RyYWMvdHJhbnMvdGlja2V0
LzExMQ0KPiANCj4gICAgIFsyXSBodHRwczovL2dpdGh1Yi5jb20vZ29vZ2xlL2NlcnRpZmljYXRl
LXRyYW5zcGFyZW5jeS1yZmNzL3B1bGwvMTg2DQo+IA0KPiAgICAgT24gMzEvMTIvMjAxOCAxNDoz
NiwgRXJpYyBSZXNjb3JsYSB3cm90ZToNCj4gICAgICA+ICsgdHJhbnMNCj4gICAgICA+DQo+ICAg
ICAgPiBPbiBTdW4sIERlYyAzMCwgMjAxOCBhdCAxMDowNiBQTSBNYXJ0aW4gVGhvbXNvbg0KPiAg
ICAgPG10QGxvd2VudHJvcHkubmV0IDxtYWlsdG86bXRAbG93ZW50cm9weS5uZXQ+DQo+ICAgICAg
PiA8bWFpbHRvOm10QGxvd2VudHJvcHkubmV0IDxtYWlsdG86bXRAbG93ZW50cm9weS5uZXQ+Pj4g
d3JvdGU6DQo+ICAgICAgPg0KPiAgICAgID4NCj4gICAgICA+wqAgwqAgwqBPbiBGcmksIERlYyAy
OCwgMjAxOCwgYXQgMDQ6NTgsIEVyaWMgUmVzY29ybGEgd3JvdGU6DQo+ICAgICAgPsKgIMKgIMKg
ID4gUGxlYXNlIHRha2UgYSBsb29rIGF0DQo+ICAgICAgPsKgIMKgIMKgID4NCj4gICAgICA+DQo+
ICAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi10cmFucy1yZmM2OTYy
LWJpcy0zMCNzZWN0aW9uLTYuNQ0KPiAgICAgID4NCj4gICAgICA+wqAgwqAgwqBBdCBhIG1pbmlt
dW0sIHRoaXMgd291bGQgc2VlbSB0byB1cGRhdGUgY2FjaGVkX2luZm8uDQo+ICAgICAgPg0KPiAg
ICAgID7CoCDCoCDCoFRoZXJlJ3Mgbm90IGEgbG90IG9mIG1lYXQgb24gdGhpcyB0ZXh0LsKgIEl0
IHNlZW1zIHRvIGJlDQo+ICAgICBzYXlpbmcgdGhhdA0KPiAgICAgID7CoCDCoCDCoGlmIHlvdSBh
cmUgcHJvdmlkaW5nIHRyYW5zcGFyZW5jeV9pbmZvLCB0aGVuIHlvdSBjYW4gcHJvdmlkZSBhDQo+
ICAgICAgPsKgIMKgIMKgY2VydGlmaWNhdGUgb3RoZXIgdGhhbiBhbnkgb2YgdGhlIGNlcnRpZmlj
YXRlcyB0aGF0IHRoZSBjbGllbnQNCj4gICAgICA+wqAgwqAgwqBiZWxpZXZlcyB0byBiZSBDVCBj
b21wbGlhbnQuwqAgQWxzbywgeW91IGRvbid0IHByb3ZpZGUNCj4gICAgICJ4NTA5X3NjdF92MiIN
Cj4gICAgICA+wqAgwqAgwqBvciAicHJlY2VydF9zY3RfdjIiIGluIHRyYW5zcGFyZW5jeV9pbmZv
Lg0KPiAgICAgID4NCj4gICAgICA+wqAgwqAgwqBIb3cgaXMgdGhlIGNsaWVudCB0aGVuIGFibGUg
dG8gZGV0ZXJtaW5lIHRoYXQgdGhpcyBuZXcNCj4gICAgIGNlcnRpZmljYXRlDQo+ICAgICAgPsKg
IMKgIMKgaXMgQ1QgY29tcGxpYW50P8KgIFVzaW5nwqAgImluY2x1c2lvbl9wcm9vZl92MiIgYW5k
DQo+ICAgICAgPsKgIMKgIMKgInNpZ25lZF90cmVlX2hlYWRfdjIiIChvciBvbmUgb3Igb3RoZXIp
P8KgIElmIHNvLCB0aGUgdGV4dCBkb2Vzbid0DQo+ICAgICAgPsKgIMKgIMKgcG9pbnQgaW4gdGhh
dCBkaXJlY3Rpb24uDQo+ICAgICAgPg0KPiAgICAgID7CoCDCoCDCoFRoZXJlJ3MgYSBsb3Qgb2Yg
IndoeSIgbWlzc2luZyBpbiB0aGlzIGRvY3VtZW50LsKgIFdoeSB3b3VsZCBhDQo+ICAgICBjbGll
bnQNCj4gICAgICA+wqAgwqAgwqBjaG9vc2UgdG8gaW5kaWNhdGUgImN0X2NvbXBsaWFudCI/wqAg
V2h5IGlzIGNhY2hlZF9pbmZvIGJlaW5nDQo+ICAgICAgPsKgIMKgIMKgZXh0ZW5kZWQgaW4gdGhp
cyB3YXk/DQo+ICAgICAgPg0KPiAgICAgID7CoCDCoCDCoEkgbWlnaHQgZ3Vlc3MgdGhhdCB0aGUg
cmVhc29uIGhlcmUgaXMgdGhhdCB0aGUgZHJhZnQgYWltcyB0bw0KPiAgICAgYXZvaWQNCj4gICAg
ICA+wqAgwqAgwqBpbmNsdWRpbmcgaW5mb3JtYXRpb24gdGhhdCBtaWdodCBjaGFuZ2Ugb3ZlciB0
aW1lLCB3aGljaCB3b3VsZA0KPiAgICAgID7CoCDCoCDCoHJlbmRlciBjYWNoZXMgaW52YWxpZC7C
oCBJc24ndCB0aGF0IG1vdGl2YXRpb24gdG8gcmVjb21tZW5kIGFuIFNDVA0KPiAgICAgID7CoCDC
oCDCoG92ZXIgYW4gU1RIPw0KPiAgICAgID4NCj4gICAgICA+wqAgwqAgwqBTZXBhcmF0ZWx5LCB3
aHkgZG9lcyB0aGlzIGVzdGFibGlzaCBhIG5ldyByZWdpc3RyeSBmb3Igc2lnbmF0dXJlDQo+ICAg
ICAgPsKgIMKgIMKgc2NoZW1lcz/CoCBJdCBpcyBvYnZpb3VzbHkgdHJ5aW5nIHRvIGtlZXAgVExT
IGNvbXBhdGliaWxpdHksDQo+ICAgICBiYXNlZCBvbg0KPiAgICAgID7CoCDCoCDCoHRoZSBjb2Rl
cG9pbnRzLCBidXQgZm9ya2luZyB0aGUgcmVnaXN0cnkgaXMgYSBncmVhdCB3YXkgdG8gY3JlYXRl
DQo+ICAgICAgPsKgIMKgIMKgcHJvYmxlbXMuDQo+IA0KPiAgICAgLS0gDQo+ICAgICBSb2IgU3Ry
YWRsaW5nDQo+ICAgICBTZW5pb3IgUmVzZWFyY2ggJiBEZXZlbG9wbWVudCBTY2llbnRpc3QNCj4g
ICAgIEVtYWlsOiByb2JAc2VjdGlnby5jb20gPG1haWx0bzpyb2JAc2VjdGlnby5jb20+DQo+IA0K
DQotLSANClJvYiBTdHJhZGxpbmcNClNlbmlvciBSZXNlYXJjaCAmIERldmVsb3BtZW50IFNjaWVu
dGlzdA0KRW1haWw6IHJvYkBzZWN0aWdvLmNvbQ0KQnJhZGZvcmQsIFVLDQpPZmZpY2U6ICs0NDEy
NzQwMjQ3MDcNClNlY3RpZ28gTGltaXRlZA0KDQpUaGlzIG1lc3NhZ2UgYW5kIGFueSBmaWxlcyBh
c3NvY2lhdGVkIHdpdGggaXQgbWF5IGNvbnRhaW4gbGVnYWxseSANCnByaXZpbGVnZWQsIGNvbmZp
ZGVudGlhbCwgb3IgcHJvcHJpZXRhcnkgaW5mb3JtYXRpb24uIElmIHlvdSBhcmUgbm90IHRoZSAN
CmludGVuZGVkIHJlY2lwaWVudCwgeW91IGFyZSBub3QgcGVybWl0dGVkIHRvIHVzZSwgY29weSwg
b3IgZm9yd2FyZCBpdCwgDQppbiB3aG9sZSBvciBpbiBwYXJ0IHdpdGhvdXQgdGhlIGV4cHJlc3Mg
Y29uc2VudCBvZiB0aGUgc2VuZGVyLiBQbGVhc2UgDQpub3RpZnkgdGhlIHNlbmRlciBieSByZXBs
eSBlbWFpbCwgZGlzcmVnYXJkIHRoZSBmb3JlZ29pbmcgbWVzc2FnZXMsIGFuZCANCmRlbGV0ZSBp
dCBpbW1lZGlhdGVseS4NCg==


From nobody Mon Feb 25 03:51:10 2019
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3276812F295 for ; Mon, 25 Feb 2019 03:51:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=comodoca.onmicrosoft.com
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 v-gBjKFTa0NH for ; Mon, 25 Feb 2019 03:51:05 -0800 (PST)
Received: from NAM05-CO1-obe.outbound.protection.outlook.com (mail-eopbgr720082.outbound.protection.outlook.com [40.107.72.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD3AD1200B3 for ; Mon, 25 Feb 2019 03:51:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comodoca.onmicrosoft.com; s=selector1-sectigo-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=VWcbsgKMSPUgBWE78EX//worAxNoNJO1zxRcYcrHIZ0=; b=LZApap5PXDU648tnaNp270GGGwSHn57EhATzHf8QBOQReu6T8yS7iDCf2UZP8BS4sDJaxH7NO/E2830ypzWo16kxHiwQIuK2WC0DTR3DNcEOjRdqUqlUdU5BKkXxIjRpWRkP1nO++cPRFG/ZnDpDYvhd8AH3t3P1503AHk+ZmPE=
Received: from DM6PR17MB2716.namprd17.prod.outlook.com (20.178.224.155) by DM6PR17MB2842.namprd17.prod.outlook.com (20.178.227.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1643.16; Mon, 25 Feb 2019 11:51:02 +0000
Received: from DM6PR17MB2716.namprd17.prod.outlook.com ([fe80::80e1:4c3b:1fac:22b9]) by DM6PR17MB2716.namprd17.prod.outlook.com ([fe80::80e1:4c3b:1fac:22b9%6]) with mapi id 15.20.1643.019; Mon, 25 Feb 2019 11:51:02 +0000
From: Rob Stradling 
To: Eric Rescorla 
CC: Paul Wouters , Trans , "draft-ietf-trans-rfc6962-bis@tools.ietf.org" 
Thread-Topic: [Trans] AD Review of draft-ietf-trans-rfc6962-bis-30
Thread-Index: AQHUm8VH/tKW0BCiOkqCMmOx6Iywx6WOj/SAgAAWgQCAAp2zgIAABZuAgAAh6YCAAo4xgIBcz06A
Date: Mon, 25 Feb 2019 11:51:02 +0000
Message-ID: 
References:       
In-Reply-To: 
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-clientproxiedby: LO2P123CA0022.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:a6::34) To DM6PR17MB2716.namprd17.prod.outlook.com (2603:10b6:5:122::27)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=rob@sectigo.com; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [2a02:1788:4ff:1000:f68e:38ff:fe7a:a226]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: eff229ab-8444-4edd-ecd6-08d69b1783ff
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:DM6PR17MB2842; 
x-ms-traffictypediagnostic: DM6PR17MB2842:
x-ms-exchange-purlcount: 2
x-microsoft-antispam-prvs: 
x-forefront-prvs: 095972DF2F
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(346002)(136003)(39850400004)(366004)(376002)(189003)(199004)(305945005)(7736002)(966005)(31696002)(86362001)(386003)(6506007)(53546011)(478600001)(14454004)(102836004)(53936002)(6916009)(46003)(6246003)(105586002)(2616005)(476003)(106356001)(446003)(11346002)(256004)(14444005)(8676002)(81156014)(52116002)(81166006)(76176011)(186003)(99286004)(8936002)(6116002)(229853002)(97736004)(71190400001)(68736007)(6436002)(6486002)(4326008)(25786009)(54906003)(5660300002)(71200400001)(6512007)(6306002)(2906002)(93886005)(316002)(486006)(31686004)(36756003); DIR:OUT; SFP:1101; SCL:1; SRVR:DM6PR17MB2842; H:DM6PR17MB2716.namprd17.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: sectigo.com does not designate permitted sender hosts)
x-microsoft-exchange-diagnostics: =?utf-8?B?MTtETTZQUjE3TUIyODQyOzIzOjJMZkRkYzNYWmlaRlRIc3c3a0pJUmFNTnBj?= =?utf-8?B?Nk5yRk1FVWRJWHVNdFVnRTU2Q0N0U1dDZjNYQ3hUbzgwL2xBZVE0VFRKUFpt?= =?utf-8?B?L1ptcEVGNXRSWWJaK3lYZmR1Wm5yTEhHdVhFemZVUzRkL3dreHFnbUxJTHl5?= =?utf-8?B?QlBTYnRYVjVPUDhEZTFFSTlVbmcrb2UzMkVIcWRITlBYZGRYRDhJVGxKZDRa?= =?utf-8?B?czBKU1VkMXpjWi8ybWVSUC9wOW5UTURIWE8wb2tGRUNpQnlZQjZEZCtJWkJC?= =?utf-8?B?bzkwSUtiVm0wWGhTVFYrL2tjcFl6Mzl2Wk5WTjBpVEp6OUVKaDRaTHpselZC?= =?utf-8?B?NmpVMkMwc092akNYbGY5YkhmNFNmbTE2ekRaQlM0Sk5yMVVOd3V4aEl4Ym9Y?= =?utf-8?B?bEdsQmIvUTVRUWtiU0NuUW9weHlySmpQb1hsVzVCeGdIQytVQmdwdm1RV2pU?= =?utf-8?B?Nng5RHI1Nlp6Y3VaVmlYRTh0ckZOeng1cEN1S0VhWldrWmo3VHFIc2Rxc1hp?= =?utf-8?B?akc1d3Q0eDVRMjB1V1RyVEhTdkdCQU1ZRnhKWkhRc09OZ05LWXBnM1Z3WGZh?= =?utf-8?B?cnJYOUoxK0pqc29La3NoSEk5cUtRczg2ZkNvRVdDajN1SjRIZEZFS3VISk9O?= =?utf-8?B?Zmprbzl0UHo2bmJBbVMvSXg1Y0FMV2c5dDNjTlM0UjJGRU85ckVJVFRwYnc1?= =?utf-8?B?OHIxYXFTemtoeGliQkFYTGlQLzB3M1JqckxUVnhZQkczVGtFcTY5THNYOFRt?= =?utf-8?B?eTkxaS91Z1lCQ29PS2U5WjlsV29oelI2akRVMlYzQmFycms2VzFCVmZnMTJ0?= =?utf-8?B?QnlSNkN0K3FURmwwMzhObndmWTVqREEyTEpOa2xsWit5UW1NSllqeWxWS0Qy?= =?utf-8?B?bVM1TGFRaVZpTGZGU25QS2JPWnVkRUNxdHJlcnVrMVJpcVhPMW9jOERhVk54?= =?utf-8?B?NkJ1cnZrdWMvQURCdjZpRy82Mkx4TmUyNkhsNSttRU9FenB5a2Q4TEJrbmVB?= =?utf-8?B?WTFISzZqc3VWeS84ak5UUU45dFhZUW9sOHMwYzRjYmRDWm5kWkJSdE5vYy9W?= =?utf-8?B?Y1R5LzFDRDZUQUZseUdsbm8zbUtqVThCVG4yZGlhUnpFTFFBMU40YndvRzZF?= =?utf-8?B?WXNRekJ3dlJXV3VOb3lGN1VHRC9vay9nRjB0NXk2ZldyaEI1cVYwa2NGZzRs?= =?utf-8?B?TkJvSFVXRVBNZngvMFNDWjJFUkQyQnNPNkVXcDVlWEJ4UUM5TDhmU0dITUtM?= =?utf-8?B?MDJ2dEZVRkEreWY5S1dBUzVSTVpVdUEwaEU1ckxmcWg4djFXSTYzWUs0Rm1w?= =?utf-8?B?RnlZeWc0U09LeFlmeVBIbmN2STdQYmh2QjVESDg5L1g1US9qQ2VSSWR2UUR4?= =?utf-8?B?SENQRW0xb0NzTkwvSUpoVjRUOHFaSVIzRXFNS3BaR094eGcrbUNhY0hHT0h4?= =?utf-8?B?WGlqamhRU2pLMlpuSldOc1NINHVLVVZ0Rm84eW1VZW85eWdkQWU2WDZvUGw3?= =?utf-8?B?Zm1tWnJFL2JVelhTRDdoWTJkcTFaV3M1UTBoQWY0ck96dkxydEtjT3BwbmlP?= =?utf-8?B?dDQyWllYTUtaaFlpcy9PRlB6OVY1TWVsUDNCTVVEUTZLS2ZvM29oY3RkVGp6?= =?utf-8?B?OW05NS9ZakQwRE54WkY4aXZrQ3cyVFExNkx5bzdKNzhkNG5rTkFRZUpyZjNx?= =?utf-8?B?dDE5enU3RnczZzh4VUFUWTFLZlRSeGVNSklqdktvUjd3UFZsRnlYRVM0cDZV?= =?utf-8?Q?xTOUVH2ZbFb9LR8Uy117lV9ySAqod+1Ot9JjY=3D?=
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: WHGIRV6T6wKsB/6a1EL12AcEv+YH2tOTe4zqrG7z85jVdkcDw7DyyG6PhM05DrP+r8Qt+wvZlQFZaJpvOKJ/L6guW84qjHRLOhZpMCFtHpTTQOITVIx63J0o9j/TB4OSjxZn0c/JnbGE0dS8Zoq8h1hCpqH2CbeWlw5q8TCSIuDjJENsCFpIkaslfH2lEk+K4wO9OWWcfwGKc671deVpNC8c0rOmpPpc9mJSpGp8XjcVBfKR4obx2lmnr+aCp+1MqulXtaPWPD0A7zU+zxToco6KAyMgNo1+3dCdGI6SZePs4jDjpmhLGyMpkYDGllE8sjLxLQ5a/5HNvn6j+M2I5MmSJW/FLaSQt6KoMhmJafegOOArWo9fq8VM93o7XaaDCF2JNehB9Cofris7LKkfTkJsUjamywZ/7aER/+M96YY=
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: sectigo.com
X-MS-Exchange-CrossTenant-Network-Message-Id: eff229ab-8444-4edd-ecd6-08d69b1783ff
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Feb 2019 11:51:00.4043 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-id: 0e9c4894-6caa-465d-9660-4b6968b49fb7
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR17MB2842
Archived-At: 
Subject: Re: [Trans] AD Review of draft-ietf-trans-rfc6962-bis-30
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Public Notary Transparency working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Feb 2019 11:51:08 -0000

RUtSLA0KDQpXZSBqdXN0IHB1Ymxpc2hlZCAtMzEsIHdoaWNoIHdlIGJlbGlldmUgYWRkcmVzc2Vz
IGFsbCBvZiB5b3VyIEEtRCByZXZpZXcgDQpjb21tZW50cy4gIFBsZWFzZSBsZXQgdXMga25vdyBp
ZiB0aGVyZSBhcmUgYW55IG90aGVyIGlzc3VlcyB0byBhZGRyZXNzIA0KYmVmb3JlIDY5NjItYmlz
IGNhbiBiZSBzZW50IHRvIHRoZSBJRVNHLg0KDQpUaGFua3MuDQoNCk9uIDI4LzEyLzIwMTggMTA6
MzMsIFJvYiBTdHJhZGxpbmcgd3JvdGU6DQo+IE9uIDI2LzEyLzIwMTggMTk6MzEsIFBhdWwgV291
dGVycyB3cm90ZToNCj4+IE9uIFdlZCwgMjYgRGVjIDIwMTgsIEVyaWMgUmVzY29ybGEgd3JvdGU6
DQo+IDxzbmlwPg0KPj4+ICDCoMKgwqDCoMKgID7CoCDCoCDCoCDCoD4gPsKgwqDCoMKgwqAgSW4g
YWRkaXRpb24gdG8gbm9ybWFsIHZhbGlkYXRpb24gb2YgdGhlIHNlcnZlcg0KPj4+IGNlcnRpZmlj
YXRlIGFuZCBpdHMNCj4+PiAgwqDCoMKgwqDCoCA+wqAgwqAgwqAgwqA+ID7CoMKgwqDCoMKgIGNo
YWluLCBDVC11c2luZyBUTFMgY2xpZW50cyBNVVNUIHZhbGlkYXRlIGVhY2gNCj4+PiByZWNlaXZl
ZCBTQ1QgZm9yIHdoaWNoDQo+Pj4gIMKgwqDCoMKgwqAgPsKgIMKgIMKgIMKgPiA+wqDCoMKgwqDC
oCB0aGV5IGhhdmUgdGhlIGNvcnJlc3BvbmRpbmcgbG9nJ3MgcGFyYW1ldGVycy4NCj4+PiBUbyB2
YWxpZGF0ZSBhbiBTQ1QsIGENCj4+PiAgwqDCoMKgwqDCoCA+wqAgwqAgwqAgwqA+ID7CoMKgwqDC
oMKgIFRMUyBjbGllbnQgY29tcHV0ZXMgdGhlIHNpZ25hdHVyZSBpbnB1dCBieQ0KPj4+IGNvbnN0
cnVjdGluZyBhICJUcmFuc0l0ZW0iDQo+Pj4gIMKgwqDCoMKgwqAgPsKgIMKgIMKgIMKgPiA+wqDC
oMKgwqDCoCBvZiB0eXBlICJ4NTA5X2VudHJ5X3YyIiBvciAicHJlY2VydF9lbnRyeV92MiIsDQo+
Pj4gZGVwZW5kaW5nIG9uIHRoZSBTQ1Qncw0KPj4+ICDCoMKgwqDCoMKgID7CoCDCoCDCoCDCoD4N
Cj4+PiAgwqDCoMKgwqDCoCA+wqAgwqAgwqAgwqA+IEhvdyBkbyBJIHByb2NlZWQgaWYgSSBoYXZl
IGFuIGludmFsaWQgU0NUIGJ1dCBieQ0KPj4+IHBvbGljeSBJIHdvdWxkIGFjY2VwdA0KPj4+ICDC
oMKgwqDCoMKgID7CoCDCoCDCoCDCoD4gdGhlIGNlcnRpZmljYXRlIGlmIHRoZSBTQ1QgaGFkIGJl
ZW4gb21pdHRlZC4NCj4+PiAgwqDCoMKgwqDCoCA+DQo+Pj4gIMKgwqDCoMKgwqAgPsKgIMKgIMKg
IMKgVGhlIHNlY3Rpb24gcXVvdGVkIHRlbGxzIHlvdSB3aGF0IHRvIGRvIHdpdGggaW52YWxpZA0K
Pj4+IFNDVCdzLCBuYW1lbHkgZmFpbCB0aGUgdmFsaWRhdGlvbi4NCj4+PiAgwqDCoMKgwqDCoCA+
DQo+Pj4gIMKgwqDCoMKgwqAgPiBUaGlzIHRleHQgZG9lcyBub3QgdGVsbCB5b3UgdG8gZmFpbCB2
YWxpZGF0aW9uIG9mIHRoZQ0KPj4+IGNlcnRpZmljYXRlOyBpdCB0ZWxscyB5b3UgeW91IE1VU1Qg
dmFsaWRhdGUgYWxsIHRoZSBTQ1RzIGFuZCB0aGVuDQo+Pj4gZG9lc24ndCB0ZWxsIHlvdSBob3cg
dG8gYmVoYXZlIGlmIG9uZSBkb2VzIG5vdCB2YWxpZGF0ZS4NCj4+Pg0KPj4+ICDCoMKgwqDCoMKg
IEkgYmVsaWV2ZSB0aGUgYWN0aW9ucyBvZiB3aGF0IHRvIGRvIG9uIHZhbGlkYXRpb24gZmFpbHVy
ZSBhcmUgYQ0KPj4+IGxvY2FsDQo+Pj4gIMKgwqDCoMKgwqAgcG9saWN5LiBJdCBjb3VsZCBiZSBh
IHRvdGFsIHJlamVjdGlvbiwgYSBwb3B1cCBldGMuIFdoaWxlDQo+Pj4gNjk2MmJpcyBnaXZlcw0K
Pj4+ICDCoMKgwqDCoMKgIGd1aWRhbmNlIGZvciBDVC11c2luZyBUTFMgY2xpZW50cywgaXQgaXMg
bm90IGEgY2xpZW50IHNwZWNpZmljYXRpb24NCj4+PiAgwqDCoMKgwqDCoCBkb2N1bWVudC4gU2Vl
IGFsc286IGh0dHBzOi8vdHJhYy5pZXRmLm9yZy90cmFjL3RyYW5zL3RpY2tldC8xNQ0KPj4+DQo+
Pj4NCj4+PiBCdXQgdGhlcmUgaXMgYSBNVVNUIGhlcmUgZm9yIGNsaWVudHMsIGFuZCBzbyBhZ2Fp
biwgdGhlIGJvdW5kYXJpZXMgb2YNCj4+PiB0aGF0IE1VU1QgbmVlZCB0byBiZSBjbGVhci4NCj4+
DQo+PiBUaGUgTVVTVCB0ZWxscyB5b3UgdG8gdmFsaWRhdGUsIG5vdCB0byB0ZWxsIHlvdSBleGFj
dGx5IHdoYXQgdG8gZG8gd2hlbg0KPj4gdmFsaWRhdGlvbiBmYWlscy4gU28gaXQgdGVsbHMgeW91
IHRoYXQgeW91IGNhbm5vdCBza2lwIHZhbGlkYXRpbmcgdGhlDQo+PiAzcmQgU0NUIGV2ZW4gaWYg
eW91IG9ubHkgbmVlZGVkIHR3byBhY2NvcmRpbmcgdG8geW91ciBjbGllbnQgcG9saWN5LiBTbw0K
Pj4gSSBzdGlsbCBkbyBub3QgdW5kZXJzdGFuZCB3aHkgeW91IHRoaW5rIHRoaXMgY2FzZSBpcyBh
IHByb2JsZW0uDQo+Pg0KPj4+ICDCoMKgwqDCoMKgID7CoCDCoCDCoCDCoEkgc3VzcGVjIHlvdXIg
cmVhbCBxdWVzdGlvbiBpcyBpZiB0aGF0IGlzIHRoZSByaWdodA0KPj4+IHRoaW5nIHRvIGRvIHdo
ZW4NCj4+PiAgwqDCoMKgwqDCoCA+wqAgwqAgwqAgwqBTQ1QncyB3ZXJlIG5vdCBtYW5kYXRvcnkg
YXMgcG9saWN5IGZvciB0aGUgQ1QtdXNpbmcNCj4+PiBjbGllbnRzPw0KPj4+ICDCoMKgwqDCoMKg
ID4NCj4+PiAgwqDCoMKgwqDCoCA+IE5vLCB0aGF0J3Mgbm90IG15IHF1ZXN0aW9uLiBDb25zaWRl
ciB0aGUgY2FzZSB3aGVyZSBteSBwb2xpY3kNCj4+PiBpcyB0aGF0IHRoZXJlIG11c3QgYmUgMiB2
YWxpZCBTQ1RzIGFuZCB0aGUgc2VydmVyIHN1cHBsaWVzIDMgYnV0IG9ubHkNCj4+PiAyIHZhbGlk
YXRlLiBJJ20gcmVxdWlyZWQgdG8gdmFsaWRhdGUgYWxsIG9mIHRoZW0sIGJ1dCBJIGNvdWxkDQo+
Pj4gIMKgwqDCoMKgwqAgY29uZm9ybSB3aXRoDQo+Pj4gIMKgwqDCoMKgwqAgPiB0aGlzIHRleHQg
YnkgdmFsaWRhdGluZyBhbGwgdGhyZWUsIGxvZ2dpbmcgdGhlIGZhaWx1cmUsIGFuZA0KPj4+IG1v
dmluZyBvbi4NCj4+Pg0KPj4+ICDCoMKgwqDCoMKgIFRoYXQgYmVoYXZpb3VyIGlzIHVwIHRvIHRo
ZSBjbGllbnQgaW1wbGVtZW50YXRpb24gYW5kL29yIGxvY2FsDQo+Pj4gcG9saWN5Lg0KPj4+DQo+
Pj4NCj4+PiBHcmVhdC4gVGhlbiB0aGUgdGV4dCBzaG91bGQgc2F5IHRoYXQuDQo+Pg0KPj4+IEkn
bSBub3QgYXNraW5nIGZvciBhIGNvbXBsZXRlIGNsaWVudCBzcGVjaWZpY2F0aW9uLiBXaGF0IEkg
YW0gYXNraW5nDQo+Pj4gaXMgdGhhdCBldmVyeSBub3JtYXRpdmUgcmVxdWlyZW1lbnQgaW4gdGhp
cyBzcGVjaWZpY2F0aW9uIGJlDQo+Pj4gdW5hbWJpZ3VvdXMsIGFuZCBJIGRvIG5vdCBiZWxpZXZl
IHRoYXQgdGhpcyBvbmUgaXMuDQo+Pg0KPj4gSSB0aGluayBpdCBkb2VzLCBidXQgSSBndWVzcyBp
dCB3b24ndCBoYXJtIHRvIG1ha2UgaXQgbW9yZSBleHBsaWNpdC4NCj4+IEknbGwgbGVhdmUgdGhh
dCB1cCB0byB0aGUgYXV0aG9ycy4NCj4gDQo+IFRoaXMgaXMgYWxyZWFkeSBjb3ZlcmVkIGJ5IHNl
Y3Rpb24gOC4xLjYgIkV2YWx1YXRpbmcgY29tcGxpYW5jZSIsIGJ1dC4uLk9LLg0KPiANCj4gUHJv
cG9zZWQgdGV4dDoNCj4gaHR0cHM6Ly9naXRodWIuY29tL2dvb2dsZS9jZXJ0aWZpY2F0ZS10cmFu
c3BhcmVuY3ktcmZjcy9wdWxsLzMwNg0KPiANCg0KLS0gDQpSb2IgU3RyYWRsaW5nDQpTZW5pb3Ig
UmVzZWFyY2ggJiBEZXZlbG9wbWVudCBTY2llbnRpc3QNCkVtYWlsOiByb2JAc2VjdGlnby5jb20N
CkJyYWRmb3JkLCBVSw0KT2ZmaWNlOiArNDQxMjc0MDI0NzA3DQpTZWN0aWdvIExpbWl0ZWQNCg0K
VGhpcyBtZXNzYWdlIGFuZCBhbnkgZmlsZXMgYXNzb2NpYXRlZCB3aXRoIGl0IG1heSBjb250YWlu
IGxlZ2FsbHkgDQpwcml2aWxlZ2VkLCBjb25maWRlbnRpYWwsIG9yIHByb3ByaWV0YXJ5IGluZm9y
bWF0aW9uLiBJZiB5b3UgYXJlIG5vdCB0aGUgDQppbnRlbmRlZCByZWNpcGllbnQsIHlvdSBhcmUg
bm90IHBlcm1pdHRlZCB0byB1c2UsIGNvcHksIG9yIGZvcndhcmQgaXQsIA0KaW4gd2hvbGUgb3Ig
aW4gcGFydCB3aXRob3V0IHRoZSBleHByZXNzIGNvbnNlbnQgb2YgdGhlIHNlbmRlci4gUGxlYXNl
IA0Kbm90aWZ5IHRoZSBzZW5kZXIgYnkgcmVwbHkgZW1haWwsIGRpc3JlZ2FyZCB0aGUgZm9yZWdv
aW5nIG1lc3NhZ2VzLCBhbmQgDQpkZWxldGUgaXQgaW1tZWRpYXRlbHkuDQo=


From nobody Thu Feb 28 06:37:42 2019
Return-Path: 
X-Original-To: trans@ietf.org
Delivered-To: trans@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BB73130E9F; Thu, 28 Feb 2019 06:37:34 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: The IESG 
To: "IETF-Announce" 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.92.1
Auto-Submitted: auto-generated
Precedence: bulk
CC: ekr@rtfm.com, trans@ietf.org, draft-ietf-trans-rfc6962-bis@ietf.org, trans-chairs@ietf.org, Paul Wouters , paul@nohats.ca
Reply-To: ietf@ietf.org
Sender: 
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Reply-To: ietf@ietf.org
Message-ID: <155136465424.28705.9131938298260461096.idtracker@ietfa.amsl.com>
Date: Thu, 28 Feb 2019 06:37:34 -0800
Archived-At: 
Subject: [Trans] Last Call:  (Certificate Transparency Version 2.0) to Experimental RFC
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Public Notary Transparency working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Feb 2019 14:37:34 -0000

The IESG has received a request from the Public Notary Transparency WG
(trans) to consider the following document: - 'Certificate Transparency
Version 2.0'
   as Experimental RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2019-03-14. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


   This document describes version 2.0 of the Certificate Transparency
   (CT) protocol for publicly logging the existence of Transport Layer
   Security (TLS) server certificates as they are issued or observed, in
   a manner that allows anyone to audit certification authority (CA)
   activity and notice the issuance of suspect certificates as well as
   to audit the certificate logs themselves.  The intent is that
   eventually clients would refuse to honor certificates that do not
   appear in a log, effectively forcing CAs to add all issued
   certificates to the logs.

   This document obsoletes RFC 6962.  It also specifies a new TLS
   extension that is used to send various CT log artifacts.

   Logs are network services that implement the protocol operations for
   submissions and queries that are defined in this document.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-trans-rfc6962-bis/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-trans-rfc6962-bis/ballot/


No IPR declarations have been submitted directly on this I-D.