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

Stefan Santesson <stefan@aaa-sec.com> Sun, 28 February 2021 19:15 UTC

Return-Path: <stefan@aaa-sec.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 E75C33A1AF3 for <pkix@ietfa.amsl.com>; Sun, 28 Feb 2021 11:15:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.004
X-Spam-Level:
X-Spam-Status: No, score=0.004 tagged_above=-999 required=5 tests=[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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CRxHTYiZq_uI for <pkix@ietfa.amsl.com>; Sun, 28 Feb 2021 11:15:27 -0800 (PST)
Received: from smtp.outgoing.loopia.se (smtp.outgoing.loopia.se [93.188.3.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 808BC3A1AF1 for <pkix@ietf.org>; Sun, 28 Feb 2021 11:15:27 -0800 (PST)
Received: from s807.loopia.se (localhost [127.0.0.1]) by s807.loopia.se (Postfix) with ESMTP id 46DEC6F72CC for <pkix@ietf.org>; Sun, 28 Feb 2021 20:15:23 +0100 (CET)
Received: from s645.loopia.se (unknown [172.22.191.5]) by s807.loopia.se (Postfix) with ESMTP id 26A162E276FF; Sun, 28 Feb 2021 20:15:23 +0100 (CET)
Received: from s472.loopia.se (unknown [172.22.191.5]) by s645.loopia.se (Postfix) with ESMTP id 1BA191579EF0; Sun, 28 Feb 2021 20:15:23 +0100 (CET)
X-Virus-Scanned: amavisd-new at amavis.loopia.se
Received: from s500.loopia.se ([172.22.191.6]) by s472.loopia.se (s472.loopia.se [172.22.190.12]) (amavisd-new, port 10024) with LMTP id jNxFhN2ITLYd; Sun, 28 Feb 2021 20:15:21 +0100 (CET)
X-Loopia-Auth: user
X-Loopia-User: mailstore2@aaa-sec.com
X-Loopia-Originating-IP: 90.229.17.25
Received: from [192.168.0.106] (unknown [90.229.17.25]) (Authenticated sender: mailstore2@aaa-sec.com) by s500.loopia.se (Postfix) with ESMTPSA id DC8151E32EAC; Sun, 28 Feb 2021 20:15:20 +0100 (CET)
User-Agent: Microsoft-MacOutlook/16.46.21021202
Date: Sun, 28 Feb 2021 20:15:19 +0100
From: Stefan Santesson <stefan@aaa-sec.com>
To: Erwann Abalea <eabalea@gmail.com>, Russ Housley <housley@vigilsec.com>
CC: "Roman D. Danyliw" <rdd@cert.org>, Carlisle Adams <cadams@site.uottawa.ca>, Ben Kaduk <kaduk@mit.edu>, IETF PKIX <pkix@ietf.org>
Message-ID: <792D6613-E546-4BDC-84ED-0916387293BA@aaa-sec.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>
In-Reply-To: <CA+i=0E4K6nWAAfiuuQ-uOR+9+9G+9=T9J=EMmqqP7-oA00tP6w@mail.gmail.com>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3697388121_580975813"
Archived-At: <https://mailarchive.ietf.org/arch/msg/pkix/IlbnLHoodSnxH531H-WjLoCWTrM>
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: Sun, 28 Feb 2021 19:15:31 -0000

My guess is that implementers got around this by fully or partly using manual implementation rather than autogenerated code.

 

And this also probably indicates how (not) widely implemented this protocol is.

 

 

Stefan Santesson 

 

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

 

 

 

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).

 

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.

 


> On Feb 26, 2021, at 3:54 PM, RFC Errata System <rfc-editor@rfc-editor.org> wrote:
> 
> The following errata report has been submitted for RFC3029,
> "Internet X.509 Public Key Infrastructure Data Validation and Certification Server Protocols".
> 
> --------------------------------------
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid6444
> 
> --------------------------------------
> Type: Technical
> Reported by: Russ Housley <housley@vigilsec.com>
> 
> Section: Appendix E
> 
> Original Text
> -------------
>  GeneralName, PolicyInformation
>  FROM PKIX1Implicit88 {iso(1) identified-organization(3)
>  dod(6) internet(1) security(5) mechanisms(5) pkix(7)
>  id-mod(0) id-pkix1-implicit-88(2)}
> 
> Corrected Text
> --------------
>  GeneralName, GeneralNames, PolicyInformation
>  FROM PKIX1Implicit88 {iso(1) identified-organization(3)
>  dod(6) internet(1) security(5) mechanisms(5) pkix(7)
>  id-mod(0) id-pkix1-implicit-88(2)}
> 
> Notes
> -----
> The ASN.1 Module uses GeneralName and GeneralNames, but only one of them is IMPORTed.  The suggested fix IMPORTS both of GeneralName and GeneralNames.
> 
> Instructions:
> -------------
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party  
> can log in to change the status and edit the report, if necessary. 
> 
> --------------------------------------
> RFC3029 (draft-ietf-pkix-dcs-07)
> --------------------------------------
> Title               : Internet X.509 Public Key Infrastructure Data Validation and Certification Server Protocols
> Publication Date    : February 2001
> Author(s)           : C. Adams, P. Sylvester, M. Zolotarev, R. Zuccherato
> Category            : EXPERIMENTAL
> Source              : Public-Key Infrastructure (X.509)
> Area                : Security
> Stream              : IETF
> Verifying Party     : IESG

_______________________________________________
pkix mailing list
pkix@ietf.org
https://www.ietf.org/mailman/listinfo/pkix


 

-- 

Erwann.

_______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix