Hi,
On Monday, 21. March 2011, Martin Paljak wrote:
> Hello Peter,
>
> Before I go on testing with CryptoStick (OpenPGP v2.0) could
you explain
> what happens with the overall behavior of OpenSC after your
patches? Do
> you get "further" with the card/token? Any other comments?
Together with the changes to opensc-explorer [see other mail
from me on Sunday] it even helped improve the situation with
1.1 cards.
> > * 0001-OpenPGP-fix-top-level-DOs-according-to-spec.patch
> > align the list of top-level data objects with the spec
>
> Are these changes between v1.1/2.0 or just mistakes? I don't
think that the
> v1.0/1.1 support is that relevant in near future, but it
would be nice if
> the code tried to explicitly maintain changes needed to
support both 2.0
> and 1.1 cards. I'm not sure if v2.0 is backwards compatible
with 1.1 and
> 1.0. If you know more and have studied both v1.1 and v2.0
specs, please
> provide pointers and/or insight.
IMHO these were simply errors even in the 1.1 support.
E.g. the DO with id 0073 is not a top level DO but contained
within another DO.
AFAICS spec 2.0 is compatible with 1.1 and only extends it.
The reference for the IDs of the DOs and how DOs are nested
can be found in the specs.
> If you do change something because of spec issues,
delete/fix the offending
> code, don't comment out. If something breaks, version
control should
> support recovery, not editor comments.
IMHO I did it with the exception of the DO 0073.
For the two other comments regarding DOs 0103 & 0104:
they are optional but require authentication for
reading. As I do not know yet how to deal with them,
I added them as comments in order to not forget the issue.
> Fiddling the driver to a state
> where it would work with 2.0 cards by sacrificing older
cards support
> would be OK as well, but in that case do add comments ("XXX:
hardcoded for
> v2.0 support" or something similar).
As far as I can say this is not the case !!!
> > * 0002-OpenPGP-add-indication-of-2048-RSA-agorithm-for-
Open.patch
> >
> > indicate 2048-bit support for version 2.0 cards
>
> In fact, 3072 :) But that would be an interesting stress
test for the
> overall forward-support of OpenSC and software that use
it...
I am not so sure.
http://www.g10code.com/p-card.html
tells about 3 2048-bits, and 3072 for signature keys only.
BTW the 2.0 cards share the ATR with the crypto stick.
I got one recently, but did not get round to putting keys on
it.
> > * 0005-OpenPGP-document-TLV-encoding-use-symbolic-
values.patch
> >
> > add comments to document the "funny TLV" encoding
>
> It looks similar to sc_asn1_read_tag, are you sure it can
not be re-used?
I only added comments.
Thanks for the hint.
What about improving the whole thing iteratively
and commit that part now?
Next step I'll take is whether sc_asn1_read_tag may be used.
> > * 0008-OpenPGP-only-malloc-when-we-need-to.patch
> >
> > avoid an unnecessary malloc(0)
>
> malloc is not checked for NULL
It hasn't been checked before too.
Thanks again.
This gives me hints about the next steps.
> > * 0009-OpenPGP-add-some-comments.patch
> >
> > a few more comments
>
> Comments are always nice!
>
> I'll give the changes a spin, if you could add some more
background
> information and updates, it would be easier to fix.
All the changes have been checked using opensc-explorer
against a 1.1 card.
Details about the DO IDs used are in the specs.
Sorry for not sending in perfect patches yet ;-)
Nonetheless it would be cool if some would be
included to mainline to give a positive feedback.
(card-openpgp did not get much love recently)
> By the way, if you use git you can fork on github [1] to
allow the pulling,
> mechanism over there do some tricks.
I'm using 'git svn' locally.
As I only have read access to SVN, I currently consider this
the easiest way to stay up-to-date
For patches, the mailing list / ticket system is OK with me.
Do you have any plans to migrate from SVN to git?
Best
Peter
--
Peter Marschall
pe...@adpm.de
_______________________________________________
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
