[lamps] Warren Kumari's No Objection on charter-ietf-lamps-02-00: (with COMMENT)

Warren Kumari <warren@kumari.net> Wed, 23 May 2018 21:14 UTC

Return-Path: <warren@kumari.net>
X-Original-To: spasm@ietf.org
Delivered-To: spasm@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F1FA9127010; Wed, 23 May 2018 14:14:53 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Warren Kumari <warren@kumari.net>
To: The IESG <iesg@ietf.org>
Cc: lamps-chairs@ietf.org, spasm@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.80.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <152711009395.26876.300138090771817722.idtracker@ietfa.amsl.com>
Date: Wed, 23 May 2018 14:14:53 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/j2WQKuVAYuXjIwkYfC72E4St7sQ>
Subject: [lamps] Warren Kumari's No Objection on charter-ietf-lamps-02-00: (with COMMENT)
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.22
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." <spasm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spasm>, <mailto:spasm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spasm/>
List-Post: <mailto:spasm@ietf.org>
List-Help: <mailto:spasm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spasm>, <mailto:spasm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 23 May 2018 21:14:54 -0000

Warren Kumari has entered the following ballot position for
charter-ietf-lamps-02-00: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)



The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/charter-ietf-lamps/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you for educating me - it sounds like my concerns have been considered,
clearing my Block position.

----

Also, "revoking them pointless" does not parse - perhaps "revoking them is
pointless"?

Original Block position (for archeology):
"3. Specify the use of short-lived X.509 certificates for which no
revocation information is made available by the Certification Authority.
Short-lived certificates have a lifespan that is shorter than the time
needed to detect, report, and distribute revocation information, as a
result revoking them pointless."

This makes me twitch -- how short is "short"? And how long is the time to
"detect, report, and distribute revocation information"? With e.g: CT,
misissued certificates may be visible before they are used in an attack,
decreasing the detection time.

Also, I would figure that it is still useful to know that a certificate was
revoked and didn't just expire -- if I see a certificate which expired 10
minutes ago I may be willing (after some consideration, checking my clock, etc)
to decide to trust it anyway (even if that's a bad idea!), but a revoked
certificate is a clear indication that something bad happened, and changes my
risk assessment.

It's entirely possible that there is a really good reason why I'm wrong / that
this argument doesn't make sense in some use cases (or just that I'm nuts!)