Subject: Re: [TSP/RFC3161] PKIFailureInfo values

From: Peter Sylvester <[email-masked]>
Date: Wed, 6 Nov 2002 18:12:21 +0100 (MET)

> 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.

---

From: Ricardo Barroso <[email-masked]>
Date: Wed, 06 Nov 2002 17:36:38 +0000

>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 <http://www.multicert.com>