Ricardo Barroso wrote:Hello! RFC 3161 (TSP) says in 2.4.2: "... When the TimeStampToken is not present, the failInfo indicates the reason why the time-stamp request was rejected and may be one of the following values. PKIFailureInfo ::= BIT STRING { badAlg (0), -- unrecognized or unsupported Algorithm Identifier badRequest (2), -- transaction not permitted or supported badDataFormat (5), -- the data submitted has the wrong format timeNotAvailable (14), -- the TSA's time source is not available unacceptedPolicy (15), -- the requested TSA policy is not supported by the TSA unacceptedExtension (16), -- the requested extension is not supported by the TSA addInfoNotAvailable (17) -- the additional information requested could not be understood -- or is not available systemFailure (25) -- the request cannot be handled due to system failure } These are the only values of PKIFailureInfo that SHALL be supported. Compliant servers SHOULD NOT produce any other values. Compliant clients MUST generate an error if values it does not understand are present. ...". Since a BIT STRING can hold several bit values that can be either 1 or 0, is it supposed that a BIT STRING representing a PKIFailureInfo MUST has ONLY one bit (correspondent to one of the defined possible values) or can a PKIFailuereInfo has more than one bit with value 1 wich means that it can indicates more than one valid failure reasons?Indeed, from the Encoding technology of ASN.1, PKIFailureInfo must have 25 bits, if bit 0 set to 1, badAlg is one reason of this failure, and so on.Using another words, in: "When the TimeStampToken is not present, the failInfo indicates the reason why the time-stamp request was rejected and may be one of the following values." "may be one" doesn't implies that compliant servers can't generate PKIFailusInfo's with more than one valid value, am I right?"may be one of the ..." will be more understandable.Thanks in advance, Ricardo Barroso MULTICERT S.A. www.multicert.com <http://www.multicert.com>