Re: [Technical Errata Reported] RFC3029 (6444)
Russ Housley <[email protected]>
| Newsgroups | gmane.ietf.x509 |
|---|---|
| Message-ID | <[email protected]> |
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 <[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