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

Carl Wallace <carl@redhoundsoftware.com> Sun, 05 September 2021 18:45 UTC

Return-Path: <carl@redhoundsoftware.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 002FD3A1116 for <spasm@ietfa.amsl.com>; Sun, 5 Sep 2021 11:45:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=redhoundsoftware.com
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 HMv0nduEi_2S for <spasm@ietfa.amsl.com>; Sun, 5 Sep 2021 11:45:09 -0700 (PDT)
Received: from mail-qt1-x834.google.com (mail-qt1-x834.google.com [IPv6:2607:f8b0:4864:20::834]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 191EA3A1115 for <spasm@ietf.org>; Sun, 5 Sep 2021 11:45:08 -0700 (PDT)
Received: by mail-qt1-x834.google.com with SMTP id b4so3847385qtx.0 for <spasm@ietf.org>; Sun, 05 Sep 2021 11:45:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhoundsoftware.com; s=google; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=SSaWvAgIQv6+kGh5JCkw75ZmvTG0/NpoGDR+QCAdJZg=; b=VLYfOpHwz6X5RuXaoI2RRFuoJp2rZ+UQCXLFnDsMXDR7TSD/Dox1WVcvNiwghlTFT1 fiTvOIGkVxKJ4UnEyLU6vVY3CbDJFprlqOMVam3l9V1Fxly5UayYCNhuPMSjCqaiKzcg 4jGglbAeKAan+mPxYMqjQGgQqg79rA3obwwvA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=SSaWvAgIQv6+kGh5JCkw75ZmvTG0/NpoGDR+QCAdJZg=; b=pbPy2TnCHw4vlLmPQ3uUiHyITTncmWWImXMBzm+B+eZCI4R94wnElKvzGQ67HNtYKW j1WxAp3hoG9lGxaXoh0uHSw9ImOTXpHJ9FRzw6LG19evl98/wIjhl4sUydEGenf02VT/ ZzwrJ2xuGY2iLsZAcL+GulRy80AGopR5RbQnNP8YbuMKh8CVH6etcaXJcLnhTbetQspT DDqZH5rT5jCxjEoWUUTtxZGO6e3sear33+wj1lZchFwrDnQdlCYdWB6WnR0AobVCGRck rCRWhqLEHxWsVr0KSJT9iiG2oUW5ZINaY+aqYJWRhzHpVD50CRqI3PD874L6LErRqiIR bHsg==
X-Gm-Message-State: AOAM530yEK0IUm7FqELWtShwpe4nz+B+0izRe3DAn8/N6KIWMy8sonCf Xzup/gwAegMK/03XmhjI6PYIDkk8f8WA24iv
X-Google-Smtp-Source: ABdhPJzfF9cJogwaSXT0+bmBqvAeuma506ifasAisK3NemGxEeAjVPRKP/xVQWzRIp6OlzjFW7mCPg==
X-Received: by 2002:a05:622a:199a:: with SMTP id u26mr7973391qtc.80.1630867506681; Sun, 05 Sep 2021 11:45:06 -0700 (PDT)
Received: from smtpclient.apple (pool-173-66-88-168.washdc.fios.verizon.net. [173.66.88.168]) by smtp.gmail.com with ESMTPSA id x29sm3803603qtv.74.2021.09.05.11.45.05 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 05 Sep 2021 11:45:05 -0700 (PDT)
Content-Type: multipart/signed; boundary=Apple-Mail-5415286B-0252-46AE-8D23-3AC6CB1DE2DF; protocol="application/pkcs7-signature"; micalg=sha-256
Content-Transfer-Encoding: 7bit
From: Carl Wallace <carl@redhoundsoftware.com>
Mime-Version: 1.0 (1.0)
Date: Sun, 5 Sep 2021 14:45:05 -0400
Message-Id: <4738AAD8-2EFF-459C-B89B-248568B91E28@redhoundsoftware.com>
References: <25dfec13-5c60-406f-7dbe-150f547ccc90@von-Oheimb.de>
Cc: Russ Housley <housley@vigilsec.com>, spasm@ietf.org
In-Reply-To: <25dfec13-5c60-406f-7dbe-150f547ccc90@von-Oheimb.de>
To: David von Oheimb <nl0@von-oheimb.de>
X-Mailer: iPhone Mail (18G82)
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/e-lxvQMZKFgZFwy7Nwndf11mwTo>
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 18:45:15 -0000


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

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