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

[Russ Housley <[e-mail]>]

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 <[e-mail]> wrote:
> 
> 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
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/spasm <https://www.ietf.org/mailman/listinfo/spasm>
> _______________________________________________
> Spasm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spasm