Re: [webfinger] secure links with https rels

[James M Snell <[e-mail]>]

On Thu, Dec 13, 2012 at 11:05 AM, Brad Fitzpatrick <[e-mail]>wrote:

> On Thu, Dec 13, 2012 at 10:54 AM, James M Snell <[e-mail]> wrote:
>
>> What I'm saying is that there should be an option of adding a signature
>> to the JRD document as a whole, generated using a key trusted by both the
>> client and server. This can be provided either within the JRD document
>> itself (perhaps leveraging JSON Web Signatures [1]) or using an external
>> mechanism such as the proposed Integrity header [2]. Providing this
>> information would be entirely optional on the part of the server. If it is
>> provided, however, the client SHOULD verify it prior to consuming the data.
>> A client could choose not to process any JRD unless the integrity check it
>> provided.
>>
>> [1] http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-07
>> [2] http://tools.ietf.org/html/draft-hallambaker-httpintegrity-02
>>
>> How the client and server determine which key to use to generate the
>> signature is out of scope but
>>
>
> Which means nobody will use this.  You can't just say "Here's a big
> optional mechanism, but key details are missing... figure it out, maybe."
>
> Also, what about this webfinger-specific?  If you want to work on signing
> HTTP responses (a noble goal), that's great, but there's no reason it needs
> to be lumped into WebFinger.
>
>
 HTTPS, on the other hand, is well-understood and widely implemented.
>
> WebFinger isn't supposed to be about designing a new PKI or crypto system.
>  It's supposed to be a simple mechanism to read some key/value pairs.
>
>
Last post on the topic because I've said basically everything I think needs
to be said on it: I never said this is WebFinger specific. I'm not
suggesting that anything be "lumped into WebFinger". Nor am I suggesting
that WF be "about designing a new PKI or crypto system". If, however,
WebFinger is going to be used in cases where verifying the integrity of the
provided information is critical, then the specification needs to properly
address how the integrity of the information can be verified. HTTPS does
not provide for that. Neither does any notion of a "secure link relation".