On Feb 25, 2008, at 3:35 PM, Jim Fenton wrote:
> Doug,
>
> Much as I appreciate your personal appeal, it's really the rough
> consensus of the working group, and not my opinion, that matters.
Jim,
Thank you for your feedback.
Of course consensus matters, but so does compatibility with RFC 48
Doug,
Much as I appreciate your personal appeal, it's really the rough
consensus of the working group, and not my opinion, that matters.
If I understand correctly, the difference between the approach you favor
and the one that I favor is as follows:
Approach A (favored by Doug): Check the g= t
Jim
As the cut-off approaches, this is an appeal for you to reconsider
where agreement might be found.
Risks associated with the use of g= restricted keys signing messages
where i= identities are not found within the From header exists
whether policy is asserted or not. A g= restricted key
On Feb 20, 2008, at 9:55 PM, Jim Fenton wrote:
> Jeff Macdonald wrote:
>> On Tue, Feb 19, 2008 at 03:04:08AM -0800, Douglas Otis wrote:
>>
>>> Expanding upon the effect of the SSP-02 Author Signature
>>> definition based upon a conversation with Jim...
>>>
>>> Jim suggested that to comply with
Jeff Macdonald wrote:
> On Tue, Feb 19, 2008 at 03:04:08AM -0800, Douglas Otis wrote:
>
>> Expanding upon the effect of the SSP-02 Author Signature definition
>> based upon a conversation with Jim...
>>
>> Jim suggested that to comply with SSP-02, signatures will not make use
>> of the i= pa
On Tue, Feb 19, 2008 at 03:04:08AM -0800, Douglas Otis wrote:
>Expanding upon the effect of the SSP-02 Author Signature definition
>based upon a conversation with Jim...
>
>Jim suggested that to comply with SSP-02, signatures will not make use
>of the i= parameter, since the i= parameter is nee
Expanding upon the effect of the SSP-02 Author Signature definition
based upon a conversation with Jim...
Jim suggested that to comply with SSP-02, signatures will not make use
of the i= parameter, since the i= parameter is needed only for g=
restricted keys.
Instead of a practice that offe
Per RFC 4871:
The signature's i= parameter is "expected" to contain on-behalf-of
information:
i= Identity of the user or agent (e.g., a mailing list manager) on
behalf of which this message is signed...
...
INFORMATIVE DISCUSSION: This document does not require the value of
the "i=" t
