Subject: [secdir] SECDIR review of draft-kucherawy-sender-auth-header-17

From: Chris Lonvick <[email-masked]>
Date: Mon, 24 Nov 2008 11:59:37 -0800 (PST)

Hi,

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

Unfortunately, I wasn't able to spend a lot of time with this document. 
I skimmed most of it and read through the Security Considerations section. 
>From what I saw, the document appears to be in good shape.  The Security 
Considerations section is thorough and appears to cover all of the cases. 
Overall, I believe that the Internet community will benefit from this 
work.

Best regards,
Chris
_______________________________________________
secdir mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/secdir

---

From: Richard Barnes <[email-masked]>
Date: Tue, 25 Nov 2008 00:22:59 -0500

Hi all,

This document defines a document format (iCalendar) for expressing 
calendaring information.  This format does not contain mechanisms for 
providing security features to the information encoded in it, but there 
is appropriate text in the Security Considerations to guide protocols 
that might carry iCalendar documents.

My only real concern is the ambiguity of the "Binary" value data type. 
The other value data types defined in this document have clear semantics 
attached that indicate how a compliant parser might handle the encoded 
data.  The Binary type defines how to decode the included data, but not 
what sort of information this data conveys.  Without further context to 
guide processing of this information, I'm concerned that this could lead 
to implementations that attempt to guess the type of binary content.  I 
would suggest adding text to Section 3.2.20 of the following character:
"
If this parameter indicates that the type of the property value is 
BINARY, then the FMTTYPE paramter MUST be set in order to indicate the 
MIME type of the encoded binary information.
"

In general, though, I think this document is ready to go.

--Richard