Re: [pkix] [Technical Errata Reported] RFC3029 (6444)

Stefan Santesson <> Mon, 01 March 2021 22:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6589A3A246D for <>; Mon, 1 Mar 2021 14:53:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id UJhDwCQW9L-w for <>; Mon, 1 Mar 2021 14:53:37 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BAA933A246A for <>; Mon, 1 Mar 2021 14:53:36 -0800 (PST)
Received: from (localhost []) by (Postfix) with ESMTP id 390152468A3F for <>; Mon, 1 Mar 2021 23:53:31 +0100 (CET)
Received: from (unknown []) by (Postfix) with ESMTP id 191DA2E2980C; Mon, 1 Mar 2021 23:53:31 +0100 (CET)
Received: from (unknown []) by (Postfix) with ESMTP id 13EC01CE61F0; Mon, 1 Mar 2021 23:53:31 +0100 (CET)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by ( []) (amavisd-new, port 10024) with LMTP id Myg1xFAyqbMx; Mon, 1 Mar 2021 23:53:29 +0100 (CET)
X-Loopia-Auth: user
Received: from [] (unknown []) (Authenticated sender: by (Postfix) with ESMTPSA id 61AAA1CE61AF; Mon, 1 Mar 2021 23:53:29 +0100 (CET)
User-Agent: Microsoft-MacOutlook/16.46.21021202
Date: Mon, 01 Mar 2021 23:53:28 +0100
From: Stefan Santesson <>
To: Russ Housley <>
CC: Carlisle Adams <>, Erwann Abalea <>, "Roman D. Danyliw" <>, Ben Kaduk <>, IETF PKIX <>
Message-ID: <>
Thread-Topic: [pkix] [Technical Errata Reported] RFC3029 (6444)
References: <> <> <> <> <YTXPR0101MB110157FF4F373702155B2361A29A9@YTXPR0101MB1101.CANPRD01.PROD.OUTLOOK.COM> <> <>
In-Reply-To: <>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3697487609_786215115"
Archived-At: <>
Subject: Re: [pkix] [Technical Errata Reported] RFC3029 (6444)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: PKIX Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 01 Mar 2021 22:53:40 -0000



I concede to your superior ASN.1 knowledge here.


Can this be fixed without changing the protocol in a way that changes the bits on the wire?

I assume that a change that alters the bits on the wire requires a regular protocol update with a new ASN.1 module.


Stefan Santesson 


From: Russ Housley <>
Date: Monday, 1 March 2021 at 23:33
To: Stefan Santesson <>
Cc: Carlisle Adams <>ca>, Erwann Abalea <>om>, "Roman D. Danyliw" <>rg>, Ben Kaduk <>du>, IETF PKIX <>
Subject: Re: [pkix] [Technical Errata Reported] RFC3029 (6444)




The addition of this definition solves the "Integer" concern:


                Integer ::= INTEGER


CRLDistributionPoints compiles without errors or warnings for me.


This situation is not two nested CHOICES, so it is not quite the same.  Here, the CHOICE followed by a SEQUENCE followed by a CHOICE is not a problem.


For example:

   value DistributionPoint ::= {

     distributionPoint fullName: {

       dNSName "",

       uniformResourceIdentifier ""


     reasons '011111000'B



DER-Encodes to:

   3031A02B A029820F 7777772E 6578616D 706C652E 636F6D86 16687474 703A2F2F

   7777772E 6578616D 706C652E 636F6D81 02027C



DistributionPoint SEQUENCE: tag = [UNIVERSAL 16] constructed; length = 49

  distributionPoint : tag = [0] constructed; length = 43

    DistributionPointName CHOICE

      fullName GeneralNames SEQUENCE OF: tag = [0] constructed; length = 41

        GeneralName CHOICE

          dNSName IA5String: tag = [2] primitive; length = 15


        GeneralName CHOICE

          uniformResourceIdentifier IA5String: tag = [6] primitive; length = 22


  reasons ReasonFlags BIT STRING: tag = [1] primitive; length = 2





On Mar 1, 2021, at 4:53 PM, Stefan Santesson <> wrote:


I think there is a need for clarification and to correct the “Integer -> INTEGER” issue.


But I don’t think it is appropriate to change any ASN.1 to attempt to fix neither the implicit tagging or the ambiguity of the “Data” type.


Here is my motivation.

On the nested implicit tagged object we have a similar issue with Distribution Point in RFC 5280:


   CRLDistributionPoints ::= SEQUENCE SIZE (1..MAX) OF DistributionPoint


   DistributionPoint ::= SEQUENCE {

        distributionPoint       [0]     DistributionPointName OPTIONAL,

        reasons                 [1]     ReasonFlags OPTIONAL,

        cRLIssuer               [2]     GeneralNames OPTIONAL }


   DistributionPointName ::= CHOICE {

        fullName                [0]     GeneralNames,

        nameRelativeToCRLIssuer [1]     RelativeDistinguishedName }


Here we have the Implicitly tagged DistributionPointName containing the implicitly tagged choice of GeneralNames or RelativeDistinguishedName.

I’m not an ASN.1 expert, but this is solved by implementations by converting the outer tag to an explicit tag.

E.g. when GeneralNames is used it is represented by [0][0]{GeneralNames length and value}


I assume that the same principle must apply to CertEtcToken.


On the “Data” structure it turns out that there are 4 different service types:


   - Certification of Possession of Data (cpd),

   - Certification of Claim of Possession of Data (ccpd),

   - Validation of Digitally Signed Document (vsd), and

   - Validation of Public Key Certificates (vpkc).

Where cpd and vsd always use message, ccpd always use messageImprint and vpkc always use sequence of TargetEtcChain


So, even if this is not great, it is still possible to implement the protocol, given that you know what service that use the “Data” type.

This is in fact how the implementation pointed out by Russ implements this:

Se the ”getInstance()” function at line 90:


My conclusion is that the protocol has design flaws, but it is not the task of an errata to fix design flaws.

Fixing design flaws is the task of a protocol update. But I don’t think there is a good motivation to put the efforts into releasing a new version of this protocol.

As it is, the protocol is at least implementable, demonstrated by the linked code.



Stefan Santesson 


From: Carlisle Adams <>
Date: Monday, 1 March 2021 at 17:23
To: Russ Housley <>om>, Erwann Abalea <>
Cc: "Roman D. Danyliw" <>rg>, Ben Kaduk <>du>, Stefan Santesson <>om>, IETF PKIX <>
Subject: RE: [pkix] [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…  L





From: Russ Housley <> 
Sent: February-28-21 5:26 PM
To: Erwann Abalea <>
Cc: Roman D. Danyliw <>rg>; Ben Kaduk <>du>; Stefan Santesson <>om>; IETF PKIX <>rg>; Carlisle Adams <>
Subject: Re: [pkix] [Technical Errata Reported] RFC3029 (6444)


Attention : courriel externe | external email



Le sam. 27 févr. 2021 à 08:45, Russ Housley <> 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.


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.



DigestInfo ::= SEQUENCE {
    digestAlgorithm   DigestAlgorithmIdentifier,
    digest            Digest

Data ::= CHOICE {
      message           OCTET STRING ,
      messageImprint    DigestInfo,
      certs             SEQUENCE SIZE (1..MAX) OF

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.