ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] All done on potential SSP requirements?

2006-08-04 06:54:50

Hi Phill,

Hallam-Baker, Phillip wrote:
Hang on a second.

...hanging:-)

We have requirements here for a policy mechanism. That's not the same as 
requirements for the SSP record.

At this stage, we supposedly don't even know that there will even
be an SSP record in DNS. Ok, we probably do know that, but the
point is that we are not yet at the stage where we decide how
stuff is structured, nor how its stored.

The implementation of the policy mechanism may be concentrated in the policy record or split between the policy record and the key record.

Sure. Its possible.

And don't try to claim that the key record is final, it is not. We were not allowed to discuss the policy aspects of the key record at the time of base. It was pointed out at the time that the key record is also part of the policy system and we were told then that we could discuss those issues now.

I could quibble, but I don't think I need to. To be clear, my
understanding is that we really, really, strongly want to maintain
compatibility with the existing key records (and we've not broken
that so far). If some new field were defined s.t. it didn't force,
or practically require, changes to existing records, that'd be ok
on the face of it (if there's WG consensus etc.) I'm not sure if
SSP related stuff would cause a problem there or not.

I don't think we need to modify base but it does look to me as if we are going 
to possibly need to add features into the key records.

I don't think that is a serious problem either. We just end up with descriptions split between two documents. We can always refactor the documents at draft if people want the key record description

If there's consensus that its worthwhile adding to the key record for
SSP-related reasons then I guess we do that. (However, I'd expect
there to be some opposition to modifying key records at all unless
there's a compelling case. I've no strong opinion myself, but I
guess we'll see.)

One requirement that MUST appear in the document if the resulting spec is to 
clear the security review is as follows:

It must be possible for Alice to publish a key record that describes use of features such as canonicalization, digest or signature algorithm that are not widely supported without negating the value of the policy record.

I will explain why that is necessary in my next post.

I guess Mike has enough info. to include something we can discuss
already, e.g. the above sentence might be fine as a putative
requirement we can discuss. (Although I think maybe you stated it
even clearer before.)

But fire away explaining why of course...

S.

PS: The intent of my post was not to say "we're done talking about this"
but to see if we've missed anything before reqs-00 hits the street. I
assume that Mike will make sure that all relevant issues raised in the
recent discussion will get at least a mention in his reqs-00. reqs-01,
of course, should hopefully have a list that's a good bit shorter.


_______________________________________________
NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html