Re: [lamps] [CMP Updates] position of hashAlg in certStatus

David von Oheimb <nl0@von-Oheimb.de> Sun, 05 September 2021 14:49 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 97EC93A1AD5 for <spasm@ietfa.amsl.com>; Sun, 5 Sep 2021 07:49:24 -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 qbV37trln_Qv for <spasm@ietfa.amsl.com>; Sun, 5 Sep 2021 07:49:19 -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 9C7AA3A174B for <spasm@ietf.org>; Sun, 5 Sep 2021 07:49:18 -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 14639421798; Sun, 5 Sep 2021 16:49:15 +0200 (CEST)
To: Carl Wallace <carl@redhoundsoftware.com>, Russ Housley <housley@vigilsec.com>
Cc: spasm@ietf.org
References: <92DF4EC6-4075-4ED2-8106-048072A26C6F@vigilsec.com> <E0F9FA03-0512-4C93-9992-80E93EDB2DF5@redhoundsoftware.com>
From: David von Oheimb <nl0@von-Oheimb.de>
Message-ID: <25dfec13-5c60-406f-7dbe-150f547ccc90@von-Oheimb.de>
Date: Sun, 5 Sep 2021 16:49:13 +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: <E0F9FA03-0512-4C93-9992-80E93EDB2DF5@redhoundsoftware.com>
Content-Type: multipart/alternative; boundary="------------69F3DB6B4003BB7841D01099"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/n-s8M16nV17J0wzVFHBsNJv4uPs>
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 14:49:25 -0000

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).


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
>>>>  
>>>>  
>>>>  
>>>> *From:* Brockhaus, Hendrik <hendrik.brockhaus@siemens.com> 
>>>> *Sent:* Friday, September 3, 2021 11:25 AM
>>>> *To:* Russ Housley <housley@vigilsec.com>om>; David von
>>>> Oheimb <nl0@von-Oheimb.de>de>; Carl
>>>> Wallace <carl@redhoundsoftware.com>om>; Uri
>>>> Blumenthal <uri@ll.mit.edu>du>; John Gray <John.Gray@entrust.com>
>>>> *Cc:* spasm@ietf.org
>>>> *Subject:* [EXTERNAL] AW: [lamps] [CMP Updates] position of hashAlg
>>>> in certStatus
>>>>  
>>>> WARNING: This email originated outside of Entrust.
>>>> DO NOT CLICK links or attachments unless you trust the sender and
>>>> know the content is safe.
>>>> ------------------------------------------------------------------------
>>>> All:
>>>>  
>>>> I am still trying to find a conclusion the majority can live with. :-)
>>>>  
>>>> To sum up:
>>>>  
>>>> CMP V1 (RFC 2510) does not define CertStatus at all.
>>>> CMP V2 (RFC 4210) defines CertStatus as follows:
>>>>    CertStatus ::= SEQUENCE {
>>>>       certHash    OCTET STRING,
>>>>       certReqId   INTEGER,
>>>>       statusInfo  PKIStatusInfo OPTIONAL
>>>>       }
>>>> Proposals for adding hashAlg for CMP V3 syntax as defined in
>>>> draft-ietf-lamps-cmp-updates.
>>>> Proposal 1 (current proposal in draft-ietf-lamps-cmp-updates-12):
>>>>    CertStatus ::= SEQUENCE {
>>>>       hashAlg [0]  AlgorithmIdentifier OPTIONAL
>>>>       certHash     OCTET STRING,
>>>>       certReqId    INTEGER,
>>>>       statusInfo   PKIStatusInfo OPTIONAL,
>>>>       }
>>>> Proposal 2 (proposal made by John):
>>>>    CertStatus ::= SEQUENCE {
>>>>       certHash     OCTET STRING,
>>>>       certReqId    INTEGER,
>>>>       statusInfo   PKIStatusInfo OPTIONAL,
>>>>       hashAlg [0]  AlgorithmIdentifier OPTIONAL
>>>>       }
>>>> Proposal 3 (preferred by Uri):
>>>>    CertStatus ::= SEQUENCE {
>>>>       certHash       OCTET STRING,
>>>>       certReqId      INTEGER,
>>>>       statusInfo [0] PKIStatusInfo OPTIONAL,
>>>>       hashAlg    [1] AlgorithmIdentifier OPTIONAL
>>>>       }
>>>> All proposals compile and therefore technically work.
>>>>  
>>>> As already stated, I can also live with proposal 2. But I dislike
>>>> proposal 3, as it changes more than necessary and we look for
>>>> limited changes to CMP V2.
>>>>  
>>>> Reviewing the email exchange, I see the following preferences.
>>>> Proposal 1
>>>> + David, Hendrik
>>>> - John, Uri
>>>> Proposal 2
>>>> + John, Russ, Carl(, Hendrik)
>>>> - Uri
>>>> Proposal 3
>>>> + Uri
>>>> - Russ, Rich, David, Hendrik
>>>>  
>>>> Summing up, I see a clear preference for proposal 2.
>>>> Please let me know if I misunderstood anyone's preference.
>>>>  
>>>> Hendrik