Re: [pkix] Fwd: [saag] Standard Crypto API + Symmetric Crypto At Rest

[Anders Rundgren <[e-mail]>]

On 2015-11-11 17:17, Massimiliano Pala wrote:
> Hi PKIX,
>
> I posted this message on the security area ML, but I think it could be useful
> to forward it here to address (possibly) an interested audience.
>
> Any comments and feedback are welcome (positive and negative alike).

I'm trying to understand who the user would be.  It is hardly super-experts
writing TLS stacks so I guess it must for example be folks working with "Apps"
for mobile devices?

They probably want to sign and/or encrypt data.  They probably also use a
popular message format like JSON.  If this is what they do they don't have
to use awkward stuff like PKCS #11, they rather call a simple library function
with the message, key, and algorithm as parameters.

Most people who use crypto APIs extensively (like me...) typically write a
wrapping-layer adapted for the actual application-space.

I also think it will be extremely hard to get the major platform vendors to
support yet another API which more or less "competes" with the existing API.

I also believe that this is a monumental task.

Maybe this is already done as well?
https://github.com/google/keyczar

Anders

>
> Cheers,
> Max
>
> -------- Forwarded Message --------
> Subject: 	[saag] Standard Crypto API + Symmetric Crypto At Rest
> Date: 	Sat, 7 Nov 2015 22:30:35 +0900
> From: 	Massimiliano Pala <[e-mail]>
> Organization: 	OpenCA Labs
> To: 	[e-mail] <[e-mail]>
>
>
>
> 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).
>
>
> _______________________________________________
> saag mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/saag
>
>
>
>
>
> _______________________________________________
> pkix mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pkix
>