Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A1C61F0C44 for ; Thu, 4 Oct 2012 18:01:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.901 X-Spam-Level: X-Spam-Status: No, score=-2.901 tagged_above=-999 required=5 tests=[AWL=-0.699, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id euzoecsWyZ5v for ; Thu, 4 Oct 2012 18:00:59 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 590141F041F for ; Thu, 4 Oct 2012 18:00:59 -0700 (PDT) Received: by mail-ob0-f172.google.com with SMTP id v19so1417766obq.31 for ; Thu, 04 Oct 2012 18:00:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to; bh=uUjhpREkotqc8fZYXA+R3J/PdJ6Bnbaw+jF5aWi9U8s=; b=MPkLDJe2keYdzkGtmQHdzcciZ8/zCKvxJObwXo2B4IJyhBqdt+LLMIJVmYvClJavPB TQYcQ3qZGz2vVx3ao345ZGrLphjYe6vXG1WYjXq71Nb1a/RGptYbMgDD2FSS/1riGqE+ hOMRA4DVN3TApgb1pkc6IQcfE6iWxlkkSyf3i6o+oD8nN1RzKWHbJUsXdd4Ni+PaBEaW AKswz6LdVEyL2BDusF4yCM+iwNv+ukReJJFdO2CZ/DvNOqszdJCPGzbZD8XTw7uFfWeZ 02g8mxAXg42xxH7ZSoEacKHYgaAkR59SJs3Xnpq1eJVWQlwyIJhTBPRJV6RPUPVjrOf1 HIqQ== Received: by 10.60.11.1 with SMTP id m1mr5784476oeb.47.1349398858896; Thu, 04 Oct 2012 18:00:58 -0700 (PDT) Received: from ?IPv6:2001:470:8:e7c:908a:6c87:73c6:e647? ([2001:470:8:e7c:908a:6c87:73c6:e647]) by mx.google.com with ESMTPS id hz6sm8116891obb.1.2012.10.04.18.00.56 (version=SSLv3 cipher=OTHER); Thu, 04 Oct 2012 18:00:57 -0700 (PDT) References: <8777DAED-4ADA-4691-B5CD-0E5CF308BC1C@gmail.com> <6C5B4E61-C18F-470A-955C-B099A2208788@gmail.com> <97A7AE3F-E3AE-4F8A-9A34-8DCD780B3C05@gmail.com> <05f101cd8597$cff358c0$6fda0a40$@augustcellars.com> <4E1F6AAD24975D4BA5B1680429673943668025FD@TK5EX14MBXC284.redmond.corp.microsoft.com> Mime-Version: 1.0 (1.0) In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943668025FD@TK5EX14MBXC284.redmond.corp.microsoft.com> Content-Type: multipart/alternative; boundary=Apple-Mail-1DED3AF9-CCE8-466B-9B16-FAAA575CF88C Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: iPad Mail (10A403) From: Daniel Holth Date: Thu, 4 Oct 2012 21:00:53 -0400 To: Mike Jones Cc: Karen O'Donoghue , "jose@ietf.org" Subject: Re: [jose] DISCUSS: Nonce/Timestamp parameter X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 01:01:00 -0000 --Apple-Mail-1DED3AF9-CCE8-466B-9B16-FAAA575CF88C Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Would it be too confusing to ask for a sat "signed at" field for the header?= In my application this makes more sense (with the multiple signatures seria= lization specification jws-js) than a payload time stamp. Daniel Holth On Oct 4, 2012, at 8:15 PM, Mike Jones wrote: > As editor, I=E2=80=99m going to make the observation this is the one poll q= uestion where the results are not clear enough for it to be obvious what I s= hould do. There were many people who made comments about the question being= unclear and the intended use and meaning of the potential field or fields u= nclear. > =20 > Unless you feel differently, Karen and Jim, I believe that the best course= at this point is for me to add nothing to the specs as a result of this pol= l question, but for the working group to try to make decisions on much less a= mbiguous proposals (should any be made) than the one in the poll question. > =20 > -- Mike > =20 > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Ji= m Schaad > Sent: Tuesday, August 28, 2012 8:38 PM > To: 'Dick Hardt'; Axel.Nennker@telekom.de > Cc: beaton@google.com; jose@ietf.org > Subject: Re: [jose] DISCUSS: Nonce/Timestamp parameter > =20 > The question from my point of view is that common fields from many structu= res should potentially be supported in the base specification so that they c= an be common rather than having each structure define them separately. This= is only an issue if one wishes them to be placed in the header structure an= d not in the data structure.=20 > =20 > If one is looking at signing an unstructured data object =E2=80=93 such as= a file =E2=80=93 then it becomes difficult to have the fields such as a tim= e that it was signed be part of the file itself, especially if one is applyi= ng multiple signatures at different times. This is not an issue for the tok= en specification but could be for other uses of the signature or encryption s= pecifications. > =20 > I would agree that =E2=80=9Ciat=E2=80=9D is a timestamp for the purposes o= f this conversation. If one wanted a formalized timestamp from a third part= y authority then a totally different way of going about it would be required= . I chose the term nonce or timestamp because both had been discussed in th= e past without any specific resolution about what is needed. > =20 > Jim > =20 > =20 > From: Dick Hardt [mailto:dick.hardt@gmail.com]=20 > Sent: Monday, August 27, 2012 2:55 PM > To: Axel.Nennker@telekom.de > Cc: dick.hardt@gmail.com; beaton@google.com; ietf@augustcellars.com; jose@= ietf.org > Subject: Re: [jose] DISCUSS: Nonce/Timestamp parameter > =20 > I was considering "iat" to be the timestamp. I was not thinking there woul= d be an additional timestamp. > =20 > On Aug 27, 2012, at 2:13 PM, wrote: > =20 >=20 > We have exp > https://tools.ietf.org/html/draft-ietf-oauth-json-web-toke= n-03#section-4.1.1 > and iat > https://tools.ietf.org/html/draft-ietf-oauth-json-web-toke= n-03#section-4.1.3 > in JWT. Why do we need a timestamp? > =20 > Replay attacks of the same jwt can be mitigated through the jti claim > https://tools.ietf.org/html/draft-ietf-oauth-json-web-token-03#section-4.1= .7 > =20 > What do timestamp and nonce add to these? > =20 > Axel > =20 > =20 > =20 > From: Dick Hardt [mailto:dick.hardt@gmail.com]=20 > Sent: Monday, August 27, 2012 10:23 PM > To: Brian Eaton > Cc: Nennker, Axel; Jim Schaad; jose@ietf.org > Subject: Re: [jose] DISCUSS: Nonce/Timestamp parameter > =20 > =20 > On Aug 27, 2012, at 1:06 PM, Brian Eaton wrote: >=20 >=20 >=20 > On Mon, Aug 27, 2012 at 12:11 PM, Dick Hardt wrote:= > I have an application for JWT that is not OAuth2. > =20 > Should nonce and timestamp logic go in the application level protocol? > =20 > I prefer to NOT have the application level deal with token validity. >=20 >=20 >=20 > =20 > Having said that, nonce's are difficult to implement at scale and I have h= eard of many sites that don't implement them fully. > =20 > Nonce alone can't be implemented efficiently. You have to have time stamp= s as well, otherwise you are stuck storing ever nonce you've ever seen, fore= ver. > =20 > Even nonce + time stamp is challenging in distributed systems. It adds a l= ot of complexity. That complexity is sometimes merited, but not always. > =20 > Thanks for confirming my statement. > =20 > I have stopped using nonce and only use time stamps lately and have made t= he system relatively stateless so that a second submission of the token is o= k. That may not work for everyone, but I have found that architecture to be e= asier to implement and scale. > =20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose --Apple-Mail-1DED3AF9-CCE8-466B-9B16-FAAA575CF88C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Would it be too confusing to ask for a= sat "signed at" field for the header? In my application this makes more sen= se (with the multiple signatures serialization specification jws-js) than a p= ayload time stamp.

Daniel Holth

On Oct 4, 2012, at 8:15= PM, Mike Jones <Michael.J= ones@microsoft.com> wrote:

=

As editor, I=E2=80=99m goin= g to make the observation this is the one poll question where the results ar= e not clear enough for it to be obvious what I should do.  There were many people who made comments about the question being unclear and the= intended use and meaning of the potential field or fields unclear.

 

Unless you feel differently= , Karen and Jim, I believe that the best course at this point is for me to a= dd nothing to the specs as a result of this poll question, but for the working group to try to make decisions on much less ambiguous p= roposals (should any be made) than the one in the poll question.<= /span>

 

    &nb= sp;            &= nbsp;            = ;            &nb= sp;            &= nbsp;    -- Mike

 

From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Jim Schaad
Sent: Tuesday, August 28, 2012 8:38 PM
To: 'Dick Hardt'; Axel.Nen= nker@telekom.de
Cc: beaton@google.com; jose@ietf.org
Subject: Re: [jose] DISCUSS: Nonce/Timestamp parameter

 

The question from my point o= f view is that common fields from many structures should potentially be supp= orted in the base specification so that they can be common rather than having each structure define them separately.  This= is only an issue if one wishes them to be placed in the header structure an= d not in the data structure. 

 

If one is looking at signin= g an unstructured data object =E2=80=93 such as a file =E2=80=93 then it bec= omes difficult to have the fields such as a time that it was signed be part of the file itself, especially if one is applying multiple signatures a= t different times.  This is not an issue for the token specification bu= t could be for other uses of the signature or encryption specifications.

 

I would agree that =E2=80=9C= iat=E2=80=9D is a timestamp for the purposes of this conversation.  If o= ne wanted a formalized timestamp from a third party authority then a totally= different way of going about it would be required.  I chose the term n= once or timestamp because both had been discussed in the past without any sp= ecific resolution about what is needed.

 

Jim

 

 

From: Dick Hardt [mailto:dick.hardt@gmail.co= m]
Sent: Monday, August 27, 2012 2:55 PM
To: Axel.Nennker@telekom.d= e
Cc: dick.hardt@gmail.com;= beaton@google.com; ietf@august= cellars.com; jose@ietf.org
Subject: Re: [jose] DISCUSS: Nonce/Timestamp parameter

 

I was considering "iat" to be the timestamp. I was no= t thinking there would be an additional timestamp.

 

On Aug 27, 2012, at 2:13 PM, <Axel.Nennker@telekom.de> wrote:

=

 

We have exp

and iat

in JWT. Why do we need a timestamp?<= /o:p>

 

Replay attacks of the same jwt can be mit= igated through the jti claim

 

What do timestamp and nonce add to these?=

 

Axel

 

 

 

From: Dick Hardt [mailto:dick.hardt@g= mail.com] 
Sent: Monday, Augus= t 27, 2012 10:23 PM
To: Brian Eaton
= Cc: Nennker, Axel; J= im Schaad; jose@ietf.org
Subject: Re: [jose]= DISCUSS: Nonce/Timestamp parameter

 

 

Thanks for confirming my statement.

 

I have stopped using nonce and only use time stamps l= ately and have made the system relatively stateless so that a second submiss= ion of the token is ok. That may not work for everyone, but I have found tha= t architecture to be easier to implement and scale.

 

= --Apple-Mail-1DED3AF9-CCE8-466B-9B16-FAAA575CF88C--