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

Russ Housley <housley@vigilsec.com> Mon, 01 March 2021 16:59 UTC

Return-Path: <housley@vigilsec.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 B04A23A1FA1 for <pkix@ietfa.amsl.com>; Mon, 1 Mar 2021 08:59:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 p1rkf1AznKY0 for <pkix@ietfa.amsl.com>; Mon, 1 Mar 2021 08:59:03 -0800 (PST)
Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 975D23A1F9D for <pkix@ietf.org>; Mon, 1 Mar 2021 08:59:03 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 07FDB300B6F for <pkix@ietf.org>; Mon, 1 Mar 2021 11:59:00 -0500 (EST)
X-Virus-Scanned: amavisd-new at mail.smeinc.net
Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id ijqepVtJC64q for <pkix@ietf.org>; Mon, 1 Mar 2021 11:58:55 -0500 (EST)
Received: from [192.168.1.161] (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id 6D1A6300B1E; Mon, 1 Mar 2021 11:58:55 -0500 (EST)
From: Russ Housley <housley@vigilsec.com>
Message-Id: <2FD81F56-E419-4FCE-AD2C-A657490275D8@vigilsec.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_9EAE2F47-67C5-4FCF-A335-8DFD8E53966F"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\))
Date: Mon, 1 Mar 2021 11:58:55 -0500
In-Reply-To: <YTXPR0101MB110157FF4F373702155B2361A29A9@YTXPR0101MB1101.CANPRD01.PROD.OUTLOOK.COM>
Cc: Erwann Abalea <eabalea@gmail.com>, "Roman D. Danyliw" <rdd@cert.org>, Ben Kaduk <kaduk@mit.edu>, Stefan Santesson <stefan@aaa-sec.com>, IETF PKIX <pkix@ietf.org>
To: Carlisle Adams <cadams@uottawa.ca>
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>
X-Mailer: Apple Mail (2.3445.104.17)
Archived-At: <https://mailarchive.ietf.org/arch/msg/pkix/cgvuwg_spQcKFbn9AKDpPRVmuCo>
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: Mon, 01 Mar 2021 16:59:06 -0000

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 <cadams@uottawa.ca> 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 <housley@vigilsec.com <mailto:housley@vigilsec.com>> 
> Sent: February-28-21 5:26 PM
> To: Erwann Abalea <eabalea@gmail.com <mailto:eabalea@gmail.com>>
> Cc: Roman D. Danyliw <rdd@cert.org <mailto:rdd@cert.org>>; Ben Kaduk <kaduk@mit.edu <mailto:kaduk@mit.edu>>; Stefan Santesson <stefan@aaa-sec.com <mailto:stefan@aaa-sec.com>>; IETF PKIX <pkix@ietf.org <mailto:pkix@ietf.org>>; Carlisle Adams <cadams@site.uottawa.ca <mailto: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 <mailto: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