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

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 4 Aug 2006 06:16:49 -0700

Hang on a second. 

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

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

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 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 

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.

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Stephen Farrell
> Sent: Friday, August 04, 2006 7:00 AM
> To: ietf-dkim
> Subject: [ietf-dkim] All done on potential SSP requirements?
> 
> 
> Folks,
> 
> We've batted about a load of stuff this week on SSP requirements.
> Some of it was new, some repeated from earlier rounds of 
> discussion, but all of stuff we needed to go over. But I 
> guess that Mike now has *plenty* of material to write up his 
> reqs-00 I-D (which he'll hopefully still manage to keep very short:-)
> 
> Rather than try resolve our different opinions based on these 
> list threads, I reckon we'd probably be better off waiting to 
> and try get consensus on requirements until after we've seen 
> them written down, so I suggest we let this week's discussion 
> rest for a little bit while Mike writes.
> 
> However, are there any potential SSP requirements that we've 
> not mentioned at all this past week or so?
> 
> Stephen.
> _______________________________________________
> NOTE WELL: This list operates according to 
> http://mipassoc.org/dkim/ietf-list-rules.html
> 
> 

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

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 04 Aug 2006 14:42:25 +0100

Hi Phill,

> 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…

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 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.)

> 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.