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

[Russ Housley <[e-mail]>]

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 <[e-mail]> 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 <[e-mail] <mailto:[e-mail]>>
> Date: Monday, 1 March 2021 at 17:23
> To: Russ Housley <[e-mail] <mailto:[e-mail]>>, Erwann Abalea <[e-mail] <mailto:[e-mail]>>
> Cc: "Roman D. Danyliw" <[e-mail] <mailto:[e-mail]>>, Ben Kaduk <[e-mail] <mailto:[e-mail]>>, Stefan Santesson <[e-mail] <mailto:[e-mail]>>, IETF PKIX <[e-mail] <mailto:[e-mail]>>
> 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 <[e-mail] <mailto:[e-mail]>> 
> Sent: February-28-21 5:26 PM
> To: Erwann Abalea <[e-mail] <mailto:[e-mail]>>
> Cc: Roman D. Danyliw <[e-mail] <mailto:[e-mail]>>; Ben Kaduk <[e-mail] <mailto:[e-mail]>>; Stefan Santesson <[e-mail] <mailto:[e-mail]>>; IETF PKIX <[e-mail] <mailto:[e-mail]>>; Carlisle Adams <[e-mail] <mailto:[e-mail]>>
> Subject: Re: [pkix] [Technical Errata Reported] RFC3029 (6444)
>  
> Attention : courriel externe | external email
> Erwann:
>>  
>> Le sam. 27 févr. 2021 à 08:45, Russ Housley <[e-mail] <mailto:[e-mail]>> 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