Hi,
I generally agree with you, but it may worth to consider that some important
smart card standards, e.g. PC/SC and EMV, do NOT support VPP (I think memory
cards are not relevant to this discussion), and if your application needs
only to be EMV compliant for example, you may consider using odd
instructions if you have very good reasons to do so...
Of course, it is always better to use only even INS codes and be compliant
to ISO 7816.
Gil.
-----Original Message-----
From: Cedric Huet [mailto:[EMAIL PROTECTED]]
Sent: Thursday, March 29, 2001 11:15 AM
To: Sebastien Jean; [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: [OCF] CLA, INS, SW available/reserved values
Hi,
Sorry Sebastien but I disagree with that. Please considere following
arguments and make your own opinion.
In some cases the ACK could be !INS xor 1, that's why INS should not be an
odd one.
That's not because some samples seems to work that they are compliant with
the standards! Beeing compliant with the standard meens reaching
interoperability at APDU level, which is a great chance for your applet to
work with as much readers as possible!
It's always better this way, but everyone is free to interpret the standard
is own way.
You can afford to brake some few sprayed standards, but there are millions
of smart card readers in the world, and this success is due to the ISO 7816
standard. None one in the card industry ignore that!
There were a mistake in the examples of the GemXpresso 211 Kit (v 2.x), the
samples of GemXPresso RAD III kit have been corrected ;)
For memory here is an excerpt from the ISO 7816_3 standard:
"INS is an instruction code in the instruction class. The instruction
code is valid only if the least significant bit is 0, and the most
significant half byte is neither 6 nor 9."
The ACK with bit b0 set is only possible when VPP is used, and I agree this
does not often happen with micro-chip cards (most of the time this is for
memory cards), but once again beeing compliant with the standard is better.
Somedays your card may encounter a reader which strictly apply the
standard, and hence reject the card! It'll be to late!
The following URL is interesting for information purpose only, do not
considere it as a reference:
http://www.scia.org/aboutSmartCards/iso7816_wimages.htm
It may be considered as a mistake that the standard sometime mixes the TPDU
level with APDU level (and I agree with that), but it's to late to get
back, and this is not such a great trouble to have some constraints on INS
byte.
Hope this will help.
Cheers,
CH
At 08:56 29/03/2001, Sebastien Jean wrote:
> > INS must not be an odd one (1 3 5 ...) due to ACK protocol at transport
> level.
> > CLA Must no be any 6X or 9X, most of the time user app may use 00. ISO
> > standards indicates partitions in CLA, with reserved, forbidden and free
> > ranges.
> > SW1 must be one of 6X or 9X
> >
> > Reading ISO 7816_3 and 7816_4 standards is strongly recommanded.
> >
> > 90 00 ;)
> > CH
>
>I do not think that INS byte is so constrained, none of both GemXpresso211
and
>Sun's examples mention such parity.
>The examples are running, and since the ack is INS (or !INS, i am just
>awaken ;-)
>), why the transport protocol should work only with odd INS numbers ?
>I agree with you while saying that SW1 should be 6X (problem) or 9X
>(normal), but
>in the case of OCF use, it is possible to use SWs that are not compliant
>to ISO if
>needed.
>Standards are just contexts, often broken, as bluetooth example.
>
>cheers,
>Baz
>
>--
>Sébastien Jean (a.k.a. Baz)
>PhD candidate
>LIFL - Université des Sciences et Technologies de Lille,
>Batiment M3, bureau 111, F-59655 Villeneuve d'Ascq Cedex
>France
>Tel : (+33/0) 320 336 132 , Fax: (+33/0) 320 436 566
>mailto:[EMAIL PROTECTED] , http://www.lifl.fr/~jean
>"if you are aware...you can succeed(Jean-Claude Van Damme)"
>
>
>
>
>---
> > Visit the OpenCard web site at http://www.opencard.org/ for more
> > information on OpenCard---binaries, source code, documents.
> > This list is being archived at http://www.opencard.org/archive/opencard/
>
>! To unsubscribe from the [EMAIL PROTECTED] mailing list send an email
>! to
>! [EMAIL PROTECTED]
>! containing the word
>! unsubscribe
>! in the body.
---
> Visit the OpenCard web site at http://www.opencard.org/ for more
> information on OpenCard---binaries, source code, documents.
> This list is being archived at http://www.opencard.org/archive/opencard/
! To unsubscribe from the [EMAIL PROTECTED] mailing list send an email
! to
! [EMAIL PROTECTED]
! containing the word
! unsubscribe
! in the body.
---
> Visit the OpenCard web site at http://www.opencard.org/ for more
> information on OpenCard---binaries, source code, documents.
> This list is being archived at http://www.opencard.org/archive/opencard/
! To unsubscribe from the [EMAIL PROTECTED] mailing list send an email
! to
! [EMAIL PROTECTED]
! containing the word
! unsubscribe
! in the body.
