From anders.rundgren@telia.com Thu Sep 5 12:48:14 2013 Return-Path: X-Original-To: keyprov@ietfa.amsl.com Delivered-To: keyprov@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD3A111E824A for ; Thu, 5 Sep 2013 12:48:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.413 X-Spam-Level: X-Spam-Status: No, score=-1.413 tagged_above=-999 required=5 tests=[AWL=0.278, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kLEEM5QaTFIl for ; Thu, 5 Sep 2013 12:47:59 -0700 (PDT) Received: from smtp-out12.han.skanova.net (smtp-out12.han.skanova.net [195.67.226.212]) by ietfa.amsl.com (Postfix) with ESMTP id 0ADAE11E8200 for ; Thu, 5 Sep 2013 12:47:58 -0700 (PDT) Received: from [192.168.0.2] (2.68.199.84) by smtp-out12.han.skanova.net (8.5.133) (authenticated as u36408181) id 521DAB17002568D9 for keyprov@ietf.org; Thu, 5 Sep 2013 21:47:57 +0200 Message-ID: <5228DFE1.1000907@telia.com> Date: Thu, 05 Sep 2013 21:47:45 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: keyprov@ietf.org X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [KEYPROV] JCS - JSON Clear Text Signature Scheme X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2013 19:48:15 -0000 New name and updated documentation. https://openkeystore.googlecode.com/svn/resources/trunk/docs/JSON-Clear-Text-Signature-Scheme.pdf Enjoy! Anders From simon@josefsson.org Tue Sep 17 13:27:47 2013 Return-Path: X-Original-To: keyprov@ietfa.amsl.com Delivered-To: keyprov@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C24611E8563 for ; Tue, 17 Sep 2013 13:27:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_41=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cI3IJQvlUBrQ for ; Tue, 17 Sep 2013 13:27:44 -0700 (PDT) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) by ietfa.amsl.com (Postfix) with ESMTP id 876F111E8198 for ; Tue, 17 Sep 2013 13:27:39 -0700 (PDT) Received: from latte.josefsson.org (static-213-115-179-130.sme.bredbandsbolaget.se [213.115.179.130]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id r8HKRR3l021724 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Tue, 17 Sep 2013 22:27:30 +0200 X-Hashcash: 1:22:130917:keyprov@ietf.org::IIBirVVniDil4dPg:6Hiq From: Simon Josefsson To: keyprov@ietf.org OpenPGP: id=B565716F; url=http://josefsson.org/key.txt Date: Tue, 17 Sep 2013 22:27:26 +0200 Message-ID: <87d2o7xkgh.fsf@latte.josefsson.org> User-Agent: Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: clamav-milter 0.97.8 at duva.sjd.se X-Virus-Status: Clean Subject: [KEYPROV] OCRA without truncation X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 20:27:47 -0000 Hi, I'm merging OCRA support into my OATH Toolkit implementation () and we are discussing how OCRA without truncation is supposed to work. I haven't been able to figure out from the RFC what the output should be when t=0. There are no test vectors for that case. A naive reader would notice this definition in section 5: In a nutshell, OCRA = CryptoFunction(K, DataInput) together with this from section 4.1: As a reminder: HOTP(K,C) = Truncate(HMAC-SHA1(K,C)) and section 5.2 which specify the CryptoFunction: We define the HOTP family of functions as an extension to HOTP: 1. HOTP-H-t: these are the different possible truncated versions of HOTP, using the dynamic truncation method for extracting an HOTP value from the HMAC output 2. We will denote HOTP-H-t as the realization of an HOTP function that uses an HMAC function with the hash function H, and the dynamic truncation as described in [RFC4226] to extract a t-digit value 3. t=0 means that no truncation is performed and the full HMAC value is used for authentication purposes so one could interpret this as when t=0, the Truncate function is not invoked at all, and instead OCRA takes on the output value of the HMAC-SHA1 function, which is a binary string. Are there any implementation of OCRA with t=0? What encoding, if any, of the HMAC output is used? Decimal, hex, binary? The sample code in the RFC will always output the static code "1" as the OCRA code for t=0, if I read the code correctly, which seems like a bug. /Simon From simon@josefsson.org Tue Sep 17 13:29:58 2013 Return-Path: X-Original-To: keyprov@ietfa.amsl.com Delivered-To: keyprov@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74C9411E856E for ; Tue, 17 Sep 2013 13:29:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.449 X-Spam-Level: X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fg5G5wCl62WJ for ; Tue, 17 Sep 2013 13:29:57 -0700 (PDT) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) by ietfa.amsl.com (Postfix) with ESMTP id 714CD11E8198 for ; Tue, 17 Sep 2013 13:29:57 -0700 (PDT) Received: from latte.josefsson.org (static-213-115-179-130.sme.bredbandsbolaget.se [213.115.179.130]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id r8HKTpNM021735 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Tue, 17 Sep 2013 22:29:55 +0200 X-Hashcash: 1:22:130917:keyprov@ietf.org::JwssmLi5+kUGIuG+:1pHZ From: Simon Josefsson To: keyprov@ietf.org OpenPGP: id=B565716F; url=http://josefsson.org/key.txt Date: Tue, 17 Sep 2013 22:29:50 +0200 Message-ID: <878uyvxkch.fsf@latte.josefsson.org> User-Agent: Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: clamav-milter 0.97.8 at duva.sjd.se X-Virus-Status: Clean Subject: [KEYPROV] OCRA test vectors for 4, 5, 7, 9 and 10 digit outputs X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 20:29:58 -0000 Could any implementer share test vectors for these cases? They aren't found in the RFC. Contact me privately if you want. /Simon From anders.rundgren@telia.com Wed Sep 18 08:08:22 2013 Return-Path: X-Original-To: keyprov@ietfa.amsl.com Delivered-To: keyprov@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED66111E8263 for ; Wed, 18 Sep 2013 08:08:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZOIy8ANoUiZt for ; Wed, 18 Sep 2013 08:08:15 -0700 (PDT) Received: from smtp-out21.han.skanova.net (smtp-out21.han.skanova.net [195.67.226.208]) by ietfa.amsl.com (Postfix) with ESMTP id 44FB711E8257 for ; Wed, 18 Sep 2013 08:07:56 -0700 (PDT) Received: from [192.168.1.99] (79.85.235.16) by smtp-out21.han.skanova.net (8.5.133) (authenticated as u36408181) id 521DAD6E0091FDCB for keyprov@ietf.org; Wed, 18 Sep 2013 17:07:53 +0200 Message-ID: <5239C1BE.5020104@telia.com> Date: Wed, 18 Sep 2013 17:07:42 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: keyprov@ietf.org X-Enigmail-Version: 1.5.2 Content-Type: multipart/alternative; boundary="------------000006030808010804000404" Subject: [KEYPROV] Converting enrollment protocols from XML to JSON X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2013 15:08:22 -0000 This is a multi-part message in MIME format. --------------000006030808010804000404 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I have "amused" myself with some initial conversions of KeyGen2 from XML to JSON. The following shows one of the ten KeyGen2 message objects: { "@context": "http://xmlns.webpki.org/keygen2/201309018", "@qualifier": "KeyCreationRequest", "ServerSessionID": "S-140f2b70a3e4eefe1627b141e20", "ClientSessionID": "C-140f2b70ba0812f22188454b453", "SubmitURL": "http://issuer.example.com/keygen", "PUKPolicy": [{ "ID": "PUK.1", "Format": "numeric", "RetryLimit": 3, "Value": "mjRuOhjhtfg6d6d51Oqw", "MAC": "xPr65fxq5hwvUX94Btpp5tey+yHH9iBrMLO7wQ2k5/0=", "PINPolicy": [{ "ID": "PIN.1", "Grouping": "shared", "Format": "numeric", "MinLength": 4, "MaxLength": 8, "RetryLimit": 3, "PatternRestrictions": ["three-in-a-row","sequence"], "MAC": "Hlzek4waNiqnWwrK83cvHE6MyoQh7N5frLEH4I3DpZ0=", "KeyEntry": [{ "ID": "Key.1", "KeyAlgorithm": "http://xmlns.webpki.org/sks/algorithm#ec.p256", "AppUsage": "authentication", "MAC": "idpbhr/L/4BnaLaxz5VJHC4/XPoyp3kR/s7Dcb7ywTM=" }, { "ID": "Key.2", "KeyAlgorithm": "http://xmlns.webpki.org/sks/algorithm#rsa2048", "AppUsage": "encryption", "MAC": "6KCho59vdV3hyXlKaQl3HQFPO32GzfXFbkJh4jsbQKA=" }] }] }] } This should be interpreted as a request for an EC key and an RSA key where both keys are protected by a single (shared) user-defined (within the specified policy limits) PIN. The PIN is in turn governed by an issuer-defined, protocol-wise secret PUK. Since multiple instances of properties is considered as a bad JSON practice, arrays have been used instead. For those who are versed in XML Schemas, @context is essentially the same as targetNameSpace while @qualifier represents an "emulation" of the top-level element in an XML instance document. The original version in XML looks considerably cooler but machines probably don't care :-) Cheers, Anders --------------000006030808010804000404 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I have "amused" myself with some initial conversions of KeyGen2 from XML to JSON.
The following shows one of the ten KeyGen2 message objects:
  
    {
        "@context": "http://xmlns.webpki.org/keygen2/201309018",
        "@qualifier": "KeyCreationRequest",
        "ServerSessionID": "S-140f2b70a3e4eefe1627b141e20",
        "ClientSessionID": "C-140f2b70ba0812f22188454b453",
        "SubmitURL": "http://issuer.example.com/keygen",
        "PUKPolicy": 
            [{
                 "ID": "PUK.1",
                 "Format": "numeric",
                 "RetryLimit": 3,
                 "Value": "mjRuOhjhtfg6d6d51Oqw",
                 "MAC": "xPr65fxq5hwvUX94Btpp5tey+yHH9iBrMLO7wQ2k5/0=",
                 "PINPolicy": 
                     [{
                          "ID": "PIN.1",
                          "Grouping": "shared",
                          "Format": "numeric",
                          "MinLength": 4,
                          "MaxLength": 8,
                          "RetryLimit": 3,
                          "PatternRestrictions": ["three-in-a-row","sequence"],
                          "MAC": "Hlzek4waNiqnWwrK83cvHE6MyoQh7N5frLEH4I3DpZ0=",
                          "KeyEntry": 
                              [{
                                   "ID": "Key.1",
                                   "KeyAlgorithm": "http://xmlns.webpki.org/sks/algorithm#ec.p256",
                                   "AppUsage": "authentication",
                                   "MAC": "idpbhr/L/4BnaLaxz5VJHC4/XPoyp3kR/s7Dcb7ywTM="
                               },
                               {
                                   "ID": "Key.2",
                                   "KeyAlgorithm": "http://xmlns.webpki.org/sks/algorithm#rsa2048",
                                   "AppUsage": "encryption",
                                   "MAC": "6KCho59vdV3hyXlKaQl3HQFPO32GzfXFbkJh4jsbQKA="
                               }]
                      }]
             }]
    }

This should be interpreted as a request for an EC key and an RSA key where both keys are protected by a single (shared) user-defined (within the specified policy limits) PIN. The PIN is in turn governed by an issuer-defined, protocol-wise secret PUK.

Since multiple instances of properties is considered as a bad JSON practice, arrays have been used instead.
For those who are versed in XML Schemas, @context is essentially the same as targetNameSpace while @qualifier represents an "emulation" of the top-level element in an XML instance document.

The original version in XML looks considerably cooler but machines probably don't care :-)

Cheers,
Anders
 --------------000006030808010804000404--