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

Russ Housley <housley@vigilsec.com> Mon, 01 March 2021 22:33 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 D82413A2434 for <pkix@ietfa.amsl.com>; Mon, 1 Mar 2021 14:33:04 -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 ZvcKAP-2_agl for <pkix@ietfa.amsl.com>; Mon, 1 Mar 2021 14:33:02 -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 EFA463A2432 for <pkix@ietf.org>; Mon, 1 Mar 2021 14:33:01 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 1E156300BEC for <pkix@ietf.org>; Mon, 1 Mar 2021 17:32:59 -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 kUurhy4KPZib for <pkix@ietf.org>; Mon, 1 Mar 2021 17:32:51 -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 09365300AE8; Mon, 1 Mar 2021 17:32:50 -0500 (EST)
From: Russ Housley <housley@vigilsec.com>
Message-Id: <B6C5AFD0-87D7-4C5B-A654-5D9BF47475BE@vigilsec.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_9B9FF303-C39F-433A-B1C3-1194D24AD389"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\))
Date: Mon, 1 Mar 2021 17:32:51 -0500
In-Reply-To: <FBE6F96D-CF0B-4952-A07F-03B220DB738A@aaa-sec.com>
Cc: Carlisle Adams <cadams@uottawa.ca>, Erwann Abalea <eabalea@gmail.com>, "Roman D. Danyliw" <rdd@cert.org>, Ben Kaduk <kaduk@mit.edu>, IETF PKIX <pkix@ietf.org>
To: Stefan Santesson <stefan@aaa-sec.com>
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>
X-Mailer: Apple Mail (2.3445.104.17)
Archived-At: <https://mailarchive.ietf.org/arch/msg/pkix/P1fyG00mHfV2Ov5RPdcXr7DvmoQ>
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 22:33:05 -0000

Stefan:

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 "www.example.com",
       uniformResourceIdentifier "http://www.example.com"
     },
     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
            "www.example.com"
        GeneralName CHOICE
          uniformResourceIdentifier IA5String: tag = [6] primitive; length = 22
            "http://www.example.com"
  reasons ReasonFlags BIT STRING: tag = [1] primitive; length = 2
    0x027c

Russ


> On Mar 1, 2021, at 4:53 PM, Stefan Santesson <stefan@aaa-sec.com> 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: https://github.com/a-i-b/jnotary/blob/master/dvcs/src/main/java/org/jnotary/dvcs/Data.java <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 <mailto:cadams@uottawa.ca>>
> Date: Monday, 1 March 2021 at 17:23
> To: Russ Housley <housley@vigilsec.com <mailto:housley@vigilsec.com>>, 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>>
> 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 <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