Subject: Seeking co-moderator for ietf-types list
From: harald at alvestrand.no (Harald Alvestrand)
Date: Tue Jan 3 16:22:31 2006

For some reason, the ietf-types list is the list I maintain that gets the 
most spam - up to 50 messages per day.
All of it (I think) gets trapped by the subscriber-only filter.

It is also a list where some mail from non-subscribers MUST get through 
(new submissions, for instance).

The combination means that moderation needs to be efficient, and fast.
I am finding that with the conversion of this list to Mailman, it is 
reasonably efficient (2 mouse clicks per message, basically), but given 
that I am the only one moderating, it is not fast.

With Mailman and Web-based moderation, having multiple moderators without 
getting confused is easy; the Web interface does the synchronization.

If there is a volunteer willing to do the mouseclicks when needed, I think 
the IETF-types would be better served by having 2 moderators than by having 
only one.

Volunteers please email me directly.

            Harald Alvestrand, IETF-types moderator

From: [email-masked] (Harald Alvestrand)
Date: Thu, 22 Nov 2001 09:52:22 +0100
Subject: Seeking co-moderator for ietf-types list
Message-ID: <[email-masked]>

For some reason, the ietf-types list is the list I maintain that gets the 
most spam - up to 50 messages per day.
All of it (I think) gets trapped by the subscriber-only filter.

It is also a list where some mail from non-subscribers MUST get through 
(new submissions, for instance).

The combination means that moderation needs to be efficient, and fast.
I am finding that with the conversion of this list to Mailman, it is 
reasonably efficient (2 mouse clicks per message, basically), but given 
that I am the only one moderating, it is not fast.

With Mailman and Web-based moderation, having multiple moderators without 
getting confused is easy; the Web interface does the synchronization.

If there is a volunteer willing to do the mouseclicks when needed, I think 
the IETF-types would be better served by having 2 moderators than by having 
only one.

Volunteers please email me directly.

            Harald Alvestrand, IETF-types moderator

From: moore at cs.utk.edu (Keith Moore)
Date: Tue Jan  3 16:22:30 2006
Subject: Registration of MIME media type application/vnd.nokia-mrv+xml 
In-Reply-To: Your message of "Wed, 07 Nov 2001 15:58:41 +0200." <[email-masked]> 
Message-ID: <[email-masked]>

> Bottom line: If you dont know what to do with a content type then you
> should discard it.

there's no need to say that explicitly, that's a given.

the point is this - just because the recipient's implementation "knows what
to do with" a content-type does not mean that its' "doing that" is an 
acceptable risk for the recipient.  far too many vendors abuse their customers
by exposing them to risks for which the customers are generally unaware,  
unable to evaluate, and wouldn't accept if they knew what they were.

Ketih

From: Leon.Hurst at nokia.com ([email-masked])
Date: Tue Jan  3 16:22:30 2006
Subject: Registration of MIME media type application/vnd.nokia-mrv+xml Message-ID: <[email-masked]>

again, the specs don't have to be public, but the specs should exist and
be referenced.  we don't want to register types that aren't yet defined.
LH> Yes we have mature specs.

and part of the purpose of the registration is to inform implementors, and
the
public, about the risks of using the type.  so I don't really like
statements
of the form "users must determine the risks for themselves" but we don't
have
a mechanism for denying registrations in vnd.* space.
LH> I think that a comment along the lines: "the content type should be
discarded
by systems which do not know what to do with it. Knowledge about this
content type
handling can be gained from existing (but currently unpublished
specifications).
Please check http://nokia.nokia.com for the specs which will be released in
the
near future"

I wish there were some effective way to compel vendors to be responsible 
regarding the security risks to which they expose their customers.  
So far, we haven't found one.
LH> Bottom line: If you dont know what to do with a content type then you
should
discard it.

Leon.

From: moore at cs.utk.edu (Keith Moore)
Date: Tue Jan  3 16:22:30 2006
Subject: Registration of MIME media type application/vnd.nokia-mrv+xml 
In-Reply-To: Your message of "Wed, 07 Nov 2001 14:22:43 +0200." <[email-masked]> 
Message-ID: <[email-masked]>

> I hope you understand that there are many facts which determine when vendor 
> related specs get published. In addition there are occasions when the MIME 
> type needs registration prior to public distribution of the specs.

again, the specs don't have to be public, but the specs should exist and
be referenced.  we don't want to register types that aren't yet defined.

and part of the purpose of the registration is to inform implementors, and the
public, about the risks of using the type.  so I don't really like statements
of the form "users must determine the risks for themselves" but we don't have
a mechanism for denying registrations in vnd.* space.

I wish there were some effective way to compel vendors to be responsible 
regarding the security risks to which they expose their customers.  
So far, we haven't found one.

Keith

From: [email-masked] (Keith Moore)
Date: Wed, 07 Nov 2001 09:06:10 -0500
Subject: Registration of MIME media type application/vnd.nokia-mrv+xml
In-Reply-To: Your message of "Wed, 07 Nov 2001 15:58:41 +0200." <[email-masked]>
Message-ID: <[email-masked]>

> Bottom line: If you dont know what to do with a content type then you
> should discard it.

there's no need to say that explicitly, that's a given.

the point is this - just because the recipient's implementation "knows what
to do with" a content-type does not mean that its' "doing that" is an 
acceptable risk for the recipient.  far too many vendors abuse their customers
by exposing them to risks for which the customers are generally unaware,  
unable to evaluate, and wouldn't accept if they knew what they were.

Ketih

From: [email-masked] ([email-masked])
Date: Wed, 7 Nov 2001 15:58:41 +0200
Subject: Registration of MIME media type application/vnd.nokia-mrv+xml
Message-ID: <[email-masked]>

again, the specs don't have to be public, but the specs should exist and
be referenced.  we don't want to register types that aren't yet defined.
LH> Yes we have mature specs.

and part of the purpose of the registration is to inform implementors, and
the
public, about the risks of using the type.  so I don't really like
statements
of the form "users must determine the risks for themselves" but we don't
have
a mechanism for denying registrations in vnd.* space.
LH> I think that a comment along the lines: "the content type should be
discarded
by systems which do not know what to do with it. Knowledge about this
content type
handling can be gained from existing (but currently unpublished
specifications).
Please check http://nokia.nokia.com for the specs which will be released in
the
near future"

I wish there were some effective way to compel vendors to be responsible 
regarding the security risks to which they expose their customers.  
So far, we haven't found one.
LH> Bottom line: If you dont know what to do with a content type then you
should
discard it.

Leon.

From: [email-masked] (Keith Moore)
Date: Wed, 07 Nov 2001 08:44:22 -0500
Subject: Registration of MIME media type application/vnd.nokia-mrv+xml
In-Reply-To: Your message of "Wed, 07 Nov 2001 14:22:43 +0200." <[email-masked]>
Message-ID: <[email-masked]>

> I hope you understand that there are many facts which determine when vendor 
> related specs get published. In addition there are occasions when the MIME 
> type needs registration prior to public distribution of the specs.

again, the specs don't have to be public, but the specs should exist and
be referenced.  we don't want to register types that aren't yet defined.

and part of the purpose of the registration is to inform implementors, and the
public, about the risks of using the type.  so I don't really like statements
of the form "users must determine the risks for themselves" but we don't have
a mechanism for denying registrations in vnd.* space.

I wish there were some effective way to compel vendors to be responsible 
regarding the security risks to which they expose their customers.  
So far, we haven't found one.

Keith

From: Leon.Hurst at nokia.com ([email-masked])
Date: Tue Jan  3 16:22:30 2006
Subject: Registration of MIME media type application/vnd.nokia-mrv+xml Message-ID: <[email-masked]>

perhaps the registration should simply say that it is not possible to 
evaluate the risks with this content-type since no information about
the time has been disclosed; and users should therefore avoid using 
this content-type unless *they* have reliable information about the nature
and format of this content-type which enables them to evaluate the risks
associated with using it.
LH> This is a very sensible approach. I hope you understand that there are
many facts which determine when vendor related specs get published. In
addition
there are occasions when the MIME type needs registration prior to public
distribution of the specs.

Do other people have comments on Keith's suggestion.

Many thanks,
Leon.

From: [email-masked] ([email-masked])
Date: Wed, 7 Nov 2001 14:22:43 +0200
Subject: Registration of MIME media type application/vnd.nokia-mrv+xml
Message-ID: <[email-masked]>

perhaps the registration should simply say that it is not possible to 
evaluate the risks with this content-type since no information about
the time has been disclosed; and users should therefore avoid using 
this content-type unless *they* have reliable information about the nature
and format of this content-type which enables them to evaluate the risks
associated with using it.
LH> This is a very sensible approach. I hope you understand that there are
many facts which determine when vendor related specs get published. In
addition
there are occasions when the MIME type needs registration prior to public
distribution of the specs.

Do other people have comments on Keith's suggestion.

Many thanks,
Leon.

From: moore at cs.utk.edu (Keith Moore)
Date: Tue Jan  3 16:22:30 2006
Subject: Registration of MIME media type application/vnd.nokia-mrv+xml 
In-Reply-To: Your message of "Tue, 06 Nov 2001 13:19:18 +0200." <[email-masked]> 
Message-ID: <[email-masked]>

> it doesn't say anything at all about what MRV document is, nor does it
> include a reference to the specification.  as such the content type is
> ambiguous.
> LH> This is vendor specific MIME type. The spec are not ready for public
> consumption.

the spec doesn't have to be generally available, but you do need a spec.

> the security considerations section is vague.  I can't tell what is
> meant by
> 
> > Authentication: Optional part of a Digital Rights Management system in
> > which MRV is used.
> 
> but any system which incorporates DRM is likely to have considerable
> security risks - including that identity of the reader will be 
> inappropriately disclosed or leaked to other parties, or that there are
> circumstances under which a reader will be denied his legal rights to
> use the document by the DRM system (for instance, when fair use rights 
> are violated). these risks need to be analyzed and disclosed.
>
> LH> Security models surrounding DRM are complex and endless. Security is a
> spectrum of threats and (less than 100% bullet proof) counter measures.
> Additionally each security infrastructure is highly. All the above types
> refer to documents which have an orthoginal security implementation. Each
> implementor is free to implement security levels appropriate for there
> application.

this is not sufficient. it gives the user or implementor *no* idea of what 
kind of security risks he will encounter if he chooses to recognize this type.

> > Threats: The MRV MIME content type definition provides for the
> > inclusion of arbitrary content information. Administrators for MIME 
> > implementations that  support this content type SHOULD take every 
> > standard precaution to assure the activation of MRV content is NOT 
> > automatic, but is only performed after  confirmation by the recipient. 
> > In addition, administrators may want to perform virus scans of MRV 
> > content information.
> 
> this provides no information about how such threats may be ameliorated.
> furthermore, it is difficult to see how such threats could be
> ameliorated unless the specification for the encapsulation format were 
> made public.
> 
> 'confirmation by the recipient' is not sufficient to ameilorate such
> threats, because the recipient is not generally aware of the threats 
> posed by the individual contents.  
> LH> This is innacurrate. MRV and the other three types are non executable 
> content. The only risk posed is the standard risk of being a host for a 
> virus which is the same with all other document/MIME types?

your second statement doesn't follow from your first one.  there are
many other potential threats to recipients besides executable content - 
particularly for DRM systems, where privacy violations are quite common.  
and it is difficult to imagine how an implementor could write a virus 
detector/filter if he/she doesn't know how enough details of your format 
the virus is encapsulated  

> > Interoperability considerations: Implementations that have support for
> > the mandatory features of this content type will greatly increase the
> > chances of interoperating with other implementations supporting this 
> > content type. Conformance to this content type requires an implementation 
> > to support every mandatory feature.
> 
> that's a meaningless statement in this context.
> LH> It is meaningful when the specs are published.

perhaps you should wait until the specs are published before attempting
to register the content-type.  then it will be much easier to evaluate
the security risks, also.

> this application should be denied or delayed until there is a published
> specification which may be reviewed, and until the security risks are 
> adequately documented.
> LH> Do any of the answers I provide above help you? It is unlikely that the
> specifications will be published prior to MIME type registration. 

if you're not willing to provide any details of the nature of your content
type, nor of the risks that users will incur by evaluating this content-type,
I don't see what purpose is served by your registration.  

perhaps the registration should simply say that it is not possible to 
evaluate the risks with this content-type since no information about
the time has been disclosed; and users should therefore avoid using 
this content-type unless *they* have reliable information about the nature
and format of this content-type which enables them to evaluate the risks
associated with using it.

Keith

From: [email-masked] (Keith Moore)
Date: Tue, 06 Nov 2001 12:10:29 -0500
Subject: Registration of MIME media type application/vnd.nokia-mrv+xml
In-Reply-To: Your message of "Tue, 06 Nov 2001 13:19:18 +0200." <[email-masked]>
Message-ID: <[email-masked]>

> it doesn't say anything at all about what MRV document is, nor does it
> include a reference to the specification.  as such the content type is
> ambiguous.
> LH> This is vendor specific MIME type. The spec are not ready for public
> consumption.

the spec doesn't have to be generally available, but you do need a spec.

> the security considerations section is vague.  I can't tell what is
> meant by
> 
> > Authentication: Optional part of a Digital Rights Management system in
> > which MRV is used.
> 
> but any system which incorporates DRM is likely to have considerable
> security risks - including that identity of the reader will be 
> inappropriately disclosed or leaked to other parties, or that there are
> circumstances under which a reader will be denied his legal rights to
> use the document by the DRM system (for instance, when fair use rights 
> are violated). these risks need to be analyzed and disclosed.
>
> LH> Security models surrounding DRM are complex and endless. Security is a
> spectrum of threats and (less than 100% bullet proof) counter measures.
> Additionally each security infrastructure is highly. All the above types
> refer to documents which have an orthoginal security implementation. Each
> implementor is free to implement security levels appropriate for there
> application.

this is not sufficient. it gives the user or implementor *no* idea of what 
kind of security risks he will encounter if he chooses to recognize this type.

> > Threats: The MRV MIME content type definition provides for the
> > inclusion of arbitrary content information. Administrators for MIME 
> > implementations that  support this content type SHOULD take every 
> > standard precaution to assure the activation of MRV content is NOT 
> > automatic, but is only performed after  confirmation by the recipient. 
> > In addition, administrators may want to perform virus scans of MRV 
> > content information.
> 
> this provides no information about how such threats may be ameliorated.
> furthermore, it is difficult to see how such threats could be
> ameliorated unless the specification for the encapsulation format were 
> made public.
> 
> 'confirmation by the recipient' is not sufficient to ameilorate such
> threats, because the recipient is not generally aware of the threats 
> posed by the individual contents.  
> LH> This is innacurrate. MRV and the other three types are non executable 
> content. The only risk posed is the standard risk of being a host for a 
> virus which is the same with all other document/MIME types?

your second statement doesn't follow from your first one.  there are
many other potential threats to recipients besides executable content - 
particularly for DRM systems, where privacy violations are quite common.  
and it is difficult to imagine how an implementor could write a virus 
detector/filter if he/she doesn't know how enough details of your format 
the virus is encapsulated  

> > Interoperability considerations: Implementations that have support for
> > the mandatory features of this content type will greatly increase the
> > chances of interoperating with other implementations supporting this 
> > content type. Conformance to this content type requires an implementation 
> > to support every mandatory feature.
> 
> that's a meaningless statement in this context.
> LH> It is meaningful when the specs are published.

perhaps you should wait until the specs are published before attempting
to register the content-type.  then it will be much easier to evaluate
the security risks, also.

> this application should be denied or delayed until there is a published
> specification which may be reviewed, and until the security risks are 
> adequately documented.
> LH> Do any of the answers I provide above help you? It is unlikely that the
> specifications will be published prior to MIME type registration. 

if you're not willing to provide any details of the nature of your content
type, nor of the risks that users will incur by evaluating this content-type,
I don't see what purpose is served by your registration.  

perhaps the registration should simply say that it is not possible to 
evaluate the risks with this content-type since no information about
the time has been disclosed; and users should therefore avoid using 
this content-type unless *they* have reliable information about the nature
and format of this content-type which enables them to evaluate the risks
associated with using it.

Keith

From: Leon.Hurst at nokia.com ([email-masked])
Date: Tue Jan  3 16:22:30 2006
Subject: Registration of MIME media type application/vnd.nokia-mrv+xml Message-ID: <[email-masked]>

it doesn't say anything at all about what MRV document is, nor does it
include a reference to the specification.  as such the content type is
ambiguous.
LH> This is vendor specific MIME type. The spec are not ready for public
consumption.

the encoding considerations section is poorly worded.  I'm not sure what
a "a 7bit character set with an IETF character encoding mechanism" is.
it would be sufficient to say that these documents need to be encoded
in base64 for transmission over text-based email.
LH> Agreed, will change.

the security considerations section is vague.  I can't tell what is
meant
by

> Authentication: Optional part of a Digital Rights Management system in
which
> MRV is used.

but any system which incorporates DRM is likely to have considerable
security risks - including that identity of the reader will be 
inappropriately disclosed or leaked to other parties, or that there are
circumstances under which a reader will be denied his legal rights to
use the document by the DRM system (for instance, when fair use rights 
are violated). these risks need to be analyzed and disclosed.
LH> Security models surrounding DRM are complex and endless. Security is a
spectrum of threats and (less than 100% bullet proof) counter measures.
Additionally each security infrastructure is highly. All the above types
refer to documents which have an orthoginal security implementation. Each
implementor is free to implement security levels appropriate for there
application.

> Threats: The MRV MIME content type definition provides for the
inclusion of
> arbitrary content information. Administrators for MIME implementations
that
> support this content type SHOULD take every standard precaution to
assure
> the activation of MRV content is NOT automatic, but is only performed
after
> confirmation by the recipient. In addition, administrators may want to
> perform virus scans of MRV content information.

this provides no information about how such threats may be ameliorated.
furthermore, it is difficult to see how such threats could be
ameliorated
unless the specification for the encapsulation format were made public.

'confirmation by the recipient' is not sufficient to ameilorate such
threats,
because the recipient is not generally aware of the threats posed by the
individual contents.
LH> This is innacurrate. MRV and the other three types are non executable 
content. The only risk posed is the standard risk of being a host for a 
virus which is the same with all other document/MIME types?

> Interoperability considerations: Implementations that have support for
the
> mandatory features of this content type will greatly increase the
chances of
> interoperating with other implementations supporting this content
type.
> Conformance to this content type requires an implementation to support
every
> mandatory feature.

that's a meaningless statement in this context.
LH> It is meaningful when the specs are published.

this application should be denied or delayed until there is a published
specification which may be reviewed, and until the security risks are 
adequately documented.
LH> Do any of the answers I provide above help you? It is unlikely that the
specifications will be published prior to MIME type registration. Thus, we
decided to use a vendor mime type which is appropriate in this situation and
does not require any approval. However, I would like to make the
registration
as meaningful as possible now with your help, given the constraint of an
unreleased
spec.

Thank you for your comments and I look forward to hearing what you think.

Cheers,
Leon.

From: [email-masked] ([email-masked])
Date: Tue, 6 Nov 2001 13:19:18 +0200
Subject: Registration of MIME media type application/vnd.nokia-mrv+xml
Message-ID: <[email-masked]>

it doesn't say anything at all about what MRV document is, nor does it
include a reference to the specification.  as such the content type is
ambiguous.
LH> This is vendor specific MIME type. The spec are not ready for public
consumption.

the encoding considerations section is poorly worded.  I'm not sure what
a "a 7bit character set with an IETF character encoding mechanism" is.
it would be sufficient to say that these documents need to be encoded
in base64 for transmission over text-based email.
LH> Agreed, will change.

the security considerations section is vague.  I can't tell what is
meant
by

> Authentication: Optional part of a Digital Rights Management system in
which
> MRV is used.

but any system which incorporates DRM is likely to have considerable
security risks - including that identity of the reader will be 
inappropriately disclosed or leaked to other parties, or that there are
circumstances under which a reader will be denied his legal rights to
use the document by the DRM system (for instance, when fair use rights 
are violated). these risks need to be analyzed and disclosed.
LH> Security models surrounding DRM are complex and endless. Security is a
spectrum of threats and (less than 100% bullet proof) counter measures.
Additionally each security infrastructure is highly. All the above types
refer to documents which have an orthoginal security implementation. Each
implementor is free to implement security levels appropriate for there
application.

> Threats: The MRV MIME content type definition provides for the
inclusion of
> arbitrary content information. Administrators for MIME implementations
that
> support this content type SHOULD take every standard precaution to
assure
> the activation of MRV content is NOT automatic, but is only performed
after
> confirmation by the recipient. In addition, administrators may want to
> perform virus scans of MRV content information.

this provides no information about how such threats may be ameliorated.
furthermore, it is difficult to see how such threats could be
ameliorated
unless the specification for the encapsulation format were made public.

'confirmation by the recipient' is not sufficient to ameilorate such
threats,
because the recipient is not generally aware of the threats posed by the
individual contents.
LH> This is innacurrate. MRV and the other three types are non executable 
content. The only risk posed is the standard risk of being a host for a 
virus which is the same with all other document/MIME types?

> Interoperability considerations: Implementations that have support for
the
> mandatory features of this content type will greatly increase the
chances of
> interoperating with other implementations supporting this content
type.
> Conformance to this content type requires an implementation to support
every
> mandatory feature.

that's a meaningless statement in this context.
LH> It is meaningful when the specs are published.

this application should be denied or delayed until there is a published
specification which may be reviewed, and until the security risks are 
adequately documented.
LH> Do any of the answers I provide above help you? It is unlikely that the
specifications will be published prior to MIME type registration. Thus, we
decided to use a vendor mime type which is appropriate in this situation and
does not require any approval. However, I would like to make the
registration
as meaningful as possible now with your help, given the constraint of an
unreleased
spec.

Thank you for your comments and I look forward to hearing what you think.

Cheers,
Leon.

From: standards at surety.com (Greg Thompson)
Date: Tue Jan  3 16:22:30 2006
Subject: Registration of MIME media type application/vnd.surety.tokenstore 
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
>
> > Security considerations: Surety Token Store files contain no executable
> > code.
>
> that's good to know, but it doesn't really say anything about
> security risks.
> is there any inherent risk to running software that uses such things?
> for instance, does such software disclose information about the recipient
> or the recipient's files, does it communicate with other network
> sites without
> the recipient's knowledge, does it alter recipient files, etc?
>
> especially given that you've said nothing at all about the
> purpose of this type,
> it's very hard to assess risk from the information provided.
>
> Keith

fair enough.

MIME media type name: application

MIME subtype name: Vendor Tree - vnd.surety.tokenstore

Required parameters: none

Optional parameters: none

Encoding considerations: Surety Token Store files contain binary data, and
must be transferred in such a way as to guarantee that no loss of
information takes place.

Security considerations: Surety Token Store files contain "Tokens" used by
the Surety Digital Notary Service.  These Tokens are used in the course of
conducting transactions with Surety Digital Notary Servers.  No personal
data is stored in a Token, and no part of a Token contains any executable
code.  Certain operations performed with Tokens within the context of an
application developed to use these Tokens may contact servers over the
Internet.  These communications do not transmit any information about the
user or the user's machine to the remote server, and only take place as a
direct result of the user's actions.

Interoperability considerations: The Surety Token Store file format is
designed such that compliant files may be parsed and generated on any
platform, independent of machine byte-ordering and word size.  As such, they
may be used with any supported product in the Surety Digital Notary Service
on any supported platform.

Published specification: none

Applications which use this media type: Surety Digital Notary Service

Additional information:

  Magic number(s): none
  File extension(s): .sts
  Macintosh File Type Code(s): none

Person & email address to contact for further information:
[email-masked]

Intended usage: common

Author/Change controller:
Written by Greg Thompson.  This type may be revised by any employee of
Surety, Inc.

From: moore at cs.utk.edu (Keith Moore)
Date: Tue Jan  3 16:22:30 2006
Subject: Registration of MIME media type application/vnd.surety.tokenstore 
In-Reply-To: Your message of "Wed, 31 Oct 2001 11:40:55 EST." <[email-masked]> 
Message-ID: <[email-masked]>

> Security considerations: Surety Token Store files contain no executable
> code.

that's good to know, but it doesn't really say anything about security risks.
is there any inherent risk to running software that uses such things?
for instance, does such software disclose information about the recipient
or the recipient's files, does it communicate with other network sites without
the recipient's knowledge, does it alter recipient files, etc?

especially given that you've said nothing at all about the purpose of this type,
it's very hard to assess risk from the information provided.

Keith

From: [email-masked] (Greg Thompson)
Date: Thu, 1 Nov 2001 10:12:37 -0500
Subject: Registration of MIME media type application/vnd.surety.tokenstore
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
>
> > Security considerations: Surety Token Store files contain no executable
> > code.
>
> that's good to know, but it doesn't really say anything about
> security risks.
> is there any inherent risk to running software that uses such things?
> for instance, does such software disclose information about the recipient
> or the recipient's files, does it communicate with other network
> sites without
> the recipient's knowledge, does it alter recipient files, etc?
>
> especially given that you've said nothing at all about the
> purpose of this type,
> it's very hard to assess risk from the information provided.
>
> Keith

fair enough.

MIME media type name: application

MIME subtype name: Vendor Tree - vnd.surety.tokenstore

Required parameters: none

Optional parameters: none

Encoding considerations: Surety Token Store files contain binary data, and
must be transferred in such a way as to guarantee that no loss of
information takes place.

Security considerations: Surety Token Store files contain "Tokens" used by
the Surety Digital Notary Service.  These Tokens are used in the course of
conducting transactions with Surety Digital Notary Servers.  No personal
data is stored in a Token, and no part of a Token contains any executable
code.  Certain operations performed with Tokens within the context of an
application developed to use these Tokens may contact servers over the
Internet.  These communications do not transmit any information about the
user or the user's machine to the remote server, and only take place as a
direct result of the user's actions.

Interoperability considerations: The Surety Token Store file format is
designed such that compliant files may be parsed and generated on any
platform, independent of machine byte-ordering and word size.  As such, they
may be used with any supported product in the Surety Digital Notary Service
on any supported platform.

Published specification: none

Applications which use this media type: Surety Digital Notary Service

Additional information:

  Magic number(s): none
  File extension(s): .sts
  Macintosh File Type Code(s): none

Person & email address to contact for further information:
[email-masked]

Intended usage: common

Author/Change controller:
Written by Greg Thompson.  This type may be revised by any employee of
Surety, Inc.

From: [email-masked] (Keith Moore)
Date: Thu, 01 Nov 2001 09:56:33 -0500
Subject: Registration of MIME media type application/vnd.surety.tokenstore
In-Reply-To: Your message of "Wed, 31 Oct 2001 11:40:55 EST." <[email-masked]>
Message-ID: <[email-masked]>

> Security considerations: Surety Token Store files contain no executable
> code.

that's good to know, but it doesn't really say anything about security risks.
is there any inherent risk to running software that uses such things?
for instance, does such software disclose information about the recipient
or the recipient's files, does it communicate with other network sites without
the recipient's knowledge, does it alter recipient files, etc?

especially given that you've said nothing at all about the purpose of this type,
it's very hard to assess risk from the information provided.

Keith

From: [email-masked] (Harald Alvestrand)
Date: Thu, 22 Nov 2001 09:52:22 +0100
Subject: Seeking co-moderator for ietf-types list
Message-ID: <[email-masked]>

For some reason, the ietf-types list is the list I maintain that gets the 
most spam - up to 50 messages per day.
All of it (I think) gets trapped by the subscriber-only filter.

It is also a list where some mail from non-subscribers MUST get through 
(new submissions, for instance).

The combination means that moderation needs to be efficient, and fast.
I am finding that with the conversion of this list to Mailman, it is 
reasonably efficient (2 mouse clicks per message, basically), but given 
that I am the only one moderating, it is not fast.

With Mailman and Web-based moderation, having multiple moderators without 
getting confused is easy; the Web interface does the synchronization.

If there is a volunteer willing to do the mouseclicks when needed, I think 
the IETF-types would be better served by having 2 moderators than by having 
only one.

Volunteers please email me directly.

            Harald Alvestrand, IETF-types moderator

From: [email-masked] (Keith Moore)
Date: Wed, 07 Nov 2001 09:06:10 -0500
Subject: Registration of MIME media type application/vnd.nokia-mrv+xml
In-Reply-To: Your message of "Wed, 07 Nov 2001 15:58:41 +0200." <[email-masked]>
Message-ID: <[email-masked]>

> Bottom line: If you dont know what to do with a content type then you
> should discard it.

there's no need to say that explicitly, that's a given.

the point is this - just because the recipient's implementation "knows what
to do with" a content-type does not mean that its' "doing that" is an 
acceptable risk for the recipient.  far too many vendors abuse their customers
by exposing them to risks for which the customers are generally unaware,  
unable to evaluate, and wouldn't accept if they knew what they were.

Ketih

From: [email-masked] ([email-masked])
Date: Wed, 7 Nov 2001 15:58:41 +0200
Subject: Registration of MIME media type application/vnd.nokia-mrv+xml
Message-ID: <[email-masked]>

again, the specs don't have to be public, but the specs should exist and
be referenced.  we don't want to register types that aren't yet defined.
LH> Yes we have mature specs.

and part of the purpose of the registration is to inform implementors, and
the
public, about the risks of using the type.  so I don't really like
statements
of the form "users must determine the risks for themselves" but we don't
have
a mechanism for denying registrations in vnd.* space.
LH> I think that a comment along the lines: "the content type should be
discarded
by systems which do not know what to do with it. Knowledge about this
content type
handling can be gained from existing (but currently unpublished
specifications).
Please check http://nokia.nokia.com for the specs which will be released in
the
near future"

I wish there were some effective way to compel vendors to be responsible 
regarding the security risks to which they expose their customers.  
So far, we haven't found one.
LH> Bottom line: If you dont know what to do with a content type then you
should
discard it.

Leon.

From: [email-masked] (Keith Moore)
Date: Wed, 07 Nov 2001 08:44:22 -0500
Subject: Registration of MIME media type application/vnd.nokia-mrv+xml
In-Reply-To: Your message of "Wed, 07 Nov 2001 14:22:43 +0200." <[email-masked]>
Message-ID: <[email-masked]>

> I hope you understand that there are many facts which determine when vendor 
> related specs get published. In addition there are occasions when the MIME 
> type needs registration prior to public distribution of the specs.

again, the specs don't have to be public, but the specs should exist and
be referenced.  we don't want to register types that aren't yet defined.

and part of the purpose of the registration is to inform implementors, and the
public, about the risks of using the type.  so I don't really like statements
of the form "users must determine the risks for themselves" but we don't have
a mechanism for denying registrations in vnd.* space.

I wish there were some effective way to compel vendors to be responsible 
regarding the security risks to which they expose their customers.  
So far, we haven't found one.

Keith

From: [email-masked] ([email-masked])
Date: Wed, 7 Nov 2001 14:22:43 +0200
Subject: Registration of MIME media type application/vnd.nokia-mrv+xml
Message-ID: <[email-masked]>

perhaps the registration should simply say that it is not possible to 
evaluate the risks with this content-type since no information about
the time has been disclosed; and users should therefore avoid using 
this content-type unless *they* have reliable information about the nature
and format of this content-type which enables them to evaluate the risks
associated with using it.
LH> This is a very sensible approach. I hope you understand that there are
many facts which determine when vendor related specs get published. In
addition
there are occasions when the MIME type needs registration prior to public
distribution of the specs.

Do other people have comments on Keith's suggestion.

Many thanks,
Leon.

From: [email-masked] (Keith Moore)
Date: Tue, 06 Nov 2001 12:10:29 -0500
Subject: Registration of MIME media type application/vnd.nokia-mrv+xml
In-Reply-To: Your message of "Tue, 06 Nov 2001 13:19:18 +0200." <[email-masked]>
Message-ID: <[email-masked]>

> it doesn't say anything at all about what MRV document is, nor does it
> include a reference to the specification.  as such the content type is
> ambiguous.
> LH> This is vendor specific MIME type. The spec are not ready for public
> consumption.

the spec doesn't have to be generally available, but you do need a spec.

> the security considerations section is vague.  I can't tell what is
> meant by
> 
> > Authentication: Optional part of a Digital Rights Management system in
> > which MRV is used.
> 
> but any system which incorporates DRM is likely to have considerable
> security risks - including that identity of the reader will be 
> inappropriately disclosed or leaked to other parties, or that there are
> circumstances under which a reader will be denied his legal rights to
> use the document by the DRM system (for instance, when fair use rights 
> are violated). these risks need to be analyzed and disclosed.
>
> LH> Security models surrounding DRM are complex and endless. Security is a
> spectrum of threats and (less than 100% bullet proof) counter measures.
> Additionally each security infrastructure is highly. All the above types
> refer to documents which have an orthoginal security implementation. Each
> implementor is free to implement security levels appropriate for there
> application.

this is not sufficient. it gives the user or implementor *no* idea of what 
kind of security risks he will encounter if he chooses to recognize this type.

> > Threats: The MRV MIME content type definition provides for the
> > inclusion of arbitrary content information. Administrators for MIME 
> > implementations that  support this content type SHOULD take every 
> > standard precaution to assure the activation of MRV content is NOT 
> > automatic, but is only performed after  confirmation by the recipient. 
> > In addition, administrators may want to perform virus scans of MRV 
> > content information.
> 
> this provides no information about how such threats may be ameliorated.
> furthermore, it is difficult to see how such threats could be
> ameliorated unless the specification for the encapsulation format were 
> made public.
> 
> 'confirmation by the recipient' is not sufficient to ameilorate such
> threats, because the recipient is not generally aware of the threats 
> posed by the individual contents.  
> LH> This is innacurrate. MRV and the other three types are non executable 
> content. The only risk posed is the standard risk of being a host for a 
> virus which is the same with all other document/MIME types?

your second statement doesn't follow from your first one.  there are
many other potential threats to recipients besides executable content - 
particularly for DRM systems, where privacy violations are quite common.  
and it is difficult to imagine how an implementor could write a virus 
detector/filter if he/she doesn't know how enough details of your format 
the virus is encapsulated  

> > Interoperability considerations: Implementations that have support for
> > the mandatory features of this content type will greatly increase the
> > chances of interoperating with other implementations supporting this 
> > content type. Conformance to this content type requires an implementation 
> > to support every mandatory feature.
> 
> that's a meaningless statement in this context.
> LH> It is meaningful when the specs are published.

perhaps you should wait until the specs are published before attempting
to register the content-type.  then it will be much easier to evaluate
the security risks, also.

> this application should be denied or delayed until there is a published
> specification which may be reviewed, and until the security risks are 
> adequately documented.
> LH> Do any of the answers I provide above help you? It is unlikely that the
> specifications will be published prior to MIME type registration. 

if you're not willing to provide any details of the nature of your content
type, nor of the risks that users will incur by evaluating this content-type,
I don't see what purpose is served by your registration.  

perhaps the registration should simply say that it is not possible to 
evaluate the risks with this content-type since no information about
the time has been disclosed; and users should therefore avoid using 
this content-type unless *they* have reliable information about the nature
and format of this content-type which enables them to evaluate the risks
associated with using it.

Keith

From: [email-masked] ([email-masked])
Date: Tue, 6 Nov 2001 13:19:18 +0200
Subject: Registration of MIME media type application/vnd.nokia-mrv+xml
Message-ID: <[email-masked]>

it doesn't say anything at all about what MRV document is, nor does it
include a reference to the specification.  as such the content type is
ambiguous.
LH> This is vendor specific MIME type. The spec are not ready for public
consumption.

the encoding considerations section is poorly worded.  I'm not sure what
a "a 7bit character set with an IETF character encoding mechanism" is.
it would be sufficient to say that these documents need to be encoded
in base64 for transmission over text-based email.
LH> Agreed, will change.

the security considerations section is vague.  I can't tell what is
meant
by

> Authentication: Optional part of a Digital Rights Management system in
which
> MRV is used.

but any system which incorporates DRM is likely to have considerable
security risks - including that identity of the reader will be 
inappropriately disclosed or leaked to other parties, or that there are
circumstances under which a reader will be denied his legal rights to
use the document by the DRM system (for instance, when fair use rights 
are violated). these risks need to be analyzed and disclosed.
LH> Security models surrounding DRM are complex and endless. Security is a
spectrum of threats and (less than 100% bullet proof) counter measures.
Additionally each security infrastructure is highly. All the above types
refer to documents which have an orthoginal security implementation. Each
implementor is free to implement security levels appropriate for there
application.

> Threats: The MRV MIME content type definition provides for the
inclusion of
> arbitrary content information. Administrators for MIME implementations
that
> support this content type SHOULD take every standard precaution to
assure
> the activation of MRV content is NOT automatic, but is only performed
after
> confirmation by the recipient. In addition, administrators may want to
> perform virus scans of MRV content information.

this provides no information about how such threats may be ameliorated.
furthermore, it is difficult to see how such threats could be
ameliorated
unless the specification for the encapsulation format were made public.

'confirmation by the recipient' is not sufficient to ameilorate such
threats,
because the recipient is not generally aware of the threats posed by the
individual contents.
LH> This is innacurrate. MRV and the other three types are non executable 
content. The only risk posed is the standard risk of being a host for a 
virus which is the same with all other document/MIME types?

> Interoperability considerations: Implementations that have support for
the
> mandatory features of this content type will greatly increase the
chances of
> interoperating with other implementations supporting this content
type.
> Conformance to this content type requires an implementation to support
every
> mandatory feature.

that's a meaningless statement in this context.
LH> It is meaningful when the specs are published.

this application should be denied or delayed until there is a published
specification which may be reviewed, and until the security risks are 
adequately documented.
LH> Do any of the answers I provide above help you? It is unlikely that the
specifications will be published prior to MIME type registration. Thus, we
decided to use a vendor mime type which is appropriate in this situation and
does not require any approval. However, I would like to make the
registration
as meaningful as possible now with your help, given the constraint of an
unreleased
spec.

Thank you for your comments and I look forward to hearing what you think.

Cheers,
Leon.

From: [email-masked] (Greg Thompson)
Date: Thu, 1 Nov 2001 10:12:37 -0500
Subject: Registration of MIME media type application/vnd.surety.tokenstore
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
>
> > Security considerations: Surety Token Store files contain no executable
> > code.
>
> that's good to know, but it doesn't really say anything about
> security risks.
> is there any inherent risk to running software that uses such things?
> for instance, does such software disclose information about the recipient
> or the recipient's files, does it communicate with other network
> sites without
> the recipient's knowledge, does it alter recipient files, etc?
>
> especially given that you've said nothing at all about the
> purpose of this type,
> it's very hard to assess risk from the information provided.
>
> Keith

fair enough.

MIME media type name: application

MIME subtype name: Vendor Tree - vnd.surety.tokenstore

Required parameters: none

Optional parameters: none

Encoding considerations: Surety Token Store files contain binary data, and
must be transferred in such a way as to guarantee that no loss of
information takes place.

Security considerations: Surety Token Store files contain "Tokens" used by
the Surety Digital Notary Service.  These Tokens are used in the course of
conducting transactions with Surety Digital Notary Servers.  No personal
data is stored in a Token, and no part of a Token contains any executable
code.  Certain operations performed with Tokens within the context of an
application developed to use these Tokens may contact servers over the
Internet.  These communications do not transmit any information about the
user or the user's machine to the remote server, and only take place as a
direct result of the user's actions.

Interoperability considerations: The Surety Token Store file format is
designed such that compliant files may be parsed and generated on any
platform, independent of machine byte-ordering and word size.  As such, they
may be used with any supported product in the Surety Digital Notary Service
on any supported platform.

Published specification: none

Applications which use this media type: Surety Digital Notary Service

Additional information:

  Magic number(s): none
  File extension(s): .sts
  Macintosh File Type Code(s): none

Person & email address to contact for further information:
[email-masked]

Intended usage: common

Author/Change controller:
Written by Greg Thompson.  This type may be revised by any employee of
Surety, Inc.

From: [email-masked] (Keith Moore)
Date: Thu, 01 Nov 2001 09:56:33 -0500
Subject: Registration of MIME media type application/vnd.surety.tokenstore
In-Reply-To: Your message of "Wed, 31 Oct 2001 11:40:55 EST." <[email-masked]>
Message-ID: <[email-masked]>

> Security considerations: Surety Token Store files contain no executable
> code.

that's good to know, but it doesn't really say anything about security risks.
is there any inherent risk to running software that uses such things?
for instance, does such software disclose information about the recipient
or the recipient's files, does it communicate with other network sites without
the recipient's knowledge, does it alter recipient files, etc?

especially given that you've said nothing at all about the purpose of this type,
it's very hard to assess risk from the information provided.

Keith

From: harald at alvestrand.no (Harald Alvestrand)
Date: Tue Jan  3 16:22:31 2006
Subject: Seeking co-moderator for ietf-types list
Message-ID: <[email-masked]>

For some reason, the ietf-types list is the list I maintain that gets the 
most spam - up to 50 messages per day.
All of it (I think) gets trapped by the subscriber-only filter.

It is also a list where some mail from non-subscribers MUST get through 
(new submissions, for instance).

The combination means that moderation needs to be efficient, and fast.
I am finding that with the conversion of this list to Mailman, it is 
reasonably efficient (2 mouse clicks per message, basically), but given 
that I am the only one moderating, it is not fast.

With Mailman and Web-based moderation, having multiple moderators without 
getting confused is easy; the Web interface does the synchronization.

If there is a volunteer willing to do the mouseclicks when needed, I think 
the IETF-types would be better served by having 2 moderators than by having 
only one.

Volunteers please email me directly.

            Harald Alvestrand, IETF-types moderator

From: [email-masked] (Harald Alvestrand)
Date: Thu, 22 Nov 2001 09:52:22 +0100
Subject: Seeking co-moderator for ietf-types list
Message-ID: <[email-masked]>

For some reason, the ietf-types list is the list I maintain that gets the 
most spam - up to 50 messages per day.
All of it (I think) gets trapped by the subscriber-only filter.

It is also a list where some mail from non-subscribers MUST get through 
(new submissions, for instance).

The combination means that moderation needs to be efficient, and fast.
I am finding that with the conversion of this list to Mailman, it is 
reasonably efficient (2 mouse clicks per message, basically), but given 
that I am the only one moderating, it is not fast.

With Mailman and Web-based moderation, having multiple moderators without 
getting confused is easy; the Web interface does the synchronization.

If there is a volunteer willing to do the mouseclicks when needed, I think 
the IETF-types would be better served by having 2 moderators than by having 
only one.

Volunteers please email me directly.

            Harald Alvestrand, IETF-types moderator

From: moore at cs.utk.edu (Keith Moore)
Date: Tue Jan  3 16:22:30 2006
Subject: Registration of MIME media type application/vnd.nokia-mrv+xml 
In-Reply-To: Your message of "Wed, 07 Nov 2001 15:58:41 +0200." <[email-masked]> 
Message-ID: <[email-masked]>

> Bottom line: If you dont know what to do with a content type then you
> should discard it.

there's no need to say that explicitly, that's a given.

the point is this - just because the recipient's implementation "knows what
to do with" a content-type does not mean that its' "doing that" is an 
acceptable risk for the recipient.  far too many vendors abuse their customers
by exposing them to risks for which the customers are generally unaware,  
unable to evaluate, and wouldn't accept if they knew what they were.

Ketih

From: Leon.Hurst at nokia.com ([email-masked])
Date: Tue Jan  3 16:22:30 2006
Subject: Registration of MIME media type application/vnd.nokia-mrv+xml Message-ID: <[email-masked]>

again, the specs don't have to be public, but the specs should exist and
be referenced.  we don't want to register types that aren't yet defined.
LH> Yes we have mature specs.

and part of the purpose of the registration is to inform implementors, and
the
public, about the risks of using the type.  so I don't really like
statements
of the form "users must determine the risks for themselves" but we don't
have
a mechanism for denying registrations in vnd.* space.
LH> I think that a comment along the lines: "the content type should be
discarded
by systems which do not know what to do with it. Knowledge about this
content type
handling can be gained from existing (but currently unpublished
specifications).
Please check http://nokia.nokia.com for the specs which will be released in
the
near future"

I wish there were some effective way to compel vendors to be responsible 
regarding the security risks to which they expose their customers.  
So far, we haven't found one.
LH> Bottom line: If you dont know what to do with a content type then you
should
discard it.

Leon.

From: moore at cs.utk.edu (Keith Moore)
Date: Tue Jan  3 16:22:30 2006
Subject: Registration of MIME media type application/vnd.nokia-mrv+xml 
In-Reply-To: Your message of "Wed, 07 Nov 2001 14:22:43 +0200." <[email-masked]> 
Message-ID: <[email-masked]>

> I hope you understand that there are many facts which determine when vendor 
> related specs get published. In addition there are occasions when the MIME 
> type needs registration prior to public distribution of the specs.

again, the specs don't have to be public, but the specs should exist and
be referenced.  we don't want to register types that aren't yet defined.

and part of the purpose of the registration is to inform implementors, and the
public, about the risks of using the type.  so I don't really like statements
of the form "users must determine the risks for themselves" but we don't have
a mechanism for denying registrations in vnd.* space.

I wish there were some effective way to compel vendors to be responsible 
regarding the security risks to which they expose their customers.  
So far, we haven't found one.

Keith

From: [email-masked] (Keith Moore)
Date: Wed, 07 Nov 2001 09:06:10 -0500
Subject: Registration of MIME media type application/vnd.nokia-mrv+xml
In-Reply-To: Your message of "Wed, 07 Nov 2001 15:58:41 +0200." <[email-masked]>
Message-ID: <[email-masked]>

> Bottom line: If you dont know what to do with a content type then you
> should discard it.

there's no need to say that explicitly, that's a given.

the point is this - just because the recipient's implementation "knows what
to do with" a content-type does not mean that its' "doing that" is an 
acceptable risk for the recipient.  far too many vendors abuse their customers
by exposing them to risks for which the customers are generally unaware,  
unable to evaluate, and wouldn't accept if they knew what they were.

Ketih

From: [email-masked] ([email-masked])
Date: Wed, 7 Nov 2001 15:58:41 +0200
Subject: Registration of MIME media type application/vnd.nokia-mrv+xml
Message-ID: <[email-masked]>

again, the specs don't have to be public, but the specs should exist and
be referenced.  we don't want to register types that aren't yet defined.
LH> Yes we have mature specs.

and part of the purpose of the registration is to inform implementors, and
the
public, about the risks of using the type.  so I don't really like
statements
of the form "users must determine the risks for themselves" but we don't
have
a mechanism for denying registrations in vnd.* space.
LH> I think that a comment along the lines: "the content type should be
discarded
by systems which do not know what to do with it. Knowledge about this
content type
handling can be gained from existing (but currently unpublished
specifications).
Please check http://nokia.nokia.com for the specs which will be released in
the
near future"

I wish there were some effective way to compel vendors to be responsible 
regarding the security risks to which they expose their customers.  
So far, we haven't found one.
LH> Bottom line: If you dont know what to do with a content type then you
should
discard it.

Leon.

From: [email-masked] (Keith Moore)
Date: Wed, 07 Nov 2001 08:44:22 -0500
Subject: Registration of MIME media type application/vnd.nokia-mrv+xml
In-Reply-To: Your message of "Wed, 07 Nov 2001 14:22:43 +0200." <[email-masked]>
Message-ID: <[email-masked]>

> I hope you understand that there are many facts which determine when vendor 
> related specs get published. In addition there are occasions when the MIME 
> type needs registration prior to public distribution of the specs.

again, the specs don't have to be public, but the specs should exist and
be referenced.  we don't want to register types that aren't yet defined.

and part of the purpose of the registration is to inform implementors, and the
public, about the risks of using the type.  so I don't really like statements
of the form "users must determine the risks for themselves" but we don't have
a mechanism for denying registrations in vnd.* space.

I wish there were some effective way to compel vendors to be responsible 
regarding the security risks to which they expose their customers.  
So far, we haven't found one.

Keith

From: Leon.Hurst at nokia.com ([email-masked])
Date: Tue Jan  3 16:22:30 2006
Subject: Registration of MIME media type application/vnd.nokia-mrv+xml Message-ID: <[email-masked]>

perhaps the registration should simply say that it is not possible to 
evaluate the risks with this content-type since no information about
the time has been disclosed; and users should therefore avoid using 
this content-type unless *they* have reliable information about the nature
and format of this content-type which enables them to evaluate the risks
associated with using it.
LH> This is a very sensible approach. I hope you understand that there are
many facts which determine when vendor related specs get published. In
addition
there are occasions when the MIME type needs registration prior to public
distribution of the specs.

Do other people have comments on Keith's suggestion.

Many thanks,
Leon.

From: [email-masked] ([email-masked])
Date: Wed, 7 Nov 2001 14:22:43 +0200
Subject: Registration of MIME media type application/vnd.nokia-mrv+xml
Message-ID: <[email-masked]>

perhaps the registration should simply say that it is not possible to 
evaluate the risks with this content-type since no information about
the time has been disclosed; and users should therefore avoid using 
this content-type unless *they* have reliable information about the nature
and format of this content-type which enables them to evaluate the risks
associated with using it.
LH> This is a very sensible approach. I hope you understand that there are
many facts which determine when vendor related specs get published. In
addition
there are occasions when the MIME type needs registration prior to public
distribution of the specs.

Do other people have comments on Keith's suggestion.

Many thanks,
Leon.

From: moore at cs.utk.edu (Keith Moore)
Date: Tue Jan  3 16:22:30 2006
Subject: Registration of MIME media type application/vnd.nokia-mrv+xml 
In-Reply-To: Your message of "Tue, 06 Nov 2001 13:19:18 +0200." <[email-masked]> 
Message-ID: <[email-masked]>

> it doesn't say anything at all about what MRV document is, nor does it
> include a reference to the specification.  as such the content type is
> ambiguous.
> LH> This is vendor specific MIME type. The spec are not ready for public
> consumption.

the spec doesn't have to be generally available, but you do need a spec.

> the security considerations section is vague.  I can't tell what is
> meant by
> 
> > Authentication: Optional part of a Digital Rights Management system in
> > which MRV is used.
> 
> but any system which incorporates DRM is likely to have considerable
> security risks - including that identity of the reader will be 
> inappropriately disclosed or leaked to other parties, or that there are
> circumstances under which a reader will be denied his legal rights to
> use the document by the DRM system (for instance, when fair use rights 
> are violated). these risks need to be analyzed and disclosed.
>
> LH> Security models surrounding DRM are complex and endless. Security is a
> spectrum of threats and (less than 100% bullet proof) counter measures.
> Additionally each security infrastructure is highly. All the above types
> refer to documents which have an orthoginal security implementation. Each
> implementor is free to implement security levels appropriate for there
> application.

this is not sufficient. it gives the user or implementor *no* idea of what 
kind of security risks he will encounter if he chooses to recognize this type.

> > Threats: The MRV MIME content type definition provides for the
> > inclusion of arbitrary content information. Administrators for MIME 
> > implementations that  support this content type SHOULD take every 
> > standard precaution to assure the activation of MRV content is NOT 
> > automatic, but is only performed after  confirmation by the recipient. 
> > In addition, administrators may want to perform virus scans of MRV 
> > content information.
> 
> this provides no information about how such threats may be ameliorated.
> furthermore, it is difficult to see how such threats could be
> ameliorated unless the specification for the encapsulation format were 
> made public.
> 
> 'confirmation by the recipient' is not sufficient to ameilorate such
> threats, because the recipient is not generally aware of the threats 
> posed by the individual contents.  
> LH> This is innacurrate. MRV and the other three types are non executable 
> content. The only risk posed is the standard risk of being a host for a 
> virus which is the same with all other document/MIME types?

your second statement doesn't follow from your first one.  there are
many other potential threats to recipients besides executable content - 
particularly for DRM systems, where privacy violations are quite common.  
and it is difficult to imagine how an implementor could write a virus 
detector/filter if he/she doesn't know how enough details of your format 
the virus is encapsulated  

> > Interoperability considerations: Implementations that have support for
> > the mandatory features of this content type will greatly increase the
> > chances of interoperating with other implementations supporting this 
> > content type. Conformance to this content type requires an implementation 
> > to support every mandatory feature.
> 
> that's a meaningless statement in this context.
> LH> It is meaningful when the specs are published.

perhaps you should wait until the specs are published before attempting
to register the content-type.  then it will be much easier to evaluate
the security risks, also.

> this application should be denied or delayed until there is a published
> specification which may be reviewed, and until the security risks are 
> adequately documented.
> LH> Do any of the answers I provide above help you? It is unlikely that the
> specifications will be published prior to MIME type registration. 

if you're not willing to provide any details of the nature of your content
type, nor of the risks that users will incur by evaluating this content-type,
I don't see what purpose is served by your registration.  

perhaps the registration should simply say that it is not possible to 
evaluate the risks with this content-type since no information about
the time has been disclosed; and users should therefore avoid using 
this content-type unless *they* have reliable information about the nature
and format of this content-type which enables them to evaluate the risks
associated with using it.

Keith

From: [email-masked] (Keith Moore)
Date: Tue, 06 Nov 2001 12:10:29 -0500
Subject: Registration of MIME media type application/vnd.nokia-mrv+xml
In-Reply-To: Your message of "Tue, 06 Nov 2001 13:19:18 +0200." <[email-masked]>
Message-ID: <[email-masked]>

> it doesn't say anything at all about what MRV document is, nor does it
> include a reference to the specification.  as such the content type is
> ambiguous.
> LH> This is vendor specific MIME type. The spec are not ready for public
> consumption.

the spec doesn't have to be generally available, but you do need a spec.

> the security considerations section is vague.  I can't tell what is
> meant by
> 
> > Authentication: Optional part of a Digital Rights Management system in
> > which MRV is used.
> 
> but any system which incorporates DRM is likely to have considerable
> security risks - including that identity of the reader will be 
> inappropriately disclosed or leaked to other parties, or that there are
> circumstances under which a reader will be denied his legal rights to
> use the document by the DRM system (for instance, when fair use rights 
> are violated). these risks need to be analyzed and disclosed.
>
> LH> Security models surrounding DRM are complex and endless. Security is a
> spectrum of threats and (less than 100% bullet proof) counter measures.
> Additionally each security infrastructure is highly. All the above types
> refer to documents which have an orthoginal security implementation. Each
> implementor is free to implement security levels appropriate for there
> application.

this is not sufficient. it gives the user or implementor *no* idea of what 
kind of security risks he will encounter if he chooses to recognize this type.

> > Threats: The MRV MIME content type definition provides for the
> > inclusion of arbitrary content information. Administrators for MIME 
> > implementations that  support this content type SHOULD take every 
> > standard precaution to assure the activation of MRV content is NOT 
> > automatic, but is only performed after  confirmation by the recipient. 
> > In addition, administrators may want to perform virus scans of MRV 
> > content information.
> 
> this provides no information about how such threats may be ameliorated.
> furthermore, it is difficult to see how such threats could be
> ameliorated unless the specification for the encapsulation format were 
> made public.
> 
> 'confirmation by the recipient' is not sufficient to ameilorate such
> threats, because the recipient is not generally aware of the threats 
> posed by the individual contents.  
> LH> This is innacurrate. MRV and the other three types are non executable 
> content. The only risk posed is the standard risk of being a host for a 
> virus which is the same with all other document/MIME types?

your second statement doesn't follow from your first one.  there are
many other potential threats to recipients besides executable content - 
particularly for DRM systems, where privacy violations are quite common.  
and it is difficult to imagine how an implementor could write a virus 
detector/filter if he/she doesn't know how enough details of your format 
the virus is encapsulated  

> > Interoperability considerations: Implementations that have support for
> > the mandatory features of this content type will greatly increase the
> > chances of interoperating with other implementations supporting this 
> > content type. Conformance to this content type requires an implementation 
> > to support every mandatory feature.
> 
> that's a meaningless statement in this context.
> LH> It is meaningful when the specs are published.

perhaps you should wait until the specs are published before attempting
to register the content-type.  then it will be much easier to evaluate
the security risks, also.

> this application should be denied or delayed until there is a published
> specification which may be reviewed, and until the security risks are 
> adequately documented.
> LH> Do any of the answers I provide above help you? It is unlikely that the
> specifications will be published prior to MIME type registration. 

if you're not willing to provide any details of the nature of your content
type, nor of the risks that users will incur by evaluating this content-type,
I don't see what purpose is served by your registration.  

perhaps the registration should simply say that it is not possible to 
evaluate the risks with this content-type since no information about
the time has been disclosed; and users should therefore avoid using 
this content-type unless *they* have reliable information about the nature
and format of this content-type which enables them to evaluate the risks
associated with using it.

Keith

From: Leon.Hurst at nokia.com ([email-masked])
Date: Tue Jan  3 16:22:30 2006
Subject: Registration of MIME media type application/vnd.nokia-mrv+xml Message-ID: <[email-masked]>

it doesn't say anything at all about what MRV document is, nor does it
include a reference to the specification.  as such the content type is
ambiguous.
LH> This is vendor specific MIME type. The spec are not ready for public
consumption.

the encoding considerations section is poorly worded.  I'm not sure what
a "a 7bit character set with an IETF character encoding mechanism" is.
it would be sufficient to say that these documents need to be encoded
in base64 for transmission over text-based email.
LH> Agreed, will change.

the security considerations section is vague.  I can't tell what is
meant
by

> Authentication: Optional part of a Digital Rights Management system in
which
> MRV is used.

but any system which incorporates DRM is likely to have considerable
security risks - including that identity of the reader will be 
inappropriately disclosed or leaked to other parties, or that there are
circumstances under which a reader will be denied his legal rights to
use the document by the DRM system (for instance, when fair use rights 
are violated). these risks need to be analyzed and disclosed.
LH> Security models surrounding DRM are complex and endless. Security is a
spectrum of threats and (less than 100% bullet proof) counter measures.
Additionally each security infrastructure is highly. All the above types
refer to documents which have an orthoginal security implementation. Each
implementor is free to implement security levels appropriate for there
application.

> Threats: The MRV MIME content type definition provides for the
inclusion of
> arbitrary content information. Administrators for MIME implementations
that
> support this content type SHOULD take every standard precaution to
assure
> the activation of MRV content is NOT automatic, but is only performed
after
> confirmation by the recipient. In addition, administrators may want to
> perform virus scans of MRV content information.

this provides no information about how such threats may be ameliorated.
furthermore, it is difficult to see how such threats could be
ameliorated
unless the specification for the encapsulation format were made public.

'confirmation by the recipient' is not sufficient to ameilorate such
threats,
because the recipient is not generally aware of the threats posed by the
individual contents.
LH> This is innacurrate. MRV and the other three types are non executable 
content. The only risk posed is the standard risk of being a host for a 
virus which is the same with all other document/MIME types?

> Interoperability considerations: Implementations that have support for
the
> mandatory features of this content type will greatly increase the
chances of
> interoperating with other implementations supporting this content
type.
> Conformance to this content type requires an implementation to support
every
> mandatory feature.

that's a meaningless statement in this context.
LH> It is meaningful when the specs are published.

this application should be denied or delayed until there is a published
specification which may be reviewed, and until the security risks are 
adequately documented.
LH> Do any of the answers I provide above help you? It is unlikely that the
specifications will be published prior to MIME type registration. Thus, we
decided to use a vendor mime type which is appropriate in this situation and
does not require any approval. However, I would like to make the
registration
as meaningful as possible now with your help, given the constraint of an
unreleased
spec.

Thank you for your comments and I look forward to hearing what you think.

Cheers,
Leon.

From: [email-masked] ([email-masked])
Date: Tue, 6 Nov 2001 13:19:18 +0200
Subject: Registration of MIME media type application/vnd.nokia-mrv+xml
Message-ID: <[email-masked]>

it doesn't say anything at all about what MRV document is, nor does it
include a reference to the specification.  as such the content type is
ambiguous.
LH> This is vendor specific MIME type. The spec are not ready for public
consumption.

the encoding considerations section is poorly worded.  I'm not sure what
a "a 7bit character set with an IETF character encoding mechanism" is.
it would be sufficient to say that these documents need to be encoded
in base64 for transmission over text-based email.
LH> Agreed, will change.

the security considerations section is vague.  I can't tell what is
meant
by

> Authentication: Optional part of a Digital Rights Management system in
which
> MRV is used.

but any system which incorporates DRM is likely to have considerable
security risks - including that identity of the reader will be 
inappropriately disclosed or leaked to other parties, or that there are
circumstances under which a reader will be denied his legal rights to
use the document by the DRM system (for instance, when fair use rights 
are violated). these risks need to be analyzed and disclosed.
LH> Security models surrounding DRM are complex and endless. Security is a
spectrum of threats and (less than 100% bullet proof) counter measures.
Additionally each security infrastructure is highly. All the above types
refer to documents which have an orthoginal security implementation. Each
implementor is free to implement security levels appropriate for there
application.

> Threats: The MRV MIME content type definition provides for the
inclusion of
> arbitrary content information. Administrators for MIME implementations
that
> support this content type SHOULD take every standard precaution to
assure
> the activation of MRV content is NOT automatic, but is only performed
after
> confirmation by the recipient. In addition, administrators may want to
> perform virus scans of MRV content information.

this provides no information about how such threats may be ameliorated.
furthermore, it is difficult to see how such threats could be
ameliorated
unless the specification for the encapsulation format were made public.

'confirmation by the recipient' is not sufficient to ameilorate such
threats,
because the recipient is not generally aware of the threats posed by the
individual contents.
LH> This is innacurrate. MRV and the other three types are non executable 
content. The only risk posed is the standard risk of being a host for a 
virus which is the same with all other document/MIME types?

> Interoperability considerations: Implementations that have support for
the
> mandatory features of this content type will greatly increase the
chances of
> interoperating with other implementations supporting this content
type.
> Conformance to this content type requires an implementation to support
every
> mandatory feature.

that's a meaningless statement in this context.
LH> It is meaningful when the specs are published.

this application should be denied or delayed until there is a published
specification which may be reviewed, and until the security risks are 
adequately documented.
LH> Do any of the answers I provide above help you? It is unlikely that the
specifications will be published prior to MIME type registration. Thus, we
decided to use a vendor mime type which is appropriate in this situation and
does not require any approval. However, I would like to make the
registration
as meaningful as possible now with your help, given the constraint of an
unreleased
spec.

Thank you for your comments and I look forward to hearing what you think.

Cheers,
Leon.

From: standards at surety.com (Greg Thompson)
Date: Tue Jan  3 16:22:30 2006
Subject: Registration of MIME media type application/vnd.surety.tokenstore 
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
>
> > Security considerations: Surety Token Store files contain no executable
> > code.
>
> that's good to know, but it doesn't really say anything about
> security risks.
> is there any inherent risk to running software that uses such things?
> for instance, does such software disclose information about the recipient
> or the recipient's files, does it communicate with other network
> sites without
> the recipient's knowledge, does it alter recipient files, etc?
>
> especially given that you've said nothing at all about the
> purpose of this type,
> it's very hard to assess risk from the information provided.
>
> Keith

fair enough.

MIME media type name: application

MIME subtype name: Vendor Tree - vnd.surety.tokenstore

Required parameters: none

Optional parameters: none

Encoding considerations: Surety Token Store files contain binary data, and
must be transferred in such a way as to guarantee that no loss of
information takes place.

Security considerations: Surety Token Store files contain "Tokens" used by
the Surety Digital Notary Service.  These Tokens are used in the course of
conducting transactions with Surety Digital Notary Servers.  No personal
data is stored in a Token, and no part of a Token contains any executable
code.  Certain operations performed with Tokens within the context of an
application developed to use these Tokens may contact servers over the
Internet.  These communications do not transmit any information about the
user or the user's machine to the remote server, and only take place as a
direct result of the user's actions.

Interoperability considerations: The Surety Token Store file format is
designed such that compliant files may be parsed and generated on any
platform, independent of machine byte-ordering and word size.  As such, they
may be used with any supported product in the Surety Digital Notary Service
on any supported platform.

Published specification: none

Applications which use this media type: Surety Digital Notary Service

Additional information:

  Magic number(s): none
  File extension(s): .sts
  Macintosh File Type Code(s): none

Person & email address to contact for further information:
[email-masked]

Intended usage: common

Author/Change controller:
Written by Greg Thompson.  This type may be revised by any employee of
Surety, Inc.

From: moore at cs.utk.edu (Keith Moore)
Date: Tue Jan  3 16:22:30 2006
Subject: Registration of MIME media type application/vnd.surety.tokenstore 
In-Reply-To: Your message of "Wed, 31 Oct 2001 11:40:55 EST." <[email-masked]> 
Message-ID: <[email-masked]>

> Security considerations: Surety Token Store files contain no executable
> code.

that's good to know, but it doesn't really say anything about security risks.
is there any inherent risk to running software that uses such things?
for instance, does such software disclose information about the recipient
or the recipient's files, does it communicate with other network sites without
the recipient's knowledge, does it alter recipient files, etc?

especially given that you've said nothing at all about the purpose of this type,
it's very hard to assess risk from the information provided.

Keith

From: [email-masked] (Greg Thompson)
Date: Thu, 1 Nov 2001 10:12:37 -0500
Subject: Registration of MIME media type application/vnd.surety.tokenstore
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
>
> > Security considerations: Surety Token Store files contain no executable
> > code.
>
> that's good to know, but it doesn't really say anything about
> security risks.
> is there any inherent risk to running software that uses such things?
> for instance, does such software disclose information about the recipient
> or the recipient's files, does it communicate with other network
> sites without
> the recipient's knowledge, does it alter recipient files, etc?
>
> especially given that you've said nothing at all about the
> purpose of this type,
> it's very hard to assess risk from the information provided.
>
> Keith

fair enough.

MIME media type name: application

MIME subtype name: Vendor Tree - vnd.surety.tokenstore

Required parameters: none

Optional parameters: none

Encoding considerations: Surety Token Store files contain binary data, and
must be transferred in such a way as to guarantee that no loss of
information takes place.

Security considerations: Surety Token Store files contain "Tokens" used by
the Surety Digital Notary Service.  These Tokens are used in the course of
conducting transactions with Surety Digital Notary Servers.  No personal
data is stored in a Token, and no part of a Token contains any executable
code.  Certain operations performed with Tokens within the context of an
application developed to use these Tokens may contact servers over the
Internet.  These communications do not transmit any information about the
user or the user's machine to the remote server, and only take place as a
direct result of the user's actions.

Interoperability considerations: The Surety Token Store file format is
designed such that compliant files may be parsed and generated on any
platform, independent of machine byte-ordering and word size.  As such, they
may be used with any supported product in the Surety Digital Notary Service
on any supported platform.

Published specification: none

Applications which use this media type: Surety Digital Notary Service

Additional information:

  Magic number(s): none
  File extension(s): .sts
  Macintosh File Type Code(s): none

Person & email address to contact for further information:
[email-masked]

Intended usage: common

Author/Change controller:
Written by Greg Thompson.  This type may be revised by any employee of
Surety, Inc.

From: [email-masked] (Keith Moore)
Date: Thu, 01 Nov 2001 09:56:33 -0500
Subject: Registration of MIME media type application/vnd.surety.tokenstore
In-Reply-To: Your message of "Wed, 31 Oct 2001 11:40:55 EST." <[email-masked]>
Message-ID: <[email-masked]>

> Security considerations: Surety Token Store files contain no executable
> code.

that's good to know, but it doesn't really say anything about security risks.
is there any inherent risk to running software that uses such things?
for instance, does such software disclose information about the recipient
or the recipient's files, does it communicate with other network sites without
the recipient's knowledge, does it alter recipient files, etc?

especially given that you've said nothing at all about the purpose of this type,
it's very hard to assess risk from the information provided.

Keith