From nobody Mon Sep 11 06:02:05 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5E75133047 for ; Mon, 11 Sep 2017 06:02:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 hK8pgjhvz2gV for ; Mon, 11 Sep 2017 06:01:56 -0700 (PDT) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (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 6AB3B13306C for ; Mon, 11 Sep 2017 06:01:53 -0700 (PDT) Received: by mail-io0-x22f.google.com with SMTP id j141so25455050ioj.4 for ; Mon, 11 Sep 2017 06:01:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to; bh=ziVNMQSzAN2HozsHDlo+CMD6t+cLPObHV1RBd/g03Ok=; b=ewFP8iiwrqvv3Cx8MiJ7Q7rTFQRlEVZUiJaxlg9LOy4jDYQsbFwCQ2ZAoR7Qus52Ni OwR4fFBI24a/8EhzfFtPcq3YvyUoXrZGleUbuVb4KjnAO7GKYZRLt1kVPPM61t5xm4C9 MYfz0p27d2d4+XDTBpDYDVX3XoYPKVf3HJySH7fNugSBFPQFugp8vQmpnxwYoJKaWNPx rIWQD3TMzAteiyRcbgell+jeY5wkLB1RlAnfM/dRD8qwnuR09twAGDumg0GwNkMMB4hL GZegpjS8LJCUP9M9jSNGql3Fn003CvDwz/guYDfSm34Wg57Jo1qMOBJuk6ML3Ldyfznv f8sQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=ziVNMQSzAN2HozsHDlo+CMD6t+cLPObHV1RBd/g03Ok=; b=qWrAIDzOPsQy9lNVyx5b9cKiMhz9nT4r1/vqbQ7nj45zlkkD/BcUlofr9+BAmPMFj3 wN6pY5+OssFBqZZeTLbn5lOcUpsCHN9ZXH1kNElQS3RWASKW/v0CcJtDpyJzjgUaHT3+ UeVOSUkB6yYPQlCf9BOeAUEghHQtSeRLh/PPnEevQtvN1SgXMwHC3O+Z2wxjTTjpK7Em LMsWYzfXN788jlkZ/12MyTW1T6TPdGbIhp8Sb+GNkWebDCy2sE+atXNsyMbSTMDY7QhJ Ya2Jq0RYaaXvju4qhKltAMSlsCUS/Hdu8uF+x3bjro0yC/mssv52QZ9hxUnxx7cH9EYl NBRQ== X-Gm-Message-State: AHPjjUhIOT9rlXWNftCY8pxrcMm3f2wego1CPzQH5dBjQigSzDiYVJbN nq9ZqvL63GLlwJxRdTeXtFBg6xx3WeaI X-Google-Smtp-Source: AOwi7QDnGJIAj6R4dB5m565HEW/qHaa5aWJyYLD1026XJn9vuuSbzdM4ePdJhkpJ4ehaTUylpWmJ3Ev0JZ1gjhg4p6M= X-Received: by 10.202.44.80 with SMTP id s77mr10628288ois.262.1505134912357; Mon, 11 Sep 2017 06:01:52 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.157.89.227 with HTTP; Mon, 11 Sep 2017 06:01:51 -0700 (PDT) From: Phillip Hallam-Baker Date: Mon, 11 Sep 2017 09:01:51 -0400 X-Google-Sender-Auth: CGFx3hfxn3f_nJ0XfG_Y4pPXgkw Message-ID: To: "saag@ietf.org" Content-Type: multipart/alternative; boundary="001a1137d83eca4b320558e987de" Archived-At: Subject: [saag] Blockchained log format X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Sep 2017 13:02:03 -0000 --001a1137d83eca4b320558e987de Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =E2=80=8BI now have the Mesh at a point where we can use it for real applic= ations. While working on writing application protocols, I noticed that a large number of applications have at their center a structure which is essentially just a sequence of entries that are 'mostly' append only. For example, a contacts file is a sequence of contacts, a bookmarks file a sequence of bookmarks, etc. etc. Even a mail spool or comments to a blog post, they all fit the same format. =E2=80=8BIt seems to me that it would be rather useful to have a cryptograp= hic file format that supported this type of interaction with confidentiality and integrity protections plus the ability to do incremental updates, to merge updates from two different logs that have got out of sync and the ability to read the file in forward and reverse directions - the most interesting information is usually at the end. I am looking at using at a JSON style encoding with some binary extensions as follows. The file consists of a header and a list of entries. The header contains a Jose structure with the cryptographic keying material for the rest of the file. This is the place where the public keys are specified, key exchange set up, etc. The list of entries consists of a sequence of frames. Each frame has the structure: The Length format follows the usual self describing approach and can be 1, 2, 4 or 8 bytes in length. The R-Length is the length in reverse order and MUST be exactly the same as the Length value or the file is declared corrupt. The R-Length value allows the log to be read in reverse order. Thus if we have a mail spool with 1 million entries, we can just read the last 200 by starting at the end and working back. This approach means that the size of the frame has to be known when it is written out. It is not possible to stream inside a frame but a stream may be represented as a sequence of frames. Within the frame itself, there is a structure
Each payload is encrypted under a new session key and IV. The header contains the following as authenticated data: * time added (used in synchronization) * digest value of * optional blockchain value Since we want to verify the data before unwrapping it or exposing it to infrastructure that has the keys, the authentication has to be on the outside and must therefore be on the encrypted data. The payload may be signed or MAC-ed The inclusion of an optional blockchain value allows a sequence of entries to be authenticated using a single signature verification. It will also make attempting to merge two sequences that have got out of sync a headache for the person writing the code. I suspect use of these features will be disjoint, pick one or the other. The simplest chaining mode would be for each entry to chain to the last digest value. A more efficient structure would be to use a Merkle tree. Ideas? Comments? --001a1137d83eca4b320558e987de Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
=E2= =80=8BI now have the Mesh at a point where we can use it for real applicati= ons. While working on writing application protocols, I noticed that a large= number of applications have at their center a structure which is essential= ly just a sequence of entries that are 'mostly' append only.
<= div class=3D"gmail_default" style=3D"font-size:small">
For example, a contacts file i= s a sequence of contacts, a bookmarks file a sequence of bookmarks, etc. et= c. Even a mail spool or comments to a blog post, they all fit the same form= at.

<= div class=3D"gmail_default" style=3D"font-size:small">
=E2=80=8BIt seems to me that i= t would be rather useful to have a cryptographic file format that supported= this type of interaction with confidentiality and integrity protections pl= us the ability to do incremental updates, to merge updates from two differe= nt logs that have got out of sync and the ability to read the file in forwa= rd and reverse directions - the most interesting information is usually at = the end.=C2=A0
=

=
I am looking at usin= g at a JSON style encoding with some binary extensions as follows.

The file consists of a header and= a list of entries.

The h= eader contains a Jose structure with the cryptographic keying material for = the rest of the file. This is the place where the public keys are specified= , key exchange set up, etc.

The list of entries consists of a sequence of frames. Each frame has the= structure:
<Length>= ; <data> <R-Length>

The Length format follows the usual self describing approach and can= be 1, 2, 4 or 8 bytes in length. The R-Length is the length in reverse ord= er and MUST be exactly the same as the Length value or the file is declared= corrupt. The R-Length value allows the log to be read in reverse order. Th= us if we have a mail spool with 1 million entries, we can just read the las= t 200 by starting at the end and working back.

This approach means that the size of the frame has to= be known when it is written out. It is not possible to stream inside a fra= me but a stream may be represented as a sequence of frames.


Within the frame itself, there is a structure

<Header> <Encrypted-= Payload>
Each payload = is encrypted under a new session key and IV.

The header contains the following as authenticated dat= a:
* time added= (used in synchronization)
* digest value of <Encrypted-Payload>
* optional blockchain value
<= div class=3D"gmail_default" style=3D"font-size:small">
Since we want to verify the da= ta before unwrapping it or exposing it to infrastructure that has the keys,= the authentication has to be on the outside and must therefore be on the e= ncrypted data.
=
The payloa= d may be signed or MAC-ed


The inclu= sion of an optional blockchain value allows a sequence of entries to be aut= henticated using a single signature verification. It will also make attempt= ing to merge two sequences that have got out of sync a headache for the per= son writing the code. I suspect use of these features will be disjoint, pic= k one or the other.

The s= implest chaining mode would be for each entry to chain to the last digest v= alue. A more efficient structure would be to use a Merkle tree.


Ideas? Comments?
--001a1137d83eca4b320558e987de-- From nobody Mon Sep 11 06:30:30 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C97CB13307E for ; Mon, 11 Sep 2017 06:30:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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=ethereum.org 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 t-VI_szN5cPj for ; Mon, 11 Sep 2017 06:30:27 -0700 (PDT) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (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 56B0D133079 for ; Mon, 11 Sep 2017 06:30:27 -0700 (PDT) Received: by mail-io0-x22f.google.com with SMTP id g32so8458870ioj.2 for ; Mon, 11 Sep 2017 06:30:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ethereum.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=9jWVptL/Pb4rqlM2LoelMxxRw/QSjmE03D/w5bbS6aA=; b=dnQhbApa1es5ju+CZVsr6nCsTVfADDYQKuC5hR6283hdG3Wqv9Wryy1Cg55GCY7E/W n138B6uWwf9LRhIHqvtNt9XQl+OUTC+KJFucdE8BeYGoHDfrb0HkEJyGIg/vK3sEQdsY VpHQG8yrR6RWPUIA85wH9skW0QFXrQrXjgau4= 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; bh=9jWVptL/Pb4rqlM2LoelMxxRw/QSjmE03D/w5bbS6aA=; b=N/ATUAKwDuEte0MgG5tx6gXIH5iNG9LPGdYqMsFYnMjh5aKkircWfh+CDrGShRvw/s mkbXrBfbedAdDNHjEBIHVAOvezESc9T7Kh2BQTad9jtxKOW7QPtxehW2hdT7Jhx8AtFG uUZ5BOYmBK8/L6ahzGqNwsyLQqLDm4tFFo7BdJlJtJyK84G+oIuuBWL0Q+fxjWPDrGCI upCOXjJkQjilneFRwFG0INbU+gNG/NPoaxRMxHXTJEdF0bWGBhysif6/r/rKmh2GPWvl 8lTNT2GSMn2lgIDJufb6SP9pVBVmt5NkGPVElJEvghKF81UsZ1D8aO7ROZ/WJAcAh+UM 8chA== X-Gm-Message-State: AHPjjUhtZharXLVJ2E3uuWwusbGN3IxpM/XPZLbNw1X9HKzv40gFidXg 2uyKi0KgIzPYAP7U+4hNGhiiWAvWJqwY2rM= X-Google-Smtp-Source: AOwi7QCx4wkuoQFlOjJNrdja55+D+R8He3+yLgoVizguUquBdN78kN/wVJknvIaD/Oy3v8TCgiWhijzbrXEoVXK+dgg= X-Received: by 10.202.216.193 with SMTP id p184mr1957520oig.124.1505136626514; Mon, 11 Sep 2017 06:30:26 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Nick Johnson Date: Mon, 11 Sep 2017 13:30:15 +0000 Message-ID: To: Phillip Hallam-Baker , "saag@ietf.org" Content-Type: multipart/alternative; boundary="001a113d57daf690fe0558e9edb2" Archived-At: Subject: Re: [saag] Blockchained log format X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Sep 2017 13:30:30 -0000 --001a113d57daf690fe0558e9edb2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Have you considered CBOR as an alternative to inventing your own binary encoding? -Nick Johnson On Mon, Sep 11, 2017 at 2:02 PM Phillip Hallam-Baker wrote: > =E2=80=8BI now have the Mesh at a point where we can use it for real appl= ications. > While working on writing application protocols, I noticed that a large > number of applications have at their center a structure which is > essentially just a sequence of entries that are 'mostly' append only. > > For example, a contacts file is a sequence of contacts, a bookmarks file = a > sequence of bookmarks, etc. etc. Even a mail spool or comments to a blog > post, they all fit the same format. > > > =E2=80=8BIt seems to me that it would be rather useful to have a cryptogr= aphic > file format that supported this type of interaction with confidentiality > and integrity protections plus the ability to do incremental updates, to > merge updates from two different logs that have got out of sync and the > ability to read the file in forward and reverse directions - the most > interesting information is usually at the end. > > > I am looking at using at a JSON style encoding with some binary extension= s > as follows. > > The file consists of a header and a list of entries. > > The header contains a Jose structure with the cryptographic keying > material for the rest of the file. This is the place where the public key= s > are specified, key exchange set up, etc. > > The list of entries consists of a sequence of frames. Each frame has the > structure: > > > > The Length format follows the usual self describing approach and can be 1= , > 2, 4 or 8 bytes in length. The R-Length is the length in reverse order an= d > MUST be exactly the same as the Length value or the file is declared > corrupt. The R-Length value allows the log to be read in reverse order. > Thus if we have a mail spool with 1 million entries, we can just read the > last 200 by starting at the end and working back. > > This approach means that the size of the frame has to be known when it is > written out. It is not possible to stream inside a frame but a stream may > be represented as a sequence of frames. > > > Within the frame itself, there is a structure > >
> > Each payload is encrypted under a new session key and IV. > > The header contains the following as authenticated data: > * time added (used in synchronization) > * digest value of > * optional blockchain value > > Since we want to verify the data before unwrapping it or exposing it to > infrastructure that has the keys, the authentication has to be on the > outside and must therefore be on the encrypted data. > > The payload may be signed or MAC-ed > > > The inclusion of an optional blockchain value allows a sequence of entrie= s > to be authenticated using a single signature verification. It will also > make attempting to merge two sequences that have got out of sync a headac= he > for the person writing the code. I suspect use of these features will be > disjoint, pick one or the other. > > The simplest chaining mode would be for each entry to chain to the last > digest value. A more efficient structure would be to use a Merkle tree. > > > Ideas? Comments? > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > --001a113d57daf690fe0558e9edb2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Have you considered CBOR as an alternative to inventing yo= ur own binary encoding?

-Nick Johnson

On Mon, Sep 11, 2017 at 2:02 PM Ph= illip Hallam-Baker <phill@halla= mbaker.com> wrote:
=E2=80=8BI = now have the Mesh at a point where we can use it for real applications. Whi= le working on writing application protocols, I noticed that a large number = of applications have at their center a structure which is essentially just = a sequence of entries that are 'mostly' append only.

For example, a contacts file is a seque= nce of contacts, a bookmarks file a sequence of bookmarks, etc. etc. Even a= mail spool or comments to a blog post, they all fit the same format.
=


=E2=80=8BIt seems to me that it would be= rather useful to have a cryptographic file format that supported this type= of interaction with confidentiality and integrity protections plus the abi= lity to do incremental updates, to merge updates from two different logs th= at have got out of sync and the ability to read the file in forward and rev= erse directions - the most interesting information is usually at the end.= =C2=A0


I am looking at using at a J= SON style encoding with some binary extensions as follows.

The file consists of a header and a list= of entries.
The header c= ontains a Jose structure with the cryptographic keying material for the res= t of the file. This is the place where the public keys are specified, key e= xchange set up, etc.

The = list of entries consists of a sequence of frames. Each frame has the struct= ure:

=
<Length> <d= ata> <R-Length>

= The Length format follows the usual self describing approach and can be 1, = 2, 4 or 8 bytes in length. The R-Length is the length in reverse order and = MUST be exactly the same as the Length value or the file is declared corrup= t. The R-Length value allows the log to be read in reverse order. Thus if w= e have a mail spool with 1 million entries, we can just read the last 200 b= y starting at the end and working back.

This approach means that the size of the frame has to be kno= wn when it is written out. It is not possible to stream inside a frame but = a stream may be represented as a sequence of frames.


Within the frame itself, there is a structure

<Header> <Encrypted-Payload= >

=
Each payload is encr= ypted under a new session key and IV.

The header contains the following as authenticated data:
=
* time added (used i= n synchronization)
* digest value of <Encrypted-Payload>
* optional blockchain value

Since we want to verify the data before= unwrapping it or exposing it to infrastructure that has the keys, the auth= entication has to be on the outside and must therefore be on the encrypted = data.

The payload may be = signed or MAC-ed


The inclusion of a= n optional blockchain value allows a sequence of entries to be authenticate= d using a single signature verification. It will also make attempting to me= rge two sequences that have got out of sync a headache for the person writi= ng the code. I suspect use of these features will be disjoint, pick one or = the other.

=
The simplest c= haining mode would be for each entry to chain to the last digest value. A m= ore efficient structure would be to use a Merkle tree.


Ideas? Comments?
_______________________________________________
saag mailing list
saag@ietf.org
https://www.ietf.org/mailman/listinfo/saag
--001a113d57daf690fe0558e9edb2-- From nobody Mon Sep 11 10:16:47 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 165B2133186 for ; Mon, 11 Sep 2017 10:16:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 LZA4TqLKB8X3 for ; Mon, 11 Sep 2017 10:16:43 -0700 (PDT) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (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 03DDD133183 for ; Mon, 11 Sep 2017 10:16:41 -0700 (PDT) Received: by mail-io0-x22f.google.com with SMTP id g32so13043043ioj.2 for ; Mon, 11 Sep 2017 10:16:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=zzt/rrhuuTI7sPXulCAlrA3lMbAuwFrPmzrquLIx4Fw=; b=f1zr11zIYiLVKlxaPgoeWnz/GV3VkdcxaX7RcD4AQNmFhzWwiWqp8l+lG/MW5XugyC hGluKmhSR1d4FAobRXWgPeeEECKO6hgNzzlESn2J5o9WpnvuEwtIEZClDdk7iDGwUtiN REmNCqZ6Syta9tBujslsPlfPp4tOKFPt2vJ7ot58ehE6WLyp657V/kb4hphEKqO5IviF 8dElbJ2dqln9p6LWSjYU/TPJlfmcAvpCOdPFJQoyj5NbTm27zNV7LouCxUTlom2QPwaV 1A9STtEvuNJvIH4DLA+yJ4PL5fk51TrnXGQ+KbYuZRAM6qU5taLjfg/kDqOA9jGW+5zC CyxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=zzt/rrhuuTI7sPXulCAlrA3lMbAuwFrPmzrquLIx4Fw=; b=cv3eihqdVaCECpesq6EnkWS9aC42xcCrIRgTkd9illa8GXNC9V32Kzw51g4gLTjhcB rQc+adPAiPM8Cj8acOXB6m8+0yvC0qFlxoLzIgAQFcUNg4dVDZCv9f6UX2ZtZJp6SZCM xokf7fipLCoWXBYe+0+9l4lmqnXselkbC/vcR8DDpqEpeX2ZSJhrj0oQZIiEkCpWTDP+ DGT0w0WYC6uoBnsjj6gKFXz/j82W4ttRwPM2tBOQ39j5Zs+3T1PPR5iemImriop49QS3 PJgRwwkExUKaIKubHrQXGYzUfSngE0jda/kYrHi6QX8MME1TYmF6UnesovRo6bPq5Ry+ cS9g== X-Gm-Message-State: AHPjjUgKDEVcxfdn2IqF6Fmmd0FjycYPXQRuZ1WC4OzDYx+GZpC4Arif 7Z9iJohxHDm43TKQ+7vgvhpZnAAkFQ== X-Google-Smtp-Source: AOwi7QCy21sY6h7079+j8CY6xZepPBFhLCWideaC+HPlcqsSSf0qgKwQKdvqBeBKLs0vhFWq7z0T2Ym8TR230qWns/c= X-Received: by 10.202.86.88 with SMTP id k85mr12892976oib.130.1505150200159; Mon, 11 Sep 2017 10:16:40 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.157.89.227 with HTTP; Mon, 11 Sep 2017 10:16:39 -0700 (PDT) In-Reply-To: References: From: Phillip Hallam-Baker Date: Mon, 11 Sep 2017 13:16:39 -0400 X-Google-Sender-Auth: oP1jjaUZK6P415DD8yFVHfLpCgc Message-ID: To: Nick Johnson Cc: "saag@ietf.org" Content-Type: multipart/alternative; boundary="001a113def5003c0760558ed1737" Archived-At: Subject: Re: [saag] Blockchained log format X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Sep 2017 17:16:46 -0000 --001a113def5003c0760558ed1737 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Sep 11, 2017 at 9:30 AM, Nick Johnson wrote: > Have you considered CBOR as an alternative to inventing your own binary > encoding? > > -Nick Johnson > > =E2=80=8B=E2=80=8BYes and rejected. JSON is the future. CBOR is intentional= ly different it has a different data model. The people designing it were told that this would be a problem but their response was 'we are doing an independent submission, we do not have to consider your ideas or requirements'. =E2=80= =8B But regardless of the history, this is a new requirement and rather different to those considered by CBOR or JSON-B. There is no way to address the 'read from the end' requirement except by either introducing new coding elements or using some form of escaping scheme (see JSON text sequences). =E2=80=8B On Mon, Sep 11, 2017 at 9:29 AM, Alan DeKok wrote: > On Sep 11, 2017, at 9:01 AM, Phillip Hallam-Baker > wrote: > > > > =E2=80=8BI now have the Mesh at a point where we can use it for real > applications. While working on writing application protocols, I noticed > that a large number of applications have at their center a structure whic= h > is essentially just a sequence of entries that are 'mostly' append only. > > My $0.02 is that such a system isn't that useful in isolation. i.e. Fo= r > an isolated system, it's not that hard to create the data && signatures > post-facto. > > The real value would be in adding cross-linking between the chains. > e.g. if you have logging on multiple machines, they can periodically > exchange hashes / states, which are incorporated into each others logs. > This "cross-links" the logs, and ties the whole system together. Which > creates a "web of signatures", instead of a "web of trust". The benefit = is > that you don't even need to trust the other systems. > =E2=80=8BThat is exactly how I intend to tie data elements together in the = Mesh. However I wasn't going to mention it here because my main reason for using the signed Merkle tree is efficiency rather than non-repudiation. =E2=80=8BThe use case I am considering here is limited to 'Alice's iPhone authenticates the changes it has made to Alice's contacts to Alice's desktop.' Yes, we could enroll that in a master log to prevent an insertion attack but this attack isn't going to be possible unless Alice is already hosed. The idea of the Mesh is that there is some portion of Alice's profile that is available persistently and published through an untrusted cloud called the cryptomesh. And in that situation we definitely want to cross link the logs held by the independent portals in some fashion. I have not yet fully worked out how to do that but this is my current scheme.=E2=80=8B There are three types of chained digest data: 1) The last link in the chain or the apex of a tree. This is a digest value 2) A digest value signed by a trusted party at some known point in time. This is a trust Apex. 3) A set of digest values that allow a chain to be established and verified to one or more entries. This is a digest chain. A digest chain is useless on its own because you don't know if it is trusted. To do that you have to specify some means of validation. So there will be some form of description of this process which may be simple (one trusted signer) or complex (multiple signers, quorums) or very complex (proof of work, multiple sources, yadda yadda). But whatever the description it must be machine readable to be useful and thus we must at some point have something we can take a fingerprint of. So let the UDF fingerprint of the description be: MA72Y-WXNYF-Z4DWJ-VZBT4-TUYR6-36PIX For routing etc. purposes, we need a domain name, so let us make a strong name out of it: example.com.mm--ma72y-wxnyf-z4dwj-vzbt4-tuyr6-36pix And now we can present the digest value mdmlr-ydtlr-2gqch-li3o6-lo6is-hrx3y as a uri: tbs:example.com.mm--ma72y-wxnyf-z4dwj-vzbt4-tuyr6-36pix:value:mdmlr-ydtlr-2= gqch-li3o6-lo6is-hrx3y So we can use the structure I already described to present cross links to arbitrary external chains and the means of resolution just by incorporating them into the authenticated data. This is not something I would normally do for a personal system but it might be something you would use as a matter of course in a file system if you were tracking patent application data, forensics, etc. To make a system like this practical, you would need to have an analog of NTP for 'current block' and likely need to distribute it down to the system level. Which is the reason I was not bringing it up. The problem when you mention time is that there is always someone who insists that 'synchronized time is absolutely useless unless it is to the femptosecond level. Which is nonsense of course. There are multiple uses for time and unless you are doing something like logging NASDAQ transactions, chances are that you do not need trusted time resolution that is anywhere close to the resolution you would prefer for synchronization. I would like all the clocks in my house to be synchronized to better than a second and preferably better than 100ms. When I am designing a system, I am not going to rely on the systems being synchronized to the hour. There are layers to trust: 1) Transparent untrusted source. (Blockchain, days) 2) Accountable trusted source. (Signed NTP, minutes) 3) Unaccountable trusted source . (NTP, seconds) =E2=80=8BWith blockchain, the trustworthiness of the data is almost zero at= the moment the block is mined (it can be overwritten) but quickly reaches near infinite as blocks are added. Within a few days, the cost of a backdating attack is the cost of breaking the hash. So the source is untrusted because we don't need to trust 'em. Signing NTP responses improves trust but introduces a performance issue. We can't get better resolution in time than the interval between signing. Unless we have a protocol where a nonce is signed, we only have protection against roll forward attacks, not roll back. --001a113def5003c0760558ed1737 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On = Mon, Sep 11, 2017 at 9:30 AM, Nick Johnson <nick@ethereum.org> wrote:
Have you c= onsidered CBOR as an alternative to inventing your own binary encoding?
-Nick Johnson


=E2=80=8B=E2=80= =8BYes and rejected. JSON is the future. CBOR is intentionally different it= has a different data model. The people designing it were told that this wo= uld be a problem but their response was 'we are doing an independent su= bmission, we do not have to consider your ideas or requirements'. =E2= =80=8B

But regardless of the history, this is a new requirement and rather = different to those considered by CBOR or JSON-B. There is no way to address= the 'read from the end' requirement except by either introducing n= ew coding elements or using some form of escaping scheme (see JSON text seq= uences).

=E2=80=8B
On Mon, Sep 11, 2017= at 9:29 AM, Alan DeKok=C2=A0<aland@deployingradius.com>=C2=A0wrote:
On Sep 11, 2017, at 9:01 AM, Phillip Hallam-Baker <phill@hallambaker.com> wrote:<= br>>
> =E2=80=8BI now have the Mesh at a point where we can use it= for real applications. While working on writing application protocols, I n= oticed that a large number of applications have at their center a structure= which is essentially just a sequence of entries that are 'mostly' = append only.

=C2=A0 My $0.02 is that such a system isn't = that useful in isolation.=C2=A0 i.e. For an isolated system, it's not t= hat hard to create the data && signatures post-facto.

=C2=A0= The real value would be in adding cross-linking between the chains.=C2=A0 = e.g. if you have logging on multiple machines, they can periodically exchan= ge hashes / states, which are incorporated into each others logs.=C2=A0 Thi= s "cross-links" the logs, and ties the whole system together.=C2= =A0 Which creates a "web of signatures", instead of a "web o= f trust".=C2=A0 The benefit is that you don't even need to trust t= he other systems.

=E2=80=8BThat is exactly how I int= end to tie data elements together in the Mesh. However I wasn't going t= o mention it here because my main reason for using the signed Merkle tree i= s efficiency rather than non-repudiation.

=E2=80=8BThe use case I am consid= ering here is limited to 'Alice's iPhone authenticates the changes = it has made to Alice's contacts to Alice's desktop.' Yes, we co= uld enroll that in a master log to prevent an insertion attack but this att= ack isn't going to be possible unless Alice is already hosed.


The idea of the Mesh is that there is some p= ortion of Alice's profile that is available persistently and published = through an untrusted cloud called the cryptomesh. And in that situation we = definitely want to cross link the logs held by the independent portals in s= ome fashion.
I have not y= et fully worked out how to do that but this is my current scheme.=E2=80=8B<= /div>


There are three types of chained di= gest data:

=
1) The last li= nk in the chain or the apex of a tree. This is a digest value =C2=A0
<= div class=3D"gmail_default" style=3D"font-size:small">2) A digest value sig= ned by a trusted party at some known point in time. This is a trust Apex.
3) A set of = digest values that allow a chain to be established and verified to one or m= ore entries. This is a digest chain.

A digest chain is useless on its own because you don't know= if it is trusted. To do that you have to specify some means of validation.= So there will be some form of description of this process which may be sim= ple (one trusted signer) or complex (multiple signers, quorums) or very com= plex (proof of work, multiple sources, yadda yadda). But whatever the descr= iption it must be machine readable to be useful and thus we must at some po= int have something we can take a fingerprint of.

So let the UDF fingerprint of the description be:= =C2=A0

MA72Y-WXNYF-Z4DWJ-VZBT4-TUYR6-36PIX


For routing etc.= purposes, we need a domain name, so let us make a strong name out of it:

example.com.mm--ma72y-wxny= f-z4dwj-vzbt4-tuyr6-36pix


And now we can present the digest = value mdmlr-ydtlr-2gqch-li3o6-lo6is-hrx3y as a uri:

tbs:example.com.mm--ma72y-wxnyf-z4dwj-vzbt4-tuyr= 6-36pix:value:mdmlr-ydtlr-2gqch-li3o6-lo6is-hrx3y


So we can use the structure I already described to present c= ross links to arbitrary external chains and the means of resolution just by= incorporating them into the authenticated data.

This is not something I would normally do for a per= sonal system but it might be something you would use as a matter of course = in a file system if you were tracking patent application data, forensics, e= tc.

<= /div>
To make a syste= m like this practical, you would need to have an analog of NTP for 'cur= rent block' and likely need to distribute it down to the system level. = Which is the reason I was not bringing it up. The problem when you mention = time is that there is always someone who insists that 'synchronized tim= e is absolutely useless unless it is to the femptosecond level. Which is no= nsense of course. There are multiple uses for time and unless you are doing= something like logging NASDAQ transactions, chances are that you do not ne= ed trusted time resolution that is anywhere close to the resolution you wou= ld prefer for synchronization.

I would like all the clocks in my house to be synchronized to better = than a second and preferably better than 100ms. When I am designing a syste= m, I am not going to rely on the systems being synchronized to the hour.

There are layers to trust:<= /div>

1) Transparent untrusted = source. (Blockchain, days)
2) Accountable trusted source. (Signed NTP, minutes)
3) Unaccountable trusted = source . (NTP, seconds)

=E2=80=8BWith blockchain, the trustworthin= ess of the data is almost zero at the moment the block is mined (it can be = overwritten) but quickly reaches near infinite as blocks are added. Within = a few days, the cost of a backdating attack is the cost of breaking the has= h. So the source is untrusted because we don't need to trust 'em.

Signing NTP responses impr= oves trust but introduces a performance issue. We can't get better reso= lution in time than the interval between signing. Unless we have a protocol= where a nonce is signed, we only have protection against roll forward atta= cks, not roll back.


<= /div>

--001a113def5003c0760558ed1737-- From nobody Mon Sep 11 10:52:18 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4942B132ECB for ; Mon, 11 Sep 2017 10:52:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 Mr6FesiIIMzO for ; Mon, 11 Sep 2017 10:52:15 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 1CDAC132D6D for ; Mon, 11 Sep 2017 10:52:15 -0700 (PDT) Received: from [192.168.20.164] (CPEf4cc55220745-CM64777ddff610.cpe.net.cable.rogers.com [99.248.225.186]) by mail.networkradius.com (Postfix) with ESMTPSA id B347F194; Mon, 11 Sep 2017 17:52:13 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alan DeKok In-Reply-To: Date: Mon, 11 Sep 2017 13:52:12 -0400 Cc: Nick Johnson , "saag@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [saag] Blockchained log format X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Sep 2017 17:52:17 -0000 On Sep 11, 2017, at 1:16 PM, Phillip Hallam-Baker = wrote: > =E2=80=8BThat is exactly how I intend to tie data elements together in = the Mesh. However I wasn't going to mention it here because my main = reason for using the signed Merkle tree is efficiency rather than = non-repudiation. I'm not clear what "efficiency" is in this context. > =E2=80=8BThe use case I am considering here is limited to 'Alice's = iPhone authenticates the changes it has made to Alice's contacts to = Alice's desktop.' Yes, we could enroll that in a master log to prevent = an insertion attack but this attack isn't going to be possible unless = Alice is already hosed. The point is to also find out when an attack occurred. Maybe you = can't trust Alice's clock because she's been attacked. But if there are = periodic cross-links, you can correlate it with other events in the = mesh. i.e. the cross-correlation is not only non-repudiation, it's a way to = ensure ordering of events, i.e. time. > The idea of the Mesh is that there is some portion of Alice's profile = that is available persistently and published through an untrusted cloud = called the cryptomesh. And in that situation we definitely want to cross = link the logs held by the independent portals in some fashion. It's a nice idea to have an untrusted cloud... the question for me is = why would people use it? For bitcoin, the answer is "to sell bitcoins = to later entrants". So there's a financial incentive. I'm not sure why I would put *my* data in an untrusted cloud. Or = would this scheme allow for individuals to control their data, in a way = people can't do right now with "cloud" systems? > This is not something I would normally do for a personal system but it = might be something you would use as a matter of course in a file system = if you were tracking patent application data, forensics, etc. >=20 > To make a system like this practical, you would need to have an analog = of NTP for 'current block' and likely need to distribute it down to the = system level. Which is the reason I was not bringing it up. The problem = when you mention time is that there is always someone who insists that = 'synchronized time is absolutely useless unless it is to the = femptosecond level. Which is nonsense of course. There are multiple uses = for time and unless you are doing something like logging NASDAQ = transactions, chances are that you do not need trusted time resolution = that is anywhere close to the resolution you would prefer for = synchronization. Once you cross-correlate events, you can have some global order of = events. You don't need an explicit time stamp for that. If dependent = events have a fixed order, it matters less that independent events don't = have a fixed order. > I would like all the clocks in my house to be synchronized to better = than a second and preferably better than 100ms. When I am designing a = system, I am not going to rely on the systems being synchronized to the = hour. I think synchronization is less important than coordination. If each = clock has it's own time (and rate of time passage), you can correct for = individual variation by looking at times across multiple clocks. i.e. they don't need to have the *same* time, but the time differences = between clocks need to be known, and bounded. Alan DeKok. From nobody Tue Sep 12 05:59:39 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDFD1132153; Tue, 12 Sep 2017 05:59:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.439 X-Spam-Level: X-Spam-Status: No, score=-2.439 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, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_LOW=-0.7, 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 pylyV2xLCTCX; Tue, 12 Sep 2017 05:59:35 -0700 (PDT) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (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 7066213208E; Tue, 12 Sep 2017 05:59:35 -0700 (PDT) Received: by mail-wm0-x22d.google.com with SMTP id i189so57825539wmf.1; Tue, 12 Sep 2017 05:59:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=nAXHDDrCBkCZJr1EdCcWq9bISIFxJiOWhBzU5tTVZJI=; b=f8eXI7yrwtGR+HS1g+XrVBejmhc8UMLFqciKUnipNnWmil7ZZa+NCTD0uSE6cecWoh fnD4DsO7mnwIEu62X/p86WIraC1LfBA/Uh45yJqpbzvR6G7EVoq23S4bnQKR2Rt3mjsd bEbBbEF30kUzR5aIIu86sCL7e9/S9hmmR/i4mVioAwds+falG3tcsdhesHKjoKlzMqjF XgaaUtl/7ICVHe87P617n/l6egiipTNiYMqmcz5SI8amSTdXsp1IbarHYVsY9604Xd30 jlYaelD7dBt83RvujsGxiDP7BELi8D2K+tkP6ZydvdzdVqI97r0xe5iiQYNfemPb5qYa Fsrg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=nAXHDDrCBkCZJr1EdCcWq9bISIFxJiOWhBzU5tTVZJI=; b=AEbQ3qwEAw7RtRBxRxmCx3re824l4HPtDhfwBoe90H82MznictzP9lsOxZLOSv0GEh Uo5tgmvUKDukf5OGd9rqOipBBflwmUeQw5vptnXjn/j2B4qjmyqznJACIGibuNtjfcrb 0de9KnnMeIxURSb2TnPuzpjTOIJVc4aKqQkpuhAwjqP0eAe7vQwsgKRGRPbLZFoE9+mH hEfJAaG1KJ/Ke+bS+gGD9gaqAnimrwqBPcJ7yGBimvTnyD4UKisQerxh5VFLvD9xHXVS ACFk4DMo5HlHZAUswj+AWB7abmymtpz5M5bSA82wI4Yq69X3mr/5bZg8TKb9wpZTTIO2 QNfA== X-Gm-Message-State: AHPjjUhUy8XPYkxJQY/MhfYpJU+i0w0YqAzz4H7ru9MKRLoe/o0lYe+J JcuB5qVfYpnRS7P6ztBcoGJ6meWe1Q== X-Google-Smtp-Source: ADKCNb6fMlIldlbwuSvGQp4jsdUyAEF74D8OS3iHJIBnMHpcRiiCJZ+InzHtcDwatjuIVK2h+ylKu1o2pYCeCxPAiLg= X-Received: by 10.80.128.133 with SMTP id 5mr6467465edb.149.1505221173801; Tue, 12 Sep 2017 05:59:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.186.44 with HTTP; Tue, 12 Sep 2017 05:59:33 -0700 (PDT) In-Reply-To: <150522092693.4724.2532571098567577114.idtracker@ietfa.amsl.com> References: <150522092693.4724.2532571098567577114.idtracker@ietfa.amsl.com> From: Dmitry Belyavsky Date: Tue, 12 Sep 2017 15:59:33 +0300 Message-ID: To: "saag@ietf.org" , LAMPS , dev-security-policy@lists.mozilla.org, pkix@ietf.org Content-Type: multipart/alternative; boundary="94eb2c067f745f77590558fd9d32" Archived-At: Subject: [saag] Fwd: New Version Notification for draft-belyavskiy-certificate-limitation-policy-04.txt X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Sep 2017 12:59:38 -0000 --94eb2c067f745f77590558fd9d32 Content-Type: text/plain; charset="UTF-8" Hello, Here is the new version of the draft updated according to the discussion on mozilla-dev-security list. ---------- Forwarded message ---------- From: Date: Tue, Sep 12, 2017 at 3:55 PM Subject: New Version Notification for draft-belyavskiy-certificate-l imitation-policy-04.txt To: Dmitry Belyavskiy A new version of I-D, draft-belyavskiy-certificate-limitation-policy-04.txt has been successfully submitted by Dmitry Belyavskiy and posted to the IETF repository. Name: draft-belyavskiy-certificate-limitation-policy Revision: 04 Title: Certificate Limitation Policy Document date: 2017-09-11 Group: Individual Submission Pages: 7 URL: https://www.ietf.org/internet-drafts/draft-belyavskiy-certif icate-limitation-policy-04.txt Status: https://datatracker.ietf.org/doc/draft-belyavskiy-certifica te-limitation-policy/ Htmlized: https://tools.ietf.org/html/draft-belyavskiy-certificate-li mitation-policy-04 Htmlized: https://datatracker.ietf.org/doc/html/draft-belyavskiy-cert ificate-limitation-policy-04 Diff: https://www.ietf.org/rfcdiff?url2=draft-belyavskiy-certific ate-limitation-policy-04 Abstract: The document provides a specification of the application-level trust model. Being provided at the application level, the limitations of trust can be distributed separately using cryptographically protected format instead of hardcoding the checks into the application itself. 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. The IETF Secretariat -- SY, Dmitry Belyavsky --94eb2c067f745f77590558fd9d32 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,

Here is the new version of the d= raft updated according to the discussion on mozilla-dev-security list.

---------- Forwarded message ---------= -
From: <internet-drafts@ietf= .org>
Date: Tue, Sep 12, 2017 at 3:55 PM
Subject: New V= ersion Notification for draft-belyavskiy-certificate-limitation-policy= -04.txt
To: Dmitry Belyavskiy <beldmit@gmail.com>



A new version of I-D, draft-belyavskiy-certificate-limitation-policy-0= 4.txt
has been successfully submitted by Dmitry Belyavskiy and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-belyavskiy-certificate-= limitation-policy
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A004
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Certificate Limitation Policy
Document date:=C2=A0 2017-09-11
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 7
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-draf= ts/draft-belyavskiy-certificate-limitation-policy-04.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-belyavskiy= -certificate-limitation-policy/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-belyavskiy-certificate-= limitation-policy-04
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-bel= yavskiy-certificate-limitation-policy-04
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddra= ft-belyavskiy-certificate-limitation-policy-04

Abstract:
=C2=A0 =C2=A0The document provides a specification of the application-level= trust
=C2=A0 =C2=A0model.=C2=A0 Being provided at the application level, the limi= tations of
=C2=A0 =C2=A0trust can be distributed separately using cryptographically pr= otected
=C2=A0 =C2=A0format instead of hardcoding the checks into the application i= tself.




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

The IETF Secretariat




--
SY, Dmitry Belyavsky
--94eb2c067f745f77590558fd9d32-- From nobody Tue Sep 12 12:32:32 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9923113293A for ; Tue, 12 Sep 2017 12:32:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 NQfdP28ukByU for ; Tue, 12 Sep 2017 12:32:28 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (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 A91EA132E2A for ; Tue, 12 Sep 2017 12:32:28 -0700 (PDT) Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v8CJWP3J029833 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 12 Sep 2017 19:32:26 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserv0021.oracle.com (8.14.4/8.14.4) with ESMTP id v8CJWPgY030039 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 12 Sep 2017 19:32:25 GMT Received: from ubhmp0017.oracle.com (ubhmp0017.oracle.com [156.151.24.70]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id v8CJWNmL030466; Tue, 12 Sep 2017 19:32:24 GMT Received: from [10.0.1.37] (/24.86.190.97) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 12 Sep 2017 19:32:23 +0000 From: Phil Hunt Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_C7A64BDD-7D1D-4576-84EA-6784D8BD0DDA" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 12 Sep 2017 12:32:22 -0700 In-Reply-To: Cc: John Bradley , Tony Nadalin , Kathleen Moriarty , Leif Johansson , saag@ietf.org To: Justin Richer References: <520208AC-FE75-43BC-BD3E-2BB7DA6EC694@oracle.com> <338C37EB-FD6B-4DCC-91AA-C877E9470986@oracle.com> <75405E28-188C-4EB9-B12D-FF3B0806DA24@nist.gov> <36DD5B6E-8871-4B2B-AE46-352138D8C8C2@ve7jtb.com> X-Mailer: Apple Mail (2.3273) X-Source-IP: aserv0021.oracle.com [141.146.126.233] Archived-At: Subject: [saag] Vectors of Trust - Experimental or Standards Track X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Sep 2017 19:32:32 -0000 --Apple-Mail=_C7A64BDD-7D1D-4576-84EA-6784D8BD0DDA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Adding saag so we can get this on the record per Kathleen=E2=80=99s = suggestion. Apologies I originally started this thread as communications with the = authors. Justin, I initiated this thread because of the classification of the = Vectors of Trust document[0] as =E2=80=9Cexperimental". As weird as you = suggest the IETF is, RFC2026 defines =E2=80=9Cexperimental=E2=80=9D = designation as: > 4.2.1 = Experimental >=20 > The "Experimental" designation typically denotes a specification = that > is part of some research or development effort. Such a = specification > is published for the general information of the Internet technical > community and as an archival record of the work, subject only to > editorial considerations and to verification that there has been > adequate coordination with the standards process (see below). An > Experimental specification may be the output of an organized = Internet > research effort (e.g., a Research Group of the IRTF), an IETF = Working > Group, or it may be an individual contribution. R&D is not the case with this draft given what is on track with NIST and = OpenID Foundation. The OpenID Foundation iGov Working Group and apparently NIST are = *currently* referencing this as a mandatory requirement for operational = use rather then use exclusively in research and development, the = classification is inappropriate. Specifically the iGov draft refers to = the VoT as an IETF =E2=80=9Cstandard=E2=80=9D. The OpenID iGov draft was = just voted to =E2=80=9Cimplementation=E2=80=9D status which means people = are now implementing for production and NOT R&D. Regardless of the = differences in terms, iGov is intended to be a standard while VoT is = currently not.[1] I understand new SP-800-63 regulations are being developed that will use = this =E2=80=9Cstandard=E2=80=9D.[2] I am concerned that as =E2=80=9Cexperimental", the VoT draft will not = receive the proper scrutiny it needs to have. I am not sure why it is at = the IETF since its domain of use is largely OpenID and SAML. I will leave comments regarding =E2=80=9CVoT=E2=80=9D draft for the VoT = list at a later time. [0] https://tools.ietf.org/html/draft-richer-vectors-of-trust-05 [1] = https://xml2rfc.tools.ietf.org/cgi-bin/xml2rfc.cgi?Submit=3DSubmit&format=3D= ascii&mode=3Dhtml&type=3Dascii&url=3Dhttps://bitbucket.org/openid/igov/raw= /master/openid-igov-profile.xml#rfc.section.3.4 [2] = https://github.com/usnistgov/800-63-3/blob/volume-d/sp800-63d/vot_mapping.= md Thanks clearing this up. Phil Oracle Corporation, Identity Cloud Services Architect @independentid www.independentid.com = phil.hunt@oracle.com = > On Sep 12, 2017, at 10:47 AM, Justin Richer wrote: >=20 > Phil, >=20 > The draft started out in standards-track then moved to experimental = during one of the revisions due to some feedback. Recent feedback has = asked to put it back in standards-track, and I=E2=80=99d be fine with = either to be honest. But in the end I don=E2=80=99t think that = designation really matters, and you=E2=80=99re reading way more into it = than is intended. I recall there was a similar discussion a couple years = ago (that you, Phil, were a part of), where OAuth was called out as not = being a =E2=80=9Creal standard=E2=80=9D because the RFC states it=E2=80=99= s a =E2=80=9Cproposed standard=E2=80=9D. This, like now, I think is a = misinterpretation of the meaning and intent of the document designations = and is a distraction from what=E2=80=99s important. Yes, the IETF is = weird in how it calls things =E2=80=94 but we don=E2=80=99t get to pick = their terms or redefine their meanings.=20 >=20 > I anticipated VoT going to RFC well over a year and a half ago =E2=80=94= it=E2=80=99s been stable that long, and that=E2=80=99s why you don=E2=80=99= t see much recent traffic on the vot@ietf mailing list =E2=80=94 but as = an AD-sponsored document it=E2=80=99s been slow finding shepherds and = getting through the process without a WG chair pushing things. This = doesn=E2=80=99t make it any less valid of a standard, but it does change = the process that it goes through, somewhat. It will still get full IESG = review. And, the important part, it=E2=80=99s still useful and usable.=20= >=20 > As far as I can see it, your main argument against using VoT is that = it=E2=80=99s a draft standard =E2=80=94 but so is iGov. And VoT can and = will be moved forward in the IETF as an RFC standard. That process is = happening now, John is the shepherd and has the power to move it = forward. >=20 > So with this in mind, John=E2=80=99s discussion below is spot on. The = way that VoT gets used is fairly simple: >=20 > The RP can request a =E2=80=9Cvtr", which basically says =E2=80=9Cthis = is the VoT that I=E2=80=99d like=E2=80=9D. IdP can respond with = =E2=80=9Cvot=E2=80=9D, which is =E2=80=9Chere=E2=80=99s your vector = values=E2=80=9D, along with =E2=80=9Cvtm", which is =E2=80=9Chere=E2=80=99= s where the contents of this vector are defined=E2=80=9D. NIST, as = mentioned and as I=E2=80=99d linked to you, is defining its own = =E2=80=9Cvtm=E2=80=9D document. This will define what =E2=80=9CP1=E2=80=9D= means (surprise, it maps directly to IAL1), among everything else. The = values in the VoT draft aren=E2=80=99t used in that case, since they = exist under a =E2=80=9Cvtm=E2=80=9D defined by the RFC, once that=E2=80=99= s assigned and published, but you don=E2=80=99t have to use them. And = iGov is not in the business of defining which =E2=80=9Cvtm=E2=80=9D = people should be using, but we want implementations to at least use the = same mechanism =E2=80=94 VoT =E2=80=94 for conveying similar = information.=20 >=20 > =E2=80=94 Justin >=20 --Apple-Mail=_C7A64BDD-7D1D-4576-84EA-6784D8BD0DDA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Adding saag so we can get this on the record per Kathleen=E2=80= =99s suggestion.

Apologies I originally started this thread as communications = with the authors.

Justin, I initiated this thread because of the classification = of the Vectors of Trust document[0] as =E2=80=9Cexperimental". As weird = as you suggest the IETF is, RFC2026 defines =E2=80=9Cexperimental=E2=80=9D= designation as:
4.2.1  Experimental


   The "Experimental" designation typically denotes a specification that
   is part of some research or development effort.  Such a specification
   is published for the general information of the Internet technical
   community and as an archival record of the work, subject only to
   editorial considerations and to verification that there has been
   adequate coordination with the standards process (see below).  An
   Experimental specification may be the output of an organized Internet
   research effort (e.g., a Research Group of the IRTF), an IETF Working
   Group, or it may be an individual =
contribution.

R&D is not the case with this draft given what is on = track with NIST and OpenID Foundation.
  • The OpenID Foundation iGov Working Group and = apparently NIST are *currently* referencing this as a mandatory = requirement for operational use rather then use exclusively in research = and development, the classification is inappropriate. Specifically the = iGov draft refers to the VoT as an IETF =E2=80=9Cstandard=E2=80=9D. The = OpenID iGov draft was just voted to =E2=80=9Cimplementation=E2=80=9D = status which means people are now implementing for production and NOT = R&D. Regardless of the differences in terms, iGov is intended to be = a standard while VoT is currently not.[1]
  • I = understand new SP-800-63 regulations are being developed that will use = this =E2=80=9Cstandard=E2=80=9D.[2]

I am concerned that as = =E2=80=9Cexperimental", the VoT draft will not receive the proper = scrutiny it needs to have. I am not sure why it is at the IETF since its = domain of use is largely OpenID and SAML.

I will leave comments regarding = =E2=80=9CVoT=E2=80=9D draft for the VoT list at a later time.

[0] https://tools.ietf.org/html/draft-richer-vectors-of-trust-05
[1] https://xml2rfc.tools.ietf.org/cgi-bin/xml2rfc.cgi?Submit=3DSub= mit&format=3Dascii&mode=3Dhtml&type=3Dascii&url=3Dhttps://= bitbucket.org/openid/igov/raw/master/openid-igov-profile.xml#rfc.section.3= .4
[2] https://github.com/usnistgov/800-63-3/blob/volume-d/sp800-63d/v= ot_mapping.md

Thanks clearing this up.

Phil

Oracle Corporation, Identity Cloud = Services Architect
@independentid
www.independentid.com
phil.hunt@oracle.com

On Sep 12, 2017, at 10:47 AM, Justin Richer <jricher@mit.edu> = wrote:

Phil,

The draft started out in = standards-track then moved to experimental during one of the revisions = due to some feedback. Recent feedback has asked to put it back in = standards-track, and I=E2=80=99d be fine with either to be honest. But = in the end I don=E2=80=99t think that designation really matters, and = you=E2=80=99re reading way more into it than is intended. I recall there = was a similar discussion a couple years ago (that you, Phil, were a part = of), where OAuth was called out as not being a =E2=80=9Creal standard=E2=80= =9D because the RFC states it=E2=80=99s a =E2=80=9Cproposed standard=E2=80= =9D. This, like now, I think is a misinterpretation of the meaning and = intent of the document designations and is a distraction from what=E2=80=99= s important. Yes, the IETF is weird in how it calls things =E2=80=94 but = we don=E2=80=99t get to pick their terms or redefine their = meanings. 

I = anticipated VoT going to RFC well over a year and a half ago =E2=80=94 = it=E2=80=99s been stable that long, and that=E2=80=99s why you don=E2=80=99= t see much recent traffic on the vot@ietf mailing list =E2=80=94 but as = an AD-sponsored document it=E2=80=99s been slow finding shepherds and = getting through the process without a WG chair pushing things. This = doesn=E2=80=99t make it any less valid of a standard, but it does change = the process that it goes through, somewhat. It will still get full IESG = review. And, the important part, it=E2=80=99s still useful and = usable. 

As far = as I can see it, your main argument against using VoT is that it=E2=80=99s= a draft standard =E2=80=94 but so is iGov. And VoT can and will be = moved forward in the IETF as an RFC standard. That process is happening = now, John is the shepherd and has the power to move it = forward.

So = with this in mind, John=E2=80=99s discussion below is spot on. The way = that VoT gets used is fairly simple:

The RP can request a =E2=80=9Cvtr", = which basically says =E2=80=9Cthis is the VoT that I=E2=80=99d like=E2=80=9D= . IdP can respond with =E2=80=9Cvot=E2=80=9D, which is =E2=80=9Chere=E2=80= =99s your vector values=E2=80=9D, along with =E2=80=9Cvtm", which is = =E2=80=9Chere=E2=80=99s where the contents of this vector are = defined=E2=80=9D. NIST, as mentioned and as I=E2=80=99d linked to you, = is defining its own =E2=80=9Cvtm=E2=80=9D document. This will define = what =E2=80=9CP1=E2=80=9D means (surprise, it maps directly to IAL1), = among everything else. The values in the VoT draft aren=E2=80=99t used = in that case, since they exist under a =E2=80=9Cvtm=E2=80=9D defined by = the RFC, once that=E2=80=99s assigned and published, but you don=E2=80=99t= have to use them. And iGov is not in the business of defining which = =E2=80=9Cvtm=E2=80=9D people should be using, but we want = implementations to at least use the same mechanism =E2=80=94 VoT =E2=80=94= for conveying similar information. 

 =E2=80=94 Justin


= --Apple-Mail=_C7A64BDD-7D1D-4576-84EA-6784D8BD0DDA-- From nobody Tue Sep 12 12:47:44 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B70041330BB for ; Tue, 12 Sep 2017 12:47:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 UPwBSf5-Pm1C for ; Tue, 12 Sep 2017 12:47:40 -0700 (PDT) Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) (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 1B58E132697 for ; Tue, 12 Sep 2017 12:47:40 -0700 (PDT) X-AuditID: 12074422-0e9ff700000055a1-f1-59b839da5176 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id 63.6E.21921.AD938B95; Tue, 12 Sep 2017 15:47:38 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id v8CJlbXx008248; Tue, 12 Sep 2017 15:47:37 -0400 Received: from [IPv6:2607:fb90:68b1:ef2a:394e:9fea:dca5:8432] ([172.58.217.68]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v8CJlXdC018878 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 12 Sep 2017 15:47:35 -0400 Message-Id: <201709121947.v8CJlXdC018878@outgoing.mit.edu> Date: Tue, 12 Sep 2017 15:47:31 -0400 Importance: normal From: Justin Richer To: Phil Hunt Cc: John Bradley , Tony Nadalin , Kathleen Moriarty , Leif Johansson , saag@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.samsung.android.email_1014825121660110" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrKKsWRmVeSWpSXmKPExsUixCmqrHvLckekwepN5hYNO/MtFvRuZbZY ML+R3WJKfyeTxaa52xgtVt/9y+bA5rFz1l12jyVLfjJ5tO74y+7x8ektFo+9m/rYPW7f3sgS wBbFZZOSmpNZllqkb5fAlXG4rYO1oOsUY8WyqYtZGxjvHGHsYuTkkBAwkdjwcgtrFyMXh5DA YiaJkxfWMEM4GxkljjzvYYNwzjBJvL9wGKyFV8BKYvrNi2wgNouAqsT1j03sILawgL3EzufL WLoYOTg4BYQkunZJgITZgEqmr2lhArFFBFQkvl29zggyk1ngCKPE/sU72CFmCkqcnPkErJdZ IFZi30OLCYy8s5BkZiFkQMLMAuoSf+ZdYoawFSWmdD9khyhRk1jWqoQsvICRbRWjbEpulW5u YmZOcWqybnFyYl5eapGuqV5uZoleakrpJkZQ2LO7KO1gnPjP6xCjAAejEg/vijvbI4VYE8uK K3MPMUpyMCmJ8mYr7ogU4kvKT6nMSCzOiC8qzUktPsQowcGsJML7SxUox5uSWFmVWpQPk5Lm YFES5xXXaIwQEkhPLEnNTk0tSC2CycpwcChJ8HZYADUKFqWmp1akZeaUIKSZODhBhvMADT8E UsNbXJCYW5yZDpE/xRjMMePm3T9MHBvA5D4w+eTavL9MQix5+XmpUuK8bMCkJCQA0pZRmgc3 WUlISECN/feEjI3vtSz95r+6s7TFCJT61ljddHnFKA70vDDve5CFPMC0CbfvFdApTECn8Fza AnJKSSJCSqqBkUfbtcxXfWnB+692ZoHLM2ruuSw6KvLoin9GyKugivQvPn2yLKaPWHu6BFcm izrMZAuemHL6mUuspvanL0rr5Hwir21jvWyus8ppq3ShRMki0+yJB/h/rig796BzWt88kRVb byk/D5j9xz/ze3adzHXX9etia24+/XhzYrmHx0u13jAZBg4hJZbijERDLeai4kQARqaKqlgD AAA= Archived-At: Subject: Re: [saag] Vectors of Trust - Experimental or Standards Track X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Sep 2017 19:47:43 -0000 ----_com.samsung.android.email_1014825121660110 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 UmlnaHQsIGFuZCBub3cgdGhhdCB0aGVyZSBhcmUgY29uY3JldGUgaW1wbGVtZW50YXRpb25zIGFu ZCByZWZlcmVuY2VzLCBJJ2QgYWdyZWUgdGhhdCBpdCdzIG5vdCBhcyBleHBlcmltZW50YWwgYW55 bW9yZSBhbmQgd2UgY2FuIHN3aXRjaCBpdCB0byBzdGFuZGFyZHMgdHJhY2suIEFzIEkgbWVudGlv bmVkIGJlbG93LCB5b3UncmUgbm90IHRoZSBmaXJzdCB0byBtYWtlIHRoaXMgc3VnZ2VzdGlvbi4g SXQncyBhIHRpbnkgY2hhbmdlIGFuZCBJIGNhbiBkbyB0aGF0IGVhc2lseSBkdXJpbmcgdGhlIG5l eHQgcmV2aXNpb24gd2hlbiB3ZSBnZXQgc2hlcGhlcmQgb3IgSUVTRyBjb21tZW50cyB0aGF0IHJl cXVpcmUgY2hhbmdlcy7CoApUaGFua3MswqAKLS1KdXN0aW4KwqBTZW50IGZyb20gbXkgcGhvbmUK LS0tLS0tLS0gT3JpZ2luYWwgbWVzc2FnZSAtLS0tLS0tLUZyb206IFBoaWwgSHVudCA8cGhpbC5o dW50QG9yYWNsZS5jb20+IERhdGU6IDkvMTIvMTcgIDM6MzIgUE0gIChHTVQtMDU6MDApIFRvOiBK dXN0aW4gUmljaGVyIDxqcmljaGVyQG1pdC5lZHU+IENjOiBKb2huIEJyYWRsZXkgPHZlN2p0YkB2 ZTdqdGIuY29tPiwgVG9ueSBOYWRhbGluIDx0b255bmFkQG1pY3Jvc29mdC5jb20+LCBLYXRobGVl biBNb3JpYXJ0eSA8a2F0aGxlZW4ubW9yaWFydHkuaWV0ZkBnbWFpbC5jb20+LCBMZWlmIEpvaGFu c3NvbiA8bGVpZmpAc3VuZXQuc2U+LCBzYWFnQGlldGYub3JnIFN1YmplY3Q6IFZlY3RvcnMgb2Yg VHJ1c3QgLSBFeHBlcmltZW50YWwgb3IgU3RhbmRhcmRzIFRyYWNrIApBZGRpbmcgc2FhZyBzbyB3 ZSBjYW4gZ2V0IHRoaXMgb24gdGhlIHJlY29yZCBwZXIgS2F0aGxlZW7igJlzIHN1Z2dlc3Rpb24u CkFwb2xvZ2llcyBJIG9yaWdpbmFsbHkgc3RhcnRlZCB0aGlzIHRocmVhZCBhcyBjb21tdW5pY2F0 aW9ucyB3aXRoIHRoZSBhdXRob3JzLgpKdXN0aW4sIEkgaW5pdGlhdGVkIHRoaXMgdGhyZWFkIGJl Y2F1c2Ugb2YgdGhlIGNsYXNzaWZpY2F0aW9uIG9mIHRoZSBWZWN0b3JzIG9mIFRydXN0IGRvY3Vt ZW50WzBdIGFzIOKAnGV4cGVyaW1lbnRhbCIuIEFzIHdlaXJkIGFzIHlvdSBzdWdnZXN0IHRoZSBJ RVRGIGlzLCBSRkMyMDI2IGRlZmluZXMg4oCcZXhwZXJpbWVudGFs4oCdIGRlc2lnbmF0aW9uIGFz OjQuMi4xICBFeHBlcmltZW50YWwKCiAgIFRoZSAiRXhwZXJpbWVudGFsIiBkZXNpZ25hdGlvbiB0 eXBpY2FsbHkgZGVub3RlcyBhIHNwZWNpZmljYXRpb24gdGhhdAogICBpcyBwYXJ0IG9mIHNvbWUg cmVzZWFyY2ggb3IgZGV2ZWxvcG1lbnQgZWZmb3J0LiAgU3VjaCBhIHNwZWNpZmljYXRpb24KICAg aXMgcHVibGlzaGVkIGZvciB0aGUgZ2VuZXJhbCBpbmZvcm1hdGlvbiBvZiB0aGUgSW50ZXJuZXQg dGVjaG5pY2FsCiAgIGNvbW11bml0eSBhbmQgYXMgYW4gYXJjaGl2YWwgcmVjb3JkIG9mIHRoZSB3 b3JrLCBzdWJqZWN0IG9ubHkgdG8KICAgZWRpdG9yaWFsIGNvbnNpZGVyYXRpb25zIGFuZCB0byB2 ZXJpZmljYXRpb24gdGhhdCB0aGVyZSBoYXMgYmVlbgogICBhZGVxdWF0ZSBjb29yZGluYXRpb24g d2l0aCB0aGUgc3RhbmRhcmRzIHByb2Nlc3MgKHNlZSBiZWxvdykuICBBbgogICBFeHBlcmltZW50 YWwgc3BlY2lmaWNhdGlvbiBtYXkgYmUgdGhlIG91dHB1dCBvZiBhbiBvcmdhbml6ZWQgSW50ZXJu ZXQKICAgcmVzZWFyY2ggZWZmb3J0IChlLmcuLCBhIFJlc2VhcmNoIEdyb3VwIG9mIHRoZSBJUlRG KSwgYW4gSUVURiBXb3JraW5nCiAgIEdyb3VwLCBvciBpdCBtYXkgYmUgYW4gaW5kaXZpZHVhbCBj b250cmlidXRpb24uClImRCBpcyBub3QgdGhlIGNhc2Ugd2l0aCB0aGlzIGRyYWZ0IGdpdmVuIHdo YXQgaXMgb24gdHJhY2sgd2l0aCBOSVNUIGFuZCBPcGVuSUQgRm91bmRhdGlvbi5UaGUgT3BlbklE IEZvdW5kYXRpb24gaUdvdiBXb3JraW5nIEdyb3VwIGFuZCBhcHBhcmVudGx5IE5JU1QgYXJlICpj dXJyZW50bHkqIHJlZmVyZW5jaW5nIHRoaXMgYXMgYSBtYW5kYXRvcnkgcmVxdWlyZW1lbnQgZm9y IG9wZXJhdGlvbmFsIHVzZSByYXRoZXIgdGhlbiB1c2UgZXhjbHVzaXZlbHkgaW4gcmVzZWFyY2gg YW5kIGRldmVsb3BtZW50LCB0aGUgY2xhc3NpZmljYXRpb24gaXMgaW5hcHByb3ByaWF0ZS4gU3Bl Y2lmaWNhbGx5IHRoZSBpR292IGRyYWZ0IHJlZmVycyB0byB0aGUgVm9UIGFzIGFuIElFVEYg4oCc c3RhbmRhcmTigJ0uIFRoZSBPcGVuSUQgaUdvdiBkcmFmdCB3YXMganVzdCB2b3RlZCB0byDigJxp bXBsZW1lbnRhdGlvbuKAnSBzdGF0dXMgd2hpY2ggbWVhbnMgcGVvcGxlIGFyZSBub3cgaW1wbGVt ZW50aW5nIGZvciBwcm9kdWN0aW9uIGFuZCBOT1QgUiZELiBSZWdhcmRsZXNzIG9mIHRoZSBkaWZm ZXJlbmNlcyBpbiB0ZXJtcywgaUdvdiBpcyBpbnRlbmRlZCB0byBiZSBhIHN0YW5kYXJkIHdoaWxl IFZvVCBpcyBjdXJyZW50bHkgbm90LlsxXUkgdW5kZXJzdGFuZCBuZXcgU1AtODAwLTYzIHJlZ3Vs YXRpb25zIGFyZSBiZWluZyBkZXZlbG9wZWQgdGhhdCB3aWxsIHVzZSB0aGlzIOKAnHN0YW5kYXJk 4oCdLlsyXQpJIGFtIGNvbmNlcm5lZCB0aGF0IGFzIOKAnGV4cGVyaW1lbnRhbCIsIHRoZSBWb1Qg ZHJhZnQgd2lsbCBub3QgcmVjZWl2ZSB0aGUgcHJvcGVyIHNjcnV0aW55IGl0IG5lZWRzIHRvIGhh dmUuIEkgYW0gbm90IHN1cmUgd2h5IGl0IGlzIGF0IHRoZSBJRVRGIHNpbmNlIGl0cyBkb21haW4g b2YgdXNlIGlzIGxhcmdlbHkgT3BlbklEIGFuZCBTQU1MLgpJIHdpbGwgbGVhdmUgY29tbWVudHMg cmVnYXJkaW5nIOKAnFZvVOKAnSBkcmFmdCBmb3IgdGhlIFZvVCBsaXN0IGF0IGEgbGF0ZXIgdGlt ZS4KWzBdwqBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcmljaGVyLXZlY3RvcnMt b2YtdHJ1c3QtMDVbMV3CoGh0dHBzOi8veG1sMnJmYy50b29scy5pZXRmLm9yZy9jZ2ktYmluL3ht bDJyZmMuY2dpP1N1Ym1pdD1TdWJtaXQmZm9ybWF0PWFzY2lpJm1vZGU9aHRtbCZ0eXBlPWFzY2lp JnVybD1odHRwczovL2JpdGJ1Y2tldC5vcmcvb3BlbmlkL2lnb3YvcmF3L21hc3Rlci9vcGVuaWQt aWdvdi1wcm9maWxlLnhtbCNyZmMuc2VjdGlvbi4zLjRbMl3CoGh0dHBzOi8vZ2l0aHViLmNvbS91 c25pc3Rnb3YvODAwLTYzLTMvYmxvYi92b2x1bWUtZC9zcDgwMC02M2Qvdm90X21hcHBpbmcubWQK VGhhbmtzIGNsZWFyaW5nIHRoaXMgdXAuCgpQaGlsCk9yYWNsZSBDb3Jwb3JhdGlvbiwgSWRlbnRp dHkgQ2xvdWQgU2VydmljZXMgQXJjaGl0ZWN0QGluZGVwZW5kZW50aWR3d3cuaW5kZXBlbmRlbnRp ZC5jb21waGlsLmh1bnRAb3JhY2xlLmNvbQoKCk9uIFNlcCAxMiwgMjAxNywgYXQgMTA6NDcgQU0s IEp1c3RpbiBSaWNoZXIgPGpyaWNoZXJAbWl0LmVkdT4gd3JvdGU6ClBoaWwsClRoZSBkcmFmdCBz dGFydGVkIG91dCBpbiBzdGFuZGFyZHMtdHJhY2sgdGhlbiBtb3ZlZCB0byBleHBlcmltZW50YWwg ZHVyaW5nIG9uZSBvZiB0aGUgcmV2aXNpb25zIGR1ZSB0byBzb21lIGZlZWRiYWNrLiBSZWNlbnQg ZmVlZGJhY2sgaGFzIGFza2VkIHRvIHB1dCBpdCBiYWNrIGluIHN0YW5kYXJkcy10cmFjaywgYW5k IEnigJlkIGJlIGZpbmUgd2l0aCBlaXRoZXIgdG8gYmUgaG9uZXN0LiBCdXQgaW4gdGhlIGVuZCBJ IGRvbuKAmXQgdGhpbmsgdGhhdCBkZXNpZ25hdGlvbiByZWFsbHkgbWF0dGVycywgYW5kIHlvdeKA mXJlIHJlYWRpbmcgd2F5IG1vcmUgaW50byBpdCB0aGFuIGlzIGludGVuZGVkLiBJIHJlY2FsbCB0 aGVyZSB3YXMgYSBzaW1pbGFyIGRpc2N1c3Npb24gYSBjb3VwbGUgeWVhcnMgYWdvICh0aGF0IHlv dSwgUGhpbCwgd2VyZSBhIHBhcnQgb2YpLCB3aGVyZSBPQXV0aCB3YXMgY2FsbGVkIG91dCBhcyBu b3QgYmVpbmcgYSDigJxyZWFsIHN0YW5kYXJk4oCdIGJlY2F1c2UgdGhlIFJGQyBzdGF0ZXMgaXTi gJlzIGEg4oCccHJvcG9zZWQgc3RhbmRhcmTigJ0uIFRoaXMsIGxpa2Ugbm93LCBJIHRoaW5rIGlz IGEgbWlzaW50ZXJwcmV0YXRpb24gb2YgdGhlIG1lYW5pbmcgYW5kIGludGVudCBvZiB0aGUgZG9j dW1lbnQgZGVzaWduYXRpb25zIGFuZCBpcyBhIGRpc3RyYWN0aW9uIGZyb20gd2hhdOKAmXMgaW1w b3J0YW50LiBZZXMsIHRoZSBJRVRGIGlzIHdlaXJkIGluIGhvdyBpdCBjYWxscyB0aGluZ3Mg4oCU IGJ1dCB3ZSBkb27igJl0IGdldCB0byBwaWNrIHRoZWlyIHRlcm1zIG9yIHJlZGVmaW5lIHRoZWly IG1lYW5pbmdzLsKgCkkgYW50aWNpcGF0ZWQgVm9UIGdvaW5nIHRvIFJGQyB3ZWxsIG92ZXIgYSB5 ZWFyIGFuZCBhIGhhbGYgYWdvIOKAlCBpdOKAmXMgYmVlbiBzdGFibGUgdGhhdCBsb25nLCBhbmQg dGhhdOKAmXMgd2h5IHlvdSBkb27igJl0IHNlZSBtdWNoIHJlY2VudCB0cmFmZmljIG9uIHRoZSB2 b3RAaWV0ZiBtYWlsaW5nIGxpc3Qg4oCUIGJ1dCBhcyBhbiBBRC1zcG9uc29yZWQgZG9jdW1lbnQg aXTigJlzIGJlZW4gc2xvdyBmaW5kaW5nIHNoZXBoZXJkcyBhbmQgZ2V0dGluZyB0aHJvdWdoIHRo ZSBwcm9jZXNzIHdpdGhvdXQgYSBXRyBjaGFpciBwdXNoaW5nIHRoaW5ncy4gVGhpcyBkb2VzbuKA mXQgbWFrZSBpdCBhbnkgbGVzcyB2YWxpZCBvZiBhIHN0YW5kYXJkLCBidXQgaXQgZG9lcyBjaGFu Z2UgdGhlIHByb2Nlc3MgdGhhdCBpdCBnb2VzIHRocm91Z2gsIHNvbWV3aGF0LiBJdCB3aWxsIHN0 aWxsIGdldCBmdWxsIElFU0cgcmV2aWV3LiBBbmQsIHRoZSBpbXBvcnRhbnQgcGFydCwgaXTigJlz IHN0aWxsIHVzZWZ1bCBhbmQgdXNhYmxlLsKgCkFzIGZhciBhcyBJIGNhbiBzZWUgaXQsIHlvdXIg bWFpbiBhcmd1bWVudCBhZ2FpbnN0IHVzaW5nIFZvVCBpcyB0aGF0IGl04oCZcyBhIGRyYWZ0IHN0 YW5kYXJkIOKAlCBidXQgc28gaXMgaUdvdi4gQW5kIFZvVCBjYW4gYW5kIHdpbGwgYmUgbW92ZWQg Zm9yd2FyZCBpbiB0aGUgSUVURiBhcyBhbiBSRkMgc3RhbmRhcmQuIFRoYXQgcHJvY2VzcyBpcyBo YXBwZW5pbmcgbm93LCBKb2huIGlzIHRoZSBzaGVwaGVyZCBhbmQgaGFzIHRoZSBwb3dlciB0byBt b3ZlIGl0IGZvcndhcmQuClNvIHdpdGggdGhpcyBpbiBtaW5kLCBKb2hu4oCZcyBkaXNjdXNzaW9u IGJlbG93IGlzIHNwb3Qgb24uIFRoZSB3YXkgdGhhdCBWb1QgZ2V0cyB1c2VkIGlzIGZhaXJseSBz aW1wbGU6ClRoZSBSUCBjYW4gcmVxdWVzdCBhIOKAnHZ0ciIsIHdoaWNoIGJhc2ljYWxseSBzYXlz IOKAnHRoaXMgaXMgdGhlIFZvVCB0aGF0IEnigJlkIGxpa2XigJ0uIElkUCBjYW4gcmVzcG9uZCB3 aXRoIOKAnHZvdOKAnSwgd2hpY2ggaXMg4oCcaGVyZeKAmXMgeW91ciB2ZWN0b3IgdmFsdWVz4oCd LCBhbG9uZyB3aXRoIOKAnHZ0bSIsIHdoaWNoIGlzIOKAnGhlcmXigJlzIHdoZXJlIHRoZSBjb250 ZW50cyBvZiB0aGlzIHZlY3RvciBhcmUgZGVmaW5lZOKAnS4gTklTVCwgYXMgbWVudGlvbmVkIGFu ZCBhcyBJ4oCZZCBsaW5rZWQgdG8geW91LCBpcyBkZWZpbmluZyBpdHMgb3duIOKAnHZ0beKAnSBk b2N1bWVudC4gVGhpcyB3aWxsIGRlZmluZSB3aGF0IOKAnFAx4oCdIG1lYW5zIChzdXJwcmlzZSwg aXQgbWFwcyBkaXJlY3RseSB0byBJQUwxKSwgYW1vbmcgZXZlcnl0aGluZyBlbHNlLiBUaGUgdmFs dWVzIGluIHRoZSBWb1QgZHJhZnQgYXJlbuKAmXQgdXNlZCBpbiB0aGF0IGNhc2UsIHNpbmNlIHRo ZXkgZXhpc3QgdW5kZXIgYSDigJx2dG3igJ0gZGVmaW5lZCBieSB0aGUgUkZDLCBvbmNlIHRoYXTi gJlzIGFzc2lnbmVkIGFuZCBwdWJsaXNoZWQsIGJ1dCB5b3UgZG9u4oCZdCBoYXZlIHRvIHVzZSB0 aGVtLiBBbmQgaUdvdiBpcyBub3QgaW4gdGhlIGJ1c2luZXNzIG9mIGRlZmluaW5nIHdoaWNoIOKA nHZ0beKAnSBwZW9wbGUgc2hvdWxkIGJlIHVzaW5nLCBidXQgd2Ugd2FudCBpbXBsZW1lbnRhdGlv bnMgdG8gYXQgbGVhc3QgdXNlIHRoZSBzYW1lIG1lY2hhbmlzbSDigJQgVm9UIOKAlCBmb3IgY29u dmV5aW5nIHNpbWlsYXIgaW5mb3JtYXRpb24uwqAKwqDigJQgSnVzdGluCgo= ----_com.samsung.android.email_1014825121660110 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keT48ZGl2PlJpZ2h0LCBhbmQgbm93IHRo YXQgdGhlcmUgYXJlIGNvbmNyZXRlIGltcGxlbWVudGF0aW9ucyBhbmQgcmVmZXJlbmNlcywgSSdk IGFncmVlIHRoYXQgaXQncyBub3QgYXMgZXhwZXJpbWVudGFsIGFueW1vcmUgYW5kIHdlIGNhbiBz d2l0Y2ggaXQgdG8gc3RhbmRhcmRzIHRyYWNrLiBBcyBJIG1lbnRpb25lZCBiZWxvdywgeW91J3Jl IG5vdCB0aGUgZmlyc3QgdG8gbWFrZSB0aGlzIHN1Z2dlc3Rpb24uIEl0J3MgYSB0aW55IGNoYW5n ZSBhbmQgSSBjYW4gZG8gdGhhdCBlYXNpbHkgZHVyaW5nIHRoZSBuZXh0IHJldmlzaW9uIHdoZW4g d2UgZ2V0IHNoZXBoZXJkIG9yIElFU0cgY29tbWVudHMgdGhhdCByZXF1aXJlIGNoYW5nZXMuJm5i c3A7PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5UaGFua3MsJm5ic3A7PC9kaXY+PGRpdj48YnI+ PC9kaXY+PGRpdiBpZD0iY29tcG9zZXJfc2lnbmF0dXJlIj48bWV0YSBodHRwLWVxdWl2PSJDb250 ZW50LVR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD1VVEYtOCI+PGRpdiBzdHlsZT0i Zm9udC1zaXplOjg1JTtjb2xvcjojNTc1NzU3Ij4tLUp1c3RpbjwvZGl2PjxkaXYgc3R5bGU9ImZv bnQtc2l6ZTo4NSU7Y29sb3I6IzU3NTc1NyI+PGJyPjwvZGl2PjxkaXYgc3R5bGU9ImZvbnQtc2l6 ZTo4NSU7Y29sb3I6IzU3NTc1NyI+Jm5ic3A7PGk+U2VudCBmcm9tIG15IHBob25lPC9pPjwvZGl2 PjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXYgc3R5bGU9ImZvbnQtc2l6ZToxMDAlO2NvbG9yOiMw MDAwMDAiPjwhLS0gb3JpZ2luYWxNZXNzYWdlIC0tPjxkaXY+LS0tLS0tLS0gT3JpZ2luYWwgbWVz c2FnZSAtLS0tLS0tLTwvZGl2PjxkaXY+RnJvbTogUGhpbCBIdW50ICZsdDtwaGlsLmh1bnRAb3Jh Y2xlLmNvbSZndDsgPC9kaXY+PGRpdj5EYXRlOiA5LzEyLzE3ICAzOjMyIFBNICAoR01ULTA1OjAw KSA8L2Rpdj48ZGl2PlRvOiBKdXN0aW4gUmljaGVyICZsdDtqcmljaGVyQG1pdC5lZHUmZ3Q7IDwv ZGl2PjxkaXY+Q2M6IEpvaG4gQnJhZGxleSAmbHQ7dmU3anRiQHZlN2p0Yi5jb20mZ3Q7LCBUb255 IE5hZGFsaW4gJmx0O3RvbnluYWRAbWljcm9zb2Z0LmNvbSZndDssIEthdGhsZWVuIE1vcmlhcnR5 ICZsdDtrYXRobGVlbi5tb3JpYXJ0eS5pZXRmQGdtYWlsLmNvbSZndDssIExlaWYgSm9oYW5zc29u ICZsdDtsZWlmakBzdW5ldC5zZSZndDssIHNhYWdAaWV0Zi5vcmcgPC9kaXY+PGRpdj5TdWJqZWN0 OiBWZWN0b3JzIG9mIFRydXN0IC0gRXhwZXJpbWVudGFsIG9yIFN0YW5kYXJkcyBUcmFjayA8L2Rp dj48ZGl2Pjxicj48L2Rpdj48L2Rpdj5BZGRpbmcgc2FhZyBzbyB3ZSBjYW4gZ2V0IHRoaXMgb24g dGhlIHJlY29yZCBwZXIgS2F0aGxlZW7igJlzIHN1Z2dlc3Rpb24uPGRpdiBjbGFzcz0iIj48YnIg Y2xhc3M9IiI+PC9kaXY+PGRpdiBjbGFzcz0iIj5BcG9sb2dpZXMgSSBvcmlnaW5hbGx5IHN0YXJ0 ZWQgdGhpcyB0aHJlYWQgYXMgY29tbXVuaWNhdGlvbnMgd2l0aCB0aGUgYXV0aG9ycy48L2Rpdj48 ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj48L2Rpdj48ZGl2IGNsYXNzPSIiPkp1c3RpbiwgSSBp bml0aWF0ZWQgdGhpcyB0aHJlYWQgYmVjYXVzZSBvZiB0aGUgY2xhc3NpZmljYXRpb24gb2YgdGhl IFZlY3RvcnMgb2YgVHJ1c3QgZG9jdW1lbnRbMF0gYXMg4oCcZXhwZXJpbWVudGFsIi4gQXMgd2Vp cmQgYXMgeW91IHN1Z2dlc3QgdGhlIElFVEYgaXMsIFJGQzIwMjYgZGVmaW5lcyDigJxleHBlcmlt ZW50YWzigJ0gZGVzaWduYXRpb24gYXM6PC9kaXY+PGRpdiBjbGFzcz0iIj48YmxvY2txdW90ZSB0 eXBlPSJjaXRlIiBjbGFzcz0iIj48cHJlIGNsYXNzPSJuZXdwYWdlIiBzdHlsZT0iZm9udC1zaXpl OiAxMy4zMzMzMzMwMTU0NDE4OTVweDsgbWFyZ2luLXRvcDogMHB4OyBtYXJnaW4tYm90dG9tOiAw cHg7IGJyZWFrLWJlZm9yZTogcGFnZTsiPjxzcGFuIGNsYXNzPSJoNCIgc3R5bGU9ImxpbmUtaGVp Z2h0OiAwcHQ7IGRpc3BsYXk6IGlubGluZTsgZm9udC1zaXplOiAxZW07IGZvbnQtd2VpZ2h0OiBi b2xkOyI+PGg0IHN0eWxlPSJsaW5lLWhlaWdodDogMHB0OyBkaXNwbGF5OiBpbmxpbmU7IGZvbnQt c2l6ZTogMWVtOyIgY2xhc3M9IiI+PGEgY2xhc3M9InNlbGZsaW5rIiBuYW1lPSJzZWN0aW9uLTQu Mi4xIiBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjMjAyNiNzZWN0aW9uLTQu Mi4xIiBzdHlsZT0iY29sb3I6IGJsYWNrOyB0ZXh0LWRlY29yYXRpb246IG5vbmU7Ij40LjIuMTwv YT4gIEV4cGVyaW1lbnRhbDwvaDQ+PC9zcGFuPgoKICAgVGhlICJFeHBlcmltZW50YWwiIGRlc2ln bmF0aW9uIHR5cGljYWxseSBkZW5vdGVzIGEgc3BlY2lmaWNhdGlvbiB0aGF0CiAgIGlzIHBhcnQg b2Ygc29tZSByZXNlYXJjaCBvciBkZXZlbG9wbWVudCBlZmZvcnQuICBTdWNoIGEgc3BlY2lmaWNh dGlvbgogICBpcyBwdWJsaXNoZWQgZm9yIHRoZSBnZW5lcmFsIGluZm9ybWF0aW9uIG9mIHRoZSBJ bnRlcm5ldCB0ZWNobmljYWwKICAgY29tbXVuaXR5IGFuZCBhcyBhbiBhcmNoaXZhbCByZWNvcmQg b2YgdGhlIHdvcmssIHN1YmplY3Qgb25seSB0bwogICBlZGl0b3JpYWwgY29uc2lkZXJhdGlvbnMg YW5kIHRvIHZlcmlmaWNhdGlvbiB0aGF0IHRoZXJlIGhhcyBiZWVuCiAgIGFkZXF1YXRlIGNvb3Jk aW5hdGlvbiB3aXRoIHRoZSBzdGFuZGFyZHMgcHJvY2VzcyAoc2VlIGJlbG93KS4gIEFuCiAgIEV4 cGVyaW1lbnRhbCBzcGVjaWZpY2F0aW9uIG1heSBiZSB0aGUgb3V0cHV0IG9mIGFuIG9yZ2FuaXpl ZCBJbnRlcm5ldAogICByZXNlYXJjaCBlZmZvcnQgKGUuZy4sIGEgUmVzZWFyY2ggR3JvdXAgb2Yg dGhlIElSVEYpLCBhbiBJRVRGIFdvcmtpbmcKICAgR3JvdXAsIG9yIGl0IG1heSBiZSBhbiBpbmRp dmlkdWFsIGNvbnRyaWJ1dGlvbi48L3ByZT48L2Jsb2NrcXVvdGU+PGRpdiBjbGFzcz0iIj48YnIg Y2xhc3M9IiI+PC9kaXY+PGRpdiBjbGFzcz0iIj5SJmFtcDtEIGlzIG5vdCB0aGUgY2FzZSB3aXRo IHRoaXMgZHJhZnQgZ2l2ZW4gd2hhdCBpcyBvbiB0cmFjayB3aXRoIE5JU1QgYW5kIE9wZW5JRCBG b3VuZGF0aW9uLjwvZGl2PjxkaXYgY2xhc3M9IiI+PHVsIGNsYXNzPSIiPjxsaSBjbGFzcz0iIj5U aGUgT3BlbklEIEZvdW5kYXRpb24gaUdvdiBXb3JraW5nIEdyb3VwIGFuZCBhcHBhcmVudGx5IE5J U1QgYXJlICpjdXJyZW50bHkqIHJlZmVyZW5jaW5nIHRoaXMgYXMgYSBtYW5kYXRvcnkgcmVxdWly ZW1lbnQgZm9yIG9wZXJhdGlvbmFsIHVzZSByYXRoZXIgdGhlbiB1c2UgZXhjbHVzaXZlbHkgaW4g cmVzZWFyY2ggYW5kIGRldmVsb3BtZW50LCB0aGUgY2xhc3NpZmljYXRpb24gaXMgaW5hcHByb3By aWF0ZS4gU3BlY2lmaWNhbGx5IHRoZSBpR292IGRyYWZ0IHJlZmVycyB0byB0aGUgVm9UIGFzIGFu IElFVEYg4oCcc3RhbmRhcmTigJ0uIFRoZSBPcGVuSUQgaUdvdiBkcmFmdCB3YXMganVzdCB2b3Rl ZCB0byDigJxpbXBsZW1lbnRhdGlvbuKAnSBzdGF0dXMgd2hpY2ggbWVhbnMgcGVvcGxlIGFyZSBu b3cgaW1wbGVtZW50aW5nIGZvciBwcm9kdWN0aW9uIGFuZCBOT1QgUiZhbXA7RC4gUmVnYXJkbGVz cyBvZiB0aGUgZGlmZmVyZW5jZXMgaW4gdGVybXMsIGlHb3YgaXMgaW50ZW5kZWQgdG8gYmUgYSBz dGFuZGFyZCB3aGlsZSBWb1QgaXMgY3VycmVudGx5IG5vdC5bMV08L2xpPjxsaSBjbGFzcz0iIj5J IHVuZGVyc3RhbmQgbmV3IFNQLTgwMC02MyByZWd1bGF0aW9ucyBhcmUgYmVpbmcgZGV2ZWxvcGVk IHRoYXQgd2lsbCB1c2UgdGhpcyDigJxzdGFuZGFyZOKAnS5bMl08L2xpPjwvdWw+PC9kaXY+PGRp diBjbGFzcz0iIj48YnIgY2xhc3M9IiI+PC9kaXY+PGRpdiBjbGFzcz0iIj5JIGFtIGNvbmNlcm5l ZCB0aGF0IGFzIOKAnGV4cGVyaW1lbnRhbCIsIHRoZSBWb1QgZHJhZnQgd2lsbCBub3QgcmVjZWl2 ZSB0aGUgcHJvcGVyIHNjcnV0aW55IGl0IG5lZWRzIHRvIGhhdmUuIEkgYW0gbm90IHN1cmUgd2h5 IGl0IGlzIGF0IHRoZSBJRVRGIHNpbmNlIGl0cyBkb21haW4gb2YgdXNlIGlzIGxhcmdlbHkgT3Bl bklEIGFuZCBTQU1MLjwvZGl2PjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPjwvZGl2PjxkaXYg Y2xhc3M9IiI+SSB3aWxsIGxlYXZlIGNvbW1lbnRzIHJlZ2FyZGluZyDigJxWb1TigJ0gZHJhZnQg Zm9yIHRoZSBWb1QgbGlzdCBhdCBhIGxhdGVyIHRpbWUuPC9kaXY+PGRpdiBjbGFzcz0iIj48YnIg Y2xhc3M9IiI+PC9kaXY+PGRpdiBjbGFzcz0iIj5bMF0mbmJzcDs8YSBocmVmPSJodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcmljaGVyLXZlY3RvcnMtb2YtdHJ1c3QtMDUiIGNsYXNz PSIiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1yaWNoZXItdmVjdG9ycy1vZi10 cnVzdC0wNTwvYT48L2Rpdj48ZGl2IGNsYXNzPSIiPlsxXSZuYnNwOzxhIGhyZWY9Imh0dHBzOi8v eG1sMnJmYy50b29scy5pZXRmLm9yZy9jZ2ktYmluL3htbDJyZmMuY2dpP1N1Ym1pdD1TdWJtaXQm YW1wO2Zvcm1hdD1hc2NpaSZhbXA7bW9kZT1odG1sJmFtcDt0eXBlPWFzY2lpJmFtcDt1cmw9aHR0 cHM6Ly9iaXRidWNrZXQub3JnL29wZW5pZC9pZ292L3Jhdy9tYXN0ZXIvb3BlbmlkLWlnb3YtcHJv ZmlsZS54bWwjcmZjLnNlY3Rpb24uMy40IiBjbGFzcz0iIj5odHRwczovL3htbDJyZmMudG9vbHMu aWV0Zi5vcmcvY2dpLWJpbi94bWwycmZjLmNnaT9TdWJtaXQ9U3VibWl0JmFtcDtmb3JtYXQ9YXNj aWkmYW1wO21vZGU9aHRtbCZhbXA7dHlwZT1hc2NpaSZhbXA7dXJsPWh0dHBzOi8vYml0YnVja2V0 Lm9yZy9vcGVuaWQvaWdvdi9yYXcvbWFzdGVyL29wZW5pZC1pZ292LXByb2ZpbGUueG1sI3JmYy5z ZWN0aW9uLjMuNDwvYT48L2Rpdj48ZGl2IGNsYXNzPSIiPlsyXSZuYnNwOzxhIGhyZWY9Imh0dHBz Oi8vZ2l0aHViLmNvbS91c25pc3Rnb3YvODAwLTYzLTMvYmxvYi92b2x1bWUtZC9zcDgwMC02M2Qv dm90X21hcHBpbmcubWQiIGNsYXNzPSIiPmh0dHBzOi8vZ2l0aHViLmNvbS91c25pc3Rnb3YvODAw LTYzLTMvYmxvYi92b2x1bWUtZC9zcDgwMC02M2Qvdm90X21hcHBpbmcubWQ8L2E+PC9kaXY+PGRp diBjbGFzcz0iIj48YnIgY2xhc3M9IiI+PC9kaXY+PGRpdiBjbGFzcz0iIj5UaGFua3MgY2xlYXJp bmcgdGhpcyB1cC48L2Rpdj48ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj48L2Rpdj48ZGl2IGNs YXNzPSIiPgo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBsZXR0ZXItc3BhY2luZzog bm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zv cm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0 LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHdvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1u YnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyIg Y2xhc3M9IiI+PGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgbGV0dGVyLXNwYWNpbmc6 IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNm b3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtp dC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQt bmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsi IGNsYXNzPSIiPjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGxldHRlci1zcGFjaW5n OiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5z Zm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJr aXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgd29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0 LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7 IiBjbGFzcz0iIj48ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBsZXR0ZXItc3BhY2lu Zzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFu c2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Vi a2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHdvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtp dC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNl OyIgY2xhc3M9IiI+PGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgbGV0dGVyLXNwYWNp bmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJh bnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdl YmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJr aXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFj ZTsiIGNsYXNzPSIiPjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGxldHRlci1zcGFj aW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRy YW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13 ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgd29yZC13cmFwOiBicmVhay13b3JkOyAtd2Vi a2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3Bh Y2U7IiBjbGFzcz0iIj48ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBsZXR0ZXItc3Bh Y2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10 cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAt d2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHdvcmQtd3JhcDogYnJlYWstd29yZDsgLXdl YmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNw YWNlOyIgY2xhc3M9IiI+PGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgbGV0dGVyLXNw YWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQt dHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsg LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13 ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1z cGFjZTsiIGNsYXNzPSIiPjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGxldHRlci1z cGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0 LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7 IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgd29yZC13cmFwOiBicmVhay13b3JkOyAt d2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUt c3BhY2U7IiBjbGFzcz0iIj48ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBsZXR0ZXIt c3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4 dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4 OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHdvcmQtd3JhcDogYnJlYWstd29yZDsg LXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRl LXNwYWNlOyIgY2xhc3M9IiI+PGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgbGV0dGVy LXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRl eHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBw eDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7 IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0 ZS1zcGFjZTsiIGNsYXNzPSIiPjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGxldHRl ci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0 ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAw cHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgd29yZC13cmFwOiBicmVhay13b3Jk OyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hp dGUtc3BhY2U7IiBjbGFzcz0iIj48ZGl2IGNsYXNzPSIiPjxzcGFuIGNsYXNzPSJBcHBsZS1zdHls ZS1zcGFuIiBzdHlsZT0iYm9yZGVyLWNvbGxhcHNlOiBzZXBhcmF0ZTsgbGluZS1oZWlnaHQ6IG5v cm1hbDsgYm9yZGVyLXNwYWNpbmc6IDBweDsiPjxkaXYgY2xhc3M9IiIgc3R5bGU9IndvcmQtd3Jh cDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJl YWs6IGFmdGVyLXdoaXRlLXNwYWNlOyI+PGRpdiBjbGFzcz0iIj48ZGl2IGNsYXNzPSIiPjxkaXYg Y2xhc3M9IiI+UGhpbDwvZGl2PjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPjwvZGl2PjxkaXYg Y2xhc3M9IiI+T3JhY2xlIENvcnBvcmF0aW9uLCBJZGVudGl0eSBDbG91ZCBTZXJ2aWNlcyBBcmNo aXRlY3Q8L2Rpdj48ZGl2IGNsYXNzPSIiPkBpbmRlcGVuZGVudGlkPC9kaXY+PGRpdiBjbGFzcz0i Ij48YSBocmVmPSJodHRwOi8vd3d3LmluZGVwZW5kZW50aWQuY29tIiBjbGFzcz0iIj53d3cuaW5k ZXBlbmRlbnRpZC5jb208L2E+PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+PC9zcGFuPjxhIGhyZWY9 Im1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSIgY2xhc3M9IiIgc3R5bGU9Im9ycGhhbnM6IDI7 IHdpZG93czogMjsiPnBoaWwuaHVudEBvcmFjbGUuY29tPC9hPjwvZGl2PjwvZGl2PjwvZGl2Pjwv ZGl2PjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2 Pgo8L2Rpdj4KPGJyIGNsYXNzPSIiPjxkaXY+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9 IiI+PGRpdiBjbGFzcz0iIj5PbiBTZXAgMTIsIDIwMTcsIGF0IDEwOjQ3IEFNLCBKdXN0aW4gUmlj aGVyICZsdDs8YSBocmVmPSJtYWlsdG86anJpY2hlckBtaXQuZWR1IiBjbGFzcz0iIj5qcmljaGVy QG1pdC5lZHU8L2E+Jmd0OyB3cm90ZTo8L2Rpdj48YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdl LW5ld2xpbmUiPjxkaXYgY2xhc3M9IiI+PGRpdiBzdHlsZT0id29yZC13cmFwOiBicmVhay13b3Jk OyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hp dGUtc3BhY2U7IiBjbGFzcz0iIj5QaGlsLDxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPjwvZGl2 PjxkaXYgY2xhc3M9IiI+VGhlIGRyYWZ0IHN0YXJ0ZWQgb3V0IGluIHN0YW5kYXJkcy10cmFjayB0 aGVuIG1vdmVkIHRvIGV4cGVyaW1lbnRhbCBkdXJpbmcgb25lIG9mIHRoZSByZXZpc2lvbnMgZHVl IHRvIHNvbWUgZmVlZGJhY2suIFJlY2VudCBmZWVkYmFjayBoYXMgYXNrZWQgdG8gcHV0IGl0IGJh Y2sgaW4gc3RhbmRhcmRzLXRyYWNrLCBhbmQgSeKAmWQgYmUgZmluZSB3aXRoIGVpdGhlciB0byBi ZSBob25lc3QuIEJ1dCBpbiB0aGUgZW5kIEkgZG9u4oCZdCB0aGluayB0aGF0IGRlc2lnbmF0aW9u IHJlYWxseSBtYXR0ZXJzLCBhbmQgeW914oCZcmUgcmVhZGluZyB3YXkgbW9yZSBpbnRvIGl0IHRo YW4gaXMgaW50ZW5kZWQuIEkgcmVjYWxsIHRoZXJlIHdhcyBhIHNpbWlsYXIgZGlzY3Vzc2lvbiBh IGNvdXBsZSB5ZWFycyBhZ28gKHRoYXQgeW91LCBQaGlsLCB3ZXJlIGEgcGFydCBvZiksIHdoZXJl IE9BdXRoIHdhcyBjYWxsZWQgb3V0IGFzIG5vdCBiZWluZyBhIOKAnHJlYWwgc3RhbmRhcmTigJ0g YmVjYXVzZSB0aGUgUkZDIHN0YXRlcyBpdOKAmXMgYSDigJxwcm9wb3NlZCBzdGFuZGFyZOKAnS4g VGhpcywgbGlrZSBub3csIEkgdGhpbmsgaXMgYSBtaXNpbnRlcnByZXRhdGlvbiBvZiB0aGUgbWVh bmluZyBhbmQgaW50ZW50IG9mIHRoZSBkb2N1bWVudCBkZXNpZ25hdGlvbnMgYW5kIGlzIGEgZGlz dHJhY3Rpb24gZnJvbSB3aGF04oCZcyBpbXBvcnRhbnQuIFllcywgdGhlIElFVEYgaXMgd2VpcmQg aW4gaG93IGl0IGNhbGxzIHRoaW5ncyDigJQgYnV0IHdlIGRvbuKAmXQgZ2V0IHRvIHBpY2sgdGhl aXIgdGVybXMgb3IgcmVkZWZpbmUgdGhlaXIgbWVhbmluZ3MuJm5ic3A7PGRpdiBjbGFzcz0iIj48 YnIgY2xhc3M9IiI+PC9kaXY+PGRpdiBjbGFzcz0iIj5JIGFudGljaXBhdGVkIFZvVCBnb2luZyB0 byBSRkMgd2VsbCBvdmVyIGEgeWVhciBhbmQgYSBoYWxmIGFnbyDigJQgaXTigJlzIGJlZW4gc3Rh YmxlIHRoYXQgbG9uZywgYW5kIHRoYXTigJlzIHdoeSB5b3UgZG9u4oCZdCBzZWUgbXVjaCByZWNl bnQgdHJhZmZpYyBvbiB0aGUgdm90QGlldGYgbWFpbGluZyBsaXN0IOKAlCBidXQgYXMgYW4gQUQt c3BvbnNvcmVkIGRvY3VtZW50IGl04oCZcyBiZWVuIHNsb3cgZmluZGluZyBzaGVwaGVyZHMgYW5k IGdldHRpbmcgdGhyb3VnaCB0aGUgcHJvY2VzcyB3aXRob3V0IGEgV0cgY2hhaXIgcHVzaGluZyB0 aGluZ3MuIFRoaXMgZG9lc27igJl0IG1ha2UgaXQgYW55IGxlc3MgdmFsaWQgb2YgYSBzdGFuZGFy ZCwgYnV0IGl0IGRvZXMgY2hhbmdlIHRoZSBwcm9jZXNzIHRoYXQgaXQgZ29lcyB0aHJvdWdoLCBz b21ld2hhdC4gSXQgd2lsbCBzdGlsbCBnZXQgZnVsbCBJRVNHIHJldmlldy4gQW5kLCB0aGUgaW1w b3J0YW50IHBhcnQsIGl04oCZcyBzdGlsbCB1c2VmdWwgYW5kIHVzYWJsZS4mbmJzcDs8ZGl2IGNs YXNzPSIiPjxiciBjbGFzcz0iIj48L2Rpdj48ZGl2IGNsYXNzPSIiPkFzIGZhciBhcyBJIGNhbiBz ZWUgaXQsIHlvdXIgbWFpbiBhcmd1bWVudCBhZ2FpbnN0IHVzaW5nIFZvVCBpcyB0aGF0IGl04oCZ cyBhIGRyYWZ0IHN0YW5kYXJkIOKAlCBidXQgc28gaXMgaUdvdi4gQW5kIFZvVCBjYW4gYW5kIHdp bGwgYmUgbW92ZWQgZm9yd2FyZCBpbiB0aGUgSUVURiBhcyBhbiBSRkMgc3RhbmRhcmQuIFRoYXQg cHJvY2VzcyBpcyBoYXBwZW5pbmcgbm93LCBKb2huIGlzIHRoZSBzaGVwaGVyZCBhbmQgaGFzIHRo ZSBwb3dlciB0byBtb3ZlIGl0IGZvcndhcmQuPC9kaXY+PGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9 IiI+PC9kaXY+PGRpdiBjbGFzcz0iIj5TbyB3aXRoIHRoaXMgaW4gbWluZCwgSm9obuKAmXMgZGlz Y3Vzc2lvbiBiZWxvdyBpcyBzcG90IG9uLiBUaGUgd2F5IHRoYXQgVm9UIGdldHMgdXNlZCBpcyBm YWlybHkgc2ltcGxlOjwvZGl2PjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPjwvZGl2PjxkaXYg Y2xhc3M9IiI+VGhlIFJQIGNhbiByZXF1ZXN0IGEg4oCcdnRyIiwgd2hpY2ggYmFzaWNhbGx5IHNh eXMg4oCcdGhpcyBpcyB0aGUgVm9UIHRoYXQgSeKAmWQgbGlrZeKAnS4gSWRQIGNhbiByZXNwb25k IHdpdGgg4oCcdm904oCdLCB3aGljaCBpcyDigJxoZXJl4oCZcyB5b3VyIHZlY3RvciB2YWx1ZXPi gJ0sIGFsb25nIHdpdGgg4oCcdnRtIiwgd2hpY2ggaXMg4oCcaGVyZeKAmXMgd2hlcmUgdGhlIGNv bnRlbnRzIG9mIHRoaXMgdmVjdG9yIGFyZSBkZWZpbmVk4oCdLiBOSVNULCBhcyBtZW50aW9uZWQg YW5kIGFzIEnigJlkIGxpbmtlZCB0byB5b3UsIGlzIGRlZmluaW5nIGl0cyBvd24g4oCcdnRt4oCd IGRvY3VtZW50LiBUaGlzIHdpbGwgZGVmaW5lIHdoYXQg4oCcUDHigJ0gbWVhbnMgKHN1cnByaXNl LCBpdCBtYXBzIGRpcmVjdGx5IHRvIElBTDEpLCBhbW9uZyBldmVyeXRoaW5nIGVsc2UuIFRoZSB2 YWx1ZXMgaW4gdGhlIFZvVCBkcmFmdCBhcmVu4oCZdCB1c2VkIGluIHRoYXQgY2FzZSwgc2luY2Ug dGhleSBleGlzdCB1bmRlciBhIOKAnHZ0beKAnSBkZWZpbmVkIGJ5IHRoZSBSRkMsIG9uY2UgdGhh dOKAmXMgYXNzaWduZWQgYW5kIHB1Ymxpc2hlZCwgYnV0IHlvdSBkb27igJl0IGhhdmUgdG8gdXNl IHRoZW0uIEFuZCBpR292IGlzIG5vdCBpbiB0aGUgYnVzaW5lc3Mgb2YgZGVmaW5pbmcgd2hpY2gg 4oCcdnRt4oCdIHBlb3BsZSBzaG91bGQgYmUgdXNpbmcsIGJ1dCB3ZSB3YW50IGltcGxlbWVudGF0 aW9ucyB0byBhdCBsZWFzdCB1c2UgdGhlIHNhbWUgbWVjaGFuaXNtIOKAlCBWb1Qg4oCUIGZvciBj b252ZXlpbmcgc2ltaWxhciBpbmZvcm1hdGlvbi4mbmJzcDs8ZGl2IGNsYXNzPSIiPjxiciBjbGFz cz0iIj48L2Rpdj48ZGl2IGNsYXNzPSIiPiZuYnNwO+KAlCBKdXN0aW48L2Rpdj48ZGl2IGNsYXNz PSIiPjxiciBjbGFzcz0iIj48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48L2Js b2NrcXVvdGU+PC9kaXY+PGJyIGNsYXNzPSIiPjwvZGl2PjwvYm9keT48L2h0bWw+ ----_com.samsung.android.email_1014825121660110-- From nobody Tue Sep 12 13:10:11 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ECC11330CA for ; Tue, 12 Sep 2017 13:10:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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=nthpermutation-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 fFqFGR-vG1gb for ; Tue, 12 Sep 2017 13:10:06 -0700 (PDT) Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::22b]) (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 13298132F2F for ; Tue, 12 Sep 2017 13:10:06 -0700 (PDT) Received: by mail-qt0-x22b.google.com with SMTP id s18so26302177qta.3 for ; Tue, 12 Sep 2017 13:10:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=jb4gLo+afG30hm+3RsEXSzVJuD/p2+kDM0nMKsdeeao=; b=xxwda4QBr4Z+0MnNJkJPlXM+7aqKlt7zqjjQ0TMn+zjVpyS+yApaCZu94xB1sHTg8P 6TskxpqKueIBJkdCjw5UB+BosPApccVhSYCuIhiaBx9tWDjb/V57e5X/VIYt6OaWKQhn a02dibUhckEV1kPyVO+vSX+vT4j4V0PbZwzm5bdhQA7ZlxxCJSCcl++Mq0K0104eb+RM fOuNItrtvqwPv72boLrifbP6MLsXkmGtxmYWuwEGbqMiViuDXE2UDwOoN9+R+WJXtP7n 5pwtiDM2ckBVLRknx1Oh6RSpY/LnC8p2tMLTQVv8P/aUxqbdxbaIxhJ72peTUl8YkqMg 8b3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=jb4gLo+afG30hm+3RsEXSzVJuD/p2+kDM0nMKsdeeao=; b=Dk6X/5FrchzOsJyMfe/YY+7U6BZCWlaCLvPZz60wsvEWSwdNXTjZRdq9r0BamQNMTO eJNSE8oBaMIZ3bc6yQkFGMZMqbAg2TJzGFK0UEL7hwZOWxl//8NNOR/GAhrUi1EFkqiW MBivMTtLwD4isZS6sOqAGrGEB9p63amt6llUtLEnvntHk481XZ87ZfRfOZH1GXWDjxlZ 3US8Y0Zb9x5TUJliA2CvrfV5FHtvu5Cq5MqIbc5qvCqWuIiAK8EpIgTzrMDy6IoUAVer ReVJGJGawtDJmTsUb3rJBhS2XS+oFyMZq+hVhR5frNsAPAtZgQNqfsqqC2Id8M4Gl3j6 9XYg== X-Gm-Message-State: AHPjjUhu6hxEyMzFgwfaZYn2m/P9DR4R7HZqvuHxS3s3QY3xeYHkCx5n 06fwosD6SP3ZAOQbBkk= X-Google-Smtp-Source: AOwi7QBin/1SS3ubYR1ROIt6wyUMwA6Qygge55z5O8O1nhE0Ur5b7U5E4lIMcTaIWz9XGlATj6Tpxg== X-Received: by 10.200.27.85 with SMTP id p21mr21604876qtk.3.1505247004671; Tue, 12 Sep 2017 13:10:04 -0700 (PDT) Received: from [192.168.1.117] (c-69-140-114-191.hsd1.md.comcast.net. [69.140.114.191]) by smtp.gmail.com with ESMTPSA id u52sm8534910qtb.34.2017.09.12.13.10.02 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 12 Sep 2017 13:10:03 -0700 (PDT) To: saag@ietf.org References: <201709121947.v8CJlXdC018878@outgoing.mit.edu> From: Michael StJohns Message-ID: <4acccd65-d3d1-d80a-0ff8-ba40d3ed2f91@nthpermutation.com> Date: Tue, 12 Sep 2017 16:10:02 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <201709121947.v8CJlXdC018878@outgoing.mit.edu> Content-Type: multipart/alternative; boundary="------------1D1AE3A32C4ECA7E113A5E20" Content-Language: en-US Archived-At: Subject: Re: [saag] Vectors of Trust - Experimental or Standards Track X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Sep 2017 20:10:09 -0000 This is a multi-part message in MIME format. --------------1D1AE3A32C4ECA7E113A5E20 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 9/12/2017 3:47 PM, Justin Richer wrote: > Right, and now that there are concrete implementations and references, > I'd agree that it's not as experimental anymore and we can switch it > to standards track. As I mentioned below, you're not the first to make > this suggestion. It's a tiny change and I can do that easily during > the next revision when we get shepherd or IESG comments that require > changes. Given what's happened with this you may want to move this to informational and get one of the OpenID or SAML groups to take ownership of it. Experimental is still possible (e.g. Experimental is how the IETF views this - we're not sure why the other folks are considering it normative - but not our problem). - but would then be subject to large changes if someone wanted to move forward to a standard. And to be fair, 2026 is probably best read more like:  "Experimental means that we're not sure this is a good idea, or that this is the best approach to implement a good idea or if we've been smoking something and gotten our figures crossed.  At some point in time we might decide to throw the whole thing in the garbage or, alternately might decide to try and salvage something from this by crafting a standard.  At no time should the presence of implementations of this experiment be confused with the existence of a standard." The key words in the 2026 definition are "typically part of some effort" and "general information" and "archival record". The question to ask is "In this particular standardization space, is the VOT effort the correct approach and do we have enough broad involvement to be able to state there is a consensus on that belief?"  If the answer is no then stick to Informational or Experimental.  If the answer is maybe - start up a working group. Later, Mike > > Thanks, > > --Justin > > /Sent from my phone/ > > -------- Original message -------- > From: Phil Hunt > Date: 9/12/17 3:32 PM (GMT-05:00) > To: Justin Richer > Cc: John Bradley , Tony Nadalin > , Kathleen Moriarty > , Leif Johansson , > saag@ietf.org > Subject: Vectors of Trust - Experimental or Standards Track > > Adding saag so we can get this on the record per Kathleen’s suggestion. > > Apologies I originally started this thread as communications with the > authors. > > Justin, I initiated this thread because of the classification of the > Vectors of Trust document[0] as “experimental". As weird as you > suggest the IETF is, RFC2026 defines “experimental” designation as: >> >> >> 4.2.1 >> Experimental >> >> >> >> The "Experimental" designation typically denotes a specification that >> is part of some research or development effort. Such a specification >> is published for the general information of the Internet technical >> community and as an archival record of the work, subject only to >> editorial considerations and to verification that there has been >> adequate coordination with the standards process (see below). An >> Experimental specification may be the output of an organized Internet >> research effort (e.g., a Research Group of the IRTF), an IETF Working >> Group, or it may be an individual contribution. > > R&D is not the case with this draft given what is on track with NIST > and OpenID Foundation. > > * The OpenID Foundation iGov Working Group and apparently NIST are > *currently* referencing this as a mandatory requirement for > operational use rather then use exclusively in research and > development, the classification is inappropriate. Specifically the > iGov draft refers to the VoT as an IETF “standard”. The OpenID > iGov draft was just voted to “implementation” status which means > people are now implementing for production and NOT R&D. Regardless > of the differences in terms, iGov is intended to be a standard > while VoT is currently not.[1] > * I understand new SP-800-63 regulations are being developed that > will use this “standard”.[2] > > > I am concerned that as “experimental", the VoT draft will not receive > the proper scrutiny it needs to have. I am not sure why it is at the > IETF since its domain of use is largely OpenID and SAML. > > I will leave comments regarding “VoT” draft for the VoT list at a > later time. > > [0] https://tools.ietf.org/html/draft-richer-vectors-of-trust-05 > [1] > https://xml2rfc.tools.ietf.org/cgi-bin/xml2rfc.cgi?Submit=Submit&format=ascii&mode=html&type=ascii&url=https://bitbucket.org/openid/igov/raw/master/openid-igov-profile.xml#rfc.section.3.4 > [2] > https://github.com/usnistgov/800-63-3/blob/volume-d/sp800-63d/vot_mapping.md > > Thanks clearing this up. > > Phil > > Oracle Corporation, Identity Cloud Services Architect > @independentid > www.independentid.com > phil.hunt@oracle.com > >> On Sep 12, 2017, at 10:47 AM, Justin Richer > > wrote: >> >> Phil, >> >> The draft started out in standards-track then moved to experimental >> during one of the revisions due to some feedback. Recent feedback has >> asked to put it back in standards-track, and I’d be fine with either >> to be honest. But in the end I don’t think that designation really >> matters, and you’re reading way more into it than is intended. I >> recall there was a similar discussion a couple years ago (that you, >> Phil, were a part of), where OAuth was called out as not being a >> “real standard” because the RFC states it’s a “proposed standard”. >> This, like now, I think is a misinterpretation of the meaning and >> intent of the document designations and is a distraction from what’s >> important. Yes, the IETF is weird in how it calls things — but we >> don’t get to pick their terms or redefine their meanings. >> >> I anticipated VoT going to RFC well over a year and a half ago — it’s >> been stable that long, and that’s why you don’t see much recent >> traffic on the vot@ietf mailing list — but as an AD-sponsored >> document it’s been slow finding shepherds and getting through the >> process without a WG chair pushing things. This doesn’t make it any >> less valid of a standard, but it does change the process that it goes >> through, somewhat. It will still get full IESG review. And, the >> important part, it’s still useful and usable. >> >> As far as I can see it, your main argument against using VoT is that >> it’s a draft standard — but so is iGov. And VoT can and will be moved >> forward in the IETF as an RFC standard. That process is happening >> now, John is the shepherd and has the power to move it forward. >> >> So with this in mind, John’s discussion below is spot on. The way >> that VoT gets used is fairly simple: >> >> The RP can request a “vtr", which basically says “this is the VoT >> that I’d like”. IdP can respond with “vot”, which is “here’s your >> vector values”, along with “vtm", which is “here’s where the contents >> of this vector are defined”. NIST, as mentioned and as I’d linked to >> you, is defining its own “vtm” document. This will define what “P1” >> means (surprise, it maps directly to IAL1), among everything else. >> The values in the VoT draft aren’t used in that case, since they >> exist under a “vtm” defined by the RFC, once that’s assigned and >> published, but you don’t have to use them. And iGov is not in the >> business of defining which “vtm” people should be using, but we want >> implementations to at least use the same mechanism — VoT — for >> conveying similar information. >> >>  — Justin >> > > > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag --------------1D1AE3A32C4ECA7E113A5E20 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 9/12/2017 3:47 PM, Justin Richer wrote:
Right, and now that there are concrete implementations and references, I'd agree that it's not as experimental anymore and we can switch it to standards track. As I mentioned below, you're not the first to make this suggestion. It's a tiny change and I can do that easily during the next revision when we get shepherd or IESG comments that require changes.

Given what's happened with this you may want to move this to informational and get one of the OpenID or SAML groups to take ownership of it.

Experimental is still possible (e.g. Experimental is how the IETF views this - we're not sure why the other folks are considering it normative - but not our problem). - but would then be subject to large changes if someone wanted to move forward to a standard.

And to be fair, 2026 is probably best read more like:  "Experimental means that we're not sure this is a good idea, or that this is the best approach to implement a good idea or if we've been smoking something and gotten our figures crossed.  At some point in time we might decide to throw the whole thing in the garbage or, alternately might decide to try and salvage something from this by crafting a standard.  At no time should the presence of implementations of this experiment be confused with the existence of a standard."

The key words in the 2026 definition are "typically part of some effort" and "general information" and "archival record".

The question to ask is "In this particular standardization space, is the VOT effort the correct approach and do we have enough broad involvement to be able to state there is a consensus on that belief?"  If the answer is no then stick to Informational or Experimental.  If the answer is maybe - start up a working group. 

Later, Mike



 

Thanks, 

--Justin

 Sent from my phone

-------- Original message --------
From: Phil Hunt <phil.hunt@oracle.com>
Date: 9/12/17 3:32 PM (GMT-05:00)
To: Justin Richer <jricher@mit.edu>
Cc: John Bradley <ve7jtb@ve7jtb.com>, Tony Nadalin <tonynad@microsoft.com>, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>, Leif Johansson <leifj@sunet.se>, saag@ietf.org
Subject: Vectors of Trust - Experimental or Standards Track

Adding saag so we can get this on the record per Kathleen’s suggestion.

Apologies I originally started this thread as communications with the authors.

Justin, I initiated this thread because of the classification of the Vectors of Trust document[0] as “experimental". As weird as you suggest the IETF is, RFC2026 defines “experimental” designation as:
4.2.1  Experimental


   The "Experimental" designation typically denotes a specification that
   is part of some research or development effort.  Such a specification
   is published for the general information of the Internet technical
   community and as an archival record of the work, subject only to
   editorial considerations and to verification that there has been
   adequate coordination with the standards process (see below).  An
   Experimental specification may be the output of an organized Internet
   research effort (e.g., a Research Group of the IRTF), an IETF Working
   Group, or it may be an individual contribution.

R&D is not the case with this draft given what is on track with NIST and OpenID Foundation.
  • The OpenID Foundation iGov Working Group and apparently NIST are *currently* referencing this as a mandatory requirement for operational use rather then use exclusively in research and development, the classification is inappropriate. Specifically the iGov draft refers to the VoT as an IETF “standard”. The OpenID iGov draft was just voted to “implementation” status which means people are now implementing for production and NOT R&D. Regardless of the differences in terms, iGov is intended to be a standard while VoT is currently not.[1]
  • I understand new SP-800-63 regulations are being developed that will use this “standard”.[2]

I am concerned that as “experimental", the VoT draft will not receive the proper scrutiny it needs to have. I am not sure why it is at the IETF since its domain of use is largely OpenID and SAML.

I will leave comments regarding “VoT” draft for the VoT list at a later time.


Thanks clearing this up.

Phil

Oracle Corporation, Identity Cloud Services Architect
@independentid
phil.hunt@oracle.com

On Sep 12, 2017, at 10:47 AM, Justin Richer <jricher@mit.edu> wrote:

Phil,

The draft started out in standards-track then moved to experimental during one of the revisions due to some feedback. Recent feedback has asked to put it back in standards-track, and I’d be fine with either to be honest. But in the end I don’t think that designation really matters, and you’re reading way more into it than is intended. I recall there was a similar discussion a couple years ago (that you, Phil, were a part of), where OAuth was called out as not being a “real standard” because the RFC states it’s a “proposed standard”. This, like now, I think is a misinterpretation of the meaning and intent of the document designations and is a distraction from what’s important. Yes, the IETF is weird in how it calls things — but we don’t get to pick their terms or redefine their meanings. 

I anticipated VoT going to RFC well over a year and a half ago — it’s been stable that long, and that’s why you don’t see much recent traffic on the vot@ietf mailing list — but as an AD-sponsored document it’s been slow finding shepherds and getting through the process without a WG chair pushing things. This doesn’t make it any less valid of a standard, but it does change the process that it goes through, somewhat. It will still get full IESG review. And, the important part, it’s still useful and usable. 

As far as I can see it, your main argument against using VoT is that it’s a draft standard — but so is iGov. And VoT can and will be moved forward in the IETF as an RFC standard. That process is happening now, John is the shepherd and has the power to move it forward.

So with this in mind, John’s discussion below is spot on. The way that VoT gets used is fairly simple:

The RP can request a “vtr", which basically says “this is the VoT that I’d like”. IdP can respond with “vot”, which is “here’s your vector values”, along with “vtm", which is “here’s where the contents of this vector are defined”. NIST, as mentioned and as I’d linked to you, is defining its own “vtm” document. This will define what “P1” means (surprise, it maps directly to IAL1), among everything else. The values in the VoT draft aren’t used in that case, since they exist under a “vtm” defined by the RFC, once that’s assigned and published, but you don’t have to use them. And iGov is not in the business of defining which “vtm” people should be using, but we want implementations to at least use the same mechanism — VoT — for conveying similar information. 

 — Justin




_______________________________________________
saag mailing list
saag@ietf.org
https://www.ietf.org/mailman/listinfo/saag


--------------1D1AE3A32C4ECA7E113A5E20-- From nobody Tue Sep 12 13:46:18 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8446E1330DE for ; Tue, 12 Sep 2017 13:46:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 bz8EVkH7f2iQ for ; Tue, 12 Sep 2017 13:46:13 -0700 (PDT) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (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 A4ADA13239C for ; Tue, 12 Sep 2017 13:46:12 -0700 (PDT) X-AuditID: 1209190c-4b3ff70000002caf-a7-59b847923ab4 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id 58.27.11439.29748B95; Tue, 12 Sep 2017 16:46:10 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id v8CKk9kc020307; Tue, 12 Sep 2017 16:46:09 -0400 Received: from [192.168.1.7] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v8CKk6kP016593 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 12 Sep 2017 16:46:07 -0400 From: Justin Richer Message-Id: <033F001D-DFE4-48F1-9FD1-5765DA406576@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_DF5DDF17-CD35-452B-BE3F-4CAC9A54EB8F" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 12 Sep 2017 16:46:05 -0400 In-Reply-To: Cc: John Bradley , Anthony Nadalin , Kathleen Moriarty , Leif Johansson , saag@ietf.org To: Phil Hunt References: X-Mailer: Apple Mail (2.3273) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrCKsWRmVeSWpSXmKPExsUixCmqrDvJfUekwZW5xhYNO/MtFvRuZbZY ML+R3WJKfyeTxaa52xgtVt/9y+bA5rFz1l12jyVLfjJ5tO74y+7x8ektFo+9m/rYPW7f3sgS wBbFZZOSmpNZllqkb5fAlbF7cRtbwbk1TBUPl21na2A81MjUxcjJISFgIvGhfxJ7FyMXh5DA YiaJKUdfMEE4Gxkl9vV/gspcY5L48OwzO0gLm4CqxPQ1LWDtvAJWEr2HfzOD2MwCSRLnt99m 62LkAIrrS/Q+ZwQJCwvYS+x8vowFJMwC1LpkAw9ImFPAXeLdya/MIOOZBY4yShzecJYNJCEi oCLx7ep1sF4hATeJW/2X2SEulZW4NfsS8wRG/llIts1C2AYR1pZYtvA1M4StKbG/ezkLpriG ROe3iawLGNlWMcqm5Fbp5iZm5hSnJusWJyfm5aUW6Rrq5WaW6KWmlG5iBEeKJM8OxjNvvA4x CnAwKvHwrrizPVKINbGsuDL3EKMkB5OSKG+24o5IIb6k/JTKjMTijPii0pzU4kOMEhzMSiK8 rS5AOd6UxMqq1KJ8mJQ0B4uSOK+ERmOEkEB6YklqdmpqQWoRTFaGg0NJgne+G1CjYFFqempF WmZOCUKaiYMTZDgP0HBlkBre4oLE3OLMdIj8KUZLjo6bd/8wcWwAk/tApBBLXn5eqpQ47ylX oAYBkIaM0jy4maDE577OzuIVozjQi8K86SBjeYBJE27qK6CFTEALeS5tAVlYkoiQkmpgdJ3X /2YTo1AH71vbn1Y67asfFk/XirgfcLJ8X42+0mTXNf9T1vQ+3mMtUXPVa+undMfOnccZO4V9 4meU8fSf+TfR835r9A0uvrj1MhNn3NtwKah+TzpTf8j+e1Xz5q3X2bf8/7L+9Te+yaxuZWRQ 7Q3Nz1IqOWi9KN1i570DNTkl2qzLJfcsVWIpzkg01GIuKk4EALjqKCRXAwAA Archived-At: Subject: Re: [saag] Vectors of Trust - Experimental or Standards Track X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Sep 2017 20:46:16 -0000 --Apple-Mail=_DF5DDF17-CD35-452B-BE3F-4CAC9A54EB8F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Actually, I=E2=80=99d had a few bits that were waiting in the update = queue already, so I went ahead and changed that flag and published a new = version just now: https://tools.ietf.org/html/draft-richer-vectors-of-trust-06 = =E2=80=94 Justin > On Sep 12, 2017, at 3:47 PM, Justin Richer wrote: >=20 > Right, and now that there are concrete implementations and references, = I'd agree that it's not as experimental anymore and we can switch it to = standards track. As I mentioned below, you're not the first to make this = suggestion. It's a tiny change and I can do that easily during the next = revision when we get shepherd or IESG comments that require changes.=20 >=20 > Thanks,=20 >=20 > --Justin >=20 > Sent from my phone > Right, and now that there are concrete implementations and references, = I'd agree that it's not as experimental anymore and we can switch it to = standards track. As I mentioned below, you're not the first to make this = suggestion. It's a tiny change and I can do that easily during the next = revision when we get shepherd or IESG comments that require changes.=20 > Thanks,=20 > --Justin > Sent from my phone > -------- Original message -------- > From: Phil Hunt > Date: 9/12/17 3:32 PM (GMT-05:00) > To: Justin Richer > Cc: John Bradley , Tony Nadalin = , Kathleen Moriarty = , Leif Johansson , = saag@ietf.org > Subject: Vectors of Trust - Experimental or Standards Track >=20 > Adding saag so we can get this on the record per Kathleen=E2=80=99s = suggestion. >=20 > Apologies I originally started this thread as communications with the = authors. >=20 > Justin, I initiated this thread because of the classification of the = Vectors of Trust document[0] as =E2=80=9Cexperimental". As weird as you = suggest the IETF is, RFC2026 defines =E2=80=9Cexperimental=E2=80=9D = designation as: >> 4.2.1 = Experimental >>=20 >> The "Experimental" designation typically denotes a specification = that >> is part of some research or development effort. Such a = specification >> is published for the general information of the Internet technical >> community and as an archival record of the work, subject only to >> editorial considerations and to verification that there has been >> adequate coordination with the standards process (see below). An >> Experimental specification may be the output of an organized = Internet >> research effort (e.g., a Research Group of the IRTF), an IETF = Working >> Group, or it may be an individual contribution. >=20 > R&D is not the case with this draft given what is on track with NIST = and OpenID Foundation. > The OpenID Foundation iGov Working Group and apparently NIST are = *currently* referencing this as a mandatory requirement for operational = use rather then use exclusively in research and development, the = classification is inappropriate. Specifically the iGov draft refers to = the VoT as an IETF =E2=80=9Cstandard=E2=80=9D. The OpenID iGov draft was = just voted to =E2=80=9Cimplementation=E2=80=9D status which means people = are now implementing for production and NOT R&D. Regardless of the = differences in terms, iGov is intended to be a standard while VoT is = currently not.[1] > I understand new SP-800-63 regulations are being developed that will = use this =E2=80=9Cstandard=E2=80=9D.[2] >=20 > I am concerned that as =E2=80=9Cexperimental", the VoT draft will not = receive the proper scrutiny it needs to have. I am not sure why it is at = the IETF since its domain of use is largely OpenID and SAML. >=20 > I will leave comments regarding =E2=80=9CVoT=E2=80=9D draft for the = VoT list at a later time. >=20 > [0] https://tools.ietf.org/html/draft-richer-vectors-of-trust-05 = > [1] = https://xml2rfc.tools.ietf.org/cgi-bin/xml2rfc.cgi?Submit=3DSubmit&format=3D= ascii&mode=3Dhtml&type=3Dascii&url=3Dhttps://bitbucket.org/openid/igov/raw= /master/openid-igov-profile.xml#rfc.section.3.4 = > [2] = https://github.com/usnistgov/800-63-3/blob/volume-d/sp800-63d/vot_mapping.= md = >=20 > Thanks clearing this up. >=20 > Phil >=20 > Oracle Corporation, Identity Cloud Services Architect > @independentid > www.independentid.com = phil.hunt@oracle.com = >> On Sep 12, 2017, at 10:47 AM, Justin Richer > wrote: >>=20 >> Phil, >>=20 >> The draft started out in standards-track then moved to experimental = during one of the revisions due to some feedback. Recent feedback has = asked to put it back in standards-track, and I=E2=80=99d be fine with = either to be honest. But in the end I don=E2=80=99t think that = designation really matters, and you=E2=80=99re reading way more into it = than is intended. I recall there was a similar discussion a couple years = ago (that you, Phil, were a part of), where OAuth was called out as not = being a =E2=80=9Creal standard=E2=80=9D because the RFC states it=E2=80=99= s a =E2=80=9Cproposed standard=E2=80=9D. This, like now, I think is a = misinterpretation of the meaning and intent of the document designations = and is a distraction from what=E2=80=99s important. Yes, the IETF is = weird in how it calls things =E2=80=94 but we don=E2=80=99t get to pick = their terms or redefine their meanings.=20 >>=20 >> I anticipated VoT going to RFC well over a year and a half ago =E2=80=94= it=E2=80=99s been stable that long, and that=E2=80=99s why you don=E2=80=99= t see much recent traffic on the vot@ietf mailing list =E2=80=94 but as = an AD-sponsored document it=E2=80=99s been slow finding shepherds and = getting through the process without a WG chair pushing things. This = doesn=E2=80=99t make it any less valid of a standard, but it does change = the process that it goes through, somewhat. It will still get full IESG = review. And, the important part, it=E2=80=99s still useful and usable.=20= >>=20 >> As far as I can see it, your main argument against using VoT is that = it=E2=80=99s a draft standard =E2=80=94 but so is iGov. And VoT can and = will be moved forward in the IETF as an RFC standard. That process is = happening now, John is the shepherd and has the power to move it = forward. >>=20 >> So with this in mind, John=E2=80=99s discussion below is spot on. The = way that VoT gets used is fairly simple: >>=20 >> The RP can request a =E2=80=9Cvtr", which basically says =E2=80=9Cthis = is the VoT that I=E2=80=99d like=E2=80=9D. IdP can respond with = =E2=80=9Cvot=E2=80=9D, which is =E2=80=9Chere=E2=80=99s your vector = values=E2=80=9D, along with =E2=80=9Cvtm", which is =E2=80=9Chere=E2=80=99= s where the contents of this vector are defined=E2=80=9D. NIST, as = mentioned and as I=E2=80=99d linked to you, is defining its own = =E2=80=9Cvtm=E2=80=9D document. This will define what =E2=80=9CP1=E2=80=9D= means (surprise, it maps directly to IAL1), among everything else. The = values in the VoT draft aren=E2=80=99t used in that case, since they = exist under a =E2=80=9Cvtm=E2=80=9D defined by the RFC, once that=E2=80=99= s assigned and published, but you don=E2=80=99t have to use them. And = iGov is not in the business of defining which =E2=80=9Cvtm=E2=80=9D = people should be using, but we want implementations to at least use the = same mechanism =E2=80=94 VoT =E2=80=94 for conveying similar = information.=20 >>=20 >> =E2=80=94 Justin >>=20 >=20 > -------- Original message --------From: Phil Hunt = Date: 9/12/17 3:32 PM (GMT-05:00) To: Justin = Richer Cc: John Bradley , Tony = Nadalin , Kathleen Moriarty = , Leif Johansson , = saag@ietf.org Subject: Vectors of Trust - Experimental or Standards = Track=20 > Adding saag so we can get this on the record per Kathleen=E2=80=99s = suggestion. > Apologies I originally started this thread as communications with the = authors. > Justin, I initiated this thread because of the classification of the = Vectors of Trust document[0] as =E2=80=9Cexperimental". As weird as you = suggest the IETF is, RFC2026 defines =E2=80=9Cexperimental=E2=80=9D = designation as:4.2.1 Experimental >=20 > The "Experimental" designation typically denotes a specification = that > is part of some research or development effort. Such a = specification > is published for the general information of the Internet technical > community and as an archival record of the work, subject only to > editorial considerations and to verification that there has been > adequate coordination with the standards process (see below). An > Experimental specification may be the output of an organized = Internet > research effort (e.g., a Research Group of the IRTF), an IETF = Working > Group, or it may be an individual contribution. > R&D is not the case with this draft given what is on track with NIST = and OpenID Foundation.The OpenID Foundation iGov Working Group and = apparently NIST are *currently* referencing this as a mandatory = requirement for operational use rather then use exclusively in research = and development, the classification is inappropriate. Specifically the = iGov draft refers to the VoT as an IETF =E2=80=9Cstandard=E2=80=9D. The = OpenID iGov draft was just voted to =E2=80=9Cimplementation=E2=80=9D = status which means people are now implementing for production and NOT = R&D. Regardless of the differences in terms, iGov is intended to be a = standard while VoT is currently not.[1]I understand new SP-800-63 = regulations are being developed that will use this =E2=80=9Cstandard=E2=80= =9D.[2] > I am concerned that as =E2=80=9Cexperimental", the VoT draft will not = receive the proper scrutiny it needs to have. I am not sure why it is at = the IETF since its domain of use is largely OpenID and SAML. > I will leave comments regarding =E2=80=9CVoT=E2=80=9D draft for the = VoT list at a later time. > [0] https://tools.ietf.org/html/draft-richer-vectors-of-trust-05[1] = https://xml2rfc.tools.ietf.org/cgi-bin/xml2rfc.cgi?Submit=3DSubmit&format=3D= ascii&mode=3Dhtml&type=3Dascii&url=3Dhttps://bitbucket.org/openid/igov/raw= /master/openid-igov-profile.xml#rfc.section.3.4[2] = https://github.com/usnistgov/800-63-3/blob/volume-d/sp800-63d/vot_mapping.= md > Thanks clearing this up. >=20 > Phil > Oracle Corporation, Identity Cloud Services = Architect@independentidwww.independentid.comphil.hunt@oracle.com >=20 >=20 > On Sep 12, 2017, at 10:47 AM, Justin Richer wrote: > Phil, > The draft started out in standards-track then moved to experimental = during one of the revisions due to some feedback. Recent feedback has = asked to put it back in standards-track, and I=E2=80=99d be fine with = either to be honest. But in the end I don=E2=80=99t think that = designation really matters, and you=E2=80=99re reading way more into it = than is intended. I recall there was a similar discussion a couple years = ago (that you, Phil, were a part of), where OAuth was called out as not = being a =E2=80=9Creal standard=E2=80=9D because the RFC states it=E2=80=99= s a =E2=80=9Cproposed standard=E2=80=9D. This, like now, I think is a = misinterpretation of the meaning and intent of the document designations = and is a distraction from what=E2=80=99s important. Yes, the IETF is = weird in how it calls things =E2=80=94 but we don=E2=80=99t get to pick = their terms or redefine their meanings.=20 > I anticipated VoT going to RFC well over a year and a half ago =E2=80=94= it=E2=80=99s been stable that long, and that=E2=80=99s why you don=E2=80=99= t see much recent traffic on the vot@ietf mailing list =E2=80=94 but as = an AD-sponsored document it=E2=80=99s been slow finding shepherds and = getting through the process without a WG chair pushing things. This = doesn=E2=80=99t make it any less valid of a standard, but it does change = the process that it goes through, somewhat. It will still get full IESG = review. And, the important part, it=E2=80=99s still useful and usable.=20= > As far as I can see it, your main argument against using VoT is that = it=E2=80=99s a draft standard =E2=80=94 but so is iGov. And VoT can and = will be moved forward in the IETF as an RFC standard. That process is = happening now, John is the shepherd and has the power to move it = forward. > So with this in mind, John=E2=80=99s discussion below is spot on. The = way that VoT gets used is fairly simple: > The RP can request a =E2=80=9Cvtr", which basically says =E2=80=9Cthis = is the VoT that I=E2=80=99d like=E2=80=9D. IdP can respond with = =E2=80=9Cvot=E2=80=9D, which is =E2=80=9Chere=E2=80=99s your vector = values=E2=80=9D, along with =E2=80=9Cvtm", which is =E2=80=9Chere=E2=80=99= s where the contents of this vector are defined=E2=80=9D. NIST, as = mentioned and as I=E2=80=99d linked to you, is defining its own = =E2=80=9Cvtm=E2=80=9D document. This will define what =E2=80=9CP1=E2=80=9D= means (surprise, it maps directly to IAL1), among everything else. The = values in the VoT draft aren=E2=80=99t used in that case, since they = exist under a =E2=80=9Cvtm=E2=80=9D defined by the RFC, once that=E2=80=99= s assigned and published, but you don=E2=80=99t have to use them. And = iGov is not in the business of defining which =E2=80=9Cvtm=E2=80=9D = people should be using, but we want implementations to at least use the = same mechanism =E2=80=94 VoT =E2=80=94 for conveying similar = information.=20 > =E2=80=94 Justin >=20 --Apple-Mail=_DF5DDF17-CD35-452B-BE3F-4CAC9A54EB8F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Actually, I=E2=80=99d had a few bits that were waiting in the = update queue already, so I went ahead and changed that flag and = published a new version just now:

https://tools.ietf.org/html/draft-richer-vectors-of-trust-06

 =E2=80=94= Justin

On Sep 12, 2017, at 3:47 PM, Justin Richer = <jricher@MIT.EDU> = wrote:

Right, and now that there are = concrete implementations and references, I'd agree that it's not as = experimental anymore and we can switch it to standards track. As I = mentioned below, you're not the first to make this suggestion. It's a = tiny change and I can do that easily during the next revision when we = get shepherd or IESG comments that require changes. 

Thanks, 

--Justin

 Sent from my = phone
Right, and now that there are concrete = implementations and references, I'd agree that it's not as experimental = anymore and we can switch it to standards track. As I mentioned below, = you're not the first to make this suggestion. It's a tiny change and I = can do that easily during the next revision when we get shepherd or IESG = comments that require changes. 
Thanks, 
--Justin
 Sent from my phone
-------- Original message = --------
From: Phil Hunt <phil.hunt@oracle.com>
Date: = 9/12/17 3:32 PM (GMT-05:00)
To: Justin Richer = <jricher@mit.edu> =
Cc: John Bradley <ve7jtb@ve7jtb.com>, = Tony Nadalin <tonynad@microsoft.com>, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>, Leif Johansson = <leifj@sunet.se>, = saag@ietf.org
Subject: Vectors of Trust - Experimental or Standards Track =

Adding saag so we can = get this on the record per Kathleen=E2=80=99s suggestion.

Apologies I originally = started this thread as communications with the authors.

Justin, I initiated this = thread because of the classification of the Vectors of Trust document[0] = as =E2=80=9Cexperimental". As weird as you suggest the IETF is, RFC2026 = defines =E2=80=9Cexperimental=E2=80=9D designation as:
4.2.1  Experimental


   The "Experimental" designation typically denotes a specification that
   is part of some research or development effort.  Such a specification
   is published for the general information of the Internet technical
   community and as an archival record of the work, subject only to
   editorial considerations and to verification that there has been
   adequate coordination with the standards process (see below).  An
   Experimental specification may be the output of an organized Internet
   research effort (e.g., a Research Group of the IRTF), an IETF Working
   Group, or it may be an individual =
contribution.

R&D is not the case with this draft given what is on = track with NIST and OpenID Foundation.
  • The OpenID Foundation iGov Working Group and = apparently NIST are *currently* referencing this as a mandatory = requirement for operational use rather then use exclusively in research = and development, the classification is inappropriate. Specifically the = iGov draft refers to the VoT as an IETF =E2=80=9Cstandard=E2=80=9D. The = OpenID iGov draft was just voted to =E2=80=9Cimplementation=E2=80=9D = status which means people are now implementing for production and NOT = R&D. Regardless of the differences in terms, iGov is intended to be = a standard while VoT is currently not.[1]
  • I = understand new SP-800-63 regulations are being developed that will use = this =E2=80=9Cstandard=E2=80=9D.[2]

I am concerned that as = =E2=80=9Cexperimental", the VoT draft will not receive the proper = scrutiny it needs to have. I am not sure why it is at the IETF since its = domain of use is largely OpenID and SAML.

I will leave comments regarding = =E2=80=9CVoT=E2=80=9D draft for the VoT list at a later time.

[0] https://tools.ietf.org/html/draft-richer-vectors-of-trust-05
[1] https://xml2rfc.tools.ietf.org/cgi-bin/xml2rfc.cgi?Submit=3DSub= mit&format=3Dascii&mode=3Dhtml&type=3Dascii&url=3Dhttps://= bitbucket.org/openid/igov/raw/master/openid-igov-profile.xml#rfc.section.3= .4
[2] https://github.com/usnistgov/800-63-3/blob/volume-d/sp800-63d/v= ot_mapping.md

Thanks clearing this up.

Phil

Oracle Corporation, Identity Cloud = Services Architect
@independentid
www.independentid.com
phil.hunt@oracle.com

On Sep 12, 2017, at 10:47 AM, Justin Richer <jricher@mit.edu> = wrote:

Phil,

The draft started out in = standards-track then moved to experimental during one of the revisions = due to some feedback. Recent feedback has asked to put it back in = standards-track, and I=E2=80=99d be fine with either to be honest. But = in the end I don=E2=80=99t think that designation really matters, and = you=E2=80=99re reading way more into it than is intended. I recall there = was a similar discussion a couple years ago (that you, Phil, were a part = of), where OAuth was called out as not being a =E2=80=9Creal standard=E2=80= =9D because the RFC states it=E2=80=99s a =E2=80=9Cproposed standard=E2=80= =9D. This, like now, I think is a misinterpretation of the meaning and = intent of the document designations and is a distraction from what=E2=80=99= s important. Yes, the IETF is weird in how it calls things =E2=80=94 but = we don=E2=80=99t get to pick their terms or redefine their = meanings. 

I = anticipated VoT going to RFC well over a year and a half ago =E2=80=94 = it=E2=80=99s been stable that long, and that=E2=80=99s why you don=E2=80=99= t see much recent traffic on the vot@ietf mailing list =E2=80=94 but as = an AD-sponsored document it=E2=80=99s been slow finding shepherds and = getting through the process without a WG chair pushing things. This = doesn=E2=80=99t make it any less valid of a standard, but it does change = the process that it goes through, somewhat. It will still get full IESG = review. And, the important part, it=E2=80=99s still useful and = usable. 

As far = as I can see it, your main argument against using VoT is that it=E2=80=99s= a draft standard =E2=80=94 but so is iGov. And VoT can and will be = moved forward in the IETF as an RFC standard. That process is happening = now, John is the shepherd and has the power to move it = forward.

So = with this in mind, John=E2=80=99s discussion below is spot on. The way = that VoT gets used is fairly simple:

The RP can request a =E2=80=9Cvtr", = which basically says =E2=80=9Cthis is the VoT that I=E2=80=99d like=E2=80=9D= . IdP can respond with =E2=80=9Cvot=E2=80=9D, which is =E2=80=9Chere=E2=80= =99s your vector values=E2=80=9D, along with =E2=80=9Cvtm", which is = =E2=80=9Chere=E2=80=99s where the contents of this vector are = defined=E2=80=9D. NIST, as mentioned and as I=E2=80=99d linked to you, = is defining its own =E2=80=9Cvtm=E2=80=9D document. This will define = what =E2=80=9CP1=E2=80=9D means (surprise, it maps directly to IAL1), = among everything else. The values in the VoT draft aren=E2=80=99t used = in that case, since they exist under a =E2=80=9Cvtm=E2=80=9D defined by = the RFC, once that=E2=80=99s assigned and published, but you don=E2=80=99t= have to use them. And iGov is not in the business of defining which = =E2=80=9Cvtm=E2=80=9D people should be using, but we want = implementations to at least use the same mechanism =E2=80=94 VoT =E2=80=94= for conveying similar information. 

 =E2=80=94 Justin


-------- Original message --------From: Phil Hunt = <phil.hunt@oracle.com> Date: 9/12/17  3:32 PM =  (GMT-05:00) To: Justin Richer <jricher@mit.edu> Cc: John Bradley <ve7jtb@ve7jtb.com>, = Tony Nadalin <tonynad@microsoft.com>, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>, Leif Johansson = <leifj@sunet.se>, = saag@ietf.org Subject: = Vectors of Trust - Experimental or Standards Track
Adding = saag so we can get this on the record per Kathleen=E2=80=99s = suggestion.
Apologies I originally started this thread as = communications with the authors.
Justin, I initiated this = thread because of the classification of the Vectors of Trust document[0] = as =E2=80=9Cexperimental". As weird as you suggest the IETF is, RFC2026 = defines =E2=80=9Cexperimental=E2=80=9D designation as:4.2.1 =  Experimental

  The = "Experimental" designation typically denotes a specification that
  is part of some research or development effort. =  Such a specification
  is published for = the general information of the Internet technical
=   community and as an archival record of the work, subject = only to
  editorial considerations and to = verification that there has been
  adequate = coordination with the standards process (see below).  An
  Experimental specification may be the output of = an organized Internet
  research effort (e.g., = a Research Group of the IRTF), an IETF Working
=   Group, or it may be an individual contribution.
R&D is not the case with this draft given what is on = track with NIST and OpenID Foundation.The OpenID Foundation iGov Working = Group and apparently NIST are *currently* referencing this as a = mandatory requirement for operational use rather then use exclusively in = research and development, the classification is inappropriate. = Specifically the iGov draft refers to the VoT as an IETF =E2=80=9Cstandard= =E2=80=9D. The OpenID iGov draft was just voted to =E2=80=9Cimplementation= =E2=80=9D status which means people are now implementing for production = and NOT R&D. Regardless of the differences in terms, iGov is = intended to be a standard while VoT is currently not.[1]I understand new = SP-800-63 regulations are being developed that will use this = =E2=80=9Cstandard=E2=80=9D.[2]
I am concerned that as = =E2=80=9Cexperimental", the VoT draft will not receive the proper = scrutiny it needs to have. I am not sure why it is at the IETF since its = domain of use is largely OpenID and SAML.
I will leave = comments regarding =E2=80=9CVoT=E2=80=9D draft for the VoT list at a = later time.
[0] https://tools.ietf.org/html/draft-richer-vectors-of-trust-05[1<= /a>] https://xml2rfc.tools.ietf.org/cgi-bin/xml2rfc.cgi?Submit=3DSub= mit&format=3Dascii&mode=3Dhtml&type=3Dascii&url=3Dhttps://= bitbucket.org/openid/igov/raw/master/openid-igov-profile.xml#rfc.section.3= .4[2] https://github.com/usnistgov/800-63-3/blob/volume-d/sp800-63d/v= ot_mapping.md
Thanks clearing this up.
Phil
Oracle Corporation, Identity Cloud = Services Architect@independentidwww.independentid.comphil.hunt@oracl= e.com


On Sep 12, 2017, at = 10:47 AM, Justin Richer <jricher@mit.edu> wrote:
Phil,
The draft started out in standards-track then moved to = experimental during one of the revisions due to some feedback. Recent = feedback has asked to put it back in standards-track, and I=E2=80=99d be = fine with either to be honest. But in the end I don=E2=80=99t think that = designation really matters, and you=E2=80=99re reading way more into it = than is intended. I recall there was a similar discussion a couple years = ago (that you, Phil, were a part of), where OAuth was called out as not = being a =E2=80=9Creal standard=E2=80=9D because the RFC states it=E2=80=99= s a =E2=80=9Cproposed standard=E2=80=9D. This, like now, I think is a = misinterpretation of the meaning and intent of the document designations = and is a distraction from what=E2=80=99s important. Yes, the IETF is = weird in how it calls things =E2=80=94 but we don=E2=80=99t get to pick = their terms or redefine their meanings. 
I = anticipated VoT going to RFC well over a year and a half ago =E2=80=94 = it=E2=80=99s been stable that long, and that=E2=80=99s why you don=E2=80=99= t see much recent traffic on the vot@ietf mailing list =E2=80=94 but as = an AD-sponsored document it=E2=80=99s been slow finding shepherds and = getting through the process without a WG chair pushing things. This = doesn=E2=80=99t make it any less valid of a standard, but it does change = the process that it goes through, somewhat. It will still get full IESG = review. And, the important part, it=E2=80=99s still useful and = usable. 
As far as I can see it, your main argument = against using VoT is that it=E2=80=99s a draft standard =E2=80=94 but so = is iGov. And VoT can and will be moved forward in the IETF as an RFC = standard. That process is happening now, John is the shepherd and has = the power to move it forward.
So with this in mind, = John=E2=80=99s discussion below is spot on. The way that VoT gets used = is fairly simple:
The RP can request a =E2=80=9Cvtr", = which basically says =E2=80=9Cthis is the VoT that I=E2=80=99d like=E2=80=9D= . IdP can respond with =E2=80=9Cvot=E2=80=9D, which is =E2=80=9Chere=E2=80= =99s your vector values=E2=80=9D, along with =E2=80=9Cvtm", which is = =E2=80=9Chere=E2=80=99s where the contents of this vector are = defined=E2=80=9D. NIST, as mentioned and as I=E2=80=99d linked to you, = is defining its own =E2=80=9Cvtm=E2=80=9D document. This will define = what =E2=80=9CP1=E2=80=9D means (surprise, it maps directly to IAL1), = among everything else. The values in the VoT draft aren=E2=80=99t used = in that case, since they exist under a =E2=80=9Cvtm=E2=80=9D defined by = the RFC, once that=E2=80=99s assigned and published, but you don=E2=80=99t= have to use them. And iGov is not in the business of defining which = =E2=80=9Cvtm=E2=80=9D people should be using, but we want = implementations to at least use the same mechanism =E2=80=94 VoT =E2=80=94= for conveying similar information. 
 =E2=80=94 = Justin


= --Apple-Mail=_DF5DDF17-CD35-452B-BE3F-4CAC9A54EB8F-- From nobody Tue Sep 12 23:40:06 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D419F133077; Tue, 12 Sep 2017 23:40:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 hBDY8916-zKd; Tue, 12 Sep 2017 23:40:03 -0700 (PDT) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (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 CF5A11321A2; Tue, 12 Sep 2017 23:40:02 -0700 (PDT) Received: by mail-qk0-x234.google.com with SMTP id j5so436746qkd.0; Tue, 12 Sep 2017 23:40:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=vmuhzgs6kGH2SyWUAWp1fH4uDVExcR8PV10GSAitkBA=; b=hEcNF2ljPvaE2LH0bR0nHVDYgdAJdkAwrg9xELatxGhio/tPuu9TpKDpxNxAFHgiOs u1Bcbf7ML4Pkee0RyFoLTFWKXBnbEQXNHPr2CQjar015WYyrA0FWadGQGnJbd26VGOa6 8lQtnidV6oDSG+wzM6730PHSfbvQBCod+nhNg0LEz57S/5wcJ/32gPM/b4BAzVLcsj49 cKvQGxLrS/hQA3Ge+p5pLTHgqBOeFrwGpWi6ohEqmm/RRwXdTsXy4l99HEx1kj+nmBzp BNpfvxP+YRRQCF9ugP77E/+OJYE0i8iBDGDcEeSyz7mxSu3dTRs0acDyVI0BxRBtRbEk Zp8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=vmuhzgs6kGH2SyWUAWp1fH4uDVExcR8PV10GSAitkBA=; b=IS698P0Zuq43foVotrbueWfFTlNv3FYTsVBF42ZN4m7CkTQccQdpIA5k/PiQWeoz6b ho6ddjcOkKHmwdKm+RIsxR9d1MM9gKoXnYH4sZD14L+rdq2MW6WS7gNpz+XKCidW6fmI 9Aj0XyYYUa9S6yM3vX+tDlc0hj6ZAqP6Pzj/tRjW1LvSDSOzBL7lIGJH7LL+iFEVU3sj Zxy05XPuH+48AOO+Yl7QEI0vDP6a2OfCq/uqgLrupZ2XH7AHc4pTNlT3AVf6NtslfwbR u9Z9n+tgq5jnE2efOzC6rIF80yoQmqMpTGAiPMFfB3UXrJynO5F3/Qugnw9I66IKQ24U qoiQ== X-Gm-Message-State: AHPjjUjj0iYljAohQAVnBOGTTDDO1z51plr1W8DJOcs2J5gr1qg3tEAJ sQyfd0DF2zedc0jKKthC0Vy8ueI4dGzNSzi6Kx68tDFH X-Google-Smtp-Source: AOwi7QCbGWPjaFGNCtozIjRcuIi3D3N/nMHO0wWFI+mTbm8bjx5zZJl0FWaWOMjWhgAXuEjReYYx6bF4nWm+Gsrrz+Y= X-Received: by 10.55.181.129 with SMTP id e123mr24767138qkf.128.1505284801569; Tue, 12 Sep 2017 23:40:01 -0700 (PDT) MIME-Version: 1.0 Sender: n.mavrogiannopoulos@gmail.com Received: by 10.12.175.136 with HTTP; Tue, 12 Sep 2017 23:39:21 -0700 (PDT) In-Reply-To: References: <150522092693.4724.2532571098567577114.idtracker@ietfa.amsl.com> From: Nikos Mavrogiannopoulos Date: Wed, 13 Sep 2017 08:39:21 +0200 X-Google-Sender-Auth: zTfCaHN7zsUhKnKDKgjEoQ4OiQE Message-ID: To: Dmitry Belyavsky Cc: "saag@ietf.org" , LAMPS , dev-security-policy@lists.mozilla.org, pkix@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [saag] Fwd: New Version Notification for draft-belyavskiy-certificate-limitation-policy-04.txt X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Sep 2017 06:40:05 -0000 On Tue, Sep 12, 2017 at 2:59 PM, Dmitry Belyavsky wrote: > Hello, > > Here is the new version of the draft updated according to the discussion on > mozilla-dev-security list. Hi, It seems that most of the details of the underlying format are missing. As far as I understand it is mostly an intentions document at this point right? I have few comments: 1. requiredX509extensions: What's the reasoning behind this? If these extensions are required and not present why keep the root certificate in the trust store? 2. What is the difference between issuedNotAfter and trustNotAfter? The description text is unclear to me. 3. applicationNameConstraints: very useful, however it is unclear from the ASN.1 description how are these stored. 4. How do you handle extensions to this format? Overall, why not use X.509 extensions to store such additional constraints? We already (in the p11-kit trust store in Fedora/RHEL systems) use the notion of stapled extensions to limit certificates [0, 1] and seems quite a flexible approach. Have you considered that path? regards, Nikos [0]. https://p11-glue.freedesktop.org/doc/storing-trust-policy/storing-trust-model.html [1]. http://nmav.gnutls.org/2016/06/restricting-scope-of-ca-certificates.html From nobody Wed Sep 13 04:22:33 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C22B120720; Wed, 13 Sep 2017 04:22:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 yYZMWCV4kSiC; Wed, 13 Sep 2017 04:22:19 -0700 (PDT) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (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 D8DC2133341; Wed, 13 Sep 2017 04:22:18 -0700 (PDT) Received: by mail-wm0-x233.google.com with SMTP id a137so7247058wma.0; Wed, 13 Sep 2017 04:22:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=bfjVObCiCgnNgXq38MobIKw1e0SFCac2liIqS1vO1EQ=; b=qPn40AcB0ypgZ6N15g2mIs38pQ5qUBsq1Ti3tsyKsIKMUtCYkDWdNyYH0GIr2dsZMV UqWBS96T5U7X8X84Wlk9DLDJhO8cd1sQG6Q+OIcvtoNRJjSVNCc+3mi9xp8sYG0Aw3SM EQGta+wIyrVLnsdVY8zk96QDxOAuOcxht/gTfmB+bfFLyAYSwbJ7gG7mBnHB0YkCciIT dZGIuG7VBBeoTxw3XJtjeSFg5dH0GwgtS7NlecdORF2WH87cwuR8WALjdh6Mm9g2bNbX vTDHqwBWUn2sguXy8mLRjOAFcPMTRL7v4jjTUerTzQ9xuk/VGyX6GJ86tNlzU2P1xk/V pVEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=bfjVObCiCgnNgXq38MobIKw1e0SFCac2liIqS1vO1EQ=; b=amexFCdou+dc4Dyj3JJZo8dIkxgqPmxKIjpMJKmUKz+b1An4x4/BbCo/7TkWOsO39k W6c1VYifXs+z2HGGwQSOAUeNMmDof7Jtn1IXisQoY+1KyYXlm58sxrB/VE4PwyR4frUW NeXoO/F9drcd1o1SkUe2vaRxqZyF9rx3fk9Ol4/XE21w4Bw1rJSfPc34ZaEMabxsP8pg oRyCXFERniqPLQoIlwO9drYUo+bbOA4HkNy3XQ8HiNyhh8Xi3m5hDgYzIURmAYzzLY2b HszJAJZkW0zGHl7Sz6Db5oXXNHIG/m7IfgR5tr+ndGZaN7Xio0tw8jPirokwEsTypcQ+ Rr9w== X-Gm-Message-State: AHPjjUh3srZQkaxoZoTT1Y+MW+w+qEtbUUBfrz2tIrFyaUqGZzCoU1ko wrMc4yPE5yl8CgBhvePVvPoGoL8ypvqheJq5+Eg= X-Google-Smtp-Source: ADKCNb4+k0R1/F7EKBZjgrBrrqWMxalFHtiaNjd5UoRLLZhdy3TYv7IECGLZZVC3/c1NwdoOek9pZ6RuyMFvb7B/fec= X-Received: by 10.80.153.98 with SMTP id l31mr13607104edb.69.1505301737412; Wed, 13 Sep 2017 04:22:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.186.44 with HTTP; Wed, 13 Sep 2017 04:22:16 -0700 (PDT) In-Reply-To: References: <150522092693.4724.2532571098567577114.idtracker@ietfa.amsl.com> From: Dmitry Belyavsky Date: Wed, 13 Sep 2017 14:22:16 +0300 Message-ID: To: Nikos Mavrogiannopoulos Cc: "saag@ietf.org" , LAMPS , dev-security-policy@lists.mozilla.org, pkix@ietf.org Content-Type: multipart/alternative; boundary="94eb2c0de59c569dc00559105f15" Archived-At: Subject: Re: [saag] Fwd: New Version Notification for draft-belyavskiy-certificate-limitation-policy-04.txt X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Sep 2017 11:22:26 -0000 --94eb2c0de59c569dc00559105f15 Content-Type: text/plain; charset="UTF-8" Dear Nikos, On Wed, Sep 13, 2017 at 9:39 AM, Nikos Mavrogiannopoulos wrote: > On Tue, Sep 12, 2017 at 2:59 PM, Dmitry Belyavsky > wrote: > > Hello, > > > > Here is the new version of the draft updated according to the discussion > on > > mozilla-dev-security list. > > Hi, > It seems that most of the details of the underlying format are > missing. As far as I understand it is mostly an intentions document at > this point right? I have few comments: > The format will be CRL-like. > > 1. requiredX509extensions: What's the reasoning behind this? If these > extensions are required and not present why keep the root certificate > in the trust store? > The main intended case is "require Certificate Transparency". Currently using the CT is not mandatory for all CAs. > > 2. What is the difference between issuedNotAfter and trustNotAfter? > The description text is unclear to me. > issuedNotAfter - we do not trust to the certificates issued after the date. trustNotAfter - we do not trust certificates after the date XXX, if they have notAfter > XXX > > 3. applicationNameConstraints: very useful, however it is unclear from > the ASN.1 description how are these stored. > I'm not so familiar with ASN1 format. I think that syntax from RFC5280 will fit here. > > 4. How do you handle extensions to this format? > > Simillary to CRL. Do you have ideas of the extensions? > Overall, why not use X.509 extensions to store such additional > constraints? We already (in the p11-kit trust store in Fedora/RHEL > systems) use the notion of stapled extensions to limit certificates > [0, 1] and seems quite a flexible approach. Have you considered that > path? > > regards, > Nikos > > [0]. https://p11-glue.freedesktop.org/doc/storing-trust-policy/ > storing-trust-model.html > [1]. http://nmav.gnutls.org/2016/06/restricting-scope-of-ca- > certificates.html > Thank you very much, I'll look at it. -- SY, Dmitry Belyavsky --94eb2c0de59c569dc00559105f15 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear Nikos,

On Wed, Sep 13, 2017 at 9:39 AM, Nikos Mavrogiannopoulos <nmav@gn= utls.org> wrote:
On Tue, Sep 12, 2017 at 2:59 PM, Dmitry Belyavsky <beldmit@gmail.com> wrote:
> Hello,
>
> Here is the new version of the draft updated according to the discussi= on on
> mozilla-dev-security list.

Hi,
=C2=A0It seems that most of the details of the underlying format are
missing. As far as I understand it is mostly an intentions document at
this point right? I have few comments:

= The format will be CRL-like. =C2=A0

1. requiredX509extensions: What's the reasoning behind this? If these extensions are required and not present why keep the root certificate
in the trust store?

The main intended c= ase is "require Certificate Transparency".=C2=A0
Curren= tly using the CT is not mandatory for all CAs.
=C2=A0

2. What is the difference between issuedNotAfter and trustNotAfter?
The description text is unclear to me.

= issuedNotAfter - we do not trust to the certificates issued after the date.=
trustNotAfter - we do not trust certificates after the date XXX,= if they have notAfter > XXX
=C2=A0

3. applicationNameConstraints: very useful, however it is unclear from
the ASN.1 description how are these stored.

=
I'm not so familiar with ASN1 format. I think that syntax from RFC= 5280 will fit here.=C2=A0

4. How do you handle extensions to this format?

Simillary to CRL. Do you have ideas of the extensions= ?
=C2=A0
Overall, why not use X.509 extensions to store such additional
constraints? We already (in the p11-kit trust store in Fedora/RHEL
systems) use the notion of stapled extensions to limit certificates
[0, 1] and seems quite a flexible approach. Have you considered that
path?

regards,
Nikos

[0]. https://p11-g= lue.freedesktop.org/doc/storing-trust-policy/storing-trust-model.= html
[1]. http://nmav.gnutls.org/= 2016/06/restricting-scope-of-ca-certificates.html

Thank you very much, I'll look at it.=C2=A0

--
SY, Dmitry Belyavsky
--94eb2c0de59c569dc00559105f15-- From nobody Thu Sep 14 07:34:52 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CBE013303B for ; Thu, 14 Sep 2017 07:34:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no 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 pJaRk8xOGRIF for ; Thu, 14 Sep 2017 07:34:48 -0700 (PDT) Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) (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 BEFBA13302B for ; Thu, 14 Sep 2017 07:34:48 -0700 (PDT) Received: from virulha.pair.com (localhost [127.0.0.1]) by virulha.pair.com (Postfix) with ESMTP id 4DBC96D537; Thu, 14 Sep 2017 10:34:47 -0400 (EDT) Received: from plata.local (iang.org [209.197.106.187]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by virulha.pair.com (Postfix) with ESMTPSA id B5D126D531; Thu, 14 Sep 2017 10:34:46 -0400 (EDT) To: saag@ietf.org, phill@hallambaker.com References: From: iang Message-ID: <6ac8feb7-a648-485f-b6d8-3bd97e8f48c5@iang.org> Date: Thu, 14 Sep 2017 16:34:44 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [saag] Blockchained log format X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Sep 2017 14:34:50 -0000 On 11/09/2017 15:01, Phillip Hallam-Baker wrote: > Ideas? Comments? First comment - I (also would) do it in binary.  I used to use text formats because I could read and confirm the code, but in the end, it was easier to be confident of a binary I/O code than text code. And when I added encryption, it made the text a bit useless. Second comment - for better generality, make it two files not one, one being indexes and one being the frames in full.  Each index locates its frame in the frame file by start / length or end. This way, you can read the entire index file into memory qiuckly, and then only pull in the frames on demand. I must admit - I never thought about doing the reverse reading. Probably because I've always read the whole (index) thing into memory for any and all processing. iang ps; in my work, both files have the same header, more or less, and the header has the encryption keys in it.  A stream cipher is needed, as we're picking up at any point in the frame, I use Chacha and poly. From nobody Thu Sep 14 08:26:13 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4592C13239C for ; Thu, 14 Sep 2017 08:26:12 -0700 (PDT) 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, FREEMAIL_FROM=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 mXa8UD-ovZRz for ; Thu, 14 Sep 2017 08:26:11 -0700 (PDT) Received: from mail-pf0-x22c.google.com (mail-pf0-x22c.google.com [IPv6:2607:f8b0:400e:c00::22c]) (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 143E11321CB for ; Thu, 14 Sep 2017 08:26:11 -0700 (PDT) Received: by mail-pf0-x22c.google.com with SMTP id r71so454955pfe.12 for ; Thu, 14 Sep 2017 08:26:11 -0700 (PDT) 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=1vdB7M1ncgZrPLLrQKTKMr+6yvV73NFZtOacLQfLRDM=; b=dvhLdNMcu8PwIMvC5rmoNOZskwK/uykxaSm/bHvC/P62HZv6QbkTbgNjn0q+cwSBio ywS3BtytUcpskFMSWAfwLscxYXeMjoPg7AGARx8TDZOsqfieAIml8kYB8XujrORrZ01O mal74xDCG/R1NFXrvx2cs1Dr7+Y10cwcx3cw3SgZtmZqRMLfIwDwyQ2XFkk4NkkJ9VWq Oil8TDApwZgP03IWww22TiU3G/3/Ivk4zWm+KOBGm8Q4saUWpPJTL3McAtB1B/LoNR4J zA1SXJ+N3gGNfjNXmIOq1y2i1Z9zwICr+9D2udyYKLRXi1XXgoqJqjpRSG8m4z+Gj7ON 9VZA== 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=1vdB7M1ncgZrPLLrQKTKMr+6yvV73NFZtOacLQfLRDM=; b=EwBAU5/N7z1ziL5nOPGS+xuFiFVgO2tpLm0xmBef1wrzAVqRzoXiwxHYLf8HK8Nmgl KWMAYCi8NQ8qX0xjPvamsiWaHtYL7Wcd6+buLBmsI9MvC3fMuJ4DfZkF+fce2CZC3OBH CI75wuGbcW/vABkzlIGeBZbNHmFD0D7s+mk2YVOrYtE9CYNoK+xji2POk/j+fVDSG6c1 7hDw4e7h/a/vMcFztAi5/Ktd1ft4Op20FiwbWitFTBab3wqzVQIZewC9rJ0kXiGunO0r DECQv7xw8LkTsnD3hDjG+FbMToOtK5TUt8rNLRDLjgzCquQmWYarIT4x0D4iwg9tgiSM AOHA== X-Gm-Message-State: AHPjjUjthURqTRJBdzYwAxGfOvQPC38zGJBRVJ4iZ8ZBFS/dn10xkz+W 0Yiz8glKUdxUvckTQD+yRRBi36dhNrMpXt48iaE= X-Google-Smtp-Source: ADKCNb6WkDkX56mtGcFRVBGQpiueQQaW2rSra/RIUZIwITXXjIisDBIHKTLa/bKG7G3+t9Btof36WdeyMlmuanDltC4= X-Received: by 10.84.131.103 with SMTP id 94mr17682701pld.302.1505402770540; Thu, 14 Sep 2017 08:26:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.144.1 with HTTP; Thu, 14 Sep 2017 08:25:29 -0700 (PDT) From: Kathleen Moriarty Date: Thu, 14 Sep 2017 11:25:29 -0400 Message-ID: To: "saag@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [saag] BoF Requests X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Sep 2017 15:26:12 -0000 Hello, If you are planning on a BoF for Singapore, please reach out to EKR and I to discuss and get in your BoF request for review. The deadline is Sept 29, 2017, but it's best to do this as soon as possible so we can help you get ready. Thank you. -- Best regards, Kathleen From nobody Wed Sep 20 06:22:04 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BC76133205; Wed, 20 Sep 2017 06:22:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 iCtZtxPKn-RN; Wed, 20 Sep 2017 06:21:58 -0700 (PDT) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (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 685EC134212; Wed, 20 Sep 2017 06:21:58 -0700 (PDT) Received: by mail-wm0-x235.google.com with SMTP id r68so7151958wmg.3; Wed, 20 Sep 2017 06:21:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/ntSqCCIbi5IkG8kBgc+o6EXHSWRyN429laHemOqxSM=; b=ogf2l0hNQ6+ZSAgnET/FT8vO/ho9jE4+WC58zPIeyD3qmEuNPs6loLXAXeTq+bMzzT 3MWs5kwuzdSrILEyhXCqq1nnlZUiZW61ZHPHEQSWUGlWoUvxva0K0mRnZ5S6cdb1d16V abZs4i1oreUR0g429UvDjsXbOK58oj8SWymSMhRmJ5zIO4jjURz78fPBGYbHaoB7e2l/ cYxpjH6NZZE6f/pl9CwS1+BZ6AIV1do3x5ntPxvTlkEdflowCbc8Gv/UNlVVXm2X31rA QA7xLQ6n+lBuk6BksfdkAx0oEz/Ef2nPQKpA83BgQabdpIOOSl86glZD64Tg46qlImRH 1KIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=/ntSqCCIbi5IkG8kBgc+o6EXHSWRyN429laHemOqxSM=; b=Jbex6MMKE9i32dl5am6KAulA/iCUx2RvzeqL0FtuS7d2u4eabRpHvt3ngq2UG1FlCC ZPPvEjBoJSRmdrQgwc0jgHGzxOJm1FFQdlnNQn8MR3gtQSDgjP1vrtG16xeUQxXIocgQ dMbFbepF2P/93Au9aCwX0jimG71hurajBwalHPRUe9D2rdljb+qL3Ik0lbz3BdGcL2Xd vtO+jyBc70CEUZCxPWD7pVzFTf66wMvv8GhaGRhmqINj5aeVpzIJeetLpUHTiTLfwp8Q Ma817piy7ojkdLPp4vhOSV/lWsS6icw/4U7vtX4evSHUnMO+S5SSEC55qGItlYzwDx2i 7Mcw== X-Gm-Message-State: AHPjjUiWGXJ/Sx0WIMHUk+XphIopqfL2kQZKNLftjz9CEiXOkB6JF+H3 eVMSkVVxcFUScLQNOlZbL8FUclGMNyE4FqC5uY8= X-Google-Smtp-Source: AOwi7QBotSqgFsU8jOJorTakDVqL7xoy0IBn3No/0KfsXfe8XFIHZI99co7uKUZbX7onAmAoSSuzx7GFAyF7oLQ2ZOo= X-Received: by 10.80.165.82 with SMTP id z18mr4463837edb.172.1505913716867; Wed, 20 Sep 2017 06:21:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.220.202 with HTTP; Wed, 20 Sep 2017 06:21:56 -0700 (PDT) In-Reply-To: References: <150522092693.4724.2532571098567577114.idtracker@ietfa.amsl.com> From: Dmitry Belyavsky Date: Wed, 20 Sep 2017 16:21:56 +0300 Message-ID: To: Nikos Mavrogiannopoulos Cc: "saag@ietf.org" , LAMPS , dev-security-policy@lists.mozilla.org, pkix@ietf.org Content-Type: multipart/alternative; boundary="94eb2c0de67c28062305599edcf9" Archived-At: Subject: Re: [saag] Fwd: New Version Notification for draft-belyavskiy-certificate-limitation-policy-04.txt X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Sep 2017 13:22:02 -0000 --94eb2c0de67c28062305599edcf9 Content-Type: text/plain; charset="UTF-8" Dear Nikos On Wed, Sep 13, 2017 at 9:39 AM, Nikos Mavrogiannopoulos wrote: > > 4. How do you handle extensions to this format? > > Overall, why not use X.509 extensions to store such additional > constraints? We already (in the p11-kit trust store in Fedora/RHEL > systems) use the notion of stapled extensions to limit certificates > [0, 1] and seems quite a flexible approach. Have you considered that > path? > > regards, > Nikos > > [0]. https://p11-glue.freedesktop.org/doc/storing-trust-policy/ > storing-trust-model.html > [1]. http://nmav.gnutls.org/2016/06/restricting-scope-of-ca- > certificates.html > I've looked through the specification. It's OK for me, but I do not get whether the attached extensions are crypto-protected. I'm ready to cooperate with you if there is any interest. -- SY, Dmitry Belyavsky --94eb2c0de67c28062305599edcf9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear Nikos

On Wed, Sep 13, 2017 at 9:39 AM, Nikos Mavrogiannopoulos <nmav@gnu= tls.org> wrote:

4. How do you handle extensions to this format?

Overall, why not use X.509 extensions to store such additional
constraints? We already (in the p11-kit trust store in Fedora/RHEL
systems) use the notion of stapled extensions to limit certificates
[0, 1] and seems quite a flexible approach. Have you considered that
path?

regards,
Nikos

[0]. https://p11-g= lue.freedesktop.org/doc/storing-trust-policy/storing-trust-model.= html
[1]. http://nmav.gnutls.org/= 2016/06/restricting-scope-of-ca-certificates.html

I've looked through the specification. It's = OK for me, but I do not get whether the attached extensions are crypto-prot= ected.
I'm ready to cooperate with you = if there is any interest.

--
SY, Dmitry Belyavsk= y
--94eb2c0de67c28062305599edcf9-- From nobody Fri Sep 22 01:07:29 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E9C11342CC; Fri, 22 Sep 2017 01:07:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 Q-n-ZH7TxNHJ; Fri, 22 Sep 2017 01:07:12 -0700 (PDT) Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::22e]) (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 AAE0D1326ED; Fri, 22 Sep 2017 01:07:12 -0700 (PDT) Received: by mail-qt0-x22e.google.com with SMTP id l25so304929qtf.13; Fri, 22 Sep 2017 01:07:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=vBJE8mrBdTSyBWtBoTFZsowcFqF8InTDMATdgzA1yJ4=; b=HsWc5Y+Vvfu+6mNOxADaWNEFc0s/ZbkN9N7Scb/srqRFOd467GXidiYJbQ+YfVYasF BzIPeD3MHjomDqMA9KNLYFnv+2dE9+majeN7qloOLGswlrEF27IjzOOVYMR6NuZnsCT/ DElsD5ajILwjgrgVsYZl0vxJlcPy46gu0gguaL/yv5nSleQWgSJMTnaquFVSSsEpgqId 4fmbfq2GTLaONAtTDpcoRb+7J1wr9aw686YeCvyC7eftPZphd6bk3XERx2GDeP2vGQNJ X+79EGiai0TsUQbinNHIz29TPX0k7ml6ULm45Xm+tI1UtEBCZ/qejhJQT+xo3cL3WCf3 EPxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=vBJE8mrBdTSyBWtBoTFZsowcFqF8InTDMATdgzA1yJ4=; b=FqTQvhtFkluruTYJU+tq2+gPafdwxmRyXRmQ+7Z9XBSHnhbxDo0JdX/zCLo8EYkbaO JJ9E6wp41jCyH2QG7WviUf97mTzNqx5Vsm6SCPJ5l+VX917YXZ5Nn0vEuUSA33njurvF VRV5FnqpaQ8E4W8wu6i25xwRVEVE8emTrNeFYHBSSrcOvs/MNMkjYSmaJF8Zg/qkemQ8 jP2wXXuUddAoh20exaz0eQ1Oxq6WjoGlV9wWQy+S03nof+KlLWbiZVg4S5eJq1zjxAsn bNmZSVyoDtub75jRpwPm771/1OZRxvp8LEOt18dAhEHSjkCrLkgD8xxqi57Fn39lBI9o 62mA== X-Gm-Message-State: AHPjjUitKmWE5FwblPVLKuIVtj5jG0AANLuF2AavM1rve9FbMusP/EyA M8aOfKApyLzFZYholQNozBkRndTi/WHlOEzQBpBlB197 X-Google-Smtp-Source: AOwi7QDDOO2NS5wxjNzH3OX/LY9A3hbgBfwO1y1ijziCfn7cGbynxVFrc4HGMEU8oz2GLD9fw47GsLtQxjYYqPClqPI= X-Received: by 10.200.52.60 with SMTP id u57mr7361042qtb.107.1506067631778; Fri, 22 Sep 2017 01:07:11 -0700 (PDT) MIME-Version: 1.0 Sender: n.mavrogiannopoulos@gmail.com Received: by 10.12.175.136 with HTTP; Fri, 22 Sep 2017 01:06:31 -0700 (PDT) In-Reply-To: References: <150522092693.4724.2532571098567577114.idtracker@ietfa.amsl.com> From: Nikos Mavrogiannopoulos Date: Fri, 22 Sep 2017 10:06:31 +0200 X-Google-Sender-Auth: Zg2LgTczXlHytCnGWbVTaghDHQU Message-ID: To: Dmitry Belyavsky Cc: "saag@ietf.org" , LAMPS , dev-security-policy@lists.mozilla.org, pkix@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [saag] Fwd: New Version Notification for draft-belyavskiy-certificate-limitation-policy-04.txt X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Sep 2017 08:07:14 -0000 On Wed, Sep 20, 2017 at 3:21 PM, Dmitry Belyavsky wrote: > Dear Nikos > > On Wed, Sep 13, 2017 at 9:39 AM, Nikos Mavrogiannopoulos > wrote: >> >> >> 4. How do you handle extensions to this format? >> >> Overall, why not use X.509 extensions to store such additional >> constraints? We already (in the p11-kit trust store in Fedora/RHEL >> systems) use the notion of stapled extensions to limit certificates >> [0, 1] and seems quite a flexible approach. Have you considered that >> path? >> >> regards, >> Nikos >> >> [0]. >> https://p11-glue.freedesktop.org/doc/storing-trust-policy/storing-trust-model.html >> [1]. >> http://nmav.gnutls.org/2016/06/restricting-scope-of-ca-certificates.html > I've looked through the specification. It's OK for me, but I do not get > whether the attached extensions are crypto-protected. No, as these values are inserted by the administrator of the system, or us (the distributor of the software), we didn't feel we needed the introduction of additional PKI. How do you see the infrastructure on the draft-belyavskiy-certificate-limitation-policy? Who do you envision signing these structures? (I assume that distribution of data will be done by software distributors?) >> 4. How do you handle extensions to this format? >> > Simillary to CRL. Do you have ideas of the extensions? One problem with that is the fact that the existing CRL extensions are about extending attributes of the CRL, rather than adding/removing attributes to the certificate in question. To bring the stapled extensions to your proposal, you'd need the Extensions and Extension fields from RFC5280, and add into limitedCertificates structure (I'll split it on the example below for clarity) the following field. LimitedCertificates ::= SEQUENCE OF LimitedCertificate LimitedCertificate ::= SEQUENCE { userCertificate CertificateSerialNumber, certificateIssuer Name, limitationDate Time, limitationPropagation Enum, fingerprint SEQUENCE { fingerprintAlgorithm AlgorithmIdentifier, fingerprintValue OCTET STRING } OPTIONAL, limitations SEQUENCE, } OPTIONAL, }; stapledExtensions Extensions; <----- NEW } Another difference between this profile and the p11-kit one, is that the extensions/revocation here is done on the certificate, while in p11-kit is done on the public key. Both approaches have pros and cons. Another question. I also noticed the fingerprint field above. Is that to distinguish between same CAs with different keys? In that case using the SubjectPublicKeyIdentifier may be sufficient, and more natural as this is how certificates with matching DNs/serials are distinguished. regards, Nikos