Menu
▾
▴
opensc-devel
|
From: Jakub J. <jj...@re...> - 2016-10-04 09:56:02
|
Hello all, recently we discussed the usefulness of the onepin library and basically came to conclusion that the onepin should be used by default. Most of the cards have only one pin (if there is the second, it is most probably not needed to be visible in the PKCS#11, since should be "signature pin") and also the PKCS#11 specification is moving away from the mapping of multiple pins to multiple PKCS#11 tokens (citation needed?). The intention of this email is to start a discussion, if we still want to have virtual slots by default. Mozilla is not going to expose the "friendly bit" in UI [1], which would be possible workaround. But AFAIK, we could make that default and for the other use cases create some virtual-slots-opensc-pkcs11.so which would behave like the current default. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=322145 Regards, -- Jakub Jelen Security Technologies Red Hat |
|
From: David W. <dw...@in...> - 2016-10-04 11:17:58
Attachments:
smime.p7s
|
On Tue, 2016-10-04 at 11:55 +0200, Jakub Jelen wrote: > Hello all, > > recently we discussed the usefulness of the onepin library and basically > came to conclusion that the onepin should be used by default. Most of > the cards have only one pin (if there is the second, it is most probably > not needed to be visible in the PKCS#11, since should be "signature > pin") and also the PKCS#11 specification is moving away from the mapping > of multiple pins to multiple PKCS#11 tokens (citation needed?). The citation for that would be http://docs.oasis-open.org/pkcs11/pkcs11-ug/v2.40/cn02/pkcs11-ug-v2.40-cn02.html#_Toc406760011 > The intention of this email is to start a discussion, if we still want > to have virtual slots by default. Mozilla is not going to expose the > "friendly bit" in UI [1], which would be possible workaround. But AFAIK, > we could make that default and for the other use cases create some > virtual-slots-opensc-pkcs11.so which would behave like the current default. > > [1] https://bugzilla.mozilla.org/show_bug.cgi?id=322145 Hm, that manages to be all about the CKA_PRIVATE attribute on objects, without ever once mentioning CKA_PRIVATE. Impressive :) It seems that the NSS softokn doesn't *permit* you to specify CKA_PRIVATE==CK_TRUE when importing a cert... $ p11tool --load-certificate ec-cert.pem --mark-private --label OC-EC --id 123403 --write 'pkcs11:token=NSS%20Certificate%20DB' ... C_CreateObject IN: hSession = S16777217 IN: pTemplate = (10) [ CKA_CLASS, CKA_ID, CKA_VALUE, CKA_TOKEN, CKA_CERTIFICATE_TYPE, CKA_SUBJECT, CKA_ISSUER, CKA_SERIAL_NUMBER, CKA_LABEL, CKA_PRIVATE ] C_CreateObject = CKR_ATTRIBUTE_VALUE_INVALID NSS therefore knows that its own token will always show *all* certificates in a C_FindObjects() call even before login. It calls this special-case behaviour "friendly". We can't know that other tokens are "friendly", because objects can be explicitly created with CKA_PRIVATE==CK_TRUE and if they are created *without* an explicit value for CKA_PRIVATE then the token itself gets to choose, and some tokens *do* set CKA_PRIVATE==CK_TRUE even for CKO_CERTIFICATE objects, if given the choice. So what's the problem here? That NSS is trying to log in to *all* the different PKCS#11 slots of a given card, which are exposed separately in PKCS#11 because they *might* theoretically have different PINs? And the proposed solution is to stop exposing multiple PKCS#11 slots per card, because in practice people *don't* actually set multiple PINs on the same card? So at least they only get one PIN prompt? I'd still prefer to see the NSS behaviour improved, and perhaps achieve some kind of consensus on how we search for objects in various "friendly" and non-friendly tokens. For a start, why can't we iterate over all the tokens and see if we find what we're after, and only *then* go back and log in to the ones that need it, if we don't? Although that doesn't necessarily fix Firefox when we *don't* have a client cert and the request was just opportunistic, it would fix many cases where the object *is* found. It might also be interesting to approach the PKCS#11 TC and suggest a new flag which tokens can report, to indicate that they *are* "friendly", which is defined as "has no CKA_PRIVATE certificates". Or perhaps the C_FindObjects() API can be extended in a compatible way, to allow a token to indicate that "No CKA_PRIVATE objects were excluded from these results" for *that* specific C_FindObjects() call. Then NSS *would* be able to extend its "PK11_IsFriendly()" hack to cover tokens other than its own internal softokn. -- dwmw2 |
|
From: Jakub J. <jj...@re...> - 2016-10-04 12:41:37
|
On 10/04/2016 01:17 PM, David Woodhouse wrote: > On Tue, 2016-10-04 at 11:55 +0200, Jakub Jelen wrote: >> Hello all, >> >> recently we discussed the usefulness of the onepin library and basically >> came to conclusion that the onepin should be used by default. Most of >> the cards have only one pin (if there is the second, it is most probably >> not needed to be visible in the PKCS#11, since should be "signature >> pin") and also the PKCS#11 specification is moving away from the mapping >> of multiple pins to multiple PKCS#11 tokens (citation needed?). > The citation for that would be > http://docs.oasis-open.org/pkcs11/pkcs11-ug/v2.40/cn02/pkcs11-ug-v2.40-cn02.html#_Toc406760011 Thank you for the reference. It is exactly what I had in my mind, but I didn't find proper words to pinpoint that. >> The intention of this email is to start a discussion, if we still want >> to have virtual slots by default. Mozilla is not going to expose the >> "friendly bit" in UI [1], which would be possible workaround. But AFAIK, >> we could make that default and for the other use cases create some >> virtual-slots-opensc-pkcs11.so which would behave like the current default. >> >> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=322145 > [...] > > So what's the problem here? That NSS is trying to log in to *all* the > different PKCS#11 slots of a given card, which are exposed separately > in PKCS#11 because they *might* theoretically have different PINs? That is basically the original problem in the bug and one of the variants brought up many times on this mailing list and among Mozilla users. But so far, the proposed solution was to use "onepin". There was an pressure on Mozilla to change their behavior (above bug), but it was never accepted. Instead the specification shifted the onepin way. I think upstream projects should follow specification recommendations and make the tools working for most of the current users and use cases, unless there is a good reason not to do that. > And the proposed solution is to stop exposing multiple PKCS#11 slots > per card, because in practice people *don't* actually set multiple PINs > on the same card? So at least they only get one PIN prompt? > > I'd still prefer to see the NSS behaviour improved, and perhaps achieve > some kind of consensus on how we search for objects in various > "friendly" and non-friendly tokens. > > For a start, why can't we iterate over all the tokens and see if we > find what we're after, and only *then* go back and log in to the ones > that need it, if we don't? Although that doesn't necessarily fix > Firefox when we *don't* have a client cert and the request was just > opportunistic, it would fix many cases where the object *is* found. The problem is how you define what "you're after". Unless you log in, you can never know if it is everything what you can see. You can have a card showing only single certificate before login and hiding the other, which would lead into very unexpected behavior for users. You can also have empty cards, which would also fail with this heuristic. > It might also be interesting to approach the PKCS#11 TC and suggest a > new flag which tokens can report, to indicate that they *are* > "friendly", which is defined as "has no CKA_PRIVATE certificates". Or > perhaps the C_FindObjects() API can be extended in a compatible way, to > allow a token to indicate that "No CKA_PRIVATE objects were excluded > from these results" for *that* specific C_FindObjects() call. Then NSS > *would* be able to extend its "PK11_IsFriendly()" hack to cover tokens > other than its own internal softokn. This would be the optimal approach, but it sounds like a run on a very long distance, updating all the software to reflect these flags and the new cards to publish these attributes. But thank you for mentioning that. I will try to pursuit that. Regards, -- Jakub Jelen Security Technologies Red Hat |
|
From: David W. <dw...@in...> - 2016-10-04 16:39:44
Attachments:
smime.p7s
|
On Tue, 2016-10-04 at 14:41 +0200, Jakub Jelen wrote: > On 10/04/2016 01:17 PM, David Woodhouse wrote: > > So what's the problem here? That NSS is trying to log in to *all* the > > different PKCS#11 slots of a given card, which are exposed separately > > in PKCS#11 because they *might* theoretically have different PINs? > > That is basically the original problem in the bug and one of the > variants brought up many times on this mailing list and among Mozilla > users. But so far, the proposed solution was to use "onepin". There was > an pressure on Mozilla to change their behavior (above bug), but it was > never accepted. Instead the specification shifted the onepin way. > > I think upstream projects should follow specification recommendations > and make the tools working for most of the current users and use cases, > unless there is a good reason not to do that. Well, the problem is that the specification doesn't actually *give* any recommendations here. The overall behaviour of applications trying to find an object across a number of PKCS#11 tokens is *entirely* unspecified, without even any hints about common practice in the Usage Guide. I'm trying to remedy that (amongst other things) in http://david.woodhou.se/draft-woodhouse-cert-best-practice.html > > For a start, why can't we iterate over all the tokens and see if we > > find what we're after, and only *then* go back and log in to the ones > > that need it, if we don't? Although that doesn't necessarily fix > > Firefox when we *don't* have a client cert and the request was just > > opportunistic, it would fix many cases where the object *is* found. > > The problem is how you define what "you're after". Unless you log in, > you can never know if it is everything what you can see. You can have a > card showing only single certificate before login and hiding the other, > which would lead into very unexpected behavior for users. You can also > have empty cards, which would also fail with this heuristic. Right. So far I've been focusing on tools which take a certificate specifier (previously just a filename, but now a PKCS#11 URI) on the command line or in a config file. In that case it's simple — if the certificate has CKA_PRIVATE==CK_TRUE, then the PKCS11 URI needs to uniquely specify the token. Then we'll log into that token, and find the certificate we need. For NSS, some of the FindCertificate* APIs do operate only on the internal softokn, and not on external tokens at all. Others will attempt to iterate over all tokens, requiring PINs for them all. > > > > It might also be interesting to approach the PKCS#11 TC and suggest a > > new flag which tokens can report, to indicate that they *are* > > "friendly", which is defined as "has no CKA_PRIVATE certificates". Or > > perhaps the C_FindObjects() API can be extended in a compatible way, to > > allow a token to indicate that "No CKA_PRIVATE objects were excluded > > from these results" for *that* specific C_FindObjects() call. Then NSS > > *would* be able to extend its "PK11_IsFriendly()" hack to cover tokens > > other than its own internal softokn. > > This would be the optimal approach, but it sounds like a run on a very > long distance, updating all the software to reflect these flags and the > new cards to publish these attributes. But thank you for mentioning > that. I will try to pursuit that. Actually, there isn't *much* software to update. Applications generally don't do this for themselves. We fix NSS, GnuTLS and the OpenSSL PKCS#11 ENGINE, and that actually covers *much* of the ecosystem. But first we do need a consensus on the behaviour we want them to implement. Even in the Mozilla bug you referenced, I don't see a specific algorithm that would work. -- dwmw2 |
|
From: <fra...@gm...> - 2016-10-04 13:56:27
|
Hi! If I'm not mistaken, we are not exposing a virtual hotplug slot to the application anymore. Slots are only created for actual readers, see https://github.com/OpenSC/OpenSC/blob/master/src/pkcs11/slot.c#L142. I reintroduced the virtual hotplug slot in https://github.com/OpenSC/OpenSC/pull/872, because NSS currently expects that, once created, a slot never disappears. Do you have a link to the one-pin-discussion? Regards, Frank. On Tuesday, October 04 at 11:55AM, Jakub Jelen wrote: > Hello all, > > recently we discussed the usefulness of the onepin library and basically > came to conclusion that the onepin should be used by default. Most of > the cards have only one pin (if there is the second, it is most probably > not needed to be visible in the PKCS#11, since should be "signature > pin") and also the PKCS#11 specification is moving away from the mapping > of multiple pins to multiple PKCS#11 tokens (citation needed?). > > The intention of this email is to start a discussion, if we still want > to have virtual slots by default. Mozilla is not going to expose the > "friendly bit" in UI [1], which would be possible workaround. But AFAIK, > we could make that default and for the other use cases create some > virtual-slots-opensc-pkcs11.so which would behave like the current default. > > [1] https://bugzilla.mozilla.org/show_bug.cgi?id=322145 > > Regards, > > -- > Jakub Jelen > Security Technologies > Red Hat > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > _______________________________________________ > Opensc-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opensc-devel > -- Frank Morgner Virtual Smart Card Architecture http://vsmartcard.sourceforge.net OpenPACE http://openpace.sourceforge.net IFD Handler for libnfc Devices http://sourceforge.net/projects/ifdnfc |
|
From: Jakub J. <jj...@re...> - 2016-10-04 16:30:17
|
On 10/04/2016 03:56 PM, fra...@gm... wrote: > Hi! > > If I'm not mistaken, we are not exposing a virtual hotplug slot to the > application anymore. Yes, you are right. The master does not show this one. But as far as I understand to this problem is not in the virtual hotplug, but in the PINs of the card creating the virtual slots, isn't it? > Slots are only created for actual readers, see > https://github.com/OpenSC/OpenSC/blob/master/src/pkcs11/slot.c#L142. I > reintroduced the virtual hotplug slot in > https://github.com/OpenSC/OpenSC/pull/872, because NSS currently expects > that, once created, a slot never disappears. > > Do you have a link to the one-pin-discussion? It was internal/offline discussion, mostly theoretical (based on the mails, comments and issues), because I don't have any cards exposing more PINs in this way and that would make a difference of the both libraries to test. From the discussion, what we would like to avoid is to have two (basically same) libraries in the OS for several reasons (p11-kit, ...). The inception to make the other symlink came in the mailing list more than two years ago [1] without any follow up. The pursuing the solution without virtual slots (single PIN) sounds reasonable for most of the cards. But still I might miss some part of the current behavior so correct me if I am wrong. [1] http://opensc.1086184.n5.nabble.com/opensc-onepin-td14433.html Regards, -- Jakub Jelen Security Technologies Red Hat |
|
From: Frank M. <fra...@gm...> - 2017-08-23 19:29:59
|
I think the onepin module is only needed for Firefox, which doesn't handle two PINs in a user convenient way. We could try to guess if we were loaded by Firefox and then switch on the onepin setting (if it wasn't specified via opensc.conf. Finding out which process loaded the PKCS#11 module could, however, get a bit complicated (https://stackoverflow.com/a/1024937)... Anyway, that would eliminate the need for the onepin module! 2016-10-04 18:30 GMT+02:00 Jakub Jelen <jj...@re...>: > On 10/04/2016 03:56 PM, fra...@gm... wrote: > > Hi! > > > > If I'm not mistaken, we are not exposing a virtual hotplug slot to the > > application anymore. > > Yes, you are right. The master does not show this one. But as far as I > understand to this problem is not in the virtual hotplug, but in the > PINs of the card creating the virtual slots, isn't it? > > > Slots are only created for actual readers, see > > https://github.com/OpenSC/OpenSC/blob/master/src/pkcs11/slot.c#L142. I > > reintroduced the virtual hotplug slot in > > https://github.com/OpenSC/OpenSC/pull/872, because NSS currently expects > > that, once created, a slot never disappears. > > > > Do you have a link to the one-pin-discussion? > It was internal/offline discussion, mostly theoretical (based on the > mails, comments and issues), because I don't have any cards exposing > more PINs in this way and that would make a difference of the both > libraries to test. > > From the discussion, what we would like to avoid is to have two > (basically same) libraries in the OS for several reasons (p11-kit, ...). > The inception to make the other symlink came in the mailing list more > than two years ago [1] without any follow up. The pursuing the solution > without virtual slots (single PIN) sounds reasonable for most of the > cards. But still I might miss some part of the current behavior so > correct me if I am wrong. > > [1] http://opensc.1086184.n5.nabble.com/opensc-onepin-td14433.html > > Regards, > > -- > Jakub Jelen > Security Technologies > Red Hat > > > ------------------------------------------------------------ > ------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > _______________________________________________ > Opensc-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opensc-devel > |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X