From nobody Fri Dec 2 09:24:56 2016 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C79F129572 for ; Fri, 2 Dec 2016 09:24:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.098 X-Spam-Level: X-Spam-Status: No, score=-107.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no 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 Y3IWp7pheLAS for ; Fri, 2 Dec 2016 09:24:52 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00831129704 for ; Fri, 2 Dec 2016 09:24:52 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 6000) id E9C3AB80267; Fri, 2 Dec 2016 09:24:51 -0800 (PST) Date: Fri, 2 Dec 2016 09:24:51 -0800 From: RFC Editor To: Mike Jones Message-ID: <20161202172451.GB21712@rfc-editor.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Cc: Jim Schaad , RFC Editor , IANA , Kathleen Moriarty , "cose@ietf.org" Subject: Re: [COSE] Inconsistencies in COSE registry names (draft-ietf-cose-msg) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2016 17:24:54 -0000 Hi Mike and Jim, Mike, thank you for raising this issue. Jim, can you confirm whether this is correct? Please note that we have added IANA to this thread in case this impacts the IANA registries being created. Thank you, RFC Editor/sg On Wed, Nov 30, 2016 at 11:41:58PM +0000, Mike Jones wrote: > While working on another spec using COSE https://tools.ietf.org/html/draft-ietf-cose-msg-24, I noticed that multiple inconsistent names are used for the same registries in some cases. I hope that this can be addressed by the RFC Editor (included in this communication) before publication. > > 1. Where multiple names appear on the same line below, I believe they refer to the same registry. What I believe to be the correct name is first: > "COSE Header Parameters", "COSE Header Labels" > "COSE Algorithms", "COSE Algorithm Value", "COSE Algorithm Values" > "COSE Key Type Parameters", "COSE Key Type Parameter Labels" > > 2. The registry name "COSE Curves" is used in the table in 13.1.1 (Double Coordinate Curves) but doesn't refer to any registry I'm aware of. > > 3. I believe that the name "COSE Key Type" should be changed to "COSE Key Types" for consistency sake, since all the other registry names use plurals. > > 4. There are several places in the running text in which the word "Registry" is included in the registry name in quotation marks, rather than being placed outside the quotation marks. For instance, I believe these changes should be made in the body text: > "COSE Key Type Registry" -> "COSE Key Type" registry > "COSE Key Common Parameters Registry" -> "COSE Key Common Parameters" registry > > For completeness, I believe these registry names and their usages are fine: > "COSE Header Algorithm Parameters" > "COSE Key Common Parameters" > "COSE Elliptic Curve Parameters" > > -- Mike > From nobody Mon Dec 5 18:21:05 2016 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57EBC12968B for ; Mon, 5 Dec 2016 18:21:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.916 X-Spam-Level: X-Spam-Status: No, score=-9.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=qti.qualcomm.com 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 28N2BnaMzGOe for ; Mon, 5 Dec 2016 18:21:01 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E16A91295AC for ; Mon, 5 Dec 2016 18:21:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1480990860; x=1512526860; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=UmvC3IolmWIHBpie5qh5xLBHJLAt0GI0jeqzvG81dHU=; b=Nyn7AFgJYd1pCP7clYgUaDP/LVW0lwQR0ibBWw+3ljPBRYcl4giKTph1 3Nckp1tcVjKvn3Q3BkKhR85B31/1bldUtd8pZTZsBiQK4GsmzsxHFLbIk +FU/glZw4F77kCnsMP6f0Oajtg0vYgd7uNC9na/oI46RUoUdRcF/TmqKM U=; X-IronPort-AV: E=Sophos;i="5.33,750,1477983600"; d="scan'208,217";a="245702680" Received: from unknown (HELO ironmsg02-R.qualcomm.com) ([10.53.140.106]) by wolverine01.qualcomm.com with ESMTP; 05 Dec 2016 18:20:59 -0800 X-IronPort-AV: E=McAfee;i="5700,7163,8370"; a="859275859" X-Amp-Result: CLEAN Received: from nasanexm01f.na.qualcomm.com ([10.85.0.32]) by ironmsg02-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 05 Dec 2016 18:20:59 -0800 Received: from NASANEXM01B.na.qualcomm.com (10.85.0.82) by NASANEXM01F.na.qualcomm.com (10.85.0.32) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Mon, 5 Dec 2016 18:20:58 -0800 Received: from NASANEXM01B.na.qualcomm.com ([10.85.0.82]) by NASANEXM01B.na.qualcomm.com ([10.85.0.82]) with mapi id 15.00.1178.000; Mon, 5 Dec 2016 18:20:58 -0800 From: "Lundblade, Laurence" To: Samuel Erdtman Thread-Topic: [COSE] New Version Notification for draft-schaad-cose-x509-00.txt Thread-Index: AQHST2dheW58hWJnjUWIGxKZC9ju0Q== Date: Tue, 6 Dec 2016 02:20:58 +0000 Message-ID: <9CE238FE-6AF0-458D-A1C7-B790870323D3@qti.qualcomm.com> References: <147987163959.30322.14158962529156430503.idtracker@ietfa.amsl.com> <004901d24546$8e76bfe0$ab643fa0$@augustcellars.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1878.6) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [199.106.107.6] Content-Type: multipart/alternative; boundary="_000_9CE238FE6AF0458DA1C7B790870323D3qtiqualcommcom_" MIME-Version: 1.0 Archived-At: Cc: Jim Schaad , cose Subject: Re: [COSE] New Version Notification for draft-schaad-cose-x509-00.txt X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2016 02:21:04 -0000 --_000_9CE238FE6AF0458DA1C7B790870323D3qtiqualcommcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Sorry for the delayed response and thanks for the draft. The order definitive chain option for x5c looks pretty good. How does the k= id parameter come into play? Is x5c in lieu of kid? Seems like it would be= . Is it usual to have the data type / semantics vary for some CBOR like x5c? = Haven=92t run into any CBOR like that before. Would it be better to have a= n x5cb (b for bag) and an x5co (o for ordered). Thanks! LL On Nov 23, 2016, at 10:43 PM, Samuel Erdtman > wrote: Looks like a good start to me. Laurence what do you think? //Samuel On Wed, Nov 23, 2016 at 6:00 AM, Jim Schaad > wrote: This is a rough draft of what a set of X.509 headers could look like. Ther= e is lots of things that are incomplete or missing, but I said I would writ= e up a fast version for people to look at so here it is. If you are interested, please comment on the headers. The pointer to the g= ithub repository is in the document. Jim > -----Original Message----- > From: internet-drafts@ietf.org [mailto:i= nternet-drafts@ietf.org] > Sent: Tuesday, November 22, 2016 7:27 PM > To: Jim Schaad > > Subject: New Version Notification for draft-schaad-cose-x509-00.txt > > > A new version of I-D, draft-schaad-cose-x509-00.txt has been successfully > submitted by Jim Schaad and posted to the IETF repository. > > Name: draft-schaad-cose-x509 > Revision: 00 > Title: CBOR Encoded Message Syntax (COSE): Headers for car= rying > and referencing X.509 certificates > Document date: 2016-11-22 > Group: Individual Submission > Pages: 6 > URL: https://www.ietf.org/internet-drafts/draft-schaad-cose-x5= 09-00.txt > Status: https://datatracker.ietf.org/doc/draft-schaad-cose-x509/ > Htmlized: https://tools.ietf.org/html/draft-schaad-cose-x509-00 > > > Abstract: > This document defines the headers and usage for referring to and > transporting X.509 certificates in the CBOR Encoded Message (COSE) > Syntax. > > Contributing to this document > > The source for this draft is being maintained in GitHub. Suggested > changes should be submitted as pull requests at cose-wg/X509>. Instructions are on that page as well. Editorial > changes can be managed in GitHub, but any substantial issues need to > be discussed on the COSE mailing list. > > > > > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat _______________________________________________ COSE mailing list COSE@ietf.org https://www.ietf.org/mailman/listinfo/cose --_000_9CE238FE6AF0458DA1C7B790870323D3qtiqualcommcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Sorry for the delayed response and thanks for the draft.

The order definitive chain option for x5c looks pretty good. How does = the kid parameter come into play? Is x5c in lieu of kid?  Seems like i= t would be.

Is it usual to have the data type / semantics vary for some CBOR like = x5c? Haven=92t run into any CBOR like that before.  Would it be better= to have an x5cb (b for bag) and an x5co (o for ordered).

Thanks!

LL





On Nov 23, 2016, at 10:43 PM, Samuel Erdtman <samuel@erdtman.se> wrote:

Looks like a good start to me.

Laurence what do you think?

//Samuel

On Wed, Nov 23, 2016 at 6:00 AM, Jim Schaad <ietf@august= cellars.com> wrote:
This is a rough draft of what a set of X.509 headers could look like. = There is lots of things that are incomplete or missing, but I said I would= write up a fast version for people to look at so here it is.

If you are interested, please comment on the headers.  The pointer to = the github repository is in the document.

Jim


> -----Original Message-----
> From: internet-drafts@ietf= .org [mailto:internet-draft= s@ietf.org]
> Sent: Tuesday, November 22, 2016 7:27 PM
> To: Jim Schaad <ietf@augu= stcellars.com>
> Subject: New Version Notification for draft-schaad-cose-x509-00.txt >
>
> A new version of I-D, draft-schaad-cose-x509-00.txt has been successfu= lly
> submitted by Jim Schaad and posted to the IETF repository.
>
> Name:         draft-schaad-cose-x509
> Revision:     00
> Title:                CBOR Enc= oded Message Syntax (COSE): Headers for carrying
> and referencing X.509 certificates
> Document date:        2016-11-22
> Group:                Individu= al Submission
> Pages:                6
> URL:            https://www.ietf.org/internet-drafts/draft-schaad-cose-x509-00.tx= t
> Status:         https://datatracker.ietf.org/doc/draft-schaad-cose-x509/
> Htmlized:       https:= //tools.ietf.org/html/draft-schaad-cose-x509-00
>
>
> Abstract:
>    This document defines the headers and usage for referring= to and
>    transporting X.509 certificates in the CBOR Encoded Messa= ge (COSE)
>    Syntax.
>
> Contributing to this document
>
>    The source for this draft is being maintained in GitHub.&= nbsp; Suggested
>    changes should be submitted as pull requests at <https://git= hub.com/
>    cose-wg/X509>.  Instructions are on that page as = well.  Editorial
>    changes can be managed in GitHub, but any substantial iss= ues need to
>    be discussed on the COSE mailing list.
>
>
>
>
> Please note that it may take a couple of minutes from the time of subm= ission
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat


_______________________________________________
COSE mailing list
COSE@ietf.org
https://www.ietf.org/mailman/listinfo/cose


--_000_9CE238FE6AF0458DA1C7B790870323D3qtiqualcommcom_-- From nobody Mon Dec 5 18:39:31 2016 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DA22129667 for ; Mon, 5 Dec 2016 18:39:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.917 X-Spam-Level: X-Spam-Status: No, score=-9.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=qti.qualcomm.com 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 dpzoYfw6uhQN for ; Mon, 5 Dec 2016 18:39:28 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AC0912955F for ; Mon, 5 Dec 2016 18:39:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1480991968; x=1512527968; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=K8XKImify1Lpe1hWbYfH1Qoy/VwlluGBBBMPOw/zzdI=; b=VKizcFtjW7LRMpgak8wPPSC5CQLs1EDRO5iwna9+DuiP08x1eAAUrLh+ YptzNeq4wvmg5rD/nt2Ox4sPlzByf9zXx91gRwJ3Bh9g/Jtf2U9n1WRMi XIA8I0IwO6iqhWIjSBhf6I0/hzHOyIWqu6ivxY9ijMKMbCdgpQAL2WN+3 A=; X-IronPort-AV: E=Sophos;i="5.33,750,1477983600"; d="scan'208";a="245709192" Received: from unknown (HELO ironmsg02-R.qualcomm.com) ([10.53.140.106]) by wolverine01.qualcomm.com with ESMTP; 05 Dec 2016 18:39:27 -0800 X-IronPort-AV: E=McAfee;i="5700,7163,8370"; a="859287046" X-Amp-Result: CLEAN Received: from nasanexm01a.na.qualcomm.com ([10.85.0.81]) by ironmsg02-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 05 Dec 2016 18:39:27 -0800 Received: from NASANEXM01B.na.qualcomm.com (10.85.0.82) by nasanexm01a.na.qualcomm.com (10.85.0.81) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Mon, 5 Dec 2016 18:39:26 -0800 Received: from NASANEXM01B.na.qualcomm.com ([10.85.0.82]) by NASANEXM01B.na.qualcomm.com ([10.85.0.82]) with mapi id 15.00.1178.000; Mon, 5 Dec 2016 18:39:26 -0800 From: "Lundblade, Laurence" To: cose Thread-Topic: exact input to the sig computation Thread-Index: AQHST2n1R6OqlPuV/EaiRlaLIWe8iw== Date: Tue, 6 Dec 2016 02:39:26 +0000 Message-ID: <6965DA5C-E0A2-4B33-A290-2CE04BB41BAC@qti.qualcomm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1878.6) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [199.106.107.6] Content-Type: text/plain; charset="Windows-1252" Content-ID: <5928F8381C6E394CB6B8D35BCDD96909@qualcomm.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [COSE] exact input to the sig computation X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2016 02:39:29 -0000 Can you confirm for me the input to the signature computation (e.g. ECDSA) = is the concatenation of the the bstr wrapped protected headers and the bst= r wrapped payload? Pretty sure that=92s right, but it doesn=92t seem to be= explicit in the cose draft. Sorry if I missed it. Thx LL From nobody Mon Dec 5 19:26:35 2016 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A315129673 for ; Mon, 5 Dec 2016 19:26:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.797 X-Spam-Level: X-Spam-Status: No, score=-4.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 ra2yTfnYM1e4 for ; Mon, 5 Dec 2016 19:26:32 -0800 (PST) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11F54129477 for ; Mon, 5 Dec 2016 19:26:31 -0800 (PST) Received: from hebrews (24.21.96.37) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 5 Dec 2016 19:46:03 -0800 From: Jim Schaad To: "'Lundblade, Laurence'" , 'cose' References: <6965DA5C-E0A2-4B33-A290-2CE04BB41BAC@qti.qualcomm.com> In-Reply-To: <6965DA5C-E0A2-4B33-A290-2CE04BB41BAC@qti.qualcomm.com> Date: Mon, 5 Dec 2016 19:26:16 -0800 Message-ID: <06e501d24f70$82e801a0$88b804e0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQLDlc/nx5EH90d8rqydjo5S1/HJ+p8XtKsg Content-Language: en-us X-Originating-IP: [24.21.96.37] Archived-At: Subject: Re: [COSE] exact input to the sig computation X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2016 03:26:34 -0000 No that is not correct. The correct input is called out in section 4.4. You can also look at https://github.com/jimsch/Examples/blob/master/ecdsa-examples/ecdsa-01.json for the ToBeSign_hex field jim > -----Original Message----- > From: COSE [mailto:cose-bounces@ietf.org] On Behalf Of Lundblade, Laurence > Sent: Monday, December 05, 2016 6:39 PM > To: cose > Subject: [COSE] exact input to the sig computation > > Can you confirm for me the input to the signature computation (e.g. ECDSA) is > the concatenation of the the bstr wrapped protected headers and the bstr > wrapped payload? Pretty sure that's right, but it doesn't seem to be explicit in > the cose draft. Sorry if I missed it. > > Thx > > LL > > _______________________________________________ > COSE mailing list > COSE@ietf.org > https://www.ietf.org/mailman/listinfo/cose From nobody Mon Dec 5 19:31:31 2016 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 059791296A0 for ; Mon, 5 Dec 2016 19:31:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.917 X-Spam-Level: X-Spam-Status: No, score=-9.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=qti.qualcomm.com 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 NAiPn9MK3m5p for ; Mon, 5 Dec 2016 19:31:29 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DAB4129477 for ; Mon, 5 Dec 2016 19:31:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1480995089; x=1512531089; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=W0a4UFrgy2M9sYG3ruEm6oJKuUQ1GdxDQ2vN/5G8s6g=; b=C63M5uPt9ksQbipgShWMwBajlXbTFm+K8gGOV+913EzACGeDxaT3jNrS IZxE+YCpyZ+Q6H4IroNxxuNIHKaZrcAWofzKzDUTEQFKvv1Cmq5cHpnNx hyeQotcbXn4WAzBH4FDXof0/l+vCnIvT8A3QBixq8VXy2oQI9zyrF6npx I=; X-IronPort-AV: E=Sophos;i="5.33,751,1477983600"; d="scan'208";a="245724063" Received: from unknown (HELO Ironmsg03-R.qualcomm.com) ([10.53.140.107]) by wolverine01.qualcomm.com with ESMTP; 05 Dec 2016 19:31:28 -0800 X-IronPort-AV: E=McAfee;i="5700,7163,8370"; a="1269057515" X-Amp-Result: CLEAN Received: from nasanexm01b.na.qualcomm.com ([10.85.0.82]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 05 Dec 2016 19:31:28 -0800 Received: from NASANEXM01B.na.qualcomm.com (10.85.0.82) by NASANEXM01B.na.qualcomm.com (10.85.0.82) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Mon, 5 Dec 2016 19:31:27 -0800 Received: from NASANEXM01B.na.qualcomm.com ([10.85.0.82]) by NASANEXM01B.na.qualcomm.com ([10.85.0.82]) with mapi id 15.00.1178.000; Mon, 5 Dec 2016 19:31:27 -0800 From: "Lundblade, Laurence" To: Jim Schaad Thread-Topic: [COSE] exact input to the sig computation Thread-Index: AQHST2n1R6OqlPuV/EaiRlaLIWe8i6D6yEkAgAABaAA= Date: Tue, 6 Dec 2016 03:31:26 +0000 Message-ID: <64BCC80D-99AA-41AE-A492-85C96873E0CF@qti.qualcomm.com> References: <6965DA5C-E0A2-4B33-A290-2CE04BB41BAC@qti.qualcomm.com> <06e501d24f70$82e801a0$88b804e0$@augustcellars.com> In-Reply-To: <06e501d24f70$82e801a0$88b804e0$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1878.6) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [199.106.107.6] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: cose Subject: Re: [COSE] exact input to the sig computation X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2016 03:31:31 -0000 Well, I sure did miss it didn=92t I. Thanks for the quick response. :-) LL On Dec 5, 2016, at 7:26 PM, Jim Schaad wrote: > No that is not correct. The correct input is called out in section 4.4. >=20 > You can also look at > https://github.com/jimsch/Examples/blob/master/ecdsa-examples/ecdsa-01.js= on > for the ToBeSign_hex field >=20 > jim >=20 >> -----Original Message----- >> From: COSE [mailto:cose-bounces@ietf.org] On Behalf Of Lundblade, Lauren= ce >> Sent: Monday, December 05, 2016 6:39 PM >> To: cose >> Subject: [COSE] exact input to the sig computation >>=20 >> Can you confirm for me the input to the signature computation (e.g. ECDS= A) > is >> the concatenation of the the bstr wrapped protected headers and the bst= r >> wrapped payload? Pretty sure that's right, but it doesn't seem to be > explicit in >> the cose draft. Sorry if I missed it. >>=20 >> Thx >>=20 >> LL >>=20 >> _______________________________________________ >> COSE mailing list >> COSE@ietf.org >> https://www.ietf.org/mailman/listinfo/cose >=20 > _______________________________________________ > COSE mailing list > COSE@ietf.org > https://www.ietf.org/mailman/listinfo/cose From nobody Mon Dec 5 20:16:54 2016 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59CFC129695 for ; Mon, 5 Dec 2016 20:16:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.796 X-Spam-Level: X-Spam-Status: No, score=-4.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 F4xf7fpsycY0 for ; Mon, 5 Dec 2016 20:16:49 -0800 (PST) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7C501296A9 for ; Mon, 5 Dec 2016 20:16:48 -0800 (PST) Received: from hebrews (24.21.96.37) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 5 Dec 2016 20:36:27 -0800 From: Jim Schaad To: "'Lundblade, Laurence'" , 'Samuel Erdtman' References: <147987163959.30322.14158962529156430503.idtracker@ietfa.amsl.com> <004901d24546$8e76bfe0$ab643fa0$@augustcellars.com> <9CE238FE-6AF0-458D-A1C7-B790870323D3@qti.qualcomm.com> In-Reply-To: <9CE238FE-6AF0-458D-A1C7-B790870323D3@qti.qualcomm.com> Date: Mon, 5 Dec 2016 20:16:40 -0800 Message-ID: <06e701d24f77$8d438280$a7ca8780$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_06E8_01D24F34.7F265D00" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQGas+U5hOX2ZwwTfdISQ4lSrZ9yRQGKptd0AmvDM5wAeJK3gqFGCfeA Content-Language: en-us X-Originating-IP: [24.21.96.37] Archived-At: Cc: 'cose' Subject: Re: [COSE] New Version Notification for draft-schaad-cose-x509-00.txt X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2016 04:16:52 -0000 ------=_NextPart_000_06E8_01D24F34.7F265D00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thanks for input, it is something that nobody else has actually given yet. I could easily get behind the idea of moving to two different headers, one for ordered and one for a bag. I don't think that there would be a huge problem with assigning the multiple code points. I don't know how common/uncommon it is for fields to allow multiple types. I do know that the COSE spec does it in a couple of places, although most of them can be ignored at this point in time. Personally, I don't find the code to support that feature to be very difficult and argued that as part of the JOSE effort when the same topic was discussed. While it does not explicitly say that in COSE, my assumption was always that 'kid' only identified COSE based keys. I think that is probably an invalid assumption. I would however expect that if an explicit key is given in the form a certificate then a kid would not need to be present. An application however could state that a kid could be the spki value from a certificate so that it could be used to find certificates if desired. I'll make a comment to myself on that. More comments from everybody about what is good and bad are wanted. Jim From: Lundblade, Laurence [mailto:llundbla@qti.qualcomm.com] Sent: Monday, December 05, 2016 6:21 PM To: Samuel Erdtman Cc: Jim Schaad ; cose Subject: Re: [COSE] New Version Notification for draft-schaad-cose-x509-00.txt Sorry for the delayed response and thanks for the draft. The order definitive chain option for x5c looks pretty good. How does the kid parameter come into play? Is x5c in lieu of kid? Seems like it would be. Is it usual to have the data type / semantics vary for some CBOR like x5c? Haven't run into any CBOR like that before. Would it be better to have an x5cb (b for bag) and an x5co (o for ordered). Thanks! LL On Nov 23, 2016, at 10:43 PM, Samuel Erdtman > wrote: Looks like a good start to me. Laurence what do you think? //Samuel On Wed, Nov 23, 2016 at 6:00 AM, Jim Schaad > wrote: This is a rough draft of what a set of X.509 headers could look like. There is lots of things that are incomplete or missing, but I said I would write up a fast version for people to look at so here it is. If you are interested, please comment on the headers. The pointer to the github repository is in the document. Jim > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org ] > Sent: Tuesday, November 22, 2016 7:27 PM > To: Jim Schaad > > Subject: New Version Notification for draft-schaad-cose-x509-00.txt > > > A new version of I-D, draft-schaad-cose-x509-00.txt has been successfully > submitted by Jim Schaad and posted to the IETF repository. > > Name: draft-schaad-cose-x509 > Revision: 00 > Title: CBOR Encoded Message Syntax (COSE): Headers for carrying > and referencing X.509 certificates > Document date: 2016-11-22 > Group: Individual Submission > Pages: 6 > URL: https://www.ietf.org/internet-drafts/draft-schaad-cose-x509-00.txt > Status: https://datatracker.ietf.org/doc/draft-schaad-cose-x509/ > Htmlized: https://tools.ietf.org/html/draft-schaad-cose-x509-00 > > > Abstract: > This document defines the headers and usage for referring to and > transporting X.509 certificates in the CBOR Encoded Message (COSE) > Syntax. > > Contributing to this document > > The source for this draft is being maintained in GitHub. Suggested > changes should be submitted as pull requests at cose-wg/X509>. Instructions are on that page as well. Editorial > changes can be managed in GitHub, but any substantial issues need to > be discussed on the COSE mailing list. > > > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org . > > The IETF Secretariat _______________________________________________ COSE mailing list COSE@ietf.org https://www.ietf.org/mailman/listinfo/cose ------=_NextPart_000_06E8_01D24F34.7F265D00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks for = input, it is something that nobody else has actually given = yet.

 

I could = easily get behind the idea of moving to two different headers, one for = ordered and one for a bag.  I don’t think that there would be = a huge problem with assigning the multiple code = points.

 

I = don’t know how common/uncommon it is for fields to allow multiple = types.  I do know that the COSE spec does it in a couple of places, = although most of them can be ignored at this point in time.  = Personally, I don’t find the code to support that feature to be = very difficult and argued that as part of the JOSE effort when the same = topic was discussed.

 

While it = does not explicitly say that in COSE, my assumption was always that = ‘kid’ only identified COSE based keys.  I think that is = probably an invalid assumption.  I would however expect that if an = explicit key is given in the form a certificate then a kid would not = need to be present.  An application however could state that a kid = could be the spki value from a certificate so that it could be used to = find certificates if desired. I’ll make a comment to myself on = that.

 

More = comments from everybody about what is good and bad are = wanted.

 

Jim

 

 

From:<= /b> = Lundblade, Laurence [mailto:llundbla@qti.qualcomm.com]
Sent: = Monday, December 05, 2016 6:21 PM
To: Samuel Erdtman = <samuel@erdtman.se>
Cc: Jim Schaad = <ietf@augustcellars.com>; cose = <cose@ietf.org>
Subject: Re: [COSE] New Version = Notification for = draft-schaad-cose-x509-00.txt

 

Sorry = for the delayed response and thanks for the = draft.

 

The order definitive chain option for x5c looks pretty = good. How does the kid parameter come into play? Is x5c in lieu of kid? =  Seems like it would be.

 

Is it usual to have the data type / semantics vary for = some CBOR like x5c? Haven’t run into any CBOR like that before. =  Would it be better to have an x5cb (b for bag) and an x5co (o for = ordered).

 

Thanks!

 

LL

 

 

 

 

 

On = Nov 23, 2016, at 10:43 PM, Samuel Erdtman <samuel@erdtman.se> = wrote:



Looks like a good start = to me.

Laurence what do you = think?

//Samuel

 

On Wed, = Nov 23, 2016 at 6:00 AM, Jim Schaad <ietf@augustcellars.com> = wrote:

This is a = rough draft of what a set of X.509 headers could look like.  There = is lots of things that are incomplete or missing, but I said I would = write up a fast version for people to look at so here it is.

If = you are interested, please comment on the headers.  The pointer to = the github repository is in the document.

Jim


> = -----Original Message-----
> From: internet-drafts@ietf.org = [mailto:internet-drafts@ietf.org]> Sent: Tuesday, November 22, 2016 7:27 PM
> To: Jim Schaad = <ietf@augustcellars.com>
= > Subject: New Version Notification for = draft-schaad-cose-x509-00.txt
>
>
> A new version of = I-D, draft-schaad-cose-x509-00.txt has been successfully
> = submitted by Jim Schaad and posted to the IETF = repository.
>
> Name:        =  draft-schaad-cose-x509
> Revision:    =  00
> Title:              =   CBOR Encoded Message Syntax (COSE): Headers for carrying
> = and referencing X.509 certificates
> Document date:    =     2016-11-22
> Group:        =         Individual Submission
> Pages:  =               6
> URL:  =           https://www.ietf.org/internet-drafts/draft-schaad-cose-= x509-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-schaad-cose-x509= /
> Htmlized:       https://tools.ietf.org/html/draft-schaad-cose-x509-00
>
>
> Abstract:
>    This document = defines the headers and usage for referring to and
>    = transporting X.509 certificates in the CBOR Encoded Message = (COSE)
>    Syntax.
>
> Contributing to this = document
>
>    The source for this draft is being = maintained in GitHub.  Suggested
>    changes = should be submitted as pull requests at <https://github.com/
>    = cose-wg/X509>.  Instructions are on that page as well.  = Editorial
>    changes can be managed in GitHub, but any = substantial issues need to
>    be discussed on the COSE = mailing list.
>
>
>
>
> Please note that = it may take a couple of minutes from the time of submission
> = until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF = Secretariat


_______________________________________________COSE mailing list
COSE@ietf.org
https://www.ietf.org/mailman/listinfo/cose

 

 

------=_NextPart_000_06E8_01D24F34.7F265D00-- From nobody Tue Dec 6 22:01:50 2016 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDC4F129677 for ; Tue, 6 Dec 2016 22:01:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=erdtman-se.20150623.gappssmtp.com 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 jRXjxi_QBuFV for ; Tue, 6 Dec 2016 22:01:47 -0800 (PST) Received: from mail-wj0-x236.google.com (mail-wj0-x236.google.com [IPv6:2a00:1450:400c:c01::236]) (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 0520C129676 for ; Tue, 6 Dec 2016 22:01:46 -0800 (PST) Received: by mail-wj0-x236.google.com with SMTP id tk12so54012319wjb.3 for ; Tue, 06 Dec 2016 22:01:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=erdtman-se.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=CRtjZpb0dSPgAzpUfQWFjVeMHa6KVzdBF3c7rgZQnU8=; b=eO6xiE5qS6GdW+PNUJQlWPQFXSENJ3RnIAMZVtW3DyqqexU8GZoGL1zvCiZ4iipUu/ 43mmuyAoeaF89dOhh/I0Zc1GBy+QZIK6mUCkTU/5BUVvVemEOnzm6b+B8pYvaRKBiBNM MwZglVE06spVMvXI0pRCXdPYRkqpzOJZ7wta4YlWAacFyaCp78jHqv5fDd5A/QouaaO1 23sjeibRsAO2Rwj99aIcqvIqjabsx3dbVxW2WYZmq8NhX01MBECronXiZ0dXu/PJkmEi OTpFYEjc1ah9S+WGmXSmdTk389oFmlXXGqGdgJ6OVG9IOHXAF8Ev9hvyrHrKUl1Zf5uZ l7wQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=CRtjZpb0dSPgAzpUfQWFjVeMHa6KVzdBF3c7rgZQnU8=; b=LEv5p0vEN9BbOFOeSdx1KMdIP54Xc5OVQvMBaeauYxSvisgZYrCwsnYhKBFkfkx3Pj bpnMpo5M0laCwU47LqnPRFtCwRyOdZ6Kduo76Mryd892QdvICvgG0NaAYBkFYhjNXwB6 F+AG4ciVFBGZ9Qx8uzus/DyYx4oKPvTtUWsEi0qLwk8Gn+gOPR7RuGqJHh1LaqHA8AZY HI6DtupDJgUFED6DhjPhypoJWfg7cVbCVGZGca8M5bdWTxqfUTxR80x2ZZvGvNxmF6sU aNKB1oJLaKTvfoogisxWXG+UHko17B1g7ZmDF/TyFqD/oaakubOrLDzBbIqA7Kt41Bao WABw== X-Gm-Message-State: AKaTC00qTrDucc1KQDH5/gfNJOhT315XIVecJLg9DHYLwhpMbHUngUPlV/qIp8v+UaZQ8IAB+HKziOvgMXTrlQ== X-Received: by 10.25.193.196 with SMTP id r187mr21513548lff.21.1481090505210; Tue, 06 Dec 2016 22:01:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.219.12 with HTTP; Tue, 6 Dec 2016 22:01:44 -0800 (PST) In-Reply-To: <06e701d24f77$8d438280$a7ca8780$@augustcellars.com> References: <147987163959.30322.14158962529156430503.idtracker@ietfa.amsl.com> <004901d24546$8e76bfe0$ab643fa0$@augustcellars.com> <9CE238FE-6AF0-458D-A1C7-B790870323D3@qti.qualcomm.com> <06e701d24f77$8d438280$a7ca8780$@augustcellars.com> From: Samuel Erdtman Date: Wed, 7 Dec 2016 07:01:44 +0100 Message-ID: To: Jim Schaad Content-Type: multipart/alternative; boundary=94eb2c1a1d56719b7e05430b41c6 Archived-At: Cc: "Lundblade, Laurence" , cose Subject: Re: [COSE] New Version Notification for draft-schaad-cose-x509-00.txt X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2016 06:01:50 -0000 --94eb2c1a1d56719b7e05430b41c6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Jim, I think we should name the parameters differently x5t, x5c and x5u are used in JOSE with slightly different semantic. This would be similar to the "content type" in the COSE specification where cty is not used. Since the names are not included in the encoded message it might make sense to name them: * x509 Certificate Thumbprint * x509 Certificate Chain * x509 Certificate URL //Samuel On Tue, Dec 6, 2016 at 5:16 AM, Jim Schaad wrote: > Thanks for input, it is something that nobody else has actually given yet= . > > > > I could easily get behind the idea of moving to two different headers, on= e > for ordered and one for a bag. I don=E2=80=99t think that there would be= a huge > problem with assigning the multiple code points. > > > > I don=E2=80=99t know how common/uncommon it is for fields to allow multip= le > types. I do know that the COSE spec does it in a couple of places, > although most of them can be ignored at this point in time. Personally, = I > don=E2=80=99t find the code to support that feature to be very difficult = and argued > that as part of the JOSE effort when the same topic was discussed. > > > > While it does not explicitly say that in COSE, my assumption was always > that =E2=80=98kid=E2=80=99 only identified COSE based keys. I think that= is probably an > invalid assumption. I would however expect that if an explicit key is > given in the form a certificate then a kid would not need to be present. > An application however could state that a kid could be the spki value fro= m > a certificate so that it could be used to find certificates if desired. > I=E2=80=99ll make a comment to myself on that. > > > > More comments from everybody about what is good and bad are wanted. > > > > Jim > > > > > > *From:* Lundblade, Laurence [mailto:llundbla@qti.qualcomm.com] > *Sent:* Monday, December 05, 2016 6:21 PM > *To:* Samuel Erdtman > *Cc:* Jim Schaad ; cose > *Subject:* Re: [COSE] New Version Notification for > draft-schaad-cose-x509-00.txt > > > > Sorry for the delayed response and thanks for the draft. > > > > The order definitive chain option for x5c looks pretty good. How does the > kid parameter come into play? Is x5c in lieu of kid? Seems like it would > be. > > > > Is it usual to have the data type / semantics vary for some CBOR like x5c= ? > Haven=E2=80=99t run into any CBOR like that before. Would it be better t= o have an > x5cb (b for bag) and an x5co (o for ordered). > > > > Thanks! > > > > LL > > > > > > > > > > > > On Nov 23, 2016, at 10:43 PM, Samuel Erdtman wrote: > > > > Looks like a good start to me. > > Laurence what do you think? > > //Samuel > > > > On Wed, Nov 23, 2016 at 6:00 AM, Jim Schaad > wrote: > > This is a rough draft of what a set of X.509 headers could look like. > There is lots of things that are incomplete or missing, but I said I woul= d > write up a fast version for people to look at so here it is. > > If you are interested, please comment on the headers. The pointer to the > github repository is in the document. > > Jim > > > > -----Original Message----- > > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > > Sent: Tuesday, November 22, 2016 7:27 PM > > To: Jim Schaad > > Subject: New Version Notification for draft-schaad-cose-x509-00.txt > > > > > > A new version of I-D, draft-schaad-cose-x509-00.txt has been successful= ly > > submitted by Jim Schaad and posted to the IETF repository. > > > > Name: draft-schaad-cose-x509 > > Revision: 00 > > Title: CBOR Encoded Message Syntax (COSE): Headers for > carrying > > and referencing X.509 certificates > > Document date: 2016-11-22 > > Group: Individual Submission > > Pages: 6 > > URL: https://www.ietf.org/internet- > drafts/draft-schaad-cose-x509-00.txt > > Status: https://datatracker.ietf.org/doc/draft-schaad-cose-x509= / > > Htmlized: https://tools.ietf.org/html/draft-schaad-cose-x509-00 > > > > > > Abstract: > > This document defines the headers and usage for referring to and > > transporting X.509 certificates in the CBOR Encoded Message (COSE) > > Syntax. > > > > Contributing to this document > > > > The source for this draft is being maintained in GitHub. Suggested > > changes should be submitted as pull requests at > cose-wg/X509>. Instructions are on that page as well. Editorial > > changes can be managed in GitHub, but any substantial issues need to > > be discussed on the COSE mailing list. > > > > > > > > > > Please note that it may take a couple of minutes from the time of > submission > > until the htmlized version and diff are available at tools.ietf.org. > > > > The IETF Secretariat > > > _______________________________________________ > COSE mailing list > COSE@ietf.org > https://www.ietf.org/mailman/listinfo/cose > > > > > > _______________________________________________ > COSE mailing list > COSE@ietf.org > https://www.ietf.org/mailman/listinfo/cose > > --94eb2c1a1d56719b7e05430b41c6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Jim,

I think we should name the = parameters differently x5t, x5c and x5u are used in JOSE with slightly diff= erent semantic. This would be similar to the "content type" in th= e COSE specification where cty is not used.
Since the names a= re not included in the encoded message it might make sense to name them:
* x509 Certificate Thumbprint
* x509 Certificate Chain
* = x509 Certificate URL

//Samuel

On Tue, Dec 6, 2016 at 5:16= AM, Jim Schaad <ietf@augustcellars.com> wrote:

<= span style=3D"font-size:11.0pt;font-family:"Calibri",sans-serif">= Thanks for input, it is something that nobody else has actually given yet.<= u>

=C2=A0=

I could easily get behind the idea of moving to= two different headers, one for ordered and one for a bag.=C2=A0 I don=E2= =80=99t think that there would be a huge problem with assigning the multipl= e code points.

=C2= =A0

I don=E2=80=99t know how commo= n/uncommon it is for fields to allow multiple types.=C2=A0 I do know that t= he COSE spec does it in a couple of places, although most of them can be ig= nored at this point in time.=C2=A0 Personally, I don=E2=80=99t find the cod= e to support that feature to be very difficult and argued that as part of t= he JOSE effort when the same topic was discussed.

<= p class=3D"MsoNormal">=C2=A0

While it does not explicitly say that in COSE, my assumption was always = that =E2=80=98kid=E2=80=99 only identified COSE based keys.=C2=A0 I think t= hat is probably an invalid assumption.=C2=A0 I would however expect that if= an explicit key is given in the form a certificate then a kid would not ne= ed to be present.=C2=A0 An application however could state that a kid could= be the spki value from a certificate so that it could be used to find cert= ificates if desired. I=E2=80=99ll make a comment to myself on that.<= u>

=C2=A0

More comments from everybody about what is good and ba= d are wanted.

=C2=A0=

Jim

=C2=A0

<= u>=C2=A0

<= b>From: Lundblade, Laurence [mailto:llundbla@qti.qualcomm.com] Sent: Monday, December 05, 2016 6:21 PM
To: Samuel Erdtm= an <samuel@erdtma= n.se>
Cc: Jim Schaad <ietf@augustcellars.com>; cose <cose@ietf.org>
Sub= ject: Re: [COSE] New Version Notification for draft-schaad-cose-x509-00= .txt

=C2=A0

Sorry for t= he delayed response and thanks for the draft.

<= p class=3D"MsoNormal">=C2=A0

The order definitive chain option for x5c looks pretty good. How does = the kid parameter come into play? Is x5c in lieu of kid?=C2=A0 Seems like i= t would be.

=C2= =A0

Is it usual to have the dat= a type / semantics vary for some CBOR like x5c? Haven=E2=80=99t run into an= y CBOR like that before.=C2=A0 Would it be better to have an x5cb (b for ba= g) and an x5co (o for ordered).

=C2=A0

Thanks!

=C2=A0

<= /div>

LL

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

On = Nov 23, 2016, at 10:43 PM, Samuel Erdtman <samuel@erdtman.se> wrote:



Looks like a good start to me.

Lauren= ce what do you think?

//Samue= l

=C2=A0

On Wed, Nov 23, 2016 at 6:00 AM, Jim Schaad &= lt;ietf@augustc= ellars.com> wrote:

This is a rough draft of what a = set of X.509 headers could look like.=C2=A0 There is lots of things that ar= e incomplete or missing, but I said I would write up a fast version for peo= ple to look at so here it is.

If you are interested, please comment = on the headers.=C2=A0 The pointer to the github repository is in the docume= nt.

Jim


> -----Original Message-----
> From: internet-drafts@= ietf.org [mailto:internet-drafts@ietf.org]
> Sent: Tuesday, November = 22, 2016 7:27 PM
> To: Jim Schaad <ietf@augustcellars.com>
> Subject= : New Version Notification for draft-schaad-cose-x509-00.txt
>
>= ;
> A new version of I-D, draft-schaad-cose-x509-00.txt has been succ= essfully
> submitted by Jim Schaad and posted to the IETF repository.=
>
> Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-schaad-cose-x= 509
> Revision:=C2=A0 =C2=A0 =C2=A000
> Title:=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 CBOR Encoded Message Syntax (COSE): = Headers for carrying
> and referencing X.509 certificates
> Doc= ument date:=C2=A0 =C2=A0 =C2=A0 =C2=A0 2016-11-22
> Group:=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
>= Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 6
> UR= L:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://w= ww.ietf.org/internet-drafts/draft-schaad-cose-x509-00.txt
= > Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatrack= er.ietf.org/doc/draft-schaad-cose-x509/
> Htmlized:=C2=A0 = =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-schaad-= cose-x509-00
>
>
> Abstract:
>=C2=A0 =C2=A0 Thi= s document defines the headers and usage for referring to and
>=C2=A0= =C2=A0 transporting X.509 certificates in the CBOR Encoded Message (COSE)<= br>>=C2=A0 =C2=A0 Syntax.
>
> Contributing to this document<= br>>
>=C2=A0 =C2=A0 The source for this draft is being maintained = in GitHub.=C2=A0 Suggested
>=C2=A0 =C2=A0 changes should be submitted= as pull requests at <= https://github.com/
>=C2=A0 =C2=A0 cose-wg/X509>.=C2=A0 Instru= ctions are on that page as well.=C2=A0 Editorial
>=C2=A0 =C2=A0 chang= es can be managed in GitHub, but any substantial issues need to
>=C2= =A0 =C2=A0 be discussed on the COSE mailing list.
>
>
>>
> Please note that it may take a couple of minutes from the ti= me of submission
> until the htmlized version and diff are available = at tools.ietf.org.=
>
> The IETF Secretariat


__________________________= _____________________
COSE mailing list
COSE@ietf.org
https://www.ietf.org/mailman/= listinfo/cose

=C2=A0

=C2=A0


_____________= __________________________________
COSE mailing list
COSE@ietf.org
https://www.ietf.org/mailman/listinfo/cose


--94eb2c1a1d56719b7e05430b41c6-- From nobody Sat Dec 31 13:27:42 2016 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6F191295AB for ; Sat, 31 Dec 2016 13:27:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com 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 igoGWcOHOtjc for ; Sat, 31 Dec 2016 13:27:39 -0800 (PST) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0118.outbound.protection.outlook.com [104.47.40.118]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B729F1295AC for ; Sat, 31 Dec 2016 13:27:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=y82XMkr5I8tyXXm+jSJM1xpyxc8baPN/1Vak7l0dFh4=; b=LeLaPVC4Jaf5S8fX+RahvPNqW5RDM2ctRGkDl+iXzw8kjqdwr9WwS5yO21JCQRkh41s1oLdmpQFEzvTY3b2SU2LUWBBguNwsTBWXrPtCONJ3PhKsXac0XyCqzFBj1rFnlxPUQvuUTz11Z5jp8Eubkw3ZXWxGdPDcHyfhiUyd7/w= Received: from BN3PR03MB2355.namprd03.prod.outlook.com (10.166.74.150) by BN3PR03MB2353.namprd03.prod.outlook.com (10.166.74.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.803.11; Sat, 31 Dec 2016 21:27:36 +0000 Received: from BN3PR03MB2355.namprd03.prod.outlook.com ([10.166.74.150]) by BN3PR03MB2355.namprd03.prod.outlook.com ([10.166.74.150]) with mapi id 15.01.0803.021; Sat, 31 Dec 2016 21:27:36 +0000 From: Mike Jones To: "cose@ietf.org" Thread-Topic: Using RSA Algorithms with COSE Messages Thread-Index: AdJjpEu8Y3CnLIB3RHKvk1NTw30gZg== Date: Sat, 31 Dec 2016 21:27:36 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [50.47.95.25] x-ms-office365-filtering-correlation-id: ebeddb95-413b-4d73-231e-08d431c3d70a x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:BN3PR03MB2353; x-microsoft-exchange-diagnostics: 1; BN3PR03MB2353; 7:H112aKugOcJ6XgBGtJPMSPY89aHNroyxsQiq0y9Ath4N2mMWOgxHNyaCo3W12EekfmBDnjJKiV4hKugj8r1DhBMn+HIKyrmyJM6hVV/ieq7iT7HI0+U+gthD3dzjGuNW8Ty804WU/7GmXcH0fCpU5sOjO6ZGx41T0afMdi9emGTllh+AHE76ifA8KFRQPGOOmQwpEVX05GWFD4NuQ5qBVP5clUlVsgKMil9rKrTPKEOG7i4oeRua/1SQk6ylizRgLrG7zbY8Fw4hQyjLe96ZeGqEzZEt51D8rb5Uwnsl00xFmjPDU3I28x/lOV6ypFqgnVp3uzvm4qB9o3aODkM/7RwuxwC02sryDG0klTTS68BIYsEP89pr9UYGznu6K1AT5UsR3WlBspwJbpKOmIVyvQEIFc3jiG7NUnkph9x1IYhkXH8CIuMuTSEeyrPeR1MriEIjt1PGNHDHBjZc2UYkZPZwAm/bSMO7mGuRAgjCXqY= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705)(31418570063057)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123562025)(20161123560025)(20161123564025)(20161123555025)(6047074)(6042181)(6072148); SRVR:BN3PR03MB2353; BCL:0; PCL:0; RULEID:; SRVR:BN3PR03MB2353; x-forefront-prvs: 0173C6D4D5 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(209900001)(199003)(189002)(5660300001)(68736007)(106356001)(6506006)(10290500002)(110136003)(38730400001)(33656002)(2900100001)(7696004)(8990500004)(3660700001)(5640700003)(2420400007)(74316002)(66066001)(15650500001)(92566002)(105586002)(99286003)(6916009)(2351001)(6436002)(606005)(7906003)(25786008)(2501003)(77096006)(7736002)(55016002)(107886002)(7110500001)(790700001)(8676002)(50986999)(5630700001)(10090500001)(54356999)(97736004)(86612001)(102836003)(81166006)(8936002)(122556002)(3280700002)(450100001)(5005710100001)(6116002)(9686002)(86362001)(3846002)(189998001)(101416001)(1730700003)(2906002)(81156014)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR03MB2353; H:BN3PR03MB2355.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN3PR03MB23552CD0BEDEAA35E0705791F56D0BN3PR03MB2355namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Dec 2016 21:27:36.0170 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR03MB2353 Archived-At: Subject: [COSE] Using RSA Algorithms with COSE Messages X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Dec 2016 21:27:41 -0000 --_000_BN3PR03MB23552CD0BEDEAA35E0705791F56D0BN3PR03MB2355namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The specification Using RSA Algorithms with COSE Messages defines encodings for using RSA algorit= hms with CBOR Object Signing and Encryption (COSE) messages. This supports use cases for the FIDO= Alliance and others that need this functionality. Security Area Director = Kathleen Moriarty has agreed to AD sponsorship of this specification. This= specification incorporates text from draft-ietf-cose-msg-05 - the last COS= E specification version before the RSA algorithms were removed. The specification is available at: * https://tools.ietf.org/html/draft-jones-cose-rsa-01 An HTML-formatted version is also available at: * http://self-issued.info/docs/draft-jones-cose-rsa-01.html Review feedback is welcomed! -- Mike P.S. This notice was also posted at http://self-issued.info/?p=3D1624 and = as @selfissued. --_000_BN3PR03MB23552CD0BEDEAA35E0705791F56D0BN3PR03MB2355namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The specification Using RSA Algorithms with COSE Messages defines encodings for using RSA= algorithms with CBOR Object = Signing and Encryption (COSE) messages.  This supports use cases f= or the FIDO Alliance and others that need this functionality.  Securit= y Area Director Kathleen Moriarty has agreed to AD sponsorship of this specification.  This specification incorpor= ates text from draft-ietf-cose-msg-05 – the last COSE specification v= ersion before the RSA algorithms were removed.

 

The specification is available at:

 

An HTML-formatted version is also available at:=

 

Review feedback is welcomed!

 

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;        -- Mike

 

P.S.  This notice was also posted at http://self-issued.info/?p=3D1624 and as @selfissued.

--_000_BN3PR03MB23552CD0BEDEAA35E0705791F56D0BN3PR03MB2355namp_--