Subject: Re: [secdir] Secdir review: draft-ietf-mile-rfc5070-bis-22

From: Robert Sparks <[email-masked]>
Date: Wed, 1 Jun 2016 09:32:09 -0400

Retransmitting to fix a typo in the Subject to make this easier to find 
when searching on the draft name.

Apologies for the extra noise.

On 5/30/16 2:43 PM, Robert Sparks wrote:
> 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.
>
> Document : draft-ietf-mile-rfc5070bis-22
>
> Summary: This document has minor issues that should be addressed 
> before publication as Proposed Standard
>
> This document defines a document format for exchanging information 
> between
> operational security teams. It points out standardized mechanisms for
> transporting the documents (RFC6545 and RFC6546), to provide 
> confidentiality,
> integrity, and authenticity, but does not restrict the use of the 
> format to
> within those protocols.  Instead, it provides a generic set of 
> "Processing
> Considerations" in section 4, which are augmented by the Security
> Considerations in section 9.
>
> There are some minor issues with this approach that should be 
> addressed before
> publication.
>
> 1) The document requires that implementations validate documents 
> against the
> schema, and reject any documents that fail validation.  In particular, 
> Section
> 5.2 Item 4 requires rejecting documents with an unrecognized element in a
> supported namespace as a syntax error. Section 4.3 requires 
> implementations to
> ->dynamically generate the schema used for validation from IANA 
> registries<-.
> Section 5.2 Item 5 calls out that this dynamic generation has security 
> and
> performance implications, but does not describe them, and has a very 
> vague
> "SHOULD NOT download schemas at runtime" to guard against them.  I 
> seem to
> recall significant discussion in other contexts of the issues with 
> generating
> schema from IANA registries at runtime.  Perhaps the ADs can provide 
> pointers
> to material generated from those discussions that the group can 
> reference.
> Otherwise, the threats need to be described in more detail, and the 
> operational
> complexity of exercising these extension points (particularly given the
> requirement to reject documents that do not validate against the 
> content of the
> registries) needs to be spelled out.
>
> 2) The document notes (in Section 9.1) that some fields in the 
> document format
> may contain executable content. It is not clear which fields are being
> mentioned, or what _kind_ of executable content is being carried. 
> Explicitly
> calling out the fields that this document defines at this point, and
> characterizing their content would help. The precautions you might 
> need to take
> against a regex are different from those you would take against arbitrary
> bytecode the recipient might be asked to execute.
>
> 3) There are several fields that are characterized as "meaningful to 
> the sender
> and recipient". This implies that the document cannot be interpreted 
> outside
> some out-of-band prior arrangement defining the context in which those 
> fields
> are meaningful. The document should explicitly mention the need for 
> such prior
> arrangements in the Security Consideration section, and note the 
> danger of
> attempting to interpret those fields if the ability to ensure the 
> message falls
> within that pre-arranged context is suspect. The existing text around 
> ensuring
> proper authentication of the sender and recipient is a start, but is not
> sufficient. While considering the problems with interpreting these 
> fields in
> the wrong context, the document should recognize the possibility that 
> a given
> sender/recipient pair might have _two different_ arrangements about 
> what these
> fields mean, especially given the passage of sufficient time.
>
> Nits:
>
> A) Section 2.11 calls out to RFC4519 to defined the syntax of telephone
> numbers.  The document calls out to E.123, which provides guidelines for
> representing phone numbers but does not define a rigorous format 
> useful for a
> protocol field.  If it's important to exchange phone numbers in an
> interoperable way, consider pointing to something with more structure. 
> Do you
> want the string to conform to E.164?  Would it be useful to have 
> something as
> structured as a tel: URI?
>
> B) Section 4.1 says a character encoding MUST be explicitly specified, 
> but then
> immediately shows an example of a document with no character encoding...
>
> C) (micronit) The use of [RFC-ENUM] as a reference number is distracting.
> Please change the reference tag to [RFC7495].
>
> Note: I did _not_ verify that the schema was well formed or that it 
> matched the
> prose.
>

---

From: [email-masked]
Date: Wed, 1 Jun 2016 10:07:37 -0400

Thanks, Robert for the review and re sending it.

Sent from my iPhone

> On Jun 1, 2016, at 9:32 AM, Robert Sparks <[email-masked]> wrote:
> 
> Retransmitting to fix a typo in the Subject to make this easier to find when searching on the draft name.
> 
>> Summary: This document has minor issues that should be addressed before publication as Proposed Standard
>> 
>> This document defines a document format for exchanging information between
>> transporting the documents (RFC6545 and RFC6546), to provide confidentiality,
>> integrity, and authenticity, but does not restrict the use of the format to
>> within those protocols.  Instead, it provides a generic set of "Processing
>> There are some minor issues with this approach that should be addressed before
>> publication.
>> 
>> 1) The document requires that implementations validate documents against the
>> schema, and reject any documents that fail validation.  In particular, Section
>> supported namespace as a syntax error. Section 4.3 requires implementations to
>> ->dynamically generate the schema used for validation from IANA registries<-.
>> Section 5.2 Item 5 calls out that this dynamic generation has security and
>> performance implications, but does not describe them, and has a very vague
>> "SHOULD NOT download schemas at runtime" to guard against them.  I seem to
>> recall significant discussion in other contexts of the issues with generating
>> schema from IANA registries at runtime.  Perhaps the ADs can provide pointers
>> to material generated from those discussions that the group can reference.
>> Otherwise, the threats need to be described in more detail, and the operational
>> requirement to reject documents that do not validate against the content of the
>> 2) The document notes (in Section 9.1) that some fields in the document format
>> mentioned, or what _kind_ of executable content is being carried. Explicitly
>> characterizing their content would help. The precautions you might need to take
>> 3) There are several fields that are characterized as "meaningful to the sender
>> and recipient". This implies that the document cannot be interpreted outside
>> some out-of-band prior arrangement defining the context in which those fields
>> are meaningful. The document should explicitly mention the need for such prior
>> arrangements in the Security Consideration section, and note the danger of
>> attempting to interpret those fields if the ability to ensure the message falls
>> within that pre-arranged context is suspect. The existing text around ensuring
>> sufficient. While considering the problems with interpreting these fields in
>> the wrong context, the document should recognize the possibility that a given
>> sender/recipient pair might have _two different_ arrangements about what these
>> representing phone numbers but does not define a rigorous format useful for a
>> interoperable way, consider pointing to something with more structure. Do you
>> want the string to conform to E.164?  Would it be useful to have something as
>> B) Section 4.1 says a character encoding MUST be explicitly specified, but then
>> Note: I did _not_ verify that the schema was well formed or that it matched the
>> prose.
>

---

From: "Roman D. Danyliw" <[email-masked]>
Date: Thu, 2 Jun 2016 05:03:16 +0000

Hello Robert!

Thanks again for this review.  Comments are inline ...

> -----Original Message-----
> From: Robert Sparks [mailto:[email-masked]]
> Sent: Monday, May 30, 2016 2:44 PM
> To: [email-masked]; [email-masked]; [email-masked]
> Subject: Secdir review: draft-ietf-mile-5070-bis-22
> 
> 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.
> 
> between operational security teams. It points out standardized mechanisms
> for transporting the documents (RFC6545 and RFC6546), to provide
> confidentiality, integrity, and authenticity, but does not restrict the use of the
> format to within those protocols.  Instead, it provides a generic set of
> "Processing Considerations" in section 4, which are augmented by the
> Security Considerations in section 9.
> 
> There are some minor issues with this approach that should be addressed
> before publication.
> 
> 1) The document requires that implementations validate documents against
> the schema, and reject any documents that fail validation.  In particular,
> Section
> "SHOULD NOT download schemas at runtime" to guard against them.  I seem
> to recall significant discussion in other contexts of the issues with generating
> pointers to material generated from those discussions that the group can
> reference.
> operational complexity of exercising these extension points (particularly
> given the requirement to reject documents that do not validate against the
> content of the

To this analysis, I'll also add Stephen Farrell's COMMENT (https://www.ietf.org/mail-archive/web/mile/current/msg01885.html) against using validation and the security issues when checking the IANA registry; and that Alexey Melnikov has marked this issue as a DISCUSS (https://datatracker.ietf.org/doc/draft-ietf-mile-rfc5070-bis/ballot/).

To the WG: 

Consideration #1
==============

---[ begin Item #4 of Section 5.2 ]---
   4.  Implementations that encounter an unrecognized element in a
       supported namespace MUST reject the document as a syntax error.
---[ end Item #4 of Section 5.2 ]---

** Do we want to weaken the validation requirement in Item #4 of Section 5.2 from MUST to MAY?

IMO, this is a straightforward change that will provide more flexibility for implementations to process even non-conforming documents. 

 One minor concern here is that this may now lead to non-standard extensions.

Consideration #2
==============
Item #5 of Section 5.2 cautions against dynamically regenerating the schema from registry values at run-time; but also from downloading the base schema then too.

---[ begin Item #5 of Section 5.2 ]---
   5.  There are security and performance implications in requiring
       implementations to dynamically download schemas at run time.
       Therefore, implementations SHOULD NOT download schemas at runtime
       unless the appropriate precautions are taken.  Implementations
       also need to contend with the potential of significant network
       and processing issues.
---[ end Item #5 of Section 5.2 ]---

** Do we want to strengthen the caution of not downloading the schema in real-time in Item #5 of Section 5.2 from SHOULD NOT to MUST NOT? 

IMO, yes.

Consideration #3
==============

As Robert suggests, minimally, there needs to be a discussion in the security considerations on how these new enum values will securely be added to the schema/parser.  However, the question remains, what guidance do we provide about how often the IANA registry should be checked.

---[ begin Section 4.3]---
   Furthermore, the
   enumerated values present in this document are a static list that
   will be incomplete over time as select attributes can be extended by
   a corresponding IANA registry per Section 10.2.  Therefore, the
   schema to validate a given document MUST be dynamically generated
   from these registry values.
---[ end Section 4.3 ]---

** Should we modify the last sentence as follows:

"Therefore, the schema to validate a given document MUST be periodically regenerated from these registry values.  It is RECOMMENDED that this SHOULD NOT occur more frequently than xxx"

Kathleen/Alexey/or any reader of this note: do you have a pointer to the prior discussion on dynamically generating a schema from an IANA registry referenced by Robert so that "xxx" can be populated?

> 2) The document notes (in Section 9.1) that some fields in the document
> format may contain executable content. It is not clear which fields are being
> characterizing their content would help. The precautions you might need to
> take against a regex are different from those you would take against
> arbitrary bytecode the recipient might be asked to execute.

The areas of concern would be:

(1) any classes that can have "binary strings" per Section 2.5 since this would allow binary code to be embedded in the document.  The affected classes are those of type iodef:ExtensionType and RecordPattern;
(2) the EmailMessage and EmailBody classes
(3) the DetectionPattern class, as it could specify a machine readable configuration for a device or application
(4) the URL class that could reference a location containing executable content
(5) the AdditionalData class which contain pretty much anything

(1) - (4) are places in the data model where binary blobs or text scripts could be inserted by design.  With (5), this is a an extension on which there are no constraints.  Technically, executable content also be put into any of the classes but the parser is unlikely to read them as such.

Clarifying language referencing these classes can be added to the security considerations.

> 3) There are several fields that are characterized as "meaningful to the
> sender and recipient". This implies that the document cannot be interpreted
> outside some out-of-band prior arrangement defining the context in which
> those fields are meaningful. The document should explicitly mention the
> need for such prior arrangements in the Security Consideration section, and
> note the danger of attempting to interpret those fields if the ability to ensure
> the message falls within that pre-arranged context is suspect. The existing
> text around ensuring proper authentication of the sender and recipient is a
> start, but is not sufficient. While considering the problems with interpreting
> these fields in the wrong context, the document should recognize the
> possibility that a given sender/recipient pair might have _two different_
> arrangements about what these fields mean, especially given the passage of
> sufficient time.

Agreed.  There needs to be language added to the security considerations to discuss profiling and out-of-band arrangements.  In scanning through the document, DefinedCOA, is one of those.  What are the other fields you caught?

> representing phone numbers but does not define a rigorous format useful
> for a protocol field.  If it's important to exchange phone numbers in an
> want the string to conform to E.164?  Would it be useful to have something
> as structured as a tel: URI?
> 
> B) Section 4.1 says a character encoding MUST be explicitly specified, but
> then immediately shows an example of a document with no character
> encoding...

Good point.  That will be fixed.  Upon further review, the example with no encoding also doesn't make sense given the MUST above in the text saying it always needs to be specified.  The two examples in this section are from RFC5070 but they don't align with the text updated in this draft.

> Please change the reference tag to [RFC7495].

Good point.  This will be fixed.

Roman

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 2 Jun 2016 09:51:29 +0100

Hi Roman,

> To this analysis, I'll also add Stephen Farrell's COMMENT (https://www.ietf.org/mail-archive/web/mile/current/msg01885.html) against using validation and the security issues when checking the IANA…
I don't mind, but I can also live with SHOULD here.
>   One minor concern here is that this may now lead to non-standard extensions.
Yes.
> Consideration #3
I have no idea about reasonable "xxx" values. This was never done 
before. (When it was suggested before IESG persuaded authors to change 
their documents.)

While talking to www.iana.org directly from devices/programs is 
tempting, it might be better if vendors periodically download new values 
from IANA and then devices/programs talk to vendor's websites (or use 
vendor's update mechanisms).

Best Regards,
Alexey

---

From: "Roman D. Danyliw" <[email-masked]>
Date: Thu, 2 Jun 2016 12:49:00 +0000

Hi Alexey!

> From: Alexey Melnikov [mailto:[email-masked]]
> Sent: Thursday, June 02, 2016 4:51 AM
> To: Roman D. Danyliw <[email-masked]>; Robert Sparks
> <[email-masked]>
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> Subject: Re: [mile] Secdir review: draft-ietf-mile-5070-bis-22
> 
> Hi Roman,
> 

[snip]

> > Consideration #3
> > ==============
> >
> > As Robert suggests, minimally, there needs to be a discussion in the
> security considerations on how these new enum values will securely be
> added to the schema/parser.  However, the question remains, what
> guidance do we provide about how often the IANA registry should be
> checked.
> >
> > "Therefore, the schema to validate a given document MUST be periodically
> regenerated from these registry values.  It is RECOMMENDED that this
> SHOULD NOT occur more frequently than xxx"
> >
> > Kathleen/Alexey/or any reader of this note: do you have a pointer to the
> prior discussion on dynamically generating a schema from an IANA registry
> referenced by Robert so that "xxx" can be populated?
> I have no idea about reasonable "xxx" values. This was never done before.
> (When it was suggested before IESG persuaded authors to change their
> documents.)

Understood.  Thanks for channeling the historical wisdom.

> While talking to www.iana.org directly from devices/programs is tempting, it
> might be better if vendors periodically download new values from IANA and
> then devices/programs talk to vendor's websites (or use vendor's update
> mechanisms).

What about language like the following in Section 4.3:

-- Therefore, the schema to validate a given document MUST 
-- be dynamically generated from these registry values.
++ Therefore, IODEF implementations MUST periodically update 
++ their schema and MAY need to update their parsing algorithms 
++ to incorporate newly registered values added 
++ to the IANA registries specified in Section xx.

In addition, add text to the security considerations that this updating needs to be done securely.

Roman

---

From: [email-masked]
Date: Thu, 2 Jun 2016 08:13:01 -0400

Hello,

Thanks Robert for the detailed and helpful review.  Inline 

Sent from my iPhone

> On Jun 2, 2016, at 4:51 AM, Alexey Melnikov <[email-masked]> wrote:
> 
> Hi Roman,
> 

Agreed, SHOULD is a bit stronger.

>> ** Do we want to strengthen the caution of not downloading the schema in real-time in Item #5 of Section 5.2 from SHOULD NOT to MUST NOT?

Yes

> I have no idea about reasonable "xxx" values. This was never done before. (When it was suggested before IESG persuaded authors to change their documents.)
> 
> While talking to www.iana.org directly from devices/programs is tempting, it might be better if vendors periodically download new values from IANA and then devices/programs talk to vendor's websites (or use vendor's update mechanisms).

I like Alexey's suggestion as it would greatly reduce the hits to IANA and accomplish the same goal.

Best regards,
Kathleen

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 02 Jun 2016 14:52:35 +0100

Hi,

> ++ to the IANA registries specified in Section xx.

I think this is an improvement. But also see Kathleen's reply.

> needs to be done securely.

Right.

---

From: "Roman D. Danyliw" <[email-masked]>
Date: Mon, 20 Jun 2016 14:08:12 +0000

Hello Robert!

> From: Roman D. Danyliw [mailto:[email-masked]]
> Sent: Thursday, June 02, 2016 1:03 AM
> To: Robert Sparks <[email-masked]>
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> Subject: RE: Secdir review: draft-ietf-mile-5070-bis-22
> 
> Hello Robert!
> 
> > between operational security teams. It points out standardized
> > mechanisms for transporting the documents (RFC6545 and RFC6546), to
> > provide confidentiality, integrity, and authenticity, but does not
> > restrict the use of the format to within those protocols.  Instead, it
> > provides a generic set of "Processing Considerations" in section 4,
> > which are augmented by the Security Considerations in section 9.
> >
> > addressed before publication.

[snip]
 
> > document format may contain executable content. It is not clear which
> > fields are being mentioned, or what _kind_ of executable content is
> > being carried. Explicitly calling out the fields that this document
> > defines at this point, and characterizing their content would help.
> > The precautions you might need to take against a regex are different
> > from those you would take against arbitrary bytecode the recipient might
> be asked to execute.
> 
> (1) any classes that can have "binary strings" per Section 2.5 since this would
> allow binary code to be embedded in the document.  The affected classes
> are those of type iodef:ExtensionType and RecordPattern;
> (3) the DetectionPattern class, as it could specify a machine readable
> configuration for a device or application
> (1) - (4) are places in the data model where binary blobs or text scripts could
> be inserted by design.  With (5), this is a an extension on which there are no
> constraints.  Technically, executable content also be put into any of the
> classes but the parser is unlikely to read them as such.
> 

The updated text in -23 reads as follows:

9.1.  Security
[snip]
   Executable content of various forms could be embedded into the IODEF
   document directly or through an extension.  Implementation MUST
   handle this content with care to prevent unintentional automated
   execution.  The following classes are explicitly intended to
   represent content that might be executable:

   o  All classes of type iodef:ExtensionType and the RecordPattern
      class can represent arbitrary binary strings such as legitimate
      software programs or malware.

   o  The EmailMessage and EmailBody classes can represent email
      attachments that can contain arbitrary content.

   o  The DetectionPattern class could specify a machine-readable
      configuration that directs the execution of the corresponding
      tool.

> > the sender and recipient". This implies that the document cannot be
> > interpreted outside some out-of-band prior arrangement defining the
> > context in which those fields are meaningful. The document should
> > explicitly mention the need for such prior arrangements in the
> > Security Consideration section, and note the danger of attempting to
> > interpret those fields if the ability to ensure the message falls
> > ensuring proper authentication of the sender and recipient is a start,
> > but is not sufficient. While considering the problems with
> > interpreting these fields in the wrong context, the document should
> > recognize the possibility that a given sender/recipient pair might
> > have _two different_ arrangements about what these fields mean,
> especially given the passage of sufficient time.
> 
> Agreed.  There needs to be language added to the security considerations to
> discuss profiling and out-of-band arrangements.  In scanning through the
> document, DefinedCOA, is one of those.  What are the other fields you
> caught?

The updated text in -23 reads as follows:

9.1.  Security
[snip]
   Certain classes may require out-of-band coordination to agree upon
   their semantics (e.g., Confidence@rating="low" or DefinedCOA).  This
   coordination MUST occur prior to operational data exchange to prevent
   the incorrect interpretation of these select data elements.  When
   parsing these data elements, implementations should validate, when
   possible, that they conform to the agreed upon semantics.  These
   semantics may need to be periodically reevaluated.

> > Nits:
> >
> > A) Section 2.11 calls out to RFC4519 to defined the syntax of
> > telephone numbers.  The document calls out to E.123, which provides
> > guidelines for representing phone numbers but does not define a
> > rigorous format useful for a protocol field.  If it's important to
> > exchange phone numbers in an interoperable way, consider pointing to
> something with more structure.
> > Do you
> > something as structured as a tel: URI?

The updated text in -23 reads as follows:

2.11.  Telephone Number

   A telephone number is represented in the information model by the
   PHONE data type.  The format of the PHONE data type is documented in
   [E.164].

   [E.164]    ITU Telecommunication Standardization Sector, "The
              International Public Telecommunication Numbering Plan",
              ITU-T Recommendation E.164 (02/05), February 2005.

> > but then immediately shows an example of a document with no character
> > encoding...
> 
> Good point.  That will be fixed.  Upon further review, the example with no
> encoding also doesn't make sense given the MUST above in the text saying it
> always needs to be specified.  The two examples in this section are from
> RFC5070 but they don't align with the text updated in this draft.

The updated text in -23 reads as follows:

4.1.  Encoding

   Every IODEF document MUST begin with an XML declaration and MUST
   specify the XML version used.  The character encoding MUST also be
   explicitly specified.  UTF-8 [RFC3629] SHOULD be used unless UTF-16
   [RFC2781] is necessary.  Encodings other than UTF-8 and UTF-16 SHOULD
   NOT be used.  The IODEF conforms to all XML data encoding conventions
   and constraints.

   The XML declaration with UTF-8 character encoding will read as
   follows:

   <?xml version="1.0" encoding="UTF-8" ?>

> > Please change the reference tag to [RFC7495].

The updated text in -23 reads as follows:

   [RFC7495]  Montville, A. and D. Black, "IODEF Enumeration Reference
              Format", RFC 7495, January 2015.

Thanks again for your detailed review.

Roman

---

From: "Roman D. Danyliw" <[email-masked]>
Date: Mon, 20 Jun 2016 14:21:36 +0000

Hello!

> Sent: Thursday, June 02, 2016 9:53 AM
> > > Cc: [email-masked]; [email-masked];
> > > [email-masked]; [email-masked]
> > > security considerations on how these new enum values will securely
> > > be added to the schema/parser.  However, the question remains, what
> > > prior discussion on dynamically generating a schema from an IANA
> > > registry referenced by Robert so that "xxx" can be populated?
> before.
> > > tempting, it might be better if vendors periodically download new
> > > values from IANA and then devices/programs talk to vendor's websites
> > > (or use vendor's update mechanisms).
> >
> > ++ Therefore, IODEF implementations MUST periodically update their
> > ++ schema and MAY need to update their parsing algorithms to
> > ++ incorporate newly registered values added to the IANA registries
> > ++ specified in Section xx.
> 

The following is the updated text in -23:

4.3.  Validation

   IODEF documents MUST be well-formed XML.  It is RECOMMENDED that
   recipients validate the document against the schema described in
   Section 8.  ...  These MUST also
   be considered by an IODEF implementation.  Furthermore, the
   enumerated values present in this document are a static list that
   will be incomplete over time as select attributes can be extended by
   a corresponding IANA registry per Section 10.2.  Therefore, IODEF
   implementations MUST periodically update their schema and MAY need to
   update their parsing algorithms to incorporate newly registered
   values.

> > updating needs to be done securely.

The following text was added in -23:

9.1.  Security
[snip]
   Per Section 4.3, IODEF implementations will need to periodically
   consult the IANA registries specified in Section 10.2 to discover
   newly registered enumerated attribute values.  These implementations
   MUST communicate with IANA in a way that ensures the integrity of the
   values and the authenticity of the source.  HTTPS over TLS
   [RFC2818][RFC5246] provides such security.

---

From: "Roman D. Danyliw" <[email-masked]>
Date: Mon, 20 Jun 2016 14:24:16 +0000

Hello!

> From: [email-masked]
> [mailto:[email-masked]]
> Sent: Thursday, June 02, 2016 8:13 AM
> To: Alexey Melnikov <[email-masked]>
> Cc: Roman D. Danyliw <[email-masked]>; Robert Sparks
> <[email-masked]>; [email-masked]; draft-ietf-mile-rfc5070-
> [email-masked]; [email-masked]; [email-masked]
> >>> security area directors.  Document editors and WG chairs should
> >>> treat these comments just like any other last call comments.
> >>>
> >>> restrict the use of the format to within those protocols.  Instead,
> >>> it provides a generic set of "Processing Considerations" in section
> >>> 4, which are augmented by the Security Considerations in section 9.
> >>>
> >>> against the schema, and reject any documents that fail validation.
> >>> In particular, Section
> >>> 5.2 Item 4 requires rejecting documents with an unrecognized element
> >>> in a supported namespace as a syntax error. Section 4.3 requires
> >>> implementations to
> >>> Section 5.2 Item 5 calls out that this dynamic generation has
> >>> security and performance implications, but does not describe them,
> >>> and has a very vague "SHOULD NOT download schemas at runtime" to
> >>> guard against them.  I seem to recall significant discussion in
> >>> other contexts of the issues with generating schema from IANA
> >>> registries at runtime.  Perhaps the ADs can provide pointers to
> >>> material generated from those discussions that the group can reference.
> >>> operational complexity of exercising these extension points
> >>> (particularly given the requirement to reject documents that do not
> >>> validate against the content of the
> >> To this analysis, I'll also add Stephen Farrell's COMMENT
> (https://www.ietf.org/mail-archive/web/mile/current/msg01885.html)
> against using validation and the security issues when checking the IANA
> registry; and that Alexey Melnikov has marked this issue as a DISCUSS
> (https://datatracker.ietf.org/doc/draft-ietf-mile-rfc5070-bis/ballot/).
> >>
> >> To the WG:
> >>
> >> Consideration #1
> >> ==============
> >>
> >> IMO, this is a straightforward change that will provide more flexibility for
> implementations to process even non-conforming documents.

The text in -23 was updated as follows:

5.2.  Extending Classes
[snip]
   4.  Implementations that encounter an unrecognized element, attribute
       or attribute value in a supported namespace SHOULD reject the
       document as a syntax error.

> >> Consideration #2
> >> ==============
> >> Item #5 of Section 5.2 cautions against dynamically regenerating the
> schema from registry values at run-time; but also from downloading the base
> schema then too.
> >>
> >> ** Do we want to strengthen the caution of not downloading the schema
> in real-time in Item #5 of Section 5.2 from SHOULD NOT to MUST NOT?
> >>
> >> IMO, yes.
> > Yes.
> 
> Yes

The text in -23 was updated as follows:

       Therefore, implementations MUST NOT download schemas at runtime

Roman