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

Anders Rundgren <anders.rundgren.net@gmail.com> Wed, 11 November 2015 19:57 UTC

Return-Path: <anders.rundgren.net@gmail.com>
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 137A61B397B for <pkix@ietfa.amsl.com>; Wed, 11 Nov 2015 11:57:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fGQ375v_-r0y for <pkix@ietfa.amsl.com>; Wed, 11 Nov 2015 11:57:34 -0800 (PST)
Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF9451B397A for <pkix@ietf.org>; Wed, 11 Nov 2015 11:57:33 -0800 (PST)
Received: by wmww144 with SMTP id w144so173500519wmw.1 for <pkix@ietf.org>; Wed, 11 Nov 2015 11:57:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=L3Fez2oKv2UDNYN5cfYlkh0QJ4m6qI3a7wa6tSmVHBk=; b=ztJkmD4G8aYOTMM8qS1FhsFmTJtO0z3IS92mbpRUzbktnLDRksJ7zpIoc2ww/+guxu VE+sP1H7yzBfZpmYH0dEkpQsA4iPHyxdx9SGLP4IYqA16LgtDPlBo0n4UI8t8FO2qFX+ dEMnSnQ5L8tkzu5PbIH0Jc4fJoRPnTm/BOsi24dfvCFybgp/85/WacXJoMXPd/fYy803 vPv+T0aGXFySpMhwGHjJOt2iLrSH6QbDA+TeieIvho231qbPZ7QNO18cfxPjrkgcSyz0 WiRE7/TZwhz2RX138EzshyCN//kYbLGRZRx0kQhbrIv7dc9pZ5tI9Fp8GW5DvsdajAQ+ 4Y6g==
X-Received: by 10.28.226.86 with SMTP id z83mr20476639wmg.77.1447271852419; Wed, 11 Nov 2015 11:57:32 -0800 (PST)
Received: from [192.168.1.79] (148.198.130.77.rev.sfr.net. [77.130.198.148]) by smtp.googlemail.com with ESMTPSA id l1sm10630505wjx.13.2015.11.11.11.57.31 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 11 Nov 2015 11:57:31 -0800 (PST)
To: Massimiliano Pala <director@openca.org>, "pkix@ietf.org" <pkix@ietf.org>
References: <563DFCFB.8090405@openca.org> <56436A0B.10005@openca.org>
From: Anders Rundgren <anders.rundgren.net@gmail.com>
Message-ID: <56439DA5.7010904@gmail.com>
Date: Wed, 11 Nov 2015 20:57:25 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <56436A0B.10005@openca.org>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/pkix/jqlTR9RMv3O4wrqZ9A6ZqRaq5QU>
Subject: Re: [pkix] Fwd: [saag] Standard Crypto API + Symmetric Crypto At Rest
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: PKIX Working Group <pkix.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pkix>, <mailto:pkix-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pkix/>
List-Post: <mailto:pkix@ietf.org>
List-Help: <mailto:pkix-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pkix>, <mailto:pkix-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Nov 2015 19:57:36 -0000

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 <director@openca.org>
> Organization: 	OpenCA Labs
> To: 	saag@ietf.org <saag@ietf.org>
>
>
>
> 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
> saag@ietf.org
> https://www.ietf.org/mailman/listinfo/saag
>
>
>
>
>
> _______________________________________________
> pkix mailing list
> pkix@ietf.org
> https://www.ietf.org/mailman/listinfo/pkix
>