Subject: Re: [lamps] Proposal for errata to RFC 2634 and 5035 - Re: Need clarification on ESS

From: David von Oheimb <[email-masked]>
Date: Thu, 15 Apr 2021 16:28:43 +0200

Some 3+ weeks ago I provided as requested the below text for discussion.
So far I did not see any reaction on it. How best to proceed?

    David

On 23.03.21 08:57, David von Oheimb wrote:
>
> Hi Ben et al.,
>
> according to your feedback on how to (re-)structure the errata texts
> to be discussed here before they get submitted,
> here is an update of my proposal, which essentially is the same as
> before but in the required format.
>
>     David
>
>
>     Proposal for erratum to RFC 2634
>
>
>       Section:
>
> 5.4
>
>
>       Original text:
>
>     The first certificate identified in the sequence of certificate
>     identifiers MUST be the certificate used to verify the signature.
>     [....]
>     If more than one certificate is present in the sequence of
>     ESSCertIDs, the certificates after the first one limit the set of
>     authorization certificates that are used during signature validation.
>
>
>       Corrected text:
>
>     The sequence of certificate identifiers MUST contain at least one
> element.
>     The first certificate identified MUST be the certificate used to
> verify the signature.
>     [... (unchanged)]
>     If more than one certificate identifier is present in the sequence
> of ESSCertIDs,
>     all certificates referenced there MUST be part of the signature
> validation chain.
>
>
>       Notes:
>
> Some aspects of the 'certs' field of a SigningCertificate attribute:
>
>    SigningCertificate ::=  SEQUENCE {
>        certs        SEQUENCE OF ESSCertID,
>        policies     SEQUENCE OF PolicyInformation OPTIONAL
>    }
> described in the sentences quoted above are very vague.
> This lead to major confusion and wrong implementations.
> As meanwhile has been clarified, they should be re-phrased;
> see suggested new version above.
>
> (One may further mandate/clarify that the certificate identifiers must
> be given in the same order
> as they are expected in the validation chain, but I think this is not
> important because
> the order should not play a critical role and will be determined by
> the validation chain anyway.)
>
>
>     Proposal for erratum to RFC 5035
>
>
>       Section:
>
> 3, which inserts new section 5.4.1
>
>
>       Original text:
>
>  certs
>       contains the list of certificates that are to be used in
>       validating the message.
>       [...]
>       If more than one certificate is present, subsequent certificates
>       limit the set of certificates that are used during validation.
>
>
>       Corrected text:
>
>  certs
>     contains the list of certificates that are to be used in
>     validating the message. It MUST contain at least one element.
>     [... (unchanged)]
>     If more than one certificate identifier is present in the sequence
> of ESSCertIDv2s,
>     all certificates referenced there MUST be part of the signature
> validation chain.
>
>
>       Notes:
>
> Some aspects of the 'certs' field of a SigningCertificateV2 attribute:
>
>    SigningCertificateV2 ::=  SEQUENCE {
>        certs        SEQUENCE OF ESSCertIDv2,
>        policies     SEQUENCE OF PolicyInformation OPTIONAL
>    }
> described in the sentences quoted above are rather vague.
> This lead to major confusion and wrong implementations.
> As meanwhile has been clarified, they should be re-phrased;
> see suggested new version above.
>
> (One may further mandate/clarify that the certificate identifiers must
> be given in the same order
> as they are expected in the validation chain, but I think this is not
> important because
> the order should not play a critical role and will be determined by
> the validation chain anyway.)
>
>
>
>
> On 18.03.21 06:57, Benjamin Kaduk wrote:
>> Hi David,
>>
>> On Wed, Mar 17, 2021 at 09:09:08AM +0100, David von Oheimb wrote:
>>> On 14.03.21 23:17, Russ Housley wrote:
>>>
>>>> I do not find the existing text as confusing as you do.  
>>> I agree in the sense that I see the topic of the 2nd clarification less
>>> confusing and critical than the 1st one
>>> because the question whether a ESSCertID{,v2} list shall contain at
>>> least one entry only influences
>>> the corner case whether signingCertificate{,V2} attributes can be used
>>> to express policy constraints only.
>>>
>>> Yet the 1st vagueness, whether the ESSCertID{,v2} list is supposed to
>>> mean a lower or upper bound of the allowed certs in the validation
>>> chain, is major.
>>> As mentioned, several implementations including Bouncy Castle simply
>>> ignore the case that that ESSCertID{,v2} contains more than one element, and
>>> the only implementation that is known to take care of them, in OpenSSL,
>>> has been confused and thus wrong from its beginning nearly two decades ago!
>>>
>>>> That said, I would suggest getting review of proposed replacement text
>>>> on the mail list before posting an errata.
>>> 1. Here is my proposal for an erratum to RFC 2634:
>>> [
>> [...]
>>
>> While your formulations are useful for the mailing-list discussion, when it
>> comes time to actually submit errata reports they will need to be
>> formulated a little differently.
>>
>> The form just has (in addition to some other metadata) the section of the
>> document, "original text", "corrected text", and "notes".  So all the
>> commentary will need to be in one place, and after the OLD/NEW text.  So,
>> with this digression over, we should continue to review the OLD/NEW text
>> and get support for the specific NEW texts. :)
>>
>> Thanks,
>>
>> Ben
>
> _______________________________________________
> Spasm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spasm

---

From: Russ Housley <[email-masked]>
Date: Thu, 15 Apr 2021 10:52:40 -0400

David:

I think you should submit the errata at https://www.rfc-editor.org/errata.php

I encourage you to put the whole text in the original and new so that the inline errata tool has a hope of doing the right thing.

Russ

> On Apr 15, 2021, at 10:28 AM, David von Oheimb <[email-masked]> wrote:
> 
>> according to your feedback on how to (re-)structure the errata texts to be discussed here before they get submitted,
>> here is an update of my proposal, which essentially is the same as before but in the required format.
>> 
>>     David
>> 
>> 
>>     The sequence of certificate identifiers MUST contain at least one element.
>>     The first certificate identified MUST be the certificate used to verify the signature.
>>     [... (unchanged)]
>>     If more than one certificate identifier is present in the sequence of ESSCertIDs,
>>     all certificates referenced there MUST be part of the signature validation chain.
>> 
>> Notes:
>> 
>> (One may further mandate/clarify that the certificate identifiers must be given in the same order 
>> as they are expected in the validation chain, but I think this is not important because 
>> the order should not play a critical role and will be determined by the validation chain anyway.)
>> 
>>     If more than one certificate identifier is present in the sequence of ESSCertIDv2s,
>>     all certificates referenced there MUST be part of the signature validation chain.
>> 
>> Notes:
>> 
>> (One may further mandate/clarify that the certificate identifiers must be given in the same order 
>> as they are expected in the validation chain, but I think this is not important because 
>> the order should not play a critical role and will be determined by the validation chain anyway.)
>> 
>> 
>> 
>> 
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/spasm <https://www.ietf.org/mailman/listinfo/spasm>

---

From: David von Oheimb <[email-masked]>
Date: Wed, 28 Apr 2021 20:14:18 +0200

Thanks Russ.

Finally I've done this, in the way you advised.
This is the outcome:

  * https://www.rfc-editor.org/errata/eid6562
    https://www.rfc-editor.org/errata/eid6563

    David

On 15.04.21 16:52, Russ Housley wrote:
> I encourage you to put the whole text in the original and new so that
> the inline errata tool has a hope of doing the right thing.
>
> Russ
>
>
>> On Apr 15, 2021, at 10:28 AM, David von Oheimb <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>