Subject: Re: [CDNi] Key ID options for URI Signing draft

From: "Brandenburg, R. (Ray) van" <[email-masked]>
Date: Wed, 25 Mar 2015 21:07:18 +0000

Hi Leif,

Sorry for taking a while to take this up. This morning Kent and I had a chat on how to fix this issue. Our conclusion was that it would probably be best to allow both numerical Key IDs as well as string-based KEY IDs (e.g. to allow including a reference to a public key in case  asymmetric encryption of the URI Signature is used).

To encode that, we will remove the current KEY_ID attribute and add both a 'KEY_NUM=<signed 64bit integer>' attribute as well as an optional ‘KEY_STR=<string>' field, with any URI never having both. If it makes sense from an implementation point of view, we could alternatively usesub-options, such as ‘KEY_ID=NUM:<64 bit integer>’ and ‘KEY_ID=STR:<string>’. Any thoughts?

In addition, we went through the list of Information Elements in the draft and apart from the Version attribute, all of the current Elements are string based. What are your thoughts on limiting the length of these string attributes? In your experience, does this have any significant advantage from a performance point of view?

Thanks,

Ray

From: <Brandenburg>, Ray van Brandenburg
Date: Wednesday 21 January 2015 02:36
To: Leif Hedstrom
Cc: "[email-masked]<mailto:[email-masked]>"
Subject: Re: [CDNi] Key ID options for URI Signing draft

Hi Leif,

I think that’s a valid point. I will work with Kent on adding max length values for all IEs that end up in the URL.

Thanks,

Ray

From: Leif Hedstrom [mailto:[email-masked]]
Sent: dinsdag 20 januari 2015 17:48
To: Brandenburg, R. (Ray) van
Cc: Kent Leung (kleung); [email-masked]<mailto:[email-masked]>
Subject: Re: [CDNi] Key ID options for URI Signing draft

On Jan 20, 2015, at 2:19 AM, Brandenburg, R. (Ray) van <[email-masked]<mailto:[email-masked]>> wrote:

Hi Kent,

I’m not a big fan of having two IEs for effectively the same purpose. I understand the arguments in favor of allowing both options, but since we don’t describe the semantics of the KID field anyway, wouldn’t it be possible for a uCDN-dCDN pair that would prefer using numeric values to just parse the KID strings as an integer?

Alternatively, if there are arguments agains that, maybe it would be possible to have some sort of sub-options (e.g. KID=NUM:<num> and KID=STR:<string>)

I’m ok either way. My primary motivation is that I think KID should have a max length defined in the standards. I don’t care if its 64-bytes, or 256-bytes, or something otherwise reasonable. Allowing it for arbitrary length makes implementations less efficient and likely, error prone. Yes, I’m painfully aware that the RFCs for HTTP and URLs do not impose a max-URL length, but that’s not an excuse for us making things worse :).

I understand that the CDNs at play can put whatever restrictions in as they like, but that also makes for iffy interops IMO.

Cheers,

— leif

This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.