Subject: [saag] Standard Crypto API + Symmetric Crypto At Rest

From: Massimiliano Pala <[email-masked]>
Date: Sat, 7 Nov 2015 22:30:35 +0900

Hi all,

I am not sure this is the right place to write this e-mail, but I hope 
is. At the meeting I spoke with several people about an idea I had some 
time ago but never landed at IETF. Since I got positive feedback and 
suggestion to post the idea to this list to see if others might be 
interested, here's the summary e-mail.

The idea is very simple: provide specifications for interfaces to 
cryptographic libraries. The basic idea is to provide an API that 
different vendors can implement on top of their libraries to provide a 
standard interface for applications. If successful, an application could 
make use of OpenSSL, MS-CAPI, Cryptlib, or any other crypto library that 
provides that interface without having to re-write the crypto-related 
code. This allows for portability (wider adoption of crypto-enabled 
applications), code/modules re-usability, and the possibility for 
applications to switch between vendors (e.g., switching to a better 
crypto library or dismissing a library that has shown vulnerabilities).

Although I received positive feedback about the idea (I know, it has be 
attempted in the past.. ), I was never able to get the green light to 
proceed with a proposal for IETF (unfortunately the answer was always 
"we don't do APIs" ... which, actually, it is not true), so I decided to 
move forward anyway, since it is a real pain that needs to be solved. If 
the IETF will like to pick up the work in the future, great. If not, 
we'll solve the problem anyway :D

If you are interested in participating in the effort (e.g., writing 
specs, participating in the discussion, provide feedback, or writing 
code) please contact me and we'll take it from there. I wrote a couple 
of pages today (very quick and dirty work for now.. so.. don't judge!), 
but I hope we'll be able to gather momentum and work together on this. 
The website is reachable at:

     http://cryptoapi.openca.org/

Last but not least - I am starting also another project that targets the 
use of SYMMETRIC crypto by providing support for encryption at rest. 
This library will provide support for storing encrypted data, signed 
(hmac) data, symmetric keys, and symmetric keys bundles (stack of keys) 
in such a way that it is simple to use (e.g., dealing with symmetric 
crypto is hard for the average developer since not much support, outside 
TLS, is provided). By defining a simple high-level API for symmetric 
crypto we want to fill the gap and, hopefully, increase the use of 
crypto also in those environment where asymmetric is not an option 
(e.g., latency constraints). The idea is to actually write a standard 
for symmetric crypto ... "at rest".

Also for this project, please contact me directly (I still do not have 
pages for this project for various reasons - most importantly I still 
have to see if I get to open source what I did for my employer of if we 
have to start from scratch) at this e-mail address.

Happy Security Everybody!

Cheers,
Max

P.S.: Other items on the back burner that I would welcome contributions 
to are OCSP over DNS (ODIN), Lightweight Revocation Tokens (LIRT), the 
PKI Resource Query Protocol (PRQP), Simplified CMC over HTTP, and the 
Public Key (Discovery) System (PKS).

---

From: Jaroslav Imrich <[email-masked]>
Date: Sat, 7 Nov 2015 14:59:54 +0100

Hi Max,

I believe PKCS#11 [0] already provides those benefits, it is widely adopted
by both commercial and open-source projects and it works not only for
hardware but also for pure software crypto implementations - for example
SoftHSM [1] works nicely on top of OpenSSL and Botan, p11-capi [2] works on
top of MS CAPI. What would be the benefits of the new API over PKCS#11?

Regards, Jaroslav

[0] https://www.oasis-open.org/committees/pkcs11/
[1] https://www.opendnssec.org/softhsm/
[2] http://thewalter.net/git/cgit.cgi/p11-capi/

On Sat, Nov 7, 2015 at 2:30 PM, Massimiliano Pala <[email-masked]>
wrote:

> Hi all,
>
> I am not sure this is the right place to write this e-mail, but I hope is.
> At the meeting I spoke with several people about an idea I had some time
> ago but never landed at IETF. Since I got positive feedback and suggestion
> to post the idea to this list to see if others might be interested, here's
> the summary e-mail.
>
> cryptographic libraries. The basic idea is to provide an API that different
> vendors can implement on top of their libraries to provide a standard
> interface for applications. If successful, an application could make use of
> OpenSSL, MS-CAPI, Cryptlib, or any other crypto library that provides that
> interface without having to re-write the crypto-related code. This allows
> for portability (wider adoption of crypto-enabled applications),
> code/modules re-usability, and the possibility for applications to switch
> between vendors (e.g., switching to a better crypto library or dismissing a
> library that has shown vulnerabilities).
>
> proceed with a proposal for IETF (unfortunately the answer was always "we
> don't do APIs" ... which, actually, it is not true), so I decided to move
> forward anyway, since it is a real pain that needs to be solved. If the
> IETF will like to pick up the work in the future, great. If not, we'll
> solve the problem anyway :D
>
> If you are interested in participating in the effort (e.g., writing specs,
> participating in the discussion, provide feedback, or writing code) please
> contact me and we'll take it from there. I wrote a couple of pages today
> (very quick and dirty work for now.. so.. don't judge!), but I hope we'll
> be able to gather momentum and work together on this. The website is
> reachable at:
>
> use of SYMMETRIC crypto by providing support for encryption at rest. This
> library will provide support for storing encrypted data, signed (hmac)
> data, symmetric keys, and symmetric keys bundles (stack of keys) in such a
> way that it is simple to use (e.g., dealing with symmetric crypto is hard
> for the average developer since not much support, outside TLS, is
> provided). By defining a simple high-level API for symmetric crypto we want
> to fill the gap and, hopefully, increase the use of crypto also in those
> environment where asymmetric is not an option (e.g., latency constraints).
> The idea is to actually write a standard for symmetric crypto ... "at rest".
>
> pages for this project for various reasons - most importantly I still have
> to see if I get to open source what I did for my employer of if we have to
> start from scratch) at this e-mail address.
>
> P.S.: Other items on the back burner that I would welcome contributions to
> are OCSP over DNS (ODIN), Lightweight Revocation Tokens (LIRT), the PKI
> Resource Query Protocol (PRQP), Simplified CMC over HTTP, and the Public
> Key (Discovery) System (PKS).
>
>
> _______________________________________________
> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag
>

---

From: Watson Ladd <[email-masked]>
Date: Sat, 7 Nov 2015 09:10:06 -0500

> top of MS CAPI. What would be the benefits of the new API over PKCS#11?

It would be sane.

For whatever reason encrypt_aes_gcm(unsigned char *nonce, unsigned
char *key, unsigned char *out, unsigned char *in, size_t inlen) is a
function that isn't provided by most libraries that implement AES-GCM.
The result is that users have to deal with an incredibly painful
amount of boilerplate, concealing flaws.

>> At the meeting I spoke with several people about an idea I had some time ago
>> but never landed at IETF. Since I got positive feedback and suggestion to
>> post the idea to this list to see if others might be interested, here's the
>> summary e-mail.
>>
>> forward anyway, since it is a real pain that needs to be solved. If the IETF
>> will like to pick up the work in the future, great. If not, we'll solve the
>> problem anyway :D
>>
>> (very quick and dirty work for now.. so.. don't judge!), but I hope we'll be
>> able to gather momentum and work together on this. The website is reachable
>> at:
>>
>> library will provide support for storing encrypted data, signed (hmac) data,
>> symmetric keys, and symmetric keys bundles (stack of keys) in such a way
>> that it is simple to use (e.g., dealing with symmetric crypto is hard for
>> the average developer since not much support, outside TLS, is provided). By
>> defining a simple high-level API for symmetric crypto we want to fill the
>> gap and, hopefully, increase the use of crypto also in those environment
>> where asymmetric is not an option (e.g., latency constraints). The idea is
>> to actually write a standard for symmetric crypto ... "at rest".
>>
>> Resource Query Protocol (PRQP), Simplified CMC over HTTP, and the Public Key
>> (Discovery) System (PKS).
>>
>>

-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.

---

From: Massimiliano Pala <[email-masked]>
Date: Sun, 8 Nov 2015 00:38:14 -0500

Hi Jaroslav,

thanks for the feedback. I do understand your position - however, I do 
disagree with the premises. PKCS#11 is a successful standard when it 
comes to hardware interfaces. However, since its design was targeted to 
standardizing interfaces for hardware devices, it does not always 
provide the easiest / best approach when it comes to applications. 
Therefore much work is required to fill those gaps (only using PKCS#11 
calls does get you only that far).

This said, I think that learning from the limitations of the solutions 
we have today is an important step towards specifying the scope of the 
proposed work. Maybe we will end up having a similar API or we might 
provide an higher level one or, again, a simplified version of it. In my 
opinion, all the solutions you are listing here try to address a real 
pain by using the only standard API we have today. A commendable effort, 
but not what I am proposing.

Another important aspect that is usually under-estimated when it comes 
to crypto APIs is usability. I personally think that PKCS#11 is not a 
great example from this point of view and, AFAIK, people that have 
developed against it have often resorted to develop their own 
abstraction layer on top of it. Moreover, most of the times, developers 
need to use other interfaces to deal with all extra details when it 
comes to, for example, dealing with certificates processing (e.g., chain 
validation, etc.).

This is my personal opinion, of course, and I do not want to start a 
discussion about if this work is needed or not here (especially because 
I have already been told that IETF is not interested in this work). I 
think there is much to be done and I am happy to discuss all these 
aspects and collaborate with as many experts (who practically have felt 
the pain when developing applications) as possible. If you feel that 
this is still a pain point today, please join the effort.

Thanks again for the feedback,

Cheers,
Max

On 11/7/15 8:59 AM, Jaroslav Imrich wrote:
> Hi Max,
>
> I believe PKCS#11 [0] already provides those benefits, it is widely 
> adopted by both commercial and open-source projects and it works not 
> only for hardware but also for pure software crypto implementations - 
> for example SoftHSM [1] works nicely on top of OpenSSL and Botan, 
> p11-capi [2] works on top of MS CAPI. What would be the benefits of 
> the new API over PKCS#11?
>
> Regards, Jaroslav
>
> On Sat, Nov 7, 2015 at 2:30 PM, Massimiliano Pala <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hi all,
>
>     I am not sure this is the right place to write this e-mail, but I
>     hope is. At the meeting I spoke with several people about an idea
>     I had some time ago but never landed at IETF. Since I got positive
>     feedback and suggestion to post the idea to this list to see if
>     others might be interested, here's the summary e-mail.
>
>     different vendors can implement on top of their libraries to
>     provide a standard interface for applications. If successful, an
>     application could make use of OpenSSL, MS-CAPI, Cryptlib, or any
>     other crypto library that provides that interface without having
>     to re-write the crypto-related code. This allows for portability
>     (wider adoption of crypto-enabled applications), code/modules
>     re-usability, and the possibility for applications to switch
>     between vendors (e.g., switching to a better crypto library or
>     dismissing a library that has shown vulnerabilities).
>
>     Although I received positive feedback about the idea (I know, it
>     has be attempted in the past.. ), I was never able to get the
>     green light to proceed with a proposal for IETF (unfortunately the
>     answer was always "we don't do APIs" ... which, actually, it is
>     not true), so I decided to move forward anyway, since it is a real
>     pain that needs to be solved. If the IETF will like to pick up the
>     work in the future, great. If not, we'll solve the problem anyway :D
>
>     If you are interested in participating in the effort (e.g.,
>     writing specs, participating in the discussion, provide feedback,
>     or writing code) please contact me and we'll take it from there. I
>     wrote a couple of pages today (very quick and dirty work for now..
>     so.. don't judge!), but I hope we'll be able to gather momentum
>     and work together on this. The website is reachable at:
>
>     Last but not least - I am starting also another project that
>     targets the use of SYMMETRIC crypto by providing support for
>     encryption at rest. This library will provide support for storing
>     encrypted data, signed (hmac) data, symmetric keys, and symmetric
>     keys bundles (stack of keys) in such a way that it is simple to
>     use (e.g., dealing with symmetric crypto is hard for the average
>     developer since not much support, outside TLS, is provided). By
>     defining a simple high-level API for symmetric crypto we want to
>     fill the gap and, hopefully, increase the use of crypto also in
>     those environment where asymmetric is not an option (e.g., latency
>     constraints). The idea is to actually write a standard for
>     symmetric crypto ... "at rest".
>
>     Also for this project, please contact me directly (I still do not
>     have pages for this project for various reasons - most importantly
>     I still have to see if I get to open source what I did for my
>     employer of if we have to start from scratch) at this e-mail address.
>
>     P.S.: Other items on the back burner that I would welcome
>     contributions to are OCSP over DNS (ODIN), Lightweight Revocation
>     Tokens (LIRT), the PKI Resource Query Protocol (PRQP), Simplified
>     CMC over HTTP, and the Public Key (Discovery) System (PKS).
>
>
>     [email-masked] <mailto:[email-masked]>

---

From: Russ Housley <[email-masked]>
Date: Sun, 8 Nov 2015 00:44:03 -0500

Max:

Wouldn't the ideal API be the same for software libraries and hardware devices?  Having the application seamlessly work regardless of the manner that the key is stored would be a big win for application developers.  To this end, some people use PKCS#11 as an interface to software.

Russ

On Nov 8, 2015, at 12:38 AM, Massimiliano Pala wrote:

> Hi Jaroslav,
> 
> thanks for the feedback. I do understand your position - however, I do disagree with the premises. PKCS#11 is a successful standard when it comes to hardware interfaces. However, since its design was targeted to standardizing interfaces for hardware devices, it does not always provide the easiest / best approach when it comes to applications. Therefore much work is required to fill those gaps (only using PKCS#11 calls does get you only that far).
> 
> This said, I think that learning from the limitations of the solutions we have today is an important step towards specifying the scope of the proposed work. Maybe we will end up having a similar API or we might provide an higher level one or, again, a simplified version of it. In my opinion, all the solutions you are listing here try to address a real pain by using the only standard API we have today. A commendable effort, but not what I am proposing.
> 
> Another important aspect that is usually under-estimated when it comes to crypto APIs is usability. I personally think that PKCS#11 is not a great example from this point of view and, AFAIK, people that have developed against it have often resorted to develop their own abstraction layer on top of it. Moreover, most of the times, developers need to use other interfaces to deal with all extra details when it comes to, for example, dealing with certificates processing (e.g., chain validation, etc.).
> 
> This is my personal opinion, of course, and I do not want to start a discussion about if this work is needed or not here (especially because I have already been told that IETF is not interested in this work). I think there is much to be done and I am happy to discuss all these aspects and collaborate with as many experts (who practically have felt the pain when developing applications) as possible. If you feel that this is still a pain point today, please join the effort.
> 
>> I believe PKCS#11 [0] already provides those benefits, it is widely adopted by both commercial and open-source projects and it works not only for hardware but also for pure software crypto implementations - for example SoftHSM [1] works nicely on top of OpenSSL and Botan, p11-capi [2] works on top of MS CAPI. What would be the benefits of the new API over PKCS#11?
>> 
>> Regards, Jaroslav
>> 
>> On Sat, Nov 7, 2015 at 2:30 PM, Massimiliano Pala <[email-masked]> wrote:
>> Hi all,
>> 
>> I am not sure this is the right place to write this e-mail, but I hope is. At the meeting I spoke with several people about an idea I had some time ago but never landed at IETF. Since I got positive feedback and suggestion to post the idea to this list to see if others might be interested, here's the summary e-mail.
>> 
>> The idea is very simple: provide specifications for interfaces to cryptographic libraries. The basic idea is to provide an API that different vendors can implement on top of their libraries to provide a standard interface for applications. If successful, an application could make use of OpenSSL, MS-CAPI, Cryptlib, or any other crypto library that provides that interface without having to re-write the crypto-related code. This allows for portability (wider adoption of crypto-enabled applications), code/modules re-usability, and the possibility for applications to switch between vendors (e.g., switching to a better crypto library or dismissing a library that has shown vulnerabilities).
>> 
>> Although I received positive feedback about the idea (I know, it has be attempted in the past.. ), I was never able to get the green light to proceed with a proposal for IETF (unfortunately the answer was always "we don't do APIs" ... which, actually, it is not true), so I decided to move forward anyway, since it is a real pain that needs to be solved. If the IETF will like to pick up the work in the future, great. If not, we'll solve the problem anyway :D
>> 
>> If you are interested in participating in the effort (e.g., writing specs, participating in the discussion, provide feedback, or writing code) please contact me and we'll take it from there. I wrote a couple of pages today (very quick and dirty work for now.. so.. don't judge!), but I hope we'll be able to gather momentum and work together on this. The website is reachable at:
>> 
>> Last but not least - I am starting also another project that targets the use of SYMMETRIC crypto by providing support for encryption at rest. This library will provide support for storing encrypted data, signed (hmac) data, symmetric keys, and symmetric keys bundles (stack of keys) in such a way that it is simple to use (e.g., dealing with symmetric crypto is hard for the average developer since not much support, outside TLS, is provided). By defining a simple high-level API for symmetric crypto we want to fill the gap and, hopefully, increase the use of crypto also in those environment where asymmetric is not an option (e.g., latency constraints). The idea is to actually write a standard for symmetric crypto ... "at rest".
>> 
>> Also for this project, please contact me directly (I still do not have pages for this project for various reasons - most importantly I still have to see if I get to open source what I did for my employer of if we have to start from scratch) at this e-mail address.
>> 
>> P.S.: Other items on the back burner that I would welcome contributions to are OCSP over DNS (ODIN), Lightweight Revocation Tokens (LIRT), the PKI Resource Query Protocol (PRQP), Simplified CMC over HTTP, and the Public Key (Discovery) System (PKS).
>> 
>>

---

From: ianG <[email-masked]>
Date: Sun, 8 Nov 2015 13:04:31 +0000

On 7/11/2015 13:30 pm, Massimiliano Pala wrote:

> cryptographic libraries.

In my experience, this is not a good idea.  I do agree that people are 
going to do it anyway, because the world of developers is built to 
create new and better and more standard APIs, but doing it is just their 
learning experience.

Some reasons... because it's Sunday.

* In theory there is a notion that forcing one good API on everyone will 
improve their code security, but in practice there are so many ways to 
shoot yourself in the foot that it might not be able to show a benefit.

* The API that is wanted tends to be different with every project. 
Every project has a different threat model.  There is a myth that the 
SSL threat model is kind of useful for other projects, and this has 
driven a lot of API design, for example the certificates, but the SSL 
threat model isn't even coherent within its own domain.  Borrowing it 
without thought is just security negligence because most projects are 
based on datagrams [0], so even their architecture mitigates against the 
open continuous reliable pipe design that SSL blithely inherits from TCP 
without question.

* In practice, what people need is a much higher level API than is 
normally provided.  For an example of this have a look at DJB's 
cryptobox.  After much hacking I ended up with the same approach in my 
code, there is no middle level API, there is instead many similar silos 
in a pattern I call BusyBee [1].

* In the alternate, there is an extreme failing from the API approach 
which is epitomised by the Java JCE.  In this monstrosity, not only can 
you be unsure which library you're getting, you can't really be sure 
you're even "allowed" to use crypto.  So we get this continual user 
configuration nightmare.  From a security pov, JCE is unauditable so 
we're in this weird position of using 256bit strength crypto but we can 
only use it in middling applications where we don't mind if it all gets 
perverted by the oracle-in-the-muddle attack.

* And that's without looking at the overall failure of the API to keep 
up with modern times, and the failure to deprecate and improve 
ciphersuites, and the complexity of figuring out what is going on 
through layers like mobile phones:  application -> manufacturer -> 
Android -> google -> oracle -> Java JCE.  Yes, there have been several 
exploits / failures that can be purely attributed to supply chain 
madness.  And money was lost, in the Bitcoin world, where they blithely 
just used this crypto stuff they were given and it turned out to be flawed.

* One good argument for an API is that the library meets it and 
therefore that code doesn't have to be written by the programmer.  This 
is good.  But this says nothing about the level that is appropriate.

iang

[0] I'm precisely saying datagrams here, not UDP.
[1] because it does everything and buzzes a lot getting it done.

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 8 Nov 2015 14:53:52 +0000

Hi Max,

I've no opinion now as to whether the IETF ought seek consensus on the
specifics of an API such as you propose. Mainly, I'd be for doing it,
if the API is good and we're not stepping on anyone's toes, and against
dong it if the API is not good and causes liaison issues. (Yes, that's
not an exhaustive characterisation, deliberately:-)

I would not however support the IETF formally starting out on such work
with a blank sheet of paper. I'm pretty sure we'd end up with an output
that'd make everyone unhappy after loads of effort.

So, I'd suggest that if you want to pursue this, best would be to get
interested folks working alongside (but outside) the IETF and write
the code you want and then propose that the resulting API be
standardised. "Alongside (but outside)" could mean various things but
what your web page indicates seems like a fine one of those. So, if you
stick with that approach, I'd say come back when you think the specs
at [1] are ready.

I'd also note that Kathleen's been doing good work on getting some of
the PKCS series under IETF change control. But I think  the plan for
PKCS#11 was to have that done in OASIS, [2] so I'd suggest that
chatting with those folks would be sensible, if you've not already.

Cheers,
S.

[1] https://github.com/SICA-WG/specs
[2] https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=pkcs11

---

From: "Dr. Pala" <[email-masked]>
Date: Sun, 8 Nov 2015 06:56:00 -0500

Hi Russ,

Absolutely. I think that there are a number of high-level concepts that are going to be included in the API definition and the underlying implementation can leverage what works today for hardware devices (e.g. PKCS#11, PKCS#12, MS-CAPI store, etc.).

I totally agree that having seamless integration between software and hardware stores would be a win-win situation. Standardizing this interface would also be important.

Cheers,
Max

> On Nov 8, 2015, at 12:44 AM, Russ Housley <[email-masked]> wrote:
> 
> Max:
>

---

From: "Max Pritikin (pritikin)" <[email-masked]>
Date: Mon, 9 Nov 2015 20:53:06 +0000

"seamless integration between software and hardware stores"
+1

Many times we work with software that assumes different interfaces and, perhaps more insidious, assumes that keys are always extracted from software stores to be used in memory. (For example instead of leveraging a crypto engine interface w/in their TLS library they instead pass the raw keys into the library and expect it to be used locally).

- max

On Nov 8, 2015, at 4:56 AM, Dr. Pala <[email-masked]<mailto:[email-masked]>> wrote:

Hi Russ,

Cheers,
Max

On Nov 8, 2015, at 12:44 AM, Russ Housley <[email-masked]<mailto:[email-masked]>> wrote:

Max:

Russ

Hi Jaroslav,

Cheers,
Max

Regards, Jaroslav

On Sat, Nov 7, 2015 at 2:30 PM, Massimiliano Pala <<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>> wrote:
Hi all,

Cheers,
Max

_______________________________________________
saag mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/saag

_______________________________________________
saag mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/saag

_______________________________________________
saag mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/saag

---

From: "Dr. Pala" <[email-masked]>
Date: Sun, 8 Nov 2015 06:47:45 -0500

Hi Russ,

Cheers,
Max

---

From: Massimiliano Pala <[email-masked]>
Date: Wed, 11 Nov 2015 11:07:41 -0500

Hi Iang,

I do understand the fact that this is a big effort, and it might be 
difficult to provide the right level of abstraction. That is why I am 
seeking people that has had these issues to participate in the project 
so we can get a usable API that can be supported by all the vendors.

The WG (outside the IETF - the recent message from Farrell explains his 
position on this topic) I am proposing is about: (a) discussing and 
defining what to address with this API and what level of abstraction, 
and (b) understanding how this API will interact with the lower level 
(e.g. the crypto API) in order to be sure that we are not limiting / 
excluding any vendors, and (c) providing a common discussion environment 
for API implementers that might drive changes related to the proposed 
standard to make it (besides developers friendly) vendors friendly.

This said, one of the benefits that can come out of this project for 
vendors (here addressing a bit Farrell's concern) is that by having this 
reference API, they might help their design. Also, third-parties can 
develop the interfaces (e.g., OpenCryptoAPI for MS-CAPI, OpenSSL, or 
Crypto++), thus providing new opportunities in the crypto space (e.g., 
both commercial and non-commercial).

We will work on this (unfortunately outside IETF for now), and we will 
try to push the results in many standardization bodies (therefore we how 
to see the specs implemented in many different environments and for 
different programming languages). If we do a good job, we might also 
prevent developers (not crypto-experts) to shoot themselves in the foot :D

Thanks for the feedback,

Cheers,
Max

On 11/8/15 8:04 AM, ianG wrote:
> create new and better and more standard APIs, but doing it is just 
> their learning experience.
>
> * In theory there is a notion that forcing one good API on everyone 
> will improve their code security, but in practice there are so many 
> ways to shoot yourself in the foot that it might not be able to show a 
> benefit.
>
> based on datagrams [0], so even their architecture mitigates against 
> the open continuous reliable pipe design that SSL blithely inherits 
> from TCP without question.
>
> code, there is no middle level API, there is instead many similar 
> silos in a pattern I call BusyBee [1].
>
> which is epitomised by the Java JCE.  In this monstrosity, not only 
> can you be unsure which library you're getting, you can't really be 
> sure you're even "allowed" to use crypto.  So we get this continual 
> user configuration nightmare. From a security pov, JCE is unauditable 
> so we're in this weird position of using 256bit strength crypto but we 
> can only use it in middling applications where we don't mind if it all 
> gets perverted by the oracle-in-the-muddle attack.
>
> madness.  And money was lost, in the Bitcoin world, where they 
> blithely just used this crypto stuff they were given and it turned out 
> to be flawed.
>

---

From: Massimiliano Pala <[email-masked]>
Date: Wed, 11 Nov 2015 11:14:57 -0500

Hi Sephen,

thanks for letting me know your point of view. I would really like to bring
this work to the IETF, as I think it is a practical engineering issue 
that could
be addressed by having a standard and related implementations. I already
received some support from several Crypto API vendors and I think we might
see (finally) this happening in the real world.

As I wrote in my other reply to iang, part of the work is to be sure we 
do not
exclude vendors as our purpose is to be available everywhere. I am thinking
about the success of the LDAP API that is implemented on every single system
I have worked on and by all the vendors I am aware of. Our scope might be
a bit more broad, and we might end up splitting the effort in different
documents (e.g., SSL/TLS, PKIX, SYMCRYPTO, etc.) - I cannot predict it now.

I am very fond of the IETF and I have been participating to the WGs for more
than 15 yrs now, but if this is your position we do not have any 
alternative but
to work outside the organization for now. I still hope that this will 
change at
some point.

Thanks Again,

Cheers,
Max

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 11 Nov 2015 16:51:32 +0000

Hi Max,

> to work outside the organization for now. I still hope that this will

Sure, I won't repeat all below, but once you've an API defined
and some interested folks, then it'll be time to ask more formally
about doing work in the IETF.

S.

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 11 Nov 2015 16:29:26 -0500

Sent from my iPhone

> On Nov 8, 2015, at 9:53 AM, Stephen Farrell <[email-masked]> wrote:
> 
> 
> Hi Max,
> 

Yes, PKCS#11 is being actively worked on in OASIS now.  The other PKCS standards are in the IETF and I'm working on getting change control transferred to the IETF for the remaining two (#1 & #5).

Best regards,
Kathleen