Re: [Technical Errata Reported] RFC3029 (6444)

Stefan looked into the one implementation we could find on GitHub, and the CHOICE of the Data item is determined by the ServiceType.  So, if we wanted to come up with a fix, it might be something similar to:

DVCSRequest ::= SEQUENCE  {
    requestInformation         DVCSRequestInformation,
    data                                ANY DEFINED BY DVCSRequestInformation.ServiceType,
    transactionIdentifier      GeneralName OPTIONAL
}

That said, if there is no imperest in implementation, I do not want to work too hard on this...

Russ


> On Mar 1, 2021, at 11:23 AM, Carlisle Adams <[email protected]> wrote:
> 
> Hi Russ, all,
>  
> I agree that these errors need fixing because there doesn’t seem to be an easy way to get around them otherwise.  I also agree with Stefan that this is probably an indication that DVCS was never widely implemented…  L
>  
> Carlisle.
>  
>  
> From: Russ Housley <[email protected] <mailto:[email protected]>> 
> Sent: February-28-21 5:26 PM
> To: Erwann Abalea <[email protected] <mailto:[email protected]>>
> Cc: Roman D. Danyliw <[email protected] <mailto:[email protected]>>; Ben Kaduk <[email protected] <mailto:[email protected]>>; Stefan Santesson <[email protected] <mailto:[email protected]>>; IETF PKIX <[email protected] <mailto:[email protected]>>; Carlisle Adams <[email protected] <mailto:[email protected]>>
> Subject: Re: [pkix] [Technical Errata Reported] RFC3029 (6444)
>  
> Attention : courriel externe | external email
> Erwann:
>  
> Le sam. 27 févr. 2021 à 08:45, Russ Housley <[email protected] <mailto:[email protected]>> a écrit :
> I guess I should have held off on reporting this ASN.1 error.  Once I corrected it, I discovered two errors that I do not know how to fix.
> 
> There is an implementation somewhere because Appendix F contains examples.  I do not know how the implementer got around these two problems.
> 
> 
> PROBLEM 1:
> 
> CertEtcToken ::= CHOICE {
>      certificate                  [0] IMPLICIT Certificate ,
>      esscertid                    [1] ESSCertId ,
>      pkistatus                    [2] IMPLICIT PKIStatusInfo ,
>      assertion                    [3] ContentInfo ,
>      crl                          [4] IMPLICIT CertificateList,
>      ocspcertstatus               [5] IMPLICIT CertStatus,
>      oscpcertid                   [6] IMPLICIT CertId ,
>      oscpresponse                 [7] IMPLICIT OCSPResponse,
>      capabilities                 [8] SMIMECapabilities,
>      extension                    Extension{{ExtensionSet}}
> }
> 
> CertEtcToken is a CHOICE with tags 0 through 8, but CertStatus CHOICE with tags 0 through 2.  You cannot nest a CHOICE in another CHOICE is the IMPLICIT tags overlap.
> 
> The use of EXPLICIT tagging would have solved the problem, but the authors clearly preferred IMPLICIT tags.
>  
> Here, it's easy. The outermost IMPLICIT tag is transformed into an EXPLICIT one by the ASN.1 compiler (it will probably emit a warning, though).
>  
> Yes, I am aware of that possibility of fixing the specification, but it is unclear what an implementer would do with a ASN.1 module with compilation errors, or a warning that inserts a EXPLICIT.
> 
> 
>  
> PROBLEM 2
> 
> DigestInfo ::= SEQUENCE {
>     digestAlgorithm   DigestAlgorithmIdentifier,
>     digest            Digest
> }
> 
> Data ::= CHOICE {
>       message           OCTET STRING ,
>       messageImprint    DigestInfo,
>       certs             SEQUENCE SIZE (1..MAX) OF
>                             TargetEtcChain
> }
> 
> DigestInfo is a SEQUENCE, and certs is a SEQUENCE, so the two have the same tag.  A recipient cannot tell which one the sender intended.
>  
> For this one, there's clearly no solution. Tagging would have solved it (any kind of tagging mode), but it's missing.
>  
> Indeed, at lease one of the SEQUENCE needs a tag.
>  
> Russ

_______________________________________________
pkix mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pkix