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

[Carl Wallace <[e-mail]>]

> On Sep 5, 2021, at 10:49 AM, David von Oheimb <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> 
>>>>> Sent: Friday, September 3, 2021 11:25 AM
>>>>> To: Russ Housley <[e-mail]>; David von Oheimb <[e-mail]>; Carl Wallace <[e-mail]>; Uri Blumenthal <[e-mail]>; John Gray <[e-mail]>
>>>>> Cc: [e-mail]
>>>>> 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