Re: [Technical Errata Reported] RFC3029 (6444)

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

Carlisle.


From: Russ Housley <[email protected]>
Sent: February-28-21 5:26 PM
To: Erwann Abalea <[email protected]>
Cc: Roman D. Danyliw <[email protected]>; Ben Kaduk <[email protected]>; Stefan Santesson <[email protected]>; IETF PKIX <[email protected]>; Carlisle Adams <[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