Re: [lamps] draft-ietf-lamps-rfc3709bis-01 security, reliability, and privacy considerations

Daniel Kahn Gillmor <dkg@fifthhorseman.net> Wed, 15 June 2022 21:13 UTC

Return-Path: <dkg@fifthhorseman.net>
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5E42C15AAC5 for <spasm@ietfa.amsl.com>; Wed, 15 Jun 2022 14:13:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.109
X-Spam-Level:
X-Spam-Status: No, score=-2.109 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=fifthhorseman.net header.b=El7eGI/a; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=nuVL53MI
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7xJ9X0ape29Q for <spasm@ietfa.amsl.com>; Wed, 15 Jun 2022 14:13:38 -0700 (PDT)
Received: from che.mayfirst.org (che.mayfirst.org [IPv6:2001:470:1:116::7]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4521C157B5E for <spasm@ietf.org>; Wed, 15 Jun 2022 14:13:37 -0700 (PDT)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1655327615; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=o/JXwaeCKsAdx4DEqAuHQt6lvrw9+eO/U6riARamcrs=; b=El7eGI/aYzZAwX+00rS8/br8TylYfr6YMAH+tE0rf/kvzK7eS9bsOaCIR9UJsiSY7CuwJ RcubuYsceGQ7jD/Aw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1655327615; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=o/JXwaeCKsAdx4DEqAuHQt6lvrw9+eO/U6riARamcrs=; b=nuVL53MIlWBDbWvmD1vlg5OVCIC/w+ZuWPKRpdZNhMJCgQ6DrIlaF/bBibMYF7DesI5Sk rUAlOUhMJ8qssLJ7I7FrAaCsCIusGQAIr1OdkE5USRv2GzYVx+1Jwyhfyz9+Ycbo40JOidX YSzQV2rZGKC50Afu4fOFfup/qdnPtpvvOhUD/kzYnEEs0xPm37B8psRmEn2UPXoi7OfCkun X/JbLVi7DyaEiA9dA36uRBpRqfVV3texg3MoA3dA7+o1T9bNY6pFirsynUyqOT2qca3gbG/ BurJ64doIt1WeK/nChOD7XiGwOYCodz6ufxdhmmO878ugYRXUhGEqiDn1VTw==
Received: from fifthhorseman.net (lair.fifthhorseman.net [108.58.6.98]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-384) server-digest SHA384) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id B1768F9B2; Wed, 15 Jun 2022 17:13:34 -0400 (EDT)
Received: by fifthhorseman.net (Postfix, from userid 1000) id EB9CA20546; Wed, 15 Jun 2022 17:13:30 -0400 (EDT)
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
To: Russ Housley <housley@vigilsec.com>
Cc: LAMPS <spasm@ietf.org>
In-Reply-To: <CAE07C5E-5F03-4AC1-AEA2-6A55DC11F59B@vigilsec.com>
References: <877d8hx019.fsf@fifthhorseman.net> <7BA047D3-B499-4395-A8BB-99D5C816ADC6@vigilsec.com> <87sfoqdk94.fsf@fifthhorseman.net> <DC7741A3-D11A-4908-8A67-5A44007B4054@vigilsec.com> <875yl1ooba.fsf@fifthhorseman.net> <CAE07C5E-5F03-4AC1-AEA2-6A55DC11F59B@vigilsec.com>
Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEX+i03xYJKwYBBAHaRw8BAQdACA4xvL/xI5dHedcnkfViyq84doe8zFRid9jW7CC9XBiI0QQf FgoAgwWCX+i03wWJBZ+mAAMLCQcJEOCS6zpcoQ26RxQAAAAAAB4AIHNhbHRAbm90YXRpb25zLnNl cXVvaWEtcGdwLm9yZ/tr8E9NA10HvcAVlSxnox6z62KXCInWjZaiBIlgX6O5AxUKCAKbAQIeARYh BMKfigwB81402BaqXOCS6zpcoQ26AADZHQD/Zx9nc3N2kj13AUsKMr/7zekBtgfSIGB3hRCU74Su G44A/34Yp6IAkndewLxb1WdRSokycnaCVyrk0nb4imeAYyoPtBc8ZGtnQGZpZnRoaG9yc2VtYW4u bmV0PojRBBMWCgCDBYJf6LTfBYkFn6YAAwsJBwkQ4JLrOlyhDbpHFAAAAAAAHgAgc2FsdEBub3Rh dGlvbnMuc2VxdW9pYS1wZ3Aub3JnL0Gwxvypz2tu1IPG+yu1zPjkiZwpscsitwrVvzN3bbADFQoI ApsBAh4BFiEEwp+KDAHzXjTYFqpc4JLrOlyhDboAAPkXAP0Z29z7jW+YzLzPTQML4EQLMbkHOfU4 +s+ki81Czt0WqgD/SJ8RyrqDCtEP8+E4ZSR01ysKqh+MUAsTaJlzZjehiQ24MwRf6LTfFgkrBgEE AdpHDwEBB0DkKHOW2kmqfAK461+acQ49gc2Z6VoXMChRqobGP0ubb4kBiAQYFgoBOgWCX+i03wWJ BZ+mAAkQ4JLrOlyhDbpHFAAAAAAAHgAgc2FsdEBub3RhdGlvbnMuc2VxdW9pYS1wZ3Aub3Jnfvo+ nHoxDwaLaJD8XZuXiaqBNZtIGXIypF1udBBRoc0CmwICHgG+oAQZFgoAbwWCX+i03wkQPp1xc3He VlxHFAAAAAAAHgAgc2FsdEBub3RhdGlvbnMuc2VxdW9pYS1wZ3Aub3JnaheiqE7Pfi3Atb3GGTw+ jFcBGOaobgzEJrhEuFpXREEWIQQttUkcnfDcj0MoY88+nXFzcd5WXAAAvrsBAIJ5sBg8Udocv25N stN/zWOiYpnjjvOjVMLH4fV3pWE1AP9T6hzHz7hRnAA8d01vqoxOlQ3O6cb/kFYAjqx3oMXSBhYh BMKfigwB81402BaqXOCS6zpcoQ26AADX7gD/b83VObe14xrNP8xcltRrBZF5OE1rQSPkMNy+eWpk eCwA/1hxiS8ZxL5/elNjXiWuHXEvUGnRoVj745Vl48sZPVYMuDgEX+i03xIKKwYBBAGXVQEFAQEH QIGex1WZbH6xhUBve5mblScGYU+Y8QJOomXH+rr5tMsMAwEICYjJBBgWCgB7BYJf6LTfBYkFn6YA CRDgkus6XKENukcUAAAAAAAeACBzYWx0QG5vdGF0aW9ucy5zZXF1b2lhLXBncC5vcmcEAx9vTD3b J0SXkhvcRcCr6uIDJwic3KFKxkH1m4QW0QKbDAIeARYhBMKfigwB81402BaqXOCS6zpcoQ26AAAX mwD8CWmukxwskU82RZLMk5fm1wCgMB5z8dA50KLw3rgsCykBAKg1w/Y7XpBS3SlXEegIg1K1e6dR fRxL7Z37WZXoH8AH
Date: Wed, 15 Jun 2022 17:13:29 -0400
Message-ID: <87k09hfx52.fsf@fifthhorseman.net>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/_-mMUB6A9eXNxklXC9UpYtXX_EE>
Subject: Re: [lamps] draft-ietf-lamps-rfc3709bis-01 security, reliability, and privacy considerations
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
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, 15 Jun 2022 21:13:43 -0000

On Wed 2022-06-15 14:39:49 -0400, Russ Housley wrote:
>>>>> v) "5. Type of Certificates" says:
>>>>> 
>>>>>    logotypes MUST NOT be part of certification path validation or any
>>>>>    type of automated processing.
>>>>> 
>>>>>  but this seems to be in conflict with requirements like "The
>>>>>  background image MUST allow black text to be clearly read when placed
>>>>>  on top of the background image." which would presumably be enforced
>>>>>  by the certificate issuer via automated processing.
>>>>> 
>>>>>  Perhaps this is supposed to mean "any type of automated processing by
>>>>>  the relying party" or "any type of automated processing during
>>>>>  certificate validation"?
>>>> 
>>>> This item (v) is also still not addressed.  Are we really saying that an
>>>> issuer MUST NOT attempt to confirm (for example) that two formats of
>>>> visual representation are actually roughly visually similar, using (for
>>>> example) a conversion to raw pixels and then some sort of distance metric?
>>> 
>>> I think you are misreading this one.  Path validation is specified in
>>> Section 6 or RFC 5280.  I'll add an explicit reference.  This is not
>>> saying anything whatsoever about the vetting that a CA might perform
>>> prior to including the logotype data in the certificate.
>> 
>> The text just says "or any type of automated processing", in addition to
>> certification path validation.  This is one of several examples in the
>> document where the document appears to implicitly refer to one
>> particular party involved with a certificate (in this case, the relying
>> party) but not considering how the text reads in the context of one of
>> the other parties involved (e.g. the subscriber, the issuing authority,
>> the resource host, an implementer, etc).
>> 
>> That potential confusion makes it difficult to apply the document.
>> Being explicit would be make it easier to use safely.
>
> I am very confused by this comment.  Only relying parties perform
> certificate path construction and validation.

Sorry for the confusion, let me retry my explanation.

The text says "or any type of automated processing".  That is, it is
apparently talking about something else *in addition to* certificate
path construction and validation.

It says this in the context of a sentence that talks specifically about
"the certificate issuer" -- which is not the relying party.

The implication seems to be that the certificate issuer (and perhaps
other parties, though again it is unclear) should avoid using these
extensions in any sort of automated processing.  I don't think that's
reasonable, or what anyone intends.  But it's what the document appears
to say.

        --dkg