From nobody Thu Sep 7 13:39:57 2017 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 341D1132397 for ; Thu, 7 Sep 2017 13:39:56 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 IbNE5AiuRuuG for ; Thu, 7 Sep 2017 13:39:54 -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 5C88D126B7E for ; Thu, 7 Sep 2017 13:39:54 -0700 (PDT) Received: by mail-qt0-x22b.google.com with SMTP id s18so316017qta.3 for ; Thu, 07 Sep 2017 13:39:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=mDaOB/xT6JBy+mBEk40SBaMjMq4bUi9mljOmKFh9wZs=; b=YpIyppdJf8cCTVdjxjTNPluCpxeV0iVOriRGaw4Lo98Eaz6ib7mOJYzFggp0ob63J9 5BhrISdT2agvmIRr8rM4rp/fQVe35k+ys/gqyhpW9SzaGn8r53fzm/QrrRPekW4SWkHl Lx82l+NekkoYI/uUjsRAhd2MwO19H3erk5zfI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=mDaOB/xT6JBy+mBEk40SBaMjMq4bUi9mljOmKFh9wZs=; b=YMM4NdnMe0YC8K30lFwGgeVgZQMz0J8cDPE+5apjizXWOecIt8jnGNMTtxwneh4cQa Sw1+n6/c0QSawEXKONv1UNS8U93dLne42RqG9eedR12IkPuJMoDryLuWCAOkluVvpP22 fVUqxDt9HHumllOyljsf3JFKD4xxsKzglH5A98soTssRiFp8d9NgKEH6Gc9kQ8EcAKns Pb+9A3LaVQpQil6sLarEIlm7w/MR9vYctex4Jru+Kwj5WCTMY6MyUm1b5IOksctt1AEg uCmAIjLIi2/wGU791zOAuxC3Zf7URwrhTT1xNuCS0CfYEbj22k9mgHZ71YsQiJJOXt5j 1uMA== X-Gm-Message-State: AHPjjUiCJxNNjZEoqfOx9uYkiJ4J5QB7rkdhYm2RRhGZkQ4TQGMuTBT1 94vnqXzf9LIB2zWVb2pdMQ== X-Google-Smtp-Source: AOwi7QCAHnLjBkcfqN2V964WQbzP1YjH4mQR9qLVtEMc1dOgbv2XObtZq1JyjdgLyLKRp4lfJ8nymw== X-Received: by 10.200.25.78 with SMTP id g14mr936083qtk.48.1504816793212; Thu, 07 Sep 2017 13:39:53 -0700 (PDT) Received: from [172.16.0.18] ([96.231.223.191]) by smtp.gmail.com with ESMTPSA id s43sm162197qta.31.2017.09.07.13.39.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 Sep 2017 13:39:51 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Sean Turner In-Reply-To: <20170907201629.87349B81779@rfc-editor.org> Date: Thu, 7 Sep 2017 16:39:50 -0400 Cc: Max Pritikin , Peter Yee , Daniel Harkins , Kathleen Moriarty , Eric Rescorla , Stephen Kent , Stefan Santesson Content-Transfer-Encoding: quoted-printable Message-Id: References: <20170907201629.87349B81779@rfc-editor.org> To: PKIX X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [pkix] [Technical Errata Reported] RFC7030 (5107) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Sep 2017 20:39:56 -0000 Note that this issue was discovered during IESG review of = draft-turner-est-extensions. Alexey, Panos, Dan, Max, and myself worked = on the wording. I=E2=80=99m hoping it can stew for a couple of days and = then be marked as accepted. spt > On Sep 7, 2017, at 16:16, RFC Errata System = wrote: >=20 > The following errata report has been submitted for RFC7030, > "Enrollment over Secure Transport". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata/eid5107 >=20 > -------------------------------------- > Type: Technical > Reported by: Sean Turner >=20 > Section: 3.2.1 >=20 > Original Text > ------------- >=20 >=20 > Corrected Text > -------------- > Add the following is as the last paragraph of Section 3.2.1: >=20 > [RFC2616] indicates "HTTP does not use the > Content-Transfer-Encoding (CTE) field of RFC 2045=E2=80=9D; = nevertheless, this > document was published specifying the use of the > Content-Transfer-Encoding header with a value of =E2=80=98base64' in = Sections > 4.1.3, 4.3.1, 4.3.2, 4.4.2, 4.5.2, as well as in the examples in > Appendices A.1-A.4. As HTTP is binary-clean transport, there is no > need to indicate this for HTTP-based protocols like EST. EST server > implementations SHOULD omit the Content-Transfer-Encoding header if > they know a priori that EST clients do not rely this field. EST > Clients SHOULD expect that the Content-Transfer-Encoding header will > be absent unless they have an a priori agreement with the EST server. > The mechanism to establish this client dependency is out-of-scope. >=20 > Notes > ----- > EST, which is an HTTP-based protocol, erroneous used CTE. This errata = addresses this error. >=20 > Note that the text was reviewed by a RAI AD as well as multiple EST = implementors. >=20 > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party =20 > can log in to change the status and edit the report, if necessary.=20 >=20 > -------------------------------------- > RFC7030 (draft-ietf-pkix-est-09) > -------------------------------------- > Title : Enrollment over Secure Transport > Publication Date : October 2013 > Author(s) : M. Pritikin, Ed., P. Yee, Ed., D. Harkins, Ed. > Category : PROPOSED STANDARD > Source : Public-Key Infrastructure (X.509) > Area : Security > Stream : IETF > Verifying Party : IESG From nobody Thu Sep 7 13:40:32 2017 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD2E61329B5 for ; Thu, 7 Sep 2017 13:40:31 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 m-y0m2iz8zkn for ; Thu, 7 Sep 2017 13:40:30 -0700 (PDT) Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D74831201F8 for ; Thu, 7 Sep 2017 13:40:29 -0700 (PDT) Received: by mail-qt0-x22a.google.com with SMTP id h15so2125051qta.4 for ; Thu, 07 Sep 2017 13:40:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=+ymGBnf+cxVQDW//cO/H3uUXdTrHMHoo1vy6I5ozq4U=; b=Z4Fc7a2sRfL+MF4blJEOG/Jj917xf532xcWFjY+YhYAh7MKADzJca6WYCvjDr+D3js BwznF66Id9xjRiwx4iyBLPk7ZMachHfvaqMywnm5VDSn2yM/74Oo5bv3Aym4RSq4msUj 8RhR4gS4MVPmlOz6GV8KX5/cAbGieLrbAHCzs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=+ymGBnf+cxVQDW//cO/H3uUXdTrHMHoo1vy6I5ozq4U=; b=ihZwYrGmoGgGPJDhSOVYA/F5NXIZQsBEJb4UoF37gWHL+QUPA/wkHd22fooKnKRRAm ZnwhHPiyZ0UmToaWCsMthX1XP5dc2GYFFsA/QytIJ1lpF3Xos8W0PUHQ34wHjfJtgV1T hxWbnJ7Bt9kNL7peGo3yLGicOCDLxbvI94qYFQtHJ4D9nISTHZwMHCZXdjeHdFkxUXIq 4jR8Nzsm3UA+75i4FMC5Lc2zwoV+vY73t+C/vXMeIbdCwi6/YgBtP5mw950TZyiPTLSb M7ayqGQxLqwkQkuMes+0vaALNyJmEzpzqZYFVo9v9WunfPLpGv3Dmo+oOCHZJzOOfySS 0UWQ== X-Gm-Message-State: AHPjjUieb5ZdkvY6ZBGDhxkzoK0nlF7PR1c5VOcT60AhuZiBSNlLCmBy r/vti3UmCqRmCgSef/8DcA== X-Google-Smtp-Source: AOwi7QCxgm2r4czBa8zNBkapRPWooNXJ8TnfdV224rKRUgTFN9YRKN+nX4dFisUNEmCsx4eyV4JseA== X-Received: by 10.237.35.238 with SMTP id k43mr964387qtc.214.1504816828676; Thu, 07 Sep 2017 13:40:28 -0700 (PDT) Received: from [172.16.0.18] ([96.231.223.191]) by smtp.gmail.com with ESMTPSA id s43sm162197qta.31.2017.09.07.13.40.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 Sep 2017 13:40:27 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Sean Turner In-Reply-To: <20170907201944.D97B7B8178F@rfc-editor.org> Date: Thu, 7 Sep 2017 16:40:26 -0400 Cc: Max Pritikin , Peter Yee , Daniel Harkins , Kathleen Moriarty , Eric Rescorla , Stephen Kent , Stefan Santesson Content-Transfer-Encoding: quoted-printable Message-Id: References: <20170907201944.D97B7B8178F@rfc-editor.org> To: PKIX X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [pkix] [Technical Errata Reported] RFC7030 (5108) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Sep 2017 20:40:32 -0000 Note that this issue was discovered during IESG review of = draft-turner-est-extensions. Alexey, Panos, Dan, Max, and myself worked = on the wording. I=E2=80=99m hoping it can stew for a couple of days and = then be marked as accepted. spt > On Sep 7, 2017, at 16:19, RFC Errata System = wrote: >=20 > The following errata report has been submitted for RFC7030, > "Enrollment over Secure Transport". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata/eid5108 >=20 > -------------------------------------- > Type: Technical > Reported by: Sean Turner >=20 > Section: 4.2.3, 4.4.2 >=20 > Original Text > ------------- > OLD from s.4.2.3: >=20 > If the content-type is not set, the response data MUST be a plaintext > human-readable error message containing explanatory information > describing why the request was rejected (for example, indicating that > CSR attributes are incomplete). >=20 > OLD from s4.4.2: >=20 > If the content-type is not set, the response data MUST be a plaintext > human-readable error message. >=20 > Corrected Text > -------------- > NEW for s4.2.3: >=20 > If the content-type is not set, the response data must be a plaintext > human-readable error message containing explanatory information > describing why the request was rejected (for example, indicating that > CSR attributes are incomplete). Servers MAY use the "text/plain=E2=80=9D= > content-type [RFC2046] for human-readable errors. >=20 > NEW for s4.4.2: >=20 > If the content-type is not set, the response data must be a plaintext > human-readable error message. Servers MAY use the "text/plain=E2=80=9D > content-type [RFC2046] for human-readable errors. >=20 > Notes > ----- > The current text is somewhat unclear as to what content-type needs to = be used for the human-readable error. There are many human-readable = content-types, but "text/plain" seems to be the most sensible. >=20 > Note that the MUST was reduced to a must because no content-type is = specified. >=20 > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party =20 > can log in to change the status and edit the report, if necessary.=20 >=20 > -------------------------------------- > RFC7030 (draft-ietf-pkix-est-09) > -------------------------------------- > Title : Enrollment over Secure Transport > Publication Date : October 2013 > Author(s) : M. Pritikin, Ed., P. Yee, Ed., D. Harkins, Ed. > Category : PROPOSED STANDARD > Source : Public-Key Infrastructure (X.509) > Area : Security > Stream : IETF > Verifying Party : IESG From nobody Tue Sep 12 05:59:52 2017 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@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: [pkix] Fwd: New Version Notification for draft-belyavskiy-certificate-limitation-policy-04.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: PKIX Working 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 23:40:13 2017 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@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: [pkix] [saag] Fwd: New Version Notification for draft-belyavskiy-certificate-limitation-policy-04.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: PKIX Working 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:27 2017 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@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: [pkix] [saag] Fwd: New Version Notification for draft-belyavskiy-certificate-limitation-policy-04.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: PKIX Working 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 Wed Sep 20 06:22:17 2017 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@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: [pkix] [saag] Fwd: New Version Notification for draft-belyavskiy-certificate-limitation-policy-04.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: PKIX Working 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:16 2017 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@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: [pkix] [saag] Fwd: New Version Notification for draft-belyavskiy-certificate-limitation-policy-04.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: PKIX Working 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