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

Russ Housley <housley@vigilsec.com> Thu, 02 June 2022 20:56 UTC

Return-Path: <housley@vigilsec.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 DDD74C147921 for <spasm@ietfa.amsl.com>; Thu, 2 Jun 2022 13:56:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01] 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 IB4YbH3-C4W6 for <spasm@ietfa.amsl.com>; Thu, 2 Jun 2022 13:56:51 -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 F3095C14F720 for <spasm@ietf.org>; Thu, 2 Jun 2022 13:56:50 -0700 (PDT)
Received: from mail3.g24.pair.com (localhost [127.0.0.1]) by mail3.g24.pair.com (Postfix) with ESMTP id 91BBB5409B; Thu, 2 Jun 2022 16:56:49 -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 849655472C; Thu, 2 Jun 2022 16:56:49 -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 <housley@vigilsec.com>
In-Reply-To: <DC7741A3-D11A-4908-8A67-5A44007B4054@vigilsec.com>
Date: Thu, 02 Jun 2022 16:56:48 -0400
Cc: LAMPS <spasm@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <34FC3EAD-5048-4C20-B0B1-7940C03C9F74@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>
To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
X-Mailer: Apple Mail (2.3445.104.21)
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/XaRNDVbOaIsldeOLMMG1RKcWVjE>
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, 02 Jun 2022 20:56:53 -0000

DKG:

>>> n) There seems to be a mismatch between the ASN.1 and the text about
>>>  whether an image must be present.  The text says yes:
>>> 
>>>     Each logotype present in a certificate MUST be represented by at least one image data object.
>>> 
>>>  but the ASN.1 seems to say that audio-only is OK:
>>> 
>>>   LogotypeData ::= SEQUENCE {
>>>      image           SEQUENCE OF LogotypeImage OPTIONAL,
>>>      audio           [1] SEQUENCE OF LogotypeAudio OPTIONAL }
>>>         -- At least one of the OPTIONAL components MUST be present
>>>         ( WITH COMPONENTS { ..., image PRESENT } |
>>>           WITH COMPONENTS { ..., audio PRESENT } )
>> 
>> This confusion remains in the document.
> 
> You are right.  Thanks for catching this.  Given the introduction of text-to-speech capability, I think the MUST statement should be changed to a SHOULD statement.
> 
> I suggest:
> 
>   Each logotype present in a certificate SHOULD be represented by at
>   least one image data object.

The I-D authors have been discussing this one, and we think it would be better to keep alignment with RFC 3709.  That is, keep the MUST statement as it is.

To make the ASN.1 match this decision is pretty straightforward:

LogotypeData ::= SEQUENCE {
   image           SEQUENCE OF LogotypeImage OPTIONAL,
   audio           [1] SEQUENCE OF LogotypeAudio OPTIONAL }
      -- At least one of the image component MUST be present
      ( WITH COMPONENTS { ..., image PRESENT } )

Russ