<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://blog.gmane.org/gmane.comp.encryption.opensc.devel">
    <title>gmane.comp.encryption.opensc.devel</title>
    <link>http://blog.gmane.org/gmane.comp.encryption.opensc.devel</link>
    <description/>
    <syn:updatePeriod>hourly</syn:updatePeriod>
    <syn:updateFrequency>1</syn:updateFrequency>
    <syn:updateBase>1901-01-01T00:00+00:00</syn:updateBase>
    <items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.encryption.opensc.devel/14094"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.encryption.opensc.devel/14093"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.encryption.opensc.devel/14092"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.encryption.opensc.devel/14091"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.encryption.opensc.devel/14090"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.encryption.opensc.devel/14089"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.encryption.opensc.devel/14088"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.encryption.opensc.devel/14087"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.encryption.opensc.devel/14086"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.encryption.opensc.devel/14085"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.encryption.opensc.devel/14084"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.encryption.opensc.devel/14083"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.encryption.opensc.devel/14082"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.encryption.opensc.devel/14081"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.encryption.opensc.devel/14080"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.encryption.opensc.devel/14079"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.encryption.opensc.devel/14078"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.encryption.opensc.devel/14077"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.encryption.opensc.devel/14076"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.encryption.opensc.devel/14075"/>
      </rdf:Seq>
    </items>
    <image rdf:resource="http://gmane.org/img/gmane-25t.png"/>
    <textinput rdf:resource=""/>
  </channel>
  <image rdf:about="http://gmane.org/img/gmane-25t.png">
    <title>Gmane</title>
    <url>http://gmane.org/img/gmane-25t.png</url>
    <link>http://gmane.org</link>
  </image>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.encryption.opensc.devel/14094">
    <title>Re: CRYPTOMATE64</title>
    <link>http://permalink.gmane.org/gmane.comp.encryption.opensc.devel/14094</link>
    <description>&lt;pre&gt;
So the only way is to buy it and try...
Worst case: about 50€ wasted. Best case: a good token.
In the worst case: have ACS been collaborative in the past, supplying
info to add support?

I'm going to order it, but I'd prefer to have something usable :)
I'd use it from XCA or openssl.

BYtE,
 Diego.
&lt;/pre&gt;</description>
    <dc:creator>NdK</dc:creator>
    <dc:date>2012-05-23T19:15:03</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.encryption.opensc.devel/14093">
    <title>Re: CRYPTOMATE64</title>
    <link>http://permalink.gmane.org/gmane.comp.encryption.opensc.devel/14093</link>
    <description>&lt;pre&gt;
I evaluated it, but it's *currently* usable only from GPG.
And the info I found said it could handle 3 keys up to 3072bits.
I still have to understand the whole "subkeys" concept, but haven't yet
actually started digging it.

Maybe, tks to the work of Nguyễn Hồng Quân et al, it'll be the next
token I'll get. Or, more probably, I'll wait the new version. :)

BYtE,
 Diego.
_______________________________________________
opensc-devel mailing list
opensc-devel&amp;lt; at &amp;gt;lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel&lt;/pre&gt;</description>
    <dc:creator>NdK</dc:creator>
    <dc:date>2012-05-23T19:13:43</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.encryption.opensc.devel/14092">
    <title>Re: CRYPTOMATE64</title>
    <link>http://permalink.gmane.org/gmane.comp.encryption.opensc.devel/14092</link>
    <description>&lt;pre&gt;Hi

2012/5/23 NdK &amp;lt;ndk.clanbo&amp;lt; at &amp;gt;gmail.com&amp;gt;


So does the OpenPGP card and the CryptoStick (which contains that card)

Peter
_______________________________________________
opensc-devel mailing list
opensc-devel&amp;lt; at &amp;gt;lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel&lt;/pre&gt;</description>
    <dc:creator>Peter Koch</dc:creator>
    <dc:date>2012-05-23T18:18:15</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.encryption.opensc.devel/14091">
    <title>Re: OpenPGP card / Cryptostick - current status???</title>
    <link>http://permalink.gmane.org/gmane.comp.encryption.opensc.devel/14091</link>
    <description>&lt;pre&gt;Hi Peter,

I do not intent to use pkcs15-init to *create* file system.
I just need it to *modify* file content from PKCS#11 interface.

I wish I could avoid pkcs15-init, but there is no other way, as Viktor 
confirmed. The OpenSC-PKCS11 always refers to pkcs15-init to do 
writing/updating.


In fact, it does more things than just creating PKCS#15 file system. 
You can see the sc_pkcs15init_operations struct in pkcs15-init.h file. 
It has members "store_key", "generate_key", "emu_store_data" which I 
may want to use.

Yes, that's what I need from pkcs15-init.

Because I want it possible to do those administrative things from 
Firefox/Thunderbird, via PKCS#11. For example, I want to use Firefox to 
import X.509 certificate from *.p12 file to OpenPGP card. Or when a 
website use Firefox API to generate key and certificate (like 
startssl.com), I want the generated certificate to be stored right into 
the card.

Yes, I don't want to create, just want to change.
I won't implement the "create" parts in pkcs15-init, just the "update" 
parts.
For the "create" parts, I will redirect it to change existing objects.

If my explanation is not clear, don't hesitate to ask more :).
Thank for your care.

--
Regards,
Quân
_______________________________________________
opensc-devel mailing list
opensc-devel&amp;lt; at &amp;gt;lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel&lt;/pre&gt;</description>
    <dc:creator>Nguyễn Hồng Quân</dc:creator>
    <dc:date>2012-05-23T14:47:56</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.encryption.opensc.devel/14090">
    <title>Re: CRYPTOMATE64</title>
    <link>http://permalink.gmane.org/gmane.comp.encryption.opensc.devel/14090</link>
    <description>&lt;pre&gt;Hi,

I have worked with ACS before handling products related to ACOS5/ACOS5 64K.
Though we have not any test with open-sc using this particular card. Are
you using it via a PKCS#11 middleware?

Regards,
Joms

On Wed, May 23, 2012 at 7:57 PM, NdK &amp;lt;ndk.clanbo&amp;lt; at &amp;gt;gmail.com&amp;gt; wrote:

_______________________________________________
opensc-devel mailing list
opensc-devel&amp;lt; at &amp;gt;lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel&lt;/pre&gt;</description>
    <dc:creator>Joemar Mante</dc:creator>
    <dc:date>2012-05-23T13:12:51</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.encryption.opensc.devel/14089">
    <title>CRYPTOMATE64</title>
    <link>http://permalink.gmane.org/gmane.comp.encryption.opensc.devel/14089</link>
    <description>&lt;pre&gt;Hello all.

Someone already tested that token? It's the only one I could find that
handles RSA4096...

http://www.acs.com.hk/index.php?pid=product&amp;amp;prod_sections=0&amp;amp;id=CRYPTOMATE64

I'm thinking to use one to store our internal root CA's key (4096bit
RSA). [actually I'm thinking more about a "ring of roots", but that's
another story]

Intermediate CAs will use other cards/tokens (still undecided between
Aventra's MyEID and Gooze's ePass2003 token), that are way cheaper and
up to the job :)

BYtE,
 Diego.
&lt;/pre&gt;</description>
    <dc:creator>NdK</dc:creator>
    <dc:date>2012-05-23T11:57:46</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.encryption.opensc.devel/14088">
    <title>Re: OpenPGP card / Cryptostick - current status???</title>
    <link>http://permalink.gmane.org/gmane.comp.encryption.opensc.devel/14088</link>
    <description>&lt;pre&gt;Hi Quân

I still don't understand what you are trying to do - maybe you can
explain that in more detail:

The purpose of pkcs15-init is to create a PKCS#15 filesystem layout
on a card.

The purpose of a pkca15-emulation routine is to make OpenSC believe
that a card has a PKCS#15 filesystem which in reality does NOT
have such a layout.

We have such an emulation for OpenPGP cards and OpenPGP cards
don't have a PKCS#15 layout and there is no way to create such a
layout on an OpenPGP card due to the lack of a CREATE EF/DF/DO
command.

So the only thing pkcs1-init might do is to change the contents of certain
already existing DOs on an OpenPGP card. And this might happen via
emulated UPDATE BINARY commands (which would do PUT DATA instead).

But changing the contents of DOs on an OpenPGP card is exactly
what the gpg administration tools do, so why reimplementing this into
pkcs15-init

And I'm afraigth that those things that "gpg --edit-card" cannot do
are impossible to do.

You cannot create a private key file on an OpenPGP card. There are
3 of them already on every OpenPGP card and the only thing you can
do is to replace their contents.

Same situation with certificates: You cannot create them. There's one
DO on an OpenPGP card meant to store one certificate. You can
replace its content with a PUT DATA but I don't see any possibility
to create additional certificates.

Peter
_______________________________________________
opensc-devel mailing list
opensc-devel&amp;lt; at &amp;gt;lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel&lt;/pre&gt;</description>
    <dc:creator>Peter Koch</dc:creator>
    <dc:date>2012-05-23T10:11:01</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.encryption.opensc.devel/14087">
    <title>Re: OpenPGP card / Cryptostick - current status???</title>
    <link>http://permalink.gmane.org/gmane.comp.encryption.opensc.devel/14087</link>
    <description>&lt;pre&gt;Hi Viktor,

Thanks for your guide, but...

On 05/21/2012 09:00 PM, Viktor Tarasov wrote:
I removed the PKCS15-AppDF from the openpgp.profile (see my attachment)
and bring up "template key-domain" block to right under "DF MF", but the
pkcs15-init still fills 5015 to the path:

0xb72236c0 09:33:58.561 [pkcs15-init]
pkcs15-lib.c:1530:sc_pkcs15init_store_certificate: Store
cert(Certificate,ID:707d8f9e04a18d5e7a4b3c3adebe8124cda8c310,der(0x9dd82a0,753))
0xb72236c0 09:33:58.562 [pkcs15-init]
pkcs15-lib.c:1720:sc_pkcs15init_store_data: called
0xb72236c0 09:33:58.562 [pkcs15-init]
pkcs15-lib.c:2274:select_object_path: called
0xb72236c0 09:33:58.562 [pkcs15-init]
pkcs15-lib.c:2299:select_object_path: key-domain.certificate &amp;lt; at &amp;gt;3f005015
(auth_id.len=0)
0xb72236c0 09:33:58.562 [pkcs15-init]
profile.c:691:sc_profile_instantiate_template: Instantiating template
key-domain at 3f005015
0xb72236c0 09:33:58.562 [pkcs15-init]
profile.c:774:sc_profile_instantiate_file: Instantiated private-key at
3f0050155f48
0xb72236c0 09:33:58.562 [pkcs15-init]
profile.c:775:sc_profile_instantiate_file:   parent=PKCS15-AppDF&amp;lt; at &amp;gt;3f005015
0xb72236c0 09:33:58.562 [pkcs15-init]
profile.c:774:sc_profile_instantiate_file: Instantiated public-key at
3f0050157f49
0xb72236c0 09:33:58.562 [pkcs15-init]
profile.c:775:sc_profile_instantiate_file:   parent=PKCS15-AppDF&amp;lt; at &amp;gt;3f005015
0xb72236c0 09:33:58.562 [pkcs15-init]
profile.c:774:sc_profile_instantiate_file: Instantiated certificate at
3f0050157f21
0xb72236c0 09:33:58.562 [pkcs15-init]
profile.c:775:sc_profile_instantiate_file:   parent=PKCS15-AppDF&amp;lt; at &amp;gt;3f005015
0xb72236c0 09:33:58.562 [pkcs15-init]
profile.c:774:sc_profile_instantiate_file: Instantiated privdata at
3f0050150101
0xb72236c0 09:33:58.562 [pkcs15-init]
profile.c:775:sc_profile_instantiate_file:   parent=PKCS15-AppDF&amp;lt; at &amp;gt;3f005015
0xb72236c0 09:33:58.562 [pkcs15-init]
pkcs15-lib.c:2321:select_object_path: instantiated template path
3f0050157f21
0xb72236c0 09:33:58.562 [pkcs15-init]
pkcs15-lib.c:2350:select_object_path: returns object path '3f0050157f21'

...
0xb72236c0 09:33:58.562 [pkcs15-init]
pkcs15-lib.c:528:sc_pkcs15init_delete_by_path: trying to delete
'3f0050157f21'
0xb72236c0 09:33:58.562 [pkcs15-init] card.c:571:sc_select_file: called;
type=2, path=3f0050157f21
0xb72236c0 09:33:58.562 [pkcs15-init]
card-openpgp.c:714:pgp_select_file: called
0xb72236c0 09:33:58.562 [pkcs15-init]
card-openpgp.c:739:pgp_select_file: returning with: -1201 (File not found)
 
Or the layout with PKCS15-AppDF is mandatory from the pkcs15 view?
If yes, I will consider to change the emulated file system layout in the
OpenPGP driver.

&amp;lt; at &amp;gt;Peter Marschall: You and me are working on OpenPGP. How do u think
about changing the emulated file layout. How should I do to not break
too much the code base?
Thanks.

&lt;/pre&gt;</description>
    <dc:creator>Nguyễn Hồng Quân</dc:creator>
    <dc:date>2012-05-23T03:45:46</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.encryption.opensc.devel/14086">
    <title>Re: OpenPGP card / Cryptostick - current status???</title>
    <link>http://permalink.gmane.org/gmane.comp.encryption.opensc.devel/14086</link>
    <description>&lt;pre&gt;Hi,

On Sunday, 20. May 2012, Peter Koch wrote:

I mostly re-factored card-openpg.c for better extensibility and extended it
to also support OpenPGPv2 cards.

The basic idea of the otriginal emulation was untouched
I aso tried to lay foundations for (maybe very limited) write support,
but 
a) real life took its toll
b) I did not get the real idea for thw write support

Martin started the extension of pkcs15-openpgp.c to support OpenPGP v2 cards 
which I continued. (but again: without write support)

While I currently don't have an idea for a breakthrough, I'll try to stay up-
to-date, adding small fixes where needed (and hoping for genius striking me ;-)

See above ;-)

Correct, but card-openpgp.c emulates a file system by treating
plain DOs as EFs and constructed (via ASN.1's TLV encoding) as DFs
with the ASN.1 label inside as the EFs / DFs in the next level down.

Simply try opensc-explorer on an initialized OpenPGPv2 card, and you'll
get the idea.

Hmm, it depends.
While you cannot create real DFs or EFs, I do not consider it impossible
to implement write support through the emulation:
i..
* for a DO that gets emulated to an EF, it should be possible to detect the
  write to the EF in the emulation layer and convert this to an DO update
* for DFs it might become a bit more tricky.
   (Maybe this is not needed - needs a very close look at the specs 
   + the right ideas ;-)


I'd personally would not hold my breath.
But maybe Nguyễn Hồng Quân is the one with that idea that give the 
breakthrough.

I definitely cannot tell, as I do not know what is needed in the PKCS15 and/or 
PCS11 levels.
I consider opensc heaily under-documented w.r.t how everything is tied togeth
(this is not specific to opensc alone, but seems to be specific to security 
related software in general ;-)

Best
Peter

&lt;/pre&gt;</description>
    <dc:creator>Peter Marschall</dc:creator>
    <dc:date>2012-05-22T19:18:47</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.encryption.opensc.devel/14085">
    <title>Re: BT reader</title>
    <link>http://permalink.gmane.org/gmane.comp.encryption.opensc.devel/14085</link>
    <description>&lt;pre&gt;
Actually I just installed the latest toolkit to my new android phone
and it requires initial pairing through USB (but IIRC it was possible
without it as well)

Nevertheless, the "NSA approved" devices all require/suggest pairing
in a secure location, with adequate pairing passwords etc. Which is
anyway a generally useful suggestion. I'd guess those guys know as
well what they are doing and what is wrong and what is right:

http://www.nsa.gov/ia/_files/factsheets/I732-016R-07.pdf
http://www.nsa.gov/ia/_files/wireless/BlueToothDoc.pdf

Then again, considering using convenience solutions (like a bluetooth
smart card reader at the moment mostly seems to be) vs "being paranoid
to the level of radio-sniffing-and-key-agreement-intercepting
adversary" is IMHO out of balance. I don't think that there are that
many scenarios where a bluetooth reader is a must have showstopper.

Martin
&lt;/pre&gt;</description>
    <dc:creator>Martin Paljak</dc:creator>
    <dc:date>2012-05-22T13:39:42</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.encryption.opensc.devel/14084">
    <title>Re: BT reader</title>
    <link>http://permalink.gmane.org/gmane.comp.encryption.opensc.devel/14084</link>
    <description>&lt;pre&gt;Il 22/05/2012 14:32, Martin Paljak ha scritto:

How does the AES key exchange work? 'cause it's the weak link...
If the attacker can obtain the AES key (for example if it's printed on
the unit and the attacker could see it), then it's the same as cleartext.

BYtE,
 Diego
&lt;/pre&gt;</description>
    <dc:creator>NdK</dc:creator>
    <dc:date>2012-05-22T13:01:54</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.encryption.opensc.devel/14083">
    <title>Re: BT reader</title>
    <link>http://permalink.gmane.org/gmane.comp.encryption.opensc.devel/14083</link>
    <description>&lt;pre&gt;Hello,


On Mon, May 21, 2012 at 2:46 PM, NdK &amp;lt;ndk.clanbo&amp;lt; at &amp;gt;gmail.com&amp;gt; wrote:


There's also a list of potential candidates in OpenSC wiki:

https://www.opensc-project.org/opensc/wiki/CardReaders#Bluetoothreaders

Out of those I've only selected Apriva (have one), as it comes with
and SDK for Android (last time I checked, it was pcsc-lite based,
javax.smartcardio-ish). Unfortunately, the protocol on BT level is not
available.

Regarding PIN codes, communication is protected with AES, in addition
to BT pairing.

Martin
&lt;/pre&gt;</description>
    <dc:creator>Martin Paljak</dc:creator>
    <dc:date>2012-05-22T12:32:43</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.encryption.opensc.devel/14082">
    <title>Getting Facial image and Biometrics off Piv Card</title>
    <link>http://permalink.gmane.org/gmane.comp.encryption.opensc.devel/14082</link>
    <description>&lt;pre&gt;Hello,

Sorry to send email on this thread, given that it is dated.  However it refers exactly to what I am doing at the moment.

First, thanks for the script posted here&amp;lt;http://www.opensc-project.org/pipermail/opensc-devel/2010-June/014318.html&amp;gt;, it was very helpful!

Second, this thread states:

It would greatly help me to see this program as well.  If it is available, can you send it to me?

Many Thanks.
--JDC

John Curtis

Software Development Manager
Cummings Engineering
(480) 459-0547

_______________________________________________
opensc-devel mailing list
opensc-devel&amp;lt; at &amp;gt;lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel&lt;/pre&gt;</description>
    <dc:creator>John Curtis</dc:creator>
    <dc:date>2012-05-18T23:41:28</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.encryption.opensc.devel/14081">
    <title>Re: BT reader</title>
    <link>http://permalink.gmane.org/gmane.comp.encryption.opensc.devel/14081</link>
    <description>&lt;pre&gt;
now i understand what you talking about...:P
&lt;/pre&gt;</description>
    <dc:creator>helpcrypto helpcrypto</dc:creator>
    <dc:date>2012-05-22T07:21:00</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.encryption.opensc.devel/14080">
    <title>Re: OpenPGP card / Cryptostick - current status???</title>
    <link>http://permalink.gmane.org/gmane.comp.encryption.opensc.devel/14080</link>
    <description>&lt;pre&gt;Hi all!


In the end of last year there has be an initiative by the German Privacy
Foundation to extend OpenSC's support of OpenPGP [1]. I don't know about
it's exact status, but the Job's status of the job offer is closed as
fixed [2]. I think, Nguyễn, you should try to find out if they have what
you need. At least the job's description looks like the stuff you are
trying to realize.

[1] http://www.opensc-project.org/pipermail/opensc-devel/2011-December/017541.html
[2] https://www.freelancer.com/projects/C-Programming-Computer-Security/patch-OpenSC-support-OpenPGP-Card.html

&lt;/pre&gt;</description>
    <dc:creator>Frank Morgner</dc:creator>
    <dc:date>2012-05-21T19:52:59</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.encryption.opensc.devel/14079">
    <title>Re: OpenPGP card / Cryptostick - current status???</title>
    <link>http://permalink.gmane.org/gmane.comp.encryption.opensc.devel/14079</link>
    <description>&lt;pre&gt;


5015 comes from your pkcs15init profile
https://github.com/hongquan/OpenSC-OpenPGP/commit/9b2ea7689b461c31b7ffda736d2c9dc332491562#L1R59
where your crypto objects are put inside the 'DF PKCS15-AppDF'.

Path for this DF is not defined in openpgp profile,
so, it takes it from the upper profile -- pkcs15.profile.
https://github.com/hongquan/OpenSC-OpenPGP/blob/openpgp/src/pkcs15init/pkcs15.profile#L135

Never tried it myself, but you can try the openpgp profile without
'PKCS15-AppDF'.


Beside the absence of pkcs15init support, afais,


If you are going to use the common pkcs15 and pkcs15init framework ,
you have to fill at least the 'write' hadle with the meanigfull actions .
https://github.com/hongquan/OpenSC-OpenPGP/blob/openpgp/src/libopensc/card-openpgp.c#L827
Inside this handle the 'PUT DATA'  or else can be used -- it's doesn't
matter.


&lt;/pre&gt;</description>
    <dc:creator>Viktor Tarasov</dc:creator>
    <dc:date>2012-05-21T14:00:53</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.encryption.opensc.devel/14078">
    <title>Re: BT reader</title>
    <link>http://permalink.gmane.org/gmane.comp.encryption.opensc.devel/14078</link>
    <description>&lt;pre&gt;Il 21/05/2012 14:11, helpcrypto helpcrypto ha scritto:
You don't. It's useful to mount an attack against any BT sc reader (if
sc doesn't support sm, or reader doesn't implement some extra security
over bt).

BYtE,
 Diego.
&lt;/pre&gt;</description>
    <dc:creator>NdK</dc:creator>
    <dc:date>2012-05-21T12:17:27</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.encryption.opensc.devel/14077">
    <title>Re: BT reader</title>
    <link>http://permalink.gmane.org/gmane.comp.encryption.opensc.devel/14077</link>
    <description>&lt;pre&gt;
how do you insert the smartcard there?...and how to connect it to the
android/iphone?
&lt;/pre&gt;</description>
    <dc:creator>helpcrypto helpcrypto</dc:creator>
    <dc:date>2012-05-21T12:11:04</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.encryption.opensc.devel/14076">
    <title>Re: BT reader</title>
    <link>http://permalink.gmane.org/gmane.comp.encryption.opensc.devel/14076</link>
    <description>&lt;pre&gt;
http://ubertooth.sourceforge.net/ about ~100 EUR including shipping.


//Peter
&lt;/pre&gt;</description>
    <dc:creator>Peter Stuge</dc:creator>
    <dc:date>2012-05-21T12:05:54</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.encryption.opensc.devel/14075">
    <title>Re: BT reader</title>
    <link>http://permalink.gmane.org/gmane.comp.encryption.opensc.devel/14075</link>
    <description>&lt;pre&gt;This might be interesting:
    http://www.apriva.com/products/iss/authentication/reader
Priced 150€ +/-
_______________________________________________
opensc-devel mailing list
opensc-devel&amp;lt; at &amp;gt;lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel&lt;/pre&gt;</description>
    <dc:creator>helpcrypto helpcrypto</dc:creator>
    <dc:date>2012-05-21T12:04:12</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.encryption.opensc.devel/14074">
    <title>Re: BT reader</title>
    <link>http://permalink.gmane.org/gmane.comp.encryption.opensc.devel/14074</link>
    <description>&lt;pre&gt;Il 21/05/2012 10:50, J.Witvliet&amp;lt; at &amp;gt;mindef.nl ha scritto:

Urgh... I wouldn't use a BT reader unless the card uses SM.
It's trivial, if you sniff the pairing, to decode the whole BT traffic.
And non-SM cards receive the pin as cleartext.

BYtE,
 Diego.
&lt;/pre&gt;</description>
    <dc:creator>NdK</dc:creator>
    <dc:date>2012-05-21T11:46:47</dc:date>
  </item>
  <textinput rdf:about="http://search.gmane.org/?group=$group=gmane.comp.encryption.opensc.devel">
    <title>Search Engine</title>
    <description>Search the mailing list at Gmane</description>
    <name>query</name>
    <link>http://search.gmane.org/?group=$group=gmane.comp.encryption.opensc.devel</link>
  </textinput>
</rdf:RDF>

