[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[KEYPROV] ISO's response to KEYPROV
Key Provisioning is getting red-hot!
May the best man (or woman) win!
Anders Rundgren
----- Original Message -----
From: "Huehnlein, Detlef" <Detlef.Huehnlein at secunet.com>
To: "Anders Rundgren" <anders.rundgren at telia.com>; <interopeid at comune.grosseto.it>
Sent: Monday, September 01, 2008 11:15
Subject: AW: [InteropEID] Key provisioning in mobile eIDs
Hallo Anders,
your mail is very interesting. The fragment below looks very
similar to what is about to be standardized in CEN 15480 and ISO/IEC 24727, which
is meant to work for any smart device (smart card, mobile phone etc.).
The standardized approach is somewhat more generic and extensible, but it seems to be
straightforward to map your structure to the standardized structures.
<CreateObject> -> <DIDCreate> (for PinCompare and Crypto Protocol)
<PUKPolicy> -> <DIDMarker> for the PinCompare-Protocol
<KeyPair> -> <DIDMarker> for the generic Crypto-Protocol
etc.
Why don't you want to use the standard?
BR,
Detlef
> -----Ursprüngliche Nachricht-----
> Von: interopeid-bounces at comune.grosseto.it
> [mailto:interopeid-bounces at comune.grosseto.it] Im Auftrag von
> Anders Rundgren
> Gesendet: Montag, 1. September 2008 09:42
> An: interopeid at comune.grosseto.it
> Betreff: [InteropEID] Key provisioning in mobile eIDs
>
> F.Y.I.
> ----- Original Message -----
> From: Anders Rundgren
> To: dev-tech-crypto at lists.mozilla.org
> Sent: Monday, September 01, 2008 09:30
> Subject: Replacement for generateCRMFrequest ()
>
>
> The following fragment of a coming XML-based provisioning
> scheme shows a somewhat extended generateCRMFrequest (From keyprov-bounces at ietf.org Mon Sep 1 02:39:43 2008
Return-Path: <keyprov-bounces at ietf.org>
X-Original-To: keyprov-archive at optimus.ietf.org
Delivered-To: ietfarch-keyprov-archive at core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 8FF6E3A6956;
Mon, 1 Sep 2008 02:39:43 -0700 (PDT)
X-Original-To: keyprov at core3.amsl.com
Delivered-To: keyprov at core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 8CDF33A6955
for <keyprov at core3.amsl.com>; Mon, 1 Sep 2008 02:39:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Level:
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5
tests=[BAYES_50=0.001]
Received: from mail.ietf.org ([64.170.98.32])
by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id 9Fgne4uN2HE6 for <keyprov at core3.amsl.com>;
Mon, 1 Sep 2008 02:39:39 -0700 (PDT)
Received: from pne-smtpout1-sn2.hy.skanova.net
(pne-smtpout1-sn2.hy.skanova.net [81.228.8.83])
by core3.amsl.com (Postfix) with ESMTP id C11CF3A6943
for <keyprov at ietf.org>; Mon, 1 Sep 2008 02:39:39 -0700 (PDT)
Received: from arport2v (81.232.45.215) by pne-smtpout1-sn2.hy.skanova.net
(7.3.129) (authenticated as u18116613)
id 48A144C5004ECA19 for keyprov at ietf.org; Mon, 1 Sep 2008 11:39:38 +0200
Message-ID: <022901c90c16$a9a47130$82c5a8c0 at arport2v>
From: "Anders Rundgren" <anders.rundgren at telia.com>
To: "KEYPROV" <keyprov at ietf.org>
Date: Mon, 1 Sep 2008 11:39:42 +0200
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1933
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1933
Subject: [KEYPROV] ISO's response to KEYPROV
X-BeenThere: keyprov at ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Provisioning of Symmetric Keys \(keyprov\)" <keyprov.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/keyprov>,
<mailto:keyprov-request at ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/keyprov>
List-Post: <mailto:keyprov at ietf.org>
List-Help: <mailto:keyprov-request at ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/keyprov>,
<mailto:keyprov-request at ietf.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: keyprov-bounces at ietf.org
Errors-To: keyprov-bounces at ietf.org
Key Provisioning is getting red-hot!
May the best man (or woman) win!
Anders Rundgren
----- Original Message -----
From: "Huehnlein, Detlef" <Detlef.Huehnlein at secunet.com>
To: "Anders Rundgren" <anders.rundgren at telia.com>; <interopeid at comune.grosseto.it>
Sent: Monday, September 01, 2008 11:15
Subject: AW: [InteropEID] Key provisioning in mobile eIDs
Hallo Anders,
your mail is very interesting. The fragment below looks very
similar to what is about to be standardized in CEN 15480 and ISO/IEC 24727, which
is meant to work for any smart device (smart card, mobile phone etc.).
The standardized approach is somewhat more generic and extensible, but it seems to be
straightforward to map your structure to the standardized structures.
<CreateObject> -> <DIDCreate> (for PinCompare and Crypto Protocol)
<PUKPolicy> -> <DIDMarker> for the PinCompare-Protocol
<KeyPair> -> <DIDMarker> for the generic Crypto-Protocol
etc.
Why don't you want to use the standard?
BR,
Detlef
> -----Ursprüngliche Nachricht-----
> Von: interopeid-bounces at comune.grosseto.it
> [mailto:interopeid-bounces at comune.grosseto.it] Im Auftrag von
> Anders Rundgren
> Gesendet: Montag, 1. September 2008 09:42
> An: interopeid at comune.grosseto.it
> Betreff: [InteropEID] Key provisioning in mobile eIDs
>
> F.Y.I.
> ----- Original Message -----
> From: Anders Rundgren
> To: dev-tech-crypto at lists.mozilla.org
> Sent: Monday, September 01, 2008 09:30
> Subject: Replacement for generateCRMFrequest ()
>
>
> The following fragment of a coming XML-based provisioning
> scheme shows a somewhat extended generateCRMFrequest () where
) where
> a PIN can span from 1 to n keys. The example uses a shared
> (synchronized) PIN for multiple keys which is useful when you
> deploy PKI and OTP. In addition there is an issuer-specified
> PUK as well (the encrypted value is in another section not
> shown for brevity). Presumably you don't need to be an XML
> "guru" in order to digest the following lines:
>
> <CreateObject>
> <PUKPolicy Format="numeric" Hidden="true"
> RetryLimit="3" ValueReference="Item.1">
> <PINPolicy Format="numeric" Grouping="shared"
> MaxLength="8" MinLength="4"
> PatternRestrictions="three-in-a-row sequence" RetryLimit="3">
> <KeyPair ID="Key.1" KeyUsage="universal">
> <RSA KeySize="2048"/>
> </KeyPair>
> <KeyPair ID="Key.2"
> KeyUsage="piggybacked-symmetric-key">
> <RSA KeySize="1024"/>
> </KeyPair>
> </PINPolicy>
> </PUKPolicy>
> </CreateObject>
>
>
> The only real snag with this scheme is that it doesn't fit
> smart cards, but I anticipate that mobile phones will take
> their role since the latter combine HW-based cryptography
> (already featured in high-end Nokia phones) with powerful
> processors, displays, keyboards, extensive connectivity
> options, and Gb storage capabilities. Yes, it would of
> course work with an extended soft token provider as well!
>
> Now to a problem regarding implementing this FireFox: Recent
> versions of MSIE as well as Android's WebKit, have an
> advantage compared to Mozilla since they in reality offer a
> richer development platform due to the links to .NET and Java
> respectively. I hope the Mozilla team some day consider
> adopting JSE or Mono as the foundation for extensibility
> rather than adding missing pieces like XML validation and
> security to the Mozilla core because the latter may turn out
> to be a dead-end.
>
> The current implementation plan is to add this in parallel to
> Mozilla's security architecture in the same way as some other
> Open Source groups have added support for Information Cards
> to Firefox. Unfortunately it won't be able to support
> TLS-client-cert-auth but there is a replacement for that as
> well which is more in line with Information Cards; in fact
> the GUI is identical.
>
> In case you are interested in this work, just drop me a line.
>
> Anders Rundgren
> WebPKI.org
> _______________________________________________
> InteropEID mailing list
> InteropEID at comune.grosseto.it
> http://lists.comune.grosseto.it/cgi-bin/mailman/listinfo/interopeid
>
_______________________________________________
KEYPROV mailing list
KEYPROV at ietf.org
https://www.ietf.org/mailman/listinfo/keyprov
> a PIN can span from 1 to n keys. The example uses a shared
> (synchronized) PIN for multiple keys which is useful when you
> deploy PKI and OTP. In addition there is an issuer-specified
> PUK as well (the encrypted value is in another section not
> shown for brevity). Presumably you don't need to be an XML
> "guru" in order to digest the following lines:
>
> <CreateObject>
> <PUKPolicy Format="numeric" Hidden="true"
> RetryLimit="3" ValueReference="Item.1">
> <PINPolicy Format="numeric" Grouping="shared"
> MaxLength="8" MinLength="4"
> PatternRestrictions="three-in-a-row sequence" RetryLimit="3">
> <KeyPair ID="Key.1" KeyUsage="universal">
> <RSA KeySize="2048"/>
> </KeyPair>
> <KeyPair ID="Key.2"
> KeyUsage="piggybacked-symmetric-key">
> <RSA KeySize="1024"/>
> </KeyPair>
> </PINPolicy>
> </PUKPolicy>
> </CreateObject>
>
>
> The only real snag with this scheme is that it doesn't fit
> smart cards, but I anticipate that mobile phones will take
> their role since the latter combine HW-based cryptography
> (already featured in high-end Nokia phones) with powerful
> processors, displays, keyboards, extensive connectivity
> options, and Gb storage capabilities. Yes, it would of
> course work with an extended soft token provider as well!
>
> Now to a problem regarding implementing this FireFox: Recent
> versions of MSIE as well as Android's WebKit, have an
> advantage compared to Mozilla since they in reality offer a
> richer development platform due to the links to .NET and Java
> respectively. I hope the Mozilla team some day consider
> adopting JSE or Mono as the foundation for extensibility
> rather than adding missing pieces like XML validation and
> security to the Mozilla core because the latter may turn out
> to be a dead-end.
>
> The current implementation plan is to add this in parallel to
> Mozilla's security architecture in the same way as some other
> Open Source groups have added support for Information Cards
> to Firefox. Unfortunately it won't be able to support
> TLS-client-cert-auth but there is a replacement for that as
> well which is more in line with Information Cards; in fact
> the GUI is identical.
>
> In case you are interested in this work, just drop me a line.
>
> Anders Rundgren
> WebPKI.org
> _______________________________________________
> InteropEID mailing list
> InteropEID at comune.grosseto.it
> http://lists.comune.grosseto.it/cgi-bin/mailman/listinfo/interopeid
>
_______________________________________________
KEYPROV mailing list
KEYPROV at ietf.org
https://www.ietf.org/mailman/listinfo/keyprov