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

Carl Wallace <carl@redhoundsoftware.com> Tue, 02 March 2021 00:45 UTC

Return-Path: <carl@redhoundsoftware.com>
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB7353A2610 for <pkix@ietfa.amsl.com>; Mon, 1 Mar 2021 16:45:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=redhoundsoftware.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07N_4iy8wcoh for <pkix@ietfa.amsl.com>; Mon, 1 Mar 2021 16:45:45 -0800 (PST)
Received: from mail-qt1-x82f.google.com (mail-qt1-x82f.google.com [IPv6:2607:f8b0:4864:20::82f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8F9C3A260F for <pkix@ietf.org>; Mon, 1 Mar 2021 16:45:44 -0800 (PST)
Received: by mail-qt1-x82f.google.com with SMTP id o34so13566271qtd.11 for <pkix@ietf.org>; Mon, 01 Mar 2021 16:45:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhoundsoftware.com; s=google; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :references:in-reply-to:mime-version; bh=Xzj8nLDmldT7Cl8mLgr5HtthRaIwOeY7jM6m2RnnB3I=; b=K/FMBKyqgXwp7I/MHWPjLU7Gyv7WPGF58UD8DfPQMbY8FXlZkjfLC4PKSMbCJ4OGvn +x8zjWBWKBrgWRcIEXF8Pya6wIr6M/o7gBYkPCay7gItqjPPxULHubAM590dH0HzMbLy xZvqwJl7st9fhc/AjhtWDVF0sOioUKxzyapdk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version; bh=Xzj8nLDmldT7Cl8mLgr5HtthRaIwOeY7jM6m2RnnB3I=; b=avHTbqQiyZi8Habz39Ih7Fcio+Xw6ZjIs+2X+rDdITTPU62OJmk6GIsDMdFFDwNoPL 0CayKjfA72mRIr3FuLGGw3H3PAMr7D4RK+k8YXhAB4b0rtYXQbwjdsD2DHngahL2jBV7 Ri6vyum57W6gh5o5WtDsJ56kzMwqFdpfCq46ARzDmjeCM7p1YTK1Le3yPk5Bukt0MYEH bdQSintYsXpXBY7m64Tl8WHrT3gdiBa1AHG2Vdrzu5KhGTqWhGMJRiGFBA5ajX7PljQr 555TNU5QO0/QcQ5MXIpBthvjLfGrLj+DvblHPyo745YfZBPJxgBRNRn0iZTbbsSiYBUj nhJA==
X-Gm-Message-State: AOAM531ISGGjKJWC5mg3W/OFtsbckTqFe3JucjP/u+4HTGCUHlZYQOSi OblFsENjWnnTasl7IhlxEO+bqg==
X-Google-Smtp-Source: ABdhPJznI1BXwkV9vhwOxVbvj4p11RuP6NISUAS1GaiUYvdrNgUPYkfgur3YL3GEdNCiH+QOcTCQ/Q==
X-Received: by 2002:a05:622a:11:: with SMTP id x17mr16157199qtw.195.1614645942863; Mon, 01 Mar 2021 16:45:42 -0800 (PST)
Received: from [192.168.2.16] (pool-108-18-106-102.washdc.fios.verizon.net. [108.18.106.102]) by smtp.gmail.com with ESMTPSA id e190sm14039167qkd.122.2021.03.01.16.45.42 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 01 Mar 2021 16:45:42 -0800 (PST)
User-Agent: Microsoft-MacOutlook/16.46.21021202
Date: Mon, 01 Mar 2021 19:45:41 -0500
From: Carl Wallace <carl@redhoundsoftware.com>
To: Stefan Santesson <stefan@aaa-sec.com>, Carlisle Adams <cadams@uottawa.ca>, Russ Housley <housley@vigilsec.com>, Erwann Abalea <eabalea@gmail.com>
CC: "Roman D. Danyliw" <rdd@cert.org>, IETF PKIX <pkix@ietf.org>, Ben Kaduk <kaduk@mit.edu>
Message-ID: <E5665C1A-69F0-4DDD-985B-DC23871B794E@redhoundsoftware.com>
Thread-Topic: [pkix] [Technical Errata Reported] RFC3029 (6444)
References: <20210226205457.C1E5FF40764@rfc-editor.org> <109BE558-3363-4030-A906-E329B7ED28B4@vigilsec.com> <CA+i=0E4K6nWAAfiuuQ-uOR+9+9G+9=T9J=EMmqqP7-oA00tP6w@mail.gmail.com> <27430A71-1D03-4704-8D31-3412FF922CD5@vigilsec.com> <YTXPR0101MB110157FF4F373702155B2361A29A9@YTXPR0101MB1101.CANPRD01.PROD.OUTLOOK.COM> <FBE6F96D-CF0B-4952-A07F-03B220DB738A@aaa-sec.com> <71DF4978-5886-4488-BAC9-10BE17CB1D73@redhoundsoftware.com>
In-Reply-To: <71DF4978-5886-4488-BAC9-10BE17CB1D73@redhoundsoftware.com>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3697472742_1487325089"
Archived-At: <https://mailarchive.ietf.org/arch/msg/pkix/wrJEKqpYTbPy6rOXWlmW0OUAGik>
Subject: Re: [pkix] [Technical Errata Reported] RFC3029 (6444)
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: PKIX Working Group <pkix.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pkix>, <mailto:pkix-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pkix/>
List-Post: <mailto:pkix@ietf.org>
List-Help: <mailto:pkix-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pkix>, <mailto:pkix-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Mar 2021 00:45:48 -0000

Bah. Except that in the DVCS there was an IMPLICIT other than the module default that was in effect. That is likely why Russ saw the compilation error. 

 

ocspcertstatus               [5] IMPLICIT CertStatus,

 

And of course the side-by-side SEQUENCE issue is unrelated. 

 

From: Carl Wallace <carl@redhoundsoftware.com>
Date: Monday, March 1, 2021 at 7:40 PM
To: Stefan Santesson <stefan@aaa-sec.com>om>, Carlisle Adams <cadams@uottawa.ca>ca>, Russ Housley <housley@vigilsec.com>om>, Erwann Abalea <eabalea@gmail.com>
Cc: "Roman D. Danyliw" <rdd@cert.org>rg>, IETF PKIX <pkix@ietf.org>rg>, Ben Kaduk <kaduk@mit.edu>
Subject: Re: [pkix] [Technical Errata Reported] RFC3029 (6444)

 

The IMPLICIT default for the module containing the DistributionPointName definition does not apply to these CHOICE types. See this snip from X.680:

 

“30.6 The tagging construction specifies explicit tagging if any of the following holds:

a) the "Tag EXPLICIT Type" alternative is used;

b) the "Tag Type" alternative is used and the value of "TagDefault" for the module is either EXPLICIT

TAGS or is empty;

c) the "Tag Type" alternative is used and the value of "TagDefault" for the module is IMPLICIT TAGS or

AUTOMATIC TAGS, but the type defined by "Type" is an untagged choice type, an untagged open type, or

an untagged "DummyReference" (see ITU-T Rec. X.683 | ISO/IEC 8824-4, 8.3).”

 

Option c) is in effect. The “untagged choice type” lingo is confusing on first read and the term is not defined but “tagged type” is defined:

 

“30.1 The notation for a tagged type shall be "TaggedType":

TaggedType ::=

                Tag Type

                                | Tag IMPLICIT Type 

                                | Tag EXPLICIT Type”

 

Since the CHOICE definitions here are not TaggedTypes, EXPLICIT is in effect.

 

The DVCS module also uses an IMPLICIT default and is not using TaggedTypes, so same would apply there too. 

 

From: pkix <pkix-bounces@ietf.org> on behalf of Stefan Santesson <stefan@aaa-sec.com>
Date: Monday, March 1, 2021 at 4:54 PM
To: Carlisle Adams <cadams@uottawa.ca>ca>, Russ Housley <housley@vigilsec.com>om>, Erwann Abalea <eabalea@gmail.com>
Cc: "Roman D. Danyliw" <rdd@cert.org>rg>, IETF PKIX <pkix@ietf.org>rg>, Ben Kaduk <kaduk@mit.edu>
Subject: Re: [pkix] [Technical Errata Reported] RFC3029 (6444)

 

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: https://github.com/a-i-b/jnotary/blob/master/dvcs/src/main/java/org/jnotary/dvcs/Data.java

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 <cadams@uottawa.ca>
Date: Monday, 1 March 2021 at 17:23
To: Russ Housley <housley@vigilsec.com>om>, Erwann Abalea <eabalea@gmail.com>
Cc: "Roman D. Danyliw" <rdd@cert.org>rg>, Ben Kaduk <kaduk@mit.edu>du>, Stefan Santesson <stefan@aaa-sec.com>om>, IETF PKIX <pkix@ietf.org>
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

 

Carlisle.

 

 

From: Russ Housley <housley@vigilsec.com> 
Sent: February-28-21 5:26 PM
To: Erwann Abalea <eabalea@gmail.com>
Cc: Roman D. Danyliw <rdd@cert.org>rg>; Ben Kaduk <kaduk@mit.edu>du>; Stefan Santesson <stefan@aaa-sec.com>om>; IETF PKIX <pkix@ietf.org>rg>; Carlisle Adams <cadams@site.uottawa.ca>
Subject: Re: [pkix] [Technical Errata Reported] RFC3029 (6444)

 

Attention : courriel externe | external email

Erwann:

 

Le sam. 27 févr. 2021 à 08:45, Russ Housley <housley@vigilsec.com> 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 pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix