It depends. If the entire input itself is within a DER encoded structure, then I would bug out. There is nothing defined for BER, CER or DER that would allow padding of structures within constructed values.
If the input is just followed by additional data or junk bytes then it is up to the protocol or otherwise your discretion if you want to accept the data. There is little harm in proceeding as long as the additional data is not treated as trusted data; discarding the untrusted data is the best option.
For some protocols it has some merit to allow additional data. I've personally seen the following security related reasons to add additional data:
- zero padding for wrapped keys where the keys are wrapped using CBC (PKCS#11 compliant HSM's often use this)
- smart cards where the size of each file (transparent EF's) is predetermined
In those cases the value of the length bytes of the first BER TLV structure (or out of band information) determines the actual size of the data. As the signature verification can only succeed if the data size is correct, the data length encoding does not have to be part of the signature itself.
It is recommended to make sure that new protocols do not have to handle spurious bytes. There are instances where spurious information is really dangerous, such as XML digital signatures where an attacker may repeat certain tags or ID's. Beware that the data you use is the data you signed; it should not be possible for an attacker to change the location of the data.