Re: [lamps] [CMP Updates] position of hashAlg in certStatus
David von Oheimb <nl0@von-Oheimb.de> Sun, 05 September 2021 19:10 UTC
Return-Path: <nl0@von-Oheimb.de>
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 C36A03A1235 for <spasm@ietfa.amsl.com>; Sun, 5 Sep 2021 12:10:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GtPkAtWQppb9 for <spasm@ietfa.amsl.com>; Sun, 5 Sep 2021 12:10:27 -0700 (PDT)
Received: from server8.webgo24.de (server8.webgo24.de [185.30.32.8]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21FC03A1234 for <spasm@ietf.org>; Sun, 5 Sep 2021 12:10:26 -0700 (PDT)
Received: from [192.168.8.103] (ip-109-43-50-218.web.vodafone.de [109.43.50.218]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by server8.webgo24.de (Postfix) with ESMTPSA id DA91B42179A; Sun, 5 Sep 2021 21:10:22 +0200 (CEST)
To: Carl Wallace <carl@redhoundsoftware.com>, Russ Housley <housley@vigilsec.com>
References: <25dfec13-5c60-406f-7dbe-150f547ccc90@von-Oheimb.de> <4738AAD8-2EFF-459C-B89B-248568B91E28@redhoundsoftware.com>
Cc: Hendrik Brockhaus <Hendrik.Brockhaus@siemens.com>, "spasm@ietf.org" <spasm@ietf.org>, John Gray <John.Gray@entrust.com>
From: David von Oheimb <nl0@von-Oheimb.de>
Message-ID: <e37845df-23ff-9edd-f3c4-168ad02fcd84@von-Oheimb.de>
Date: Sun, 05 Sep 2021 21:10:22 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1
MIME-Version: 1.0
In-Reply-To: <4738AAD8-2EFF-459C-B89B-248568B91E28@redhoundsoftware.com>
Content-Type: multipart/alternative; boundary="------------901F1F911BE2DFD61409B9F6"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/4K5i6gG_jfCTf7y24AgGP7YRv9M>
Subject: Re: [lamps] [CMP Updates] position of hashAlg in certStatus
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.29
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: Sun, 05 Sep 2021 19:10:33 -0000
On 05.09.21 20:45, Carl Wallace wrote: >> On Sep 5, 2021, at 10:49 AM, David von Oheimb <nl0@von-oheimb.de> wrote: >> >> On 05.09.21 16:26, Carl Wallace wrote: >>> Option 2 plays nicer with EXTENSIBILITY IMPLIED (definition from >>> X.680 is below). Not sure how often that is used though or how often >>> folks manually insert extensibility markers at the end of >>> definitions (I have on occasion but only in modules not controlled >>> by a standard and to mixed results). >>> >>> ‘ 12.4 The EXTENSIBILITY IMPLIED option is equivalent to the textual >>> insertion of an extension marker ("...") in the definition of each >>> type in the module for which it is permitted. The location of the >>> implied extension marker is the last position in the type where an >>> explicitly specified extension marker is allowed. The absence of >>> EXTENSIBILITY IMPLIED means that extensibility is only provided for >>> those types within the module where an extension marker is >>> explicitly present.’ >> Interesting. Yet the original definition (of CMPv2): >> >> CertStatus ::= SEQUENCE { >> certHash OCTET STRING, >> certReqId INTEGER, >> statusInfo PKIStatusInfo OPTIONAL >> >> } >> >> does not have such an extensibility option. >> So there is no advantage in terms of backward compatibility to have >> the new optional hashAlg field at the end (over having it anywhere). >> > > Not per the definition in the spec. As with Russ I would favor adding > to the end aside from the thin notion that it fits with non-standard > extensibility marker usage. I see - then let's go for that since there was already a consensus on it. Hendrik it also fine with proposal 2. Cheers, David >> On 05.09.21 16:00, Russ Housley wrote: >> >>> Option 1 and 2 are both fine to me. As I already said, I have a >>> slight preference for option 2. That is because the new field is at >>> the end. >> I know you wrote that, but this does not explain why in your view it >> would be (in total) slightly better to have the new field at the end, >> although, as I just wrote again, it has the disadvantage that the >> fields are not in logical order. >> In other words: what do you see as the advantage(s) overweighing the >> mentioned disadvantage? >> >> David >> >> >>>>> On Sep 5, 2021, at 9:52 AM, David von Oheimb <nl0@von-Oheimb.de >>>>> <mailto:nl0@von-Oheimb.de>> wrote: >>>>> >>>>> John, Russ, Carl, >>>>> >>>>> can you explain why you (to some extent) prefer proposal 2 over >>>>> proposal 1? >>>>> As mentioned, proposal 1 should be as backward-compatible as >>>>> proposal 2, >>>>> and proposal 1 has the clear conceptual advantage that the hashAlg >>>>> field comes before the field that it governs: certHash. >>>>> >>>>> David >>>>> >>>>> On 03.09.21 17:46, John Gray wrote: >>>>>> Hi Hendrik, >>>>>> >>>>>> Thanks for helping us to come to a consensus! >>>>>> >>>>>> You can add a ‘–‘ to proposal 3 from me as well. It actually >>>>>> changes the 4210 definition (when hashAlg) is not there, and >>>>>> would add an extra bit of complexity in the ASN.1 parsing to >>>>>> handle backwards compatibility for implementers that does not >>>>>> need to be there… >>>>>> >>>>>> Cheers, >>>>>> >>>>>> John Gray
- [lamps] [CMP Updates] position of hashAlg in cert… Brockhaus, Hendrik
- Re: [lamps] [CMP Updates] position of hashAlg in … Russ Housley
- Re: [lamps] [CMP Updates] position of hashAlg in … Brockhaus, Hendrik
- Re: [lamps] [CMP Updates] position of hashAlg in … Russ Housley
- Re: [lamps] [CMP Updates] position of hashAlg in … Blumenthal, Uri - 0553 - MITLL
- Re: [lamps] [CMP Updates] position of hashAlg in … Carl Wallace
- Re: [lamps] [CMP Updates] position of hashAlg in … Carl Wallace
- Re: [lamps] [CMP Updates] position of hashAlg in … Blumenthal, Uri - 0553 - MITLL
- Re: [lamps] [CMP Updates] position of hashAlg in … Carl Wallace
- Re: [lamps] [CMP Updates] position of hashAlg in … David von Oheimb
- Re: [lamps] [CMP Updates] position of hashAlg in … Carl Wallace
- Re: [lamps] [CMP Updates] position of hashAlg in … Brockhaus, Hendrik
- Re: [lamps] [CMP Updates] position of hashAlg in … Blumenthal, Uri - 0553 - MITLL
- Re: [lamps] [CMP Updates] position of hashAlg in … Russ Housley
- Re: [lamps] [CMP Updates] position of hashAlg in … Russ Housley
- Re: [lamps] [CMP Updates] position of hashAlg in … Salz, Rich
- Re: [lamps] [CMP Updates] position of hashAlg in … Blumenthal, Uri - 0553 - MITLL
- Re: [lamps] [CMP Updates] position of hashAlg in … David von Oheimb
- Re: [lamps] [CMP Updates] position of hashAlg in … Blumenthal, Uri - 0553 - MITLL
- Re: [lamps] [CMP Updates] position of hashAlg in … Salz, Rich
- Re: [lamps] [CMP Updates] position of hashAlg in … Russ Housley
- Re: [lamps] [CMP Updates] position of hashAlg in … Brockhaus, Hendrik
- Re: [lamps] [CMP Updates] position of hashAlg in … John Gray
- Re: [lamps] [CMP Updates] position of hashAlg in … John Gray
- Re: [lamps] [CMP Updates] position of hashAlg in … Blumenthal, Uri - 0553 - MITLL
- Re: [lamps] [CMP Updates] position of hashAlg in … David von Oheimb
- Re: [lamps] [CMP Updates] position of hashAlg in … Russ Housley
- Re: [lamps] [CMP Updates] position of hashAlg in … Carl Wallace
- Re: [lamps] [CMP Updates] position of hashAlg in … David von Oheimb
- Re: [lamps] [CMP Updates] position of hashAlg in … Carl Wallace
- Re: [lamps] [CMP Updates] position of hashAlg in … David von Oheimb
- Re: [lamps] [CMP Updates] position of hashAlg in … Russ Housley
- Re: [lamps] [CMP Updates] position of hashAlg in … Salz, Rich
- Re: [lamps] [CMP Updates] position of hashAlg in … Blumenthal, Uri - 0553 - MITLL