Re: [Technical Errata Reported] RFC3029 (6444)

PROBLEM 1: The minimal change is an "IMPLICIT" to "EXPLICIT".  Technically, that is a change on the wire.

PROBLEM 2: As I said in another message, the ANY DEFINED BY could be used.  I have never seen that done where the DEFINED BY points to a field that is not at the same level.  That will require some further investigation.

Russ


> On Mar 1, 2021, at 5:53 PM, Stefan Santesson <[email protected]> wrote:
> 
> Russ
>  
> I concede to your superior ASN.1 knowledge here.
>  
> Can this be fixed without changing the protocol in a way that changes the bits on the wire?
> I assume that a change that alters the bits on the wire requires a regular protocol update with a new ASN.1 module.
>  
> Stefan Santesson 
>  
> From: Russ Housley <[email protected] <mailto:[email protected]>>
> Date: Monday, 1 March 2021 at 23:33
> To: Stefan Santesson <[email protected] <mailto:[email protected]>>
> Cc: Carlisle Adams <[email protected] <mailto:[email protected]>>, Erwann Abalea <[email protected] <mailto:[email protected]>>, "Roman D. Danyliw" <[email protected] <mailto:[email protected]>>, Ben Kaduk <[email protected] <mailto:[email protected]>>, IETF PKIX <[email protected] <mailto:[email protected]>>
> Subject: Re: [pkix] [Technical Errata Reported] RFC3029 (6444)
>  
> 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 <http://www.example.com/>",
>        uniformResourceIdentifier "http://www.example.com <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 <http://www.example.com/>"
>         GeneralName CHOICE
>           uniformResourceIdentifier IA5String: tag = [6] primitive; length = 22
>             "http://www.example.com <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 <[email protected] <mailto:[email protected]>> 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 <[email protected] <mailto:[email protected]>>
>> Date: Monday, 1 March 2021 at 17:23
>> To: Russ Housley <[email protected] <mailto:[email protected]>>, Erwann Abalea <[email protected] <mailto:[email protected]>>
>> Cc: "Roman D. Danyliw" <[email protected] <mailto:[email protected]>>, Ben Kaduk <[email protected] <mailto:[email protected]>>, Stefan Santesson <[email protected] <mailto:[email protected]>>, IETF PKIX <[email protected] <mailto:[email protected]>>
>> 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 <[email protected] <mailto:[email protected]>> 
>> Sent: February-28-21 5:26 PM
>> To: Erwann Abalea <[email protected] <mailto:[email protected]>>
>> Cc: Roman D. Danyliw <[email protected] <mailto:[email protected]>>; Ben Kaduk <[email protected] <mailto:[email protected]>>; Stefan Santesson <[email protected] <mailto:[email protected]>>; IETF PKIX <[email protected] <mailto:[email protected]>>; Carlisle Adams <[email protected] <mailto:[email protected]>>
>> Subject: Re: [pkix] [Technical Errata Reported] RFC3029 (6444)
>>  
>> Attention : courriel externe | external email
>> Erwann:
>>>  
>>> Le sam. 27 févr. 2021 à 08:45, Russ Housley <[email protected] <mailto:[email protected]>> 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
[email protected]
https://www.ietf.org/mailman/listinfo/pkix