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
- [lamps] draft-ietf-lamps-rfc3709bis-01 security, … Daniel Kahn Gillmor
- Re: [lamps] draft-ietf-lamps-rfc3709bis-01 securi… Stefan Santesson
- Re: [lamps] draft-ietf-lamps-rfc3709bis-01 securi… Daniel Kahn Gillmor
- Re: [lamps] draft-ietf-lamps-rfc3709bis-01 securi… Stefan Santesson
- Re: [lamps] draft-ietf-lamps-rfc3709bis-01 securi… Daniel Kahn Gillmor
- Re: [lamps] draft-ietf-lamps-rfc3709bis-01 securi… Russ Housley
- Re: [lamps] draft-ietf-lamps-rfc3709bis-01 securi… Daniel Kahn Gillmor
- Re: [lamps] draft-ietf-lamps-rfc3709bis-01 securi… Russ Housley
- Re: [lamps] draft-ietf-lamps-rfc3709bis-01 securi… Russ Housley
- Re: [lamps] draft-ietf-lamps-rfc3709bis-01 securi… Daniel Kahn Gillmor
- Re: [lamps] draft-ietf-lamps-rfc3709bis-01 securi… Russ Housley
- Re: [lamps] draft-ietf-lamps-rfc3709bis-01 securi… Daniel Kahn Gillmor
- Re: [lamps] draft-ietf-lamps-rfc3709bis-01 securi… Russ Housley
- Re: [lamps] draft-ietf-lamps-rfc3709bis-01 securi… Stefan Santesson
- Re: [lamps] draft-ietf-lamps-rfc3709bis-01 securi… Stefan Santesson
- Re: [lamps] draft-ietf-lamps-rfc3709bis-01 securi… Russ Housley