On 06/06/2012 06:14 PM, SM wrote:
> Hi Ken,
> At 13:17 06-06-2012, Ken Murchison wrote:
>> I'm investigating using libopendkim for our CalDAV/iSchedule server.
>> The iSchedule spec is still being developed, but it will most
>> certainly rely on DKIM (or DOSETA if that effort is still alive).
>>
>> I have two questions about using the library as it currently exists:
>>
>> 1. Is there a way to keep the library from requiring a From: header,
>> other that modifying the source? This obviously makes it email-centric.
>
> The From: header is required as mentioned in Section 5.4 of RFC 6376.
> The only way around that is to modify the source.
Right. I wasn't sure if there was some function call or back-door that
I wasn't seeing in the source.
>> 2. What is the proper way to include an extra instance of a header
>> field name in "h=", per section 5.4.2 of RFC 6373? iSchedule will
>> most likely require that "h=" includes the number of Recipient:
>> headers + 1, to protect from intermediaries adding Recipients.
>> Obviously, the signer needs to add the extra instance, but does the
>> verifier have to as well?
>
> See dkim_options() and DKIM_OPTS_ALWAYSHDRS for signing. If a header
> is listed in "h=", the verifier will automatically look for it. That
> "protects" from the header being added in transit if it was not
> present during DKIM signing. BTW, the To" and Cc: headers are
> signed. Isn't that adequate protection from a RFC 5322 perspective?
Thanks, I will look into ALWAYSHDRS. I won't have To: or Cc: headers.
iSchedule is a HTTP-based protocol for transferring iCalendar scheduling
objects and it uses a different set of headers.
--
Kenneth Murchison
Principal Systems Software Engineer
Carnegie Mellon University
Received on Thu Jun 07 2012 - 01:16:39 PST