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, 5 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