Subject: RE: TSP version 03

From: "David P. Kemp" <[email-masked]>
Date: Thu, 23 Sep 1999 11:09:00 -0400 (EDT)

> From: "Salz, Rich" <[email-masked]>
> To: "'David P. Kemp'" <[email-masked]>
> Cc: "[email-masked]'" <[email-masked]>
> Subject: RE: TSP version 03
> Date: Thu, 23 Sep 1999 10:12:50 -0400
> 
> >In short, saying "add an explicit version number field" to allow for
> >future changes is both easy and ineffective.
> 
> I disagree.  It makes it easy to "bail out" quickly and generate a
> useful diagnostic.

You can generate an *additional* diagnostic ("unrecognized version
number field"), but how useful is it?

If the software doesn't bail out correctly (defined as something other
than a core dump/GPF or wedge) when receiving malformed data, then
the software is of poor quality.  If the software does handle malformed
data correctly, how much quicker is it to parse and handle an explicit
version field than to omit the field and allow version mismatches to
be treated as any other malformed-ness error?

The recent discussion of v1/v2 CRLs is illustrative of the problem with
version numbers.  CRL extensions were defined in v2, and v1 software
might not be expected to understand them.  But instead of having only
two reasonable cases (CRLs without extensions, CRLs with extensions),
we have a third case (CRLs without extensions but with an explicit
version=v2 field) whose validity has been the subject of debate.

The very existence of the explicit version field has caused unnecessary
confusion. If it did not exist, the discussion would never have been
needed.  If the outcome of the discussion had not been to modify X.509
to allow the third case, then applications would have been
unnecessarily complicated by checking for consistency between version
number and the presence of extensions.

I don't want to have to think about what to do if I receive a cert with
a SubjectUID field present and a version number absent (defaulting to v1).
If I understand SubjectUIDs, I'll handle them, otherwise I'll bail.
Much simpler.

---

From: Paul Koning <[email-masked]>
Date: Thu, 23 Sep 1999 11:34:15 -0400

>>>>> "David" == David P Kemp <[email-masked]> writes:

 >> From: "Salz, Rich" <[email-masked]> To: "'David P. Kemp'"
 >> <[email-masked]> Cc: "[email-masked]'"
 >> <[email-masked]> Subject: RE: TSP version 03 Date: Thu, 23 Sep
 >> 1999 10:12:50 -0400
 >> 
 >> >In short, saying "add an explicit version number field" to allow
 >> for >future changes is both easy and ineffective.
 >> 

 David> You can generate an *additional* diagnostic ("unrecognized
 David> version number field"), but how useful is it?

If version numbers are incremented for the wrong reason, they can hurt 
-- you may end up rejecting a packet you could have supported solely
because it has an unexpected version number.

 David> If the software doesn't bail out correctly (defined as
 David> something other than a core dump/GPF or wedge) when receiving
 David> malformed data, then the software is of poor quality.  If the
 David> software does handle malformed data correctly, how much
 David> quicker is it to parse and handle an explicit version field
 David> than to omit the field and allow version mismatches to be
 David> treated as any other malformed-ness error?

That's true but that's a different issue.

No system should crash because it receives malformed packets
(including intentionally malformed packets).  But it shouldn't be
required to act in a particularly useful way when that happens.

On the other hand, packets with new elements added in accordance to
the protocol extension rules are NOT malformed packets.  Those should
be handled as specified by the rules of the protocol.

	paul