Re: [OAUTH-WG] On the discovery of the OAuth Signature

Dirk Balfanz <balfanz@google.com> Wed, 28 July 2010 16:27 UTC

Return-Path: <balfanz@google.com>
X-Original-To: oauth@core3.amsl.com
Delivered-To: oauth@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80BC428C192 for <oauth@core3.amsl.com>; Wed, 28 Jul 2010 09:27:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.876
X-Spam-Level:
X-Spam-Status: No, score=-105.876 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 l0uiQdNGljfB for <oauth@core3.amsl.com>; Wed, 28 Jul 2010 09:27:19 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id C2E483A6969 for <oauth@ietf.org>; Wed, 28 Jul 2010 09:27:18 -0700 (PDT)
Received: from wpaz17.hot.corp.google.com (wpaz17.hot.corp.google.com [172.24.198.81]) by smtp-out.google.com with ESMTP id o6SGRfDo018488 for <oauth@ietf.org>; Wed, 28 Jul 2010 09:27:41 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1280334461; bh=JXZT3aS0bSNQu8dHTSHFLxI2X5w=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=UVN6MF1Uy+dh4wbLrcBpj4eyvjtlMmzkOqenj8vEuxxtvKmN31p1rsnm8hiELHCCV 9+MKpEcOE82pBBaFyRxMA==
DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=GNTsMTGXboEuJOemMfEqqqcF3fc/ltINORpwv/Iy9m/ifxTARVIWoxfF2l+pFakpz LxwM+RBKy7+idWT//j9bg==
Received: from ywg8 (ywg8.prod.google.com [10.192.7.8]) by wpaz17.hot.corp.google.com with ESMTP id o6SGR8Eh029307 for <oauth@ietf.org>; Wed, 28 Jul 2010 09:27:40 -0700
Received: by ywg8 with SMTP id 8so1132536ywg.14 for <oauth@ietf.org>; Wed, 28 Jul 2010 09:27:40 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.90.68.16 with SMTP id q16mr8207751aga.0.1280334459804; Wed, 28 Jul 2010 09:27:39 -0700 (PDT)
Received: by 10.231.130.9 with HTTP; Wed, 28 Jul 2010 09:27:39 -0700 (PDT)
In-Reply-To: <AANLkTi=SW3w-_pJZ5Oa4+fG_34dQPxsm92gNRVwq4OaU@mail.gmail.com>
References: <AANLkTi=SW3w-_pJZ5Oa4+fG_34dQPxsm92gNRVwq4OaU@mail.gmail.com>
Date: Wed, 28 Jul 2010 09:27:39 -0700
Message-ID: <AANLkTinV8G6CWs4VuhY9ZD+swtQx9rHQrB2kXrF5xf70@mail.gmail.com>
From: Dirk Balfanz <balfanz@google.com>
To: Nat Sakimura <sakimura@gmail.com>
Content-Type: multipart/alternative; boundary="00163613a328ab9dbf048c7518a6"
X-System-Of-Record: true
Cc: oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] On the discovery of the OAuth Signature
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 28 Jul 2010 16:27:20 -0000

On Tue, Jul 27, 2010 at 4:31 PM, Nat Sakimura <sakimura@gmail.com> wrote:

> Hi.
>
> Currently, the discovery document would have something like:
>
> {
>        "verification_keys":  {
>                "key1":"RSA.ALqcwR...",
>                "key2":"X509.<certificate>
>        }
> }
>
> It defines RSA and X509. Could we define a third type "certs_url" that
> points to the
> file that stores PEM format certificates (chain as well)?
>

I'm a bit hesitant to add more formats, since the client libraries would
have to support all of them. I'd be more comfortable actually replacing,
say, the X509.<certificate> version with this indirection.

One question, though: in my proposal, I'm saying that the validity of the
public key is controlled by the caching directives of this document. I.e.,
if you fetch this document, it has a key in it, and it says "you can cache
this for 24 hours", then it's ok to use the public keys in there for the
next 24 hours. If you use self-signed certs (the X509.<certificate>
version), you're supposed to ignore the not-before and not-after fields in
there. How does that work for this additional level of indirection? Let's
say the "server info" document is cacheable for 10 hours, the PEM you
download from there says that it can be cached for 24 hours, and the
not-after field in the cert says that it's valid for another week. Which of
those takes precedence?

Dirk.


>
> =nat
>
> --
> Nat Sakimura (=nat)
> http://www.sakimura.org/en/
> http://twitter.com/_nat_en
>