Subject: Re: [TSP/RFC3161] PKIFailureInfo values

From: Peter Sylvester <[email-masked]>
Date: Wed, 6 Nov 2002 18:04:09 +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!

It seems that the text could say 'MAY only be any of the following values'.
as the list is a restriction (and extension) of the values define in CMP.

Or: 'Only the following values MAY occur'.

I could detect an invalid hash algorithm and an unsupported extension,
an unacceptable policy, and even time source not available all together.

---

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

>an unacceptable policy, and even time source not available all together. 
Peter, I agree with you.

Ricardo Barroso

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 07 Nov 2002 11:11:47 +0100

Since, you seem to all agree in principle, can some of you propose a full 
text remplacement, providing the old and new sentence ?

"Only the following values MAY occur" is not crystal clear when bits are 
described.

Denis

PS. Remember that I am still awaiting an interoperability test so that we 
can progress the document on the Standards Track.

---

From: Ricardo Barroso <[email-masked]>
Date: Thu, 07 Nov 2002 13:18:53 +0000

In my opion in RFC 3161/draft-ietf-pkix-rfc3161bis-00, section 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.»

should be replace by something like this:

   «When the TimeStampToken is not present, the failInfo indicates one
   or more reasons why the time-stamp request was rejected and may be
   one or more of the following values.»

and:

   «The statusString field of PKIStatusInfo MAY be used to include reason
   text such as "messageImprint field is not correctly formatted".»

should also be replaced by something like this:

   «The statusString field of PKIStatusInfo MAY be used to include reason(s)
   text such as "messageImprint field is not correctly formatted".»

I have no experience in writing RFCs and I don't know if my English is 
the best suited for this
cases but it's my proposal.

Denis, I don't know if I got it right, when you say "is not crystal 
clear when bits are described"
do you mean that should be written something more about the bits inside 
the PKIFailureInfo
BIT STRING?

Best regards,
Ricardo Barroso

MULTICERT S.A.
www.multicert.com <http://www.multicert.com>

Denis Pinkas wrote:

>
> Since, you seem to all agree in principle, can some of you propose a 
> full text remplacement, providing the old and new sentence ?
>
> "Only the following values MAY occur" is not crystal clear when bits 
> are described.
>
> Denis
>
> PS. Remember that I am still awaiting an interoperability test so that 
> we can progress the document on the Standards Track.
>
>
>> Peter Sylvester wrote:
>>

---

From: "Phillip H. Griffin" <[email-masked]>
Date: Thu, 07 Nov 2002 09:58:21 -0500

It seems to me that you have a notation readily at hand that allows
you to assign names to any bit pattern you choose. For example,

   ErrorCodes ::= BIT STRING

   iMeanAllOfTheBits ErrorCodes ::= '1111111111111'B

Once you've assigned useful names to acceptable bit patterns, you gain
the advantage of being able to refer to them in English prose, such as
stating "when the value of type ErrorCodes is iManAllOfTheBits, the
receiving application should blah blah blah".

Phil

Ricardo Barroso wrote:

> do you mean that should be written something more about the bits 
> inside the PKIFailureInfo
> BIT STRING?
>
> Best regards,
> Ricardo Barroso
>
> MULTICERT S.A.
>> PS. Remember that I am still awaiting an interoperability test so 
>> that we can progress the document on the Standards Track.
>>
>>
>>> Peter Sylvester wrote:
>>>

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 07 Nov 2002 16:36:04 +0100

Ricardo,

Thank you for the proposal.

Is it fine with Peter (S), Andrew, Peter (G) and Phil  ?
Any proposal from any one else ?

Denis

---

From: Ricardo Barroso <[email-masked]>
Date: Fri, 08 Nov 2002 10:59:32 +0000

Phil, thanks for trying to help, I think that's for sure useful in some 
cases but here we can't / don't wan't
to describe all the possible combinations of PKIFailure BIT STRING 
values since in my opinion that
will probably create a great mess around a "simple" issue!

Maybe Peter, Denis, Andrew, Peter S. or someone else have another opinion...

Best regards,
Ricardo Barroso

MULTICERT S.A.

Phillip H. Griffin wrote:

>> I have no experience in writing RFCs and I don't know if my English 
>> is the best suited for this