Subject: [dane] Closing issues that are no longer relevant...

From: Warren Kumari <[email-masked]>
Date: Tue, 19 Jul 2011 17:20:02 -0400

Hello.

Apologies all, I have not been very diligent in closing issues as they are discussed / become non-relevant. 

I'm going through the issue tracker and think that many of them can be closed -- unless I hear strong objections by the end of week I'm planning marking the following as closed:

Issue /#6: Downgrade -- Addressed by discussions on DNSSEC stripping, and in Section 4.4.

Issue #15:  What data should be hashed  -- Addressed in Protocol doc / discussions.

Issue #22: Provide the security of the strongest digest supported by both sides -- Discussions on list (decided that this should be left to the relying party)

Issue #2: Relying parties policies -- Addressed by discussions / changes in the Protocol doc.

Issue #7: Error Handling : What to do when you receive an invalid record -- Addressed in Protocol doc ((e.g Section 4.4)) 

W

---

From: "Jim Schaad" <[email-masked]>
Date: Tue, 19 Jul 2011 14:42:42 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Warren Kumari
> Sent: Tuesday, July 19, 2011 2:20 PM
> To: IETF DANE WG list
> Subject: [dane] Closing issues that are no longer relevant...
> 
> Hello.
> 
> I'm going through the issue tracker and think that many of them can be
> closed -- unless I hear strong objections by the end of week I'm planning
> marking the following as closed:
> 
> 
> Issue #22: Provide the security of the strongest digest supported by both
> sides -- Discussions on list (decided that this should be left to the
relying
> party)
> 
> Issue #2: Relying parties policies -- Addressed by discussions / changes
in the
> Protocol doc.
> 
> Issue #7: Error Handling : What to do when you receive an invalid record
--
> Addressed in Protocol doc ((e.g Section 4.4))

This is not fully addressed in the spec at present.  Specifically what to do
with unknown certificate types is not documented.  Also I am not sure what
the correct behavior should be for mal-formatted items.  I.e. if bytes are
missing or added to the current records.  If you use an ASN.1 parser on the
certificate and compare it, rather than byte comparing it then trailing bad
bytes might be ignored.

Jim

> 
> 
> W
> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane

---

From: Matt McCutchen <[email-masked]>
Date: Wed, 27 Jul 2011 02:03:15 -0400

On Tue, 2011-07-19 at 17:20 -0400, Warren Kumari wrote:
> closed -- unless I hear strong objections by the end of week I'm
> planning marking the following as closed:

I am just coming back to this now, and I think the following issues have

> Issue #22: Provide the security of the strongest digest supported by
> both sides -- Discussions on list (decided that this should be left to
> the relying party)

> changes in the Protocol doc.

I don't fault you for aggressively closing issues and putting the onus
on others to reopen them, but you could perhaps have given more thought
to the resolutions; your proposed closure of the three below would
probably have been better described as "wontfix".  :)

Also, IMO, a link should be mandatory to cite "discussions".  In this
kind of high-stakes standardization process, you can expect that at
least one person will want to check your sources.

-- 
Matt