Hi Viktor,
Thanks for your response.
> > The first issue is that as per the IAS/ECC specifications, my key
> > is enabled for KeyDecipher or Unwrap usage, and not Decrypt. However,
> > it should still be made available as an AT_KEYEXCHANGE key, so that
> > the unwrap is possible.
>
> Sorry, i
Hi Viktor/all
The commit made on the 25 Dec - "minidriver: allow double key usage", on the
secure-messaging
branch introduced some issues for my testing of an IAS/ECC card.
The first issue is that as per the IAS/ECC specifications, my key is enabled
for KeyDecipher
or Unwrap usage, and not De
> >> My first suggestion is to set authId when parsing the contents of PrKDF.
> > Ok, for now that should work fine, although longer term a better solution
> > may be needed. Note that the AuthID may also be specified in terms of a
> > security environment, which makes things a lot more complicated
Hi Viktor/all
As previously discussed (see thread -
http://www.opensc-project.org/pipermail/opensc-devel/2011-December/017486.html),
please find
attached an internal public domain implementation of the SHA1 algorithm in
order to calculate
key GUID's for the minidriver without depending on Open
On 08 December 2011 11:03 Viktor Tarasov wrote:
> Le 07/12/2011 15:24, Hunter William a écrit :
> >> Is it happens for you to have the accessControlRule that protects by
> >> the different 'PIN' objects the IntrenalAuth, Decipher and Sign
> >> operation
On 08 December 2011 00:41 Douglas E. Engert wrote:
> With regards to the original problem of a short serial number
> being the issue, the problem may be that some code is comparing
> the MAX_CONTAINER_NAME_LEN as binary and not as a string.
> We may have in OpenSC some field that is not initialized
> -Original Message-
> From: Douglas E. Engert [mailto:deeng...@anl.gov]
> Sent: 08 December 2011 00:41
>
> > I did notice this - however, I also noticed that the piv_get_guid
> routine returns values which
> > are in a different format to the normal routine - it returns e.g.
> "1A2B3C.
Hi Viktor,
> -Original Message-
> From: Viktor Tarasov [mailto:viktor.tara...@gmail.com]
> Sent: 07 December 2011 13:08
>
> Hello William,
>
> Le 06/12/2011 11:54, Hunter William a écrit :
> > Looking at the specs, the card seems correct - it seems that the
> -Original Message-
> From: Viktor Tarasov [mailto:viktor.tara...@gmail.com]
>
> Le 06/12/2011 16:42, Douglas E. Engert a écrit :
> > There are some cards where there is a GUID on the card card driver
> > can provide a routine to get the GUID. in card-piv.c:
> >p15card->ops.get_guid =
Hi Viktor/all,
It seems that in the following commit to the secure-messaging branch - "pkcs11:
rewrite
pkcs15_create_tokens() -- use static sub-funcs" - the requirement for a private
key to have a link
to a PIN ID got a bit stricter. In previous versions, it seems that if an
object wasn't add
> Since the minidriver is being built within the Microsoft Crypto
> framework, rather then using OpenSSL SHA1, we could use a Microsoft
> hash
> function.
>
> Thus we do not depend on #ifdef ENABLE_OPENSSL for this one purpose.
>
Ok, this is a good idea. I can make this change. One question tho
Hi,
Having just done this, I may be able to help. You do need the minidriver
installed for this to work. Check out
http://www.opensc-project.org/opensc/wiki/MiniDriver for details. In a nutshell:
- Make sure you have the minidriver dll - you may need a different version of
OpenSC (look for ope
Hi,
I've attached a patch for some updates that I've made to Viktor's
secure-messaging branch. Sorry about the size and number of changes - I didn't
initially think that there would be so many. The commit details are after this
message. I've used the secure-messaging branch because it seems to
13 matches
Mail list logo
