Re: [TSP/RFC3161] PKIFailureInfo values

[Ricardo Barroso <ricardo.barroso@xxxxxxxxxxxxx>]

Peter Sylvester wrote:
> > Because with RFC 3161 it's possible that exist two compliant systems
> > which can't
> > interoperate properly in some situations because one accepts that
> > PKIFailueInfo
> > contains more than one bit with value one (1) and the other not!
> >
> >   
>
> A client signals an error in both cases. If there is no time stamp
> token available, if any of the values are set, then there is an error, 
> the difference may only be that the client do not get the same local
> error message.  
>
> The actual text does not specify different possible actions depending
> in different errors, a server cannot indicate that there is only
> a temporary error, no logic that provokes a different behaviour
> of the client depending on the values or combinations of them
> can be deduced from the actual text.
Peter, that depends on your ASN.1 coder/decoder implementation...
If you have implicitly in your ASN.1 co/decoder that a PKIFailureInfo
can't have 
multiple bits with value one (1) then the client difficultly or even won't
be able to 
decode the TSA response!

I don't know if you agree with my startegy but I think a better approach
would be if you can 
make implicitly your ASN.1 co/decoder only generate/accept (code/decode)
valid RFC 3161 
compliant ASN.1 definitions (or other context appliable). This will prevent
some errors 
you can stop there to be expanded (outside the scope of the coder/decoder)
to somewhere in 
your system. Possibly this is more a question about Software Engineering
than in the scope 
of IETF-PKIX, I don't know.

Best regards,
Ricardo Barroso

 MULTICERT S.A. 
 www.multicert.com
>