From nobody Thu Jun 16 15:33:40 2022 Return-Path: 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 BB096C15AE2D for ; Thu, 16 Jun 2022 15:33:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 8lochXi8TcV1 for ; Thu, 16 Jun 2022 15:33:38 -0700 (PDT) Received: from mail3.g24.pair.com (mail3.g24.pair.com [66.39.134.11]) (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 C5728C15AACA for ; Thu, 16 Jun 2022 15:33:38 -0700 (PDT) Received: from mail3.g24.pair.com (localhost [127.0.0.1]) by mail3.g24.pair.com (Postfix) with ESMTP id 09B645165E; Thu, 16 Jun 2022 18:33:38 -0400 (EDT) Received: from [10.0.1.2] (pfs.iad.rg.net [198.180.150.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail3.g24.pair.com (Postfix) with ESMTPSA id E9604510ED; Thu, 16 Jun 2022 18:33:37 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.21\)) From: Russ Housley In-Reply-To: <0bba4030-d5b0-dc6a-8a35-9f5b1b8f2861@aaa-sec.com> Date: Thu, 16 Jun 2022 18:33:37 -0400 Cc: Daniel Kahn Gillmor , LAMPS Content-Transfer-Encoding: quoted-printable Message-Id: References: <877d8hx019.fsf@fifthhorseman.net> <7BA047D3-B499-4395-A8BB-99D5C816ADC6@vigilsec.com> <87sfoqdk94.fsf@fifthhorseman.net> <875yl1ooba.fsf@fifthhorseman.net> <87k09hfx52.fsf@fifthhorseman.net> <0bba4030-d5b0-dc6a-8a35-9f5b1b8f2861@aaa-sec.com> To: Stefan Santesson X-Mailer: Apple Mail (2.3445.104.21) Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2022 22:33:39 -0000 I agree. I have made that change. Russ > On Jun 15, 2022, at 8:05 PM, Stefan Santesson = wrote: >=20 > 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". >=20 > "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). >=20 > /Stefan >=20 >=20 >=20 > On 2022-06-16 01:11, Russ Housley wrote: >> DKG: >>=20 >> Please see below. >>=20 >>> On Jun 15, 2022, at 5:13 PM, Daniel Kahn Gillmor = wrote: >>>=20 >>> On Wed 2022-06-15 14:39:49 -0400, Russ Housley wrote: >>>>>>>> v) "5. Type of Certificates" says: >>>>>>>>=20 >>>>>>>> logotypes MUST NOT be part of certification path validation = or any >>>>>>>> type of automated processing. >>>>>>>>=20 >>>>>>>> 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. >>>>>>>>=20 >>>>>>>> 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). >>>>>=20 >>>>> 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. >>>=20 >>> 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. >>>=20 >>> It says this in the context of a sentence that talks specifically = about >>> "the certificate issuer" -- which is not the relying party. >>>=20 >>> 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: >>=20 >> OLD: >>=20 >> 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. >>=20 >> NEW; >>=20 >> 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. >>=20 >> Russ >> _______________________________________________ >> Spasm mailing list >> Spasm@ietf.org >> https://www.ietf.org/mailman/listinfo/spasm >=20 > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm