On Tue, Jul 27, 2010 at 4:31 PM, Nat Sakimura <sakim...@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
>
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
