ETSI Checker too strict: NotKnownComponent RevocationInfoArchival

[eramons]

Our Signing Service issues PDF/PAdES signatures including the signed attribute RevocationInfoArchival - defined by Adobe with OID 1.2.840.113583.1.1.8 - in the CMS object. Adobe Reader and other PDF-spec-aware applications will retrieve and process the revocation values, allowing for long-term validation.

The PAdES standard (ETSI EN 319 142-1 PAdES) does not explicitly disallow the addition of unknown attributes, as the exclusion defined in section 6.3 only refers to attributes defined in (ETSI EN 319 122-1 CAdES).

However, the ETSI Checker shows an error message and interrupts the validation:

Location-{CodeTest}:Contents/CAdESSignature/content/signedData/signerInfos/signerInfo[1]/signedAttrs/attribute[4]/attrValues/NotKnownComponent[1]-{ForAllTheChildrenDo}
An unknown component has been reached. Consequently, its children and their processing are unknown to the TLCC. No further checks will be done to this component

Thus, we think the ETSI checker behaves too strict: it should actually ignore the unknown attribute and continue its validation.

Is it possible for you to change the behaviour of the checker to make it more resilient, not showing an error (or maybe showing just a warning) and continuing the validation?

Thanks.

[MarcelMCT]

I get the same error.
Is this something that needs to be changed in our signing or is the checker too strict?

Location-{CodeTest}:Contents/CAdESSignature/content/signedData/signerInfos/signerInfo[1]/signedAttrs/attribute[4]/attrValues/NotKnownComponent[1]-{ForAllTheChildrenDo} An unknown component has been reached. Consequently, its children and their processing are unknown to the TLCC. No further checks will be done to this component

[jccruellas]

Good morning Marcel,
First of all I apology for not having reacting before. Actually, I had a problem and for some time I did not receive in my email any notification from Github, and also a heavy workload in the university.

Regarding to your issue, I would like to make two remarks:

1. Despite the fact that at present the PAdESCC signals an error, it continues to check the rest of the components that. are known to it: the appearance of an error does not stop the process.
2. I will carefully read again the standard (I do not remember it by heart). If I arrive to the same conclusion (that inclusion of not standardized attributes is allowed) then I would start thinking in converting this "error" to a "warning", because it would mean that the signature would still be compliant with the standard, although the CC finds an attribute that is not able to check,

I will keep you posted

Regards
Juan Carlos.

[MarcelMCT]

Thx for letting me know. Op wo 14 apr. 2021 09:42 schreef jccruellas ***@***.***>:

…

Good morning Marcel, First of all I apology for not having reacting before. Actually, I had a problem and for some time I did not receive in my email any notification from Github, and also a heavy workload in the university. Regarding to your issue, I would like to make two remarks: 1. Despite the fact that at present the PAdESCC signals an error, it continues to check the rest of the components that. are known to it: the appearance of an error does not stop the process. 2. I will carefully read again the standard (I do not remember it by heart). If I arrive to the same conclusion (that inclusion of not standardized attributes is allowed) then I would start thinking in converting this "error" to a "warning", because it would mean that the signature would still be compliant with the standard, although the CC finds an attribute that is not able to check, I will keep you posted Regards Juan Carlos. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#5 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFNTD76V6BSPGT6QOPQN2FLTIVBPXANCNFSM4RSCIS5Q> .

[SebastiaanPolfliet]

Hi

I'm getting the same error. @jccruellas were you able to further analyse this?

Thank you in advance.

Regards