Re: [Freeipa-devel] DNSSEC key wrapping: cryptographer needed
On Tue, 2014-06-24 at 15:33 -0400, Simo Sorce wrote: > On Tue, 2014-06-24 at 20:30 +0200, Petr Spacek wrote: > > In this case the standard says that user has to provide IV explicitly and > > the > > C_WrapKey should fall-back to standardized default if IV was not given by > > user. > > Sounds completely bogus, but in this case we'll have to either provide a > random IV ourselves (and then store it alongside or provide data with a Add "the key data)" here-^ Simo. > confounder at the start implementing padding on our own. > > > See section "6.13.3 AES Key Wrap" in "PKCS #11 Mechanisms v2.30: Cryptoki – > > Draft 7" on > > ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-11/v2-30/pkcs-11v2-30m1-d7.pdf > > > > > > > >> >What do we do? > > >> >- Convince OpenSSL to review and accept the patch? > > > I would say the patch is not too useful as is - there are multiple > > > problems with it such as it is not using proper high level interfaces > > > for the AES encryption, etc. > > Ah, right, nowadays openssl/crypto/aes/aes_wrap.c file is very different > > from > > the 2010-version. I didn't notice it. > > > > Would you review the patch if we re-write it against current OpenSSL git > > head? > > > > -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] DNSSEC key wrapping: cryptographer needed
On Tue, 2014-06-24 at 20:30 +0200, Petr Spacek wrote: > On 24.6.2014 15:45, Tomas Mraz wrote: > >> >Technically SoftHSM's C_WrapKey call produces PKCS#8 structure encrypted > >> >with > >> >AES according to RFC 3394 (no padding) or RFC 5649 (with padding). > >> > > >> >RFC 3394 works only on blocks of 64 bits, which is not our case because > >> >EncryptedPrivateKeyInfo has no padding. So we should use RFC 5649 to get > >> >proper padding etc. > >> > > >> >And here is the problem: SoftHSM can use RFC 5649 using OpenSSL functions > >> >but > >> >OpenSSL doesn't support RFC 5649! The patch with this functionality was > >> >submitted back in 2010 to OpenSSL bug tracker [3] but the ticket is in > >> >state > >> >"new" and there was no reply to the e-mail in the original thread [4]. > > I am sorry, but this does not make much sense to me. Iff the SoftHSM's > > C_WrapKey is really safe wrapping method for backing up and/or > > replicating HSM's it must provide wrapped key in such format that the IV > > is pregenerated as part of the Wrap operation and stored in the final > > blob of wrapped key. Unfortunately I do not know much of SoftHSM. > SoftHSM is "just" PKCS#11 interface implementation so SoftHSM can't do > something against PKCS#11 standard. > > In this case the standard says that user has to provide IV explicitly and the > C_WrapKey should fall-back to standardized default if IV was not given by > user. Sounds completely bogus, but in this case we'll have to either provide a random IV ourselves (and then store it alongside or provide data with a confounder at the start implementing padding on our own. > See section "6.13.3 AES Key Wrap" in "PKCS #11 Mechanisms v2.30: Cryptoki – > Draft 7" on > ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-11/v2-30/pkcs-11v2-30m1-d7.pdf > > > > >> >What do we do? > >> >- Convince OpenSSL to review and accept the patch? > > I would say the patch is not too useful as is - there are multiple > > problems with it such as it is not using proper high level interfaces > > for the AES encryption, etc. > Ah, right, nowadays openssl/crypto/aes/aes_wrap.c file is very different from > the 2010-version. I didn't notice it. > > Would you review the patch if we re-write it against current OpenSSL git head? > -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] DNSSEC key wrapping: cryptographer needed
On 24.6.2014 15:45, Tomas Mraz wrote: >Technically SoftHSM's C_WrapKey call produces PKCS#8 structure encrypted with >AES according to RFC 3394 (no padding) or RFC 5649 (with padding). > >RFC 3394 works only on blocks of 64 bits, which is not our case because >EncryptedPrivateKeyInfo has no padding. So we should use RFC 5649 to get >proper padding etc. > >And here is the problem: SoftHSM can use RFC 5649 using OpenSSL functions but >OpenSSL doesn't support RFC 5649! The patch with this functionality was >submitted back in 2010 to OpenSSL bug tracker [3] but the ticket is in state >"new" and there was no reply to the e-mail in the original thread [4]. I am sorry, but this does not make much sense to me. Iff the SoftHSM's C_WrapKey is really safe wrapping method for backing up and/or replicating HSM's it must provide wrapped key in such format that the IV is pregenerated as part of the Wrap operation and stored in the final blob of wrapped key. Unfortunately I do not know much of SoftHSM. SoftHSM is "just" PKCS#11 interface implementation so SoftHSM can't do something against PKCS#11 standard. In this case the standard says that user has to provide IV explicitly and the C_WrapKey should fall-back to standardized default if IV was not given by user. See section "6.13.3 AES Key Wrap" in "PKCS #11 Mechanisms v2.30: Cryptoki – Draft 7" on ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-11/v2-30/pkcs-11v2-30m1-d7.pdf >What do we do? >- Convince OpenSSL to review and accept the patch? I would say the patch is not too useful as is - there are multiple problems with it such as it is not using proper high level interfaces for the AES encryption, etc. Ah, right, nowadays openssl/crypto/aes/aes_wrap.c file is very different from the 2010-version. I didn't notice it. Would you review the patch if we re-write it against current OpenSSL git head? -- Petr^2 Spacek ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] DNSSEC key wrapping: cryptographer needed
On Po, 2014-06-23 at 14:57 +0200, Petr Spacek wrote: > Hello list, > > I'm working on key wrapping mechanism described in thread "LDAP schema for > DNSSEC keys" [0] and I'm really puzzled from the maze of crypto here. I would > really appreciate any suggestions or comments on this. I am not sure I am able to respond to all of your questions and problems you're trying to solve but let's try at least some. > - I have difficulties to pick and use proper wrapping mechanisms and their > configuration/usage patterns. > > - Rick van Rein from OpenDNSSEC-user list noted that we are defeating purpose > of PKCS#11 by exporting raw keys from HSM. I can see his point and we should > be able to do all crypto operations inside SoftHSM. > > I have asked him to describe his doubts on freeipa-devel list - stay tuned. It is really questionable what are you trying to achieve here. I would definitely stay away from trying to replicate any back-up mechanisms that eventual HSM (software or hardware one) should have. This is all fairly non-trivial functionality and if any HSM implementation is serious enough it should have backup facility of its own (which should also allow duplicating such HSM if needed). Note that simply allowing to export wrapped key with a key you provide to HSM during a normal operation (not as a special privileged operation) is defeating the purpose of HSM anyway as you can unwrap the protected key as you wish. So the only wrapping key that can be used in normal operation should be a key that is preset or pre-generated in the HSM by the HSM admin. > > We need to wrap > === > - asymmetric key (zone key) with symmetric key (master key) > - symmetric key (master key) with asymmetric key (replica key) Can you please provide more info what purpose these keys have? I understand that the zone key is the DNSSEC asymmetric key for the zone. But what about the master key and replica key? Why the master key is symmetric and the replica asymmetric? > LDAP schema prescribes some storage formats but my question is about crypto > algorithms (and padding!) used for key wrapping. > > > Asymmetric keys > === > According to schema [1] wrapped asymmetric (i.e. private) key must be stored > in 'ipaPrivateKey' attribute as DER-encoded EncryptedPrivateKeyInfo structure > according to RFC 5958 [2]. > > It seem that SoftHSM's C_WrapKey PKCS#11 call will give us encryptedData part > of EncryptedPrivateKeyInfo structure so we only have to add algorithm > identifier, DER-encode the whole thing, and we could be done. > > I'm not sure where should I stick IV or what happens if default (fixed) IV > value is left in place...? In general using fixed IV when encrypting multiple data (keys) with the same key breaks the security of the wrapped data. So no, fixed IV must not be used. > > Technically SoftHSM's C_WrapKey call produces PKCS#8 structure encrypted with > AES according to RFC 3394 (no padding) or RFC 5649 (with padding). > > RFC 3394 works only on blocks of 64 bits, which is not our case because > EncryptedPrivateKeyInfo has no padding. So we should use RFC 5649 to get > proper padding etc. > > And here is the problem: SoftHSM can use RFC 5649 using OpenSSL functions but > OpenSSL doesn't support RFC 5649! The patch with this functionality was > submitted back in 2010 to OpenSSL bug tracker [3] but the ticket is in state > "new" and there was no reply to the e-mail in the original thread [4]. I am sorry, but this does not make much sense to me. Iff the SoftHSM's C_WrapKey is really safe wrapping method for backing up and/or replicating HSM's it must provide wrapped key in such format that the IV is pregenerated as part of the Wrap operation and stored in the final blob of wrapped key. Unfortunately I do not know much of SoftHSM. > What do we do? > - Convince OpenSSL to review and accept the patch? I would say the patch is not too useful as is - there are multiple problems with it such as it is not using proper high level interfaces for the AES encryption, etc. > - Hack it around #0: Use something else as key wrapping method? Other > wrapping > methods would require SoftHSM modification because SoftHSM supports only AES > mechanisms now. > - Hack it around #1: Implement the RFC 5649 wrapping algorithm in a > downstream > patch in SoftHSM? Do we have enough expertise to implement it correctly? > - Hack it around #2: Implement raw key extraction from SoftHSM and do key > wrapping somehow somewhere? (Please nooo.) > > > Symmetric keys > == > should be stored in 'ipaSecretKey' attribute but detailed storage format > definition is missing from schema [1] right now. > > Unfortunately, SoftHSM doesn't support C_WrapKey PKCS#11 function with > asymmetric key as *wrapping* key so we need to add this functionality. > > The first question is: > What algorithm and padding scheme should we use? > > Something like OpenSSL's RSA_PKCS1_OAEP_PADDING [6]
Re: [Freeipa-devel] DNSSEC key wrapping: cryptographer needed
- Original Message - > Hello list, > > I'm working on key wrapping mechanism described in thread "LDAP schema for > DNSSEC keys" [0] and I'm really puzzled from the maze of crypto here. I would > really appreciate any suggestions or comments on this. > > - I have difficulties to pick and use proper wrapping mechanisms and their > configuration/usage patterns. > > - Rick van Rein from OpenDNSSEC-user list noted that we are defeating purpose > of PKCS#11 by exporting raw keys from HSM. I can see his point and we should > be able to do all crypto operations inside SoftHSM. > > I have asked him to describe his doubts on freeipa-devel list - stay tuned. > > > We need to wrap > === > - asymmetric key (zone key) with symmetric key (master key) > - symmetric key (master key) with asymmetric key (replica key) > > LDAP schema prescribes some storage formats but my question is about crypto > algorithms (and padding!) used for key wrapping. It is important to get these details right indeed, we must be able to change crypto algorithms if needed in the future, so algorithm agility must be part of the story. > Asymmetric keys > === > According to schema [1] wrapped asymmetric (i.e. private) key must be stored > in 'ipaPrivateKey' attribute as DER-encoded EncryptedPrivateKeyInfo structure > according to RFC 5958 [2]. > > It seem that SoftHSM's C_WrapKey PKCS#11 call will give us encryptedData part > of EncryptedPrivateKeyInfo structure so we only have to add algorithm > identifier, DER-encode the whole thing, and we could be done. Right. > I'm not sure where should I stick IV or what happens if default (fixed) IV > value is left in place...? We cannot use a fixed IV unless the wrapping algorithm uses an obfuscator within the data, otherwise you open yourself up for attacks. I expect the IV (if needed) to be provided by the SoftHSM itself ? If not something sounds broken. If the IV is fixed for some reason we culd provide the data with a secret confounder in the first block, but then we would not respect the standard in the first place. I will try to take a look at RFC 5958 once I am back at home tomorrow. > Technically SoftHSM's C_WrapKey call produces PKCS#8 structure encrypted with > AES according to RFC 3394 (no padding) or RFC 5649 (with padding). > > RFC 3394 works only on blocks of 64 bits, which is not our case because > EncryptedPrivateKeyInfo has no padding. So we should use RFC 5649 to get > proper padding etc. We could also define how we generate padding ourselves if RFC 3394 is easier, although of course using RFC 5649 wuld be preferable rather than massaging the data ourselves. > And here is the problem: SoftHSM can use RFC 5649 using OpenSSL functions but > OpenSSL doesn't support RFC 5649! The patch with this functionality was > submitted back in 2010 to OpenSSL bug tracker [3] but the ticket is in state > "new" and there was no reply to the e-mail in the original thread [4]. > > What do we do? > - Convince OpenSSL to review and accept the patch? If we are using a standard this is not as important, we can make our own implementation and then work with the OpenSSL community to get a proper implementation in. Does NSS implements it btw ? > - Hack it around #0: Use something else as key wrapping method? Other > wrapping > methods would require SoftHSM modification because SoftHSM supports only AES > mechanisms now. > - Hack it around #1: Implement the RFC 5649 wrapping algorithm in a > downstream > patch in SoftHSM? Do we have enough expertise to implement it correctly? > - Hack it around #2: Implement raw key extraction from SoftHSM and do key > wrapping somehow somewhere? (Please nooo.) No, let's use standards where they exist, it is ok to make our own implementation until upstream libraries finally get a good one, but let's avoid completely custom stuff. > Symmetric keys > == > should be stored in 'ipaSecretKey' attribute but detailed storage format > definition is missing from schema [1] right now. > > Unfortunately, SoftHSM doesn't support C_WrapKey PKCS#11 function with > asymmetric key as *wrapping* key so we need to add this functionality. > > The first question is: > What algorithm and padding scheme should we use? We need algorithm agility here too, so I would use some generic envelope mechanism defined for encrypting data with asymetric keys and use it. If it is a good mechanism it will allow to use multiple algorithms and key sizes etc.. > Something like OpenSSL's RSA_PKCS1_OAEP_PADDING [6]? That would be relatively > easy to implement to SoftHSM because it is already there, just not handled in > C_WrapKey (so we need to add appropriate 'glue' there). I would not use something that ties us to RSA keys, it is probably highly desirable to use EC keys too as an alternative. > Another question is storage format of the wrapped key. > PKCS#11 2.40d2 [7] contains this comment about "PKCS #1 RSA OAEP" algorithm: >
Re: [Freeipa-devel] DNSSEC key wrapping: cryptographer needed
Tomas Mraz: > On, 2014-06-23 at 14:57 +0200, Petr Spacek wrote: > > We need to wrap > > === > > - asymmetric key (zone key) with symmetric key (master key) > > - symmetric key (master key) with asymmetric key (replica key) > > Can you please provide more info what purpose these keys have? I > understand that the zone key is the DNSSEC asymmetric key for the zone. > But what about the master key and replica key? Why the master key is > symmetric and the replica asymmetric? What we want is the ability to store keys in LDAP so that multiple servers can generate DNSSEC keys. This allows no single points of failure, and also allows local servers to generate signatures for DNS names that may differ from replica to replica in the future (think things like views). In order to do that each DNS server need access to the Zone keys, but we do not want to distribute the unencrypted in LDAP. We also do not want to have to invent a parallel distribution method to send these keys to all the replicas that need them. We do have a private/public key pair on each replica though so we can use this fact to wrap a symmetric master key with all the public keys of the replicas that need access to the zone keys, and encrypt the zone keys with this master key. The reason to use a symmetric in the middle is that is allows for a few things: 1. it is easy to re-encrypt it t replica creation time by one of the other servers as soon as the replica is built and publishes its on key. This solves the distribution problem to new replicas. This same mechanism also allows to redistribute a new key if you need/want to rotate it for whatever reason. It also avoids the need to encrypt every zone private key multiple times with each replica public key, which would cause a lot of churn. HTH, Simo. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] DNSSEC key wrapping: cryptographer needed
On 23.6.2014 14:57, Petr Spacek wrote: Hello list, I'm working on key wrapping mechanism described in thread "LDAP schema for DNSSEC keys" [0] and I'm really puzzled from the maze of crypto here. I would really appreciate any suggestions or comments on this. - I have difficulties to pick and use proper wrapping mechanisms and their configuration/usage patterns. - Rick van Rein from OpenDNSSEC-user list noted that we are defeating purpose of PKCS#11 by exporting raw keys from HSM. I can see his point and we should be able to do all crypto operations inside SoftHSM. I have asked him to describe his doubts on freeipa-devel list - stay tuned. We need to wrap === - asymmetric key (zone key) with symmetric key (master key) - symmetric key (master key) with asymmetric key (replica key) LDAP schema prescribes some storage formats but my question is about crypto algorithms (and padding!) used for key wrapping. Asymmetric keys === According to schema [1] wrapped asymmetric (i.e. private) key must be stored in 'ipaPrivateKey' attribute as DER-encoded EncryptedPrivateKeyInfo structure according to RFC 5958 [2]. It seem that SoftHSM's C_WrapKey PKCS#11 call will give us encryptedData part of EncryptedPrivateKeyInfo structure so we only have to add algorithm identifier, DER-encode the whole thing, and we could be done. I'm not sure where should I stick IV or what happens if default (fixed) IV value is left in place...? Technically SoftHSM's C_WrapKey call produces PKCS#8 structure encrypted with AES according to RFC 3394 (no padding) or RFC 5649 (with padding). RFC 3394 works only on blocks of 64 bits, which is not our case because EncryptedPrivateKeyInfo has no padding. So we should use RFC 5649 to get proper padding etc. And here is the problem: SoftHSM can use RFC 5649 using OpenSSL functions but OpenSSL doesn't support RFC 5649! The patch with this functionality was submitted back in 2010 to OpenSSL bug tracker [3] but the ticket is in state "new" and there was no reply to the e-mail in the original thread [4]. Does this mean SoftHSM does not support RFC 5649? What do we do? - Convince OpenSSL to review and accept the patch? - Hack it around #0: Use something else as key wrapping method? Other wrapping methods would require SoftHSM modification because SoftHSM supports only AES mechanisms now. - Hack it around #1: Implement the RFC 5649 wrapping algorithm in a downstream patch in SoftHSM? Do we have enough expertise to implement it correctly? - Hack it around #2: Implement raw key extraction from SoftHSM and do key wrapping somehow somewhere? (Please nooo.) Symmetric keys == should be stored in 'ipaSecretKey' attribute but detailed storage format definition is missing from schema [1] right now. I thought we already agreed on using raw encrypted blob. Unfortunately, SoftHSM doesn't support C_WrapKey PKCS#11 function with asymmetric key as *wrapping* key so we need to add this functionality. The first question is: What algorithm and padding scheme should we use? I guess PKCS#1 RSA or PKCS#1 RSA OAEP. Something like OpenSSL's RSA_PKCS1_OAEP_PADDING [6]? That would be relatively easy to implement to SoftHSM because it is already there, just not handled in C_WrapKey (so we need to add appropriate 'glue' there). Another question is storage format of the wrapped key. PKCS#11 2.40d2 [7] contains this comment about "PKCS #1 RSA OAEP" algorithm: "For wrapping, the “input” to the encryption operation is the value of the CKA_VALUE attribute of the key that is wrapped; similarly for unwrapping. The mechanism does not wrap the key type or any other information about the key, except the key length; the application must convey these separately." AFAIK it means that it wraps raw secret key and nothing else. If I'm not wrong we should be able to take resulting blob and stick it into OneSymmetricKey structure from RFC 6031 [5]. Honza, is it correct assumption/idea? What is the benefit of using OneSymmetricKey here? There is no wrapping algorithm identifier as in EncryptedPrivateKeyInfo and the whole thing looks very PSKC-specific. I would really appreciate any suggestions or comments on this. Thank you for your time. [0] https://www.redhat.com/archives/freeipa-devel/2014-April/msg00565.html [1] http://www.freeipa.org/page/V4/PKCS11_in_LDAP/Schema#Encoded_key_data_2 [2] http://tools.ietf.org/html/rfc5958#section-3 [3] http://rt.openssl.org/Ticket/Display.html?id=2204 [4] http://marc.info/?l=openssl-dev&m=126953517430167&w=2 [5] https://tools.ietf.org/html/rfc6031#section-2 [6] https://www.openssl.org/docs/crypto/RSA_public_encrypt.html [7] http://docs.oasis-open.org/pkcs11/pkcs11-curr/v2.40/csprd02/pkcs11-curr-v2.40-csprd02.html#_Toc387327841 -- Jan Cholasta ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] DNSSEC key wrapping: cryptographer needed
Hello list, I'm working on key wrapping mechanism described in thread "LDAP schema for DNSSEC keys" [0] and I'm really puzzled from the maze of crypto here. I would really appreciate any suggestions or comments on this. - I have difficulties to pick and use proper wrapping mechanisms and their configuration/usage patterns. - Rick van Rein from OpenDNSSEC-user list noted that we are defeating purpose of PKCS#11 by exporting raw keys from HSM. I can see his point and we should be able to do all crypto operations inside SoftHSM. I have asked him to describe his doubts on freeipa-devel list - stay tuned. We need to wrap === - asymmetric key (zone key) with symmetric key (master key) - symmetric key (master key) with asymmetric key (replica key) LDAP schema prescribes some storage formats but my question is about crypto algorithms (and padding!) used for key wrapping. Asymmetric keys === According to schema [1] wrapped asymmetric (i.e. private) key must be stored in 'ipaPrivateKey' attribute as DER-encoded EncryptedPrivateKeyInfo structure according to RFC 5958 [2]. It seem that SoftHSM's C_WrapKey PKCS#11 call will give us encryptedData part of EncryptedPrivateKeyInfo structure so we only have to add algorithm identifier, DER-encode the whole thing, and we could be done. I'm not sure where should I stick IV or what happens if default (fixed) IV value is left in place...? Technically SoftHSM's C_WrapKey call produces PKCS#8 structure encrypted with AES according to RFC 3394 (no padding) or RFC 5649 (with padding). RFC 3394 works only on blocks of 64 bits, which is not our case because EncryptedPrivateKeyInfo has no padding. So we should use RFC 5649 to get proper padding etc. And here is the problem: SoftHSM can use RFC 5649 using OpenSSL functions but OpenSSL doesn't support RFC 5649! The patch with this functionality was submitted back in 2010 to OpenSSL bug tracker [3] but the ticket is in state "new" and there was no reply to the e-mail in the original thread [4]. What do we do? - Convince OpenSSL to review and accept the patch? - Hack it around #0: Use something else as key wrapping method? Other wrapping methods would require SoftHSM modification because SoftHSM supports only AES mechanisms now. - Hack it around #1: Implement the RFC 5649 wrapping algorithm in a downstream patch in SoftHSM? Do we have enough expertise to implement it correctly? - Hack it around #2: Implement raw key extraction from SoftHSM and do key wrapping somehow somewhere? (Please nooo.) Symmetric keys == should be stored in 'ipaSecretKey' attribute but detailed storage format definition is missing from schema [1] right now. Unfortunately, SoftHSM doesn't support C_WrapKey PKCS#11 function with asymmetric key as *wrapping* key so we need to add this functionality. The first question is: What algorithm and padding scheme should we use? Something like OpenSSL's RSA_PKCS1_OAEP_PADDING [6]? That would be relatively easy to implement to SoftHSM because it is already there, just not handled in C_WrapKey (so we need to add appropriate 'glue' there). Another question is storage format of the wrapped key. PKCS#11 2.40d2 [7] contains this comment about "PKCS #1 RSA OAEP" algorithm: "For wrapping, the “input” to the encryption operation is the value of the CKA_VALUE attribute of the key that is wrapped; similarly for unwrapping. The mechanism does not wrap the key type or any other information about the key, except the key length; the application must convey these separately." AFAIK it means that it wraps raw secret key and nothing else. If I'm not wrong we should be able to take resulting blob and stick it into OneSymmetricKey structure from RFC 6031 [5]. Honza, is it correct assumption/idea? I would really appreciate any suggestions or comments on this. Thank you for your time. [0] https://www.redhat.com/archives/freeipa-devel/2014-April/msg00565.html [1] http://www.freeipa.org/page/V4/PKCS11_in_LDAP/Schema#Encoded_key_data_2 [2] http://tools.ietf.org/html/rfc5958#section-3 [3] http://rt.openssl.org/Ticket/Display.html?id=2204 [4] http://marc.info/?l=openssl-dev&m=126953517430167&w=2 [5] https://tools.ietf.org/html/rfc6031#section-2 [6] https://www.openssl.org/docs/crypto/RSA_public_encrypt.html [7] http://docs.oasis-open.org/pkcs11/pkcs11-curr/v2.40/csprd02/pkcs11-curr-v2.40-csprd02.html#_Toc387327841 -- Petr^2 Spacek ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
