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

Stefan Santesson <stefan@aaa-sec.com> Thu, 16 June 2022 00:05 UTC

Return-Path: <stefan@aaa-sec.com>
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 91BF5C14CF0D for <spasm@ietfa.amsl.com>; Wed, 15 Jun 2022 17:05:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.782
X-Spam-Level:
X-Spam-Status: No, score=-3.782 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-1.876, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 09KG6VN9KBd5 for <spasm@ietfa.amsl.com>; Wed, 15 Jun 2022 17:05:36 -0700 (PDT)
Received: from smtp.outgoing.loopia.se (smtp.outgoing.loopia.se [93.188.3.37]) (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 CED34C14CF01 for <spasm@ietf.org>; Wed, 15 Jun 2022 17:05:34 -0700 (PDT)
Received: from s807.loopia.se (localhost [127.0.0.1]) by s807.loopia.se (Postfix) with ESMTP id 571242F30822 for <spasm@ietf.org>; Thu, 16 Jun 2022 02:05:32 +0200 (CEST)
Received: from s630.loopia.se (unknown [172.22.191.6]) by s807.loopia.se (Postfix) with ESMTP id 472C02E27498; Thu, 16 Jun 2022 02:05:32 +0200 (CEST)
Received: from s474.loopia.se (unknown [172.22.191.5]) by s630.loopia.se (Postfix) with ESMTP id 3CB0F13ABE25; Thu, 16 Jun 2022 02:05:32 +0200 (CEST)
X-Virus-Scanned: amavisd-new at amavis.loopia.se
Received: from s899.loopia.se ([172.22.191.5]) by s474.loopia.se (s474.loopia.se [172.22.190.14]) (amavisd-new, port 10024) with LMTP id eW3zLWBhQ-Dd; Thu, 16 Jun 2022 02:05:31 +0200 (CEST)
X-Loopia-Auth: user
X-Loopia-User: mailstore2@aaa-sec.com
X-Loopia-Originating-IP: 85.235.7.89
Received: from [192.168.1.218] (gw.aaa-sec.ideon.se [85.235.7.89]) (Authenticated sender: mailstore2@aaa-sec.com) by s899.loopia.se (Postfix) with ESMTPSA id 9298D2C8BAA8; Thu, 16 Jun 2022 02:05:31 +0200 (CEST)
Message-ID: <0bba4030-d5b0-dc6a-8a35-9f5b1b8f2861@aaa-sec.com>
Date: Thu, 16 Jun 2022 02:05:31 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.0
Content-Language: sv-SE, en-GB
To: Russ Housley <housley@vigilsec.com>, Daniel Kahn Gillmor <dkg@fifthhorseman.net>
Cc: LAMPS <spasm@ietf.org>
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> <87k09hfx52.fsf@fifthhorseman.net> <DF1EC3BE-C208-412B-8568-F16041F2DF99@vigilsec.com>
From: Stefan Santesson <stefan@aaa-sec.com>
Organization: 3xA Security AB
In-Reply-To: <DF1EC3BE-C208-412B-8568-F16041F2DF99@vigilsec.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/S_XCdDOBD8SA4IetOIvN-UxULNA>
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: Thu, 16 Jun 2022 00:05:41 -0000

I don not oppose this change. However, if we change this, I would 
clarify further and change "any type of automated processing" to 
"automated trust decision".

"any type of" is redundant and "processing" is to generic. What we meant 
with the text was to say that automated processing should not determine 
certificate trust or validity based on logotypes (It's purely meant for 
human consumption).

/Stefan



On 2022-06-16 01:11, Russ Housley wrote:
> DKG:
>
> Please see below.
>
>> On Jun 15, 2022, at 5:13 PM, Daniel Kahn Gillmor <dkg@fifthhorseman.net> wrote:
>>
>> 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.
> Let's look at the whole paragraph.  I think I now understand your concern, and I suggest:
>
> OLD:
>
>     Logotypes MAY be included in public key certificates and attribute
>     certificates at the discretion of the certificate issuer; however,
>     logotypes MUST NOT be part of certification path validation or any
>     type of automated processing.  The sole purpose of logotypes is to
>     enhance the display of a particular certificate, regardless of its
>     position in a certification path.
>
> NEW;
>
>     Logotypes MAY be included in public key certificates and attribute
>     certificates at the discretion of the certificate issuer; however, the
>     relying party MUST NOT use the logotypes as part of certification
>     path validation or any type of automated processing.  The sole
>     purpose of logotypes is to enhance the display of a particular
>     certificate, regardless of its position in a certification path.
>
> Russ
> _______________________________________________
> Spasm mailing list
> Spasm@ietf.org
> https://www.ietf.org/mailman/listinfo/spasm