CTI TAXII Subcommittee

All, Previously in the TAXII SC we had talked about and agreed to have some restrictions to the names and lengths of API-Bases and Resource names like "channel names" and "collection names". In STIX we do not have restrictions for the contents of a "string" property.  However, we do have very tight restrictions for property names and custom properties / custom objects.   The current restrictions we have in place and nearly a copy-n-paste from what we do in STIX today, they are: * An API Base MUST be in ASCII and are limited to characters a–z (lowercase ASCII) and dash (-). * An API Base SHOULD be no longer than 30 ASCII characters in length. * An API Base MUST have a minimum length of three ASCII characters. * An API Base MUST be no longer than 256 ASCII characters in length. * Resource names MUST be in ASCII and are limited to characters a–z (lowercase ASCII) and underscore (_). * Resource names SHOULD be no longer than 30 ASCII characters in length. * Resource names MUST have a minimum length of three ASCII characters. * Resource names MUST be no longer than 256 ASCII characters in length. Personally I really like this approach, I believe there to be value in restricting these.  I am, however, curious to know if the SC still feels this is the best way to go. Bret

This seems like a good idea. I say keep the restrictions. Cheers Terry MacDonald Cosive On 9 Oct. 2016 04:00, "Bret Jordan (CS)" < Bret_Jordan@symantec.com > wrote: All, Previously in the TAXII SC we had talked about and agreed to have some restrictions to the names and lengths of API-Bases and Resource names like "channel names" and "collection names". In STIX we do not have restrictions for the contents of a "string" property.  However, we do have very tight restrictions for property names and custom properties / custom objects.   The current restrictions we have in place and nearly a copy-n-paste from what we do in STIX today, they are: * An API Base MUST be in ASCII and are limited to characters a–z (lowercase ASCII) and dash (-). * An API Base SHOULD be no longer than 30 ASCII characters in length. * An API Base MUST have a minimum length of three ASCII characters. * An API Base MUST be no longer than 256 ASCII characters in length. * Resource names MUST be in ASCII and are limited to characters a–z (lowercase ASCII) and underscore (_). * Resource names SHOULD be no longer than 30 ASCII characters in length. * Resource names MUST have a minimum length of three ASCII characters. * Resource names MUST be no longer than 256 ASCII characters in length. Personally I really like this approach, I believe there to be value in restricting these.  I am, however, curious to know if the SC still feels this is the best way to go. Bret

I generally agree but one thing to think about is future proofing in case we decide that the limit has to change from 256 to 256+X.
 
How will a legacy (TAXII 2.0 implementation) work with TAXII servers of the future that have different limits?

 
i.e.
 
a TAXII server that can support 512 resource names but the client only supports 256 names?
 
Is that determined as part of the initial version negotiation and then resource names/api that are longer than 256 are not used by the older TAXII implementations?
 
Something to ponder.
 
allan
 

From:
<cti-taxii@lists.oasis-open.org> on behalf of Terry MacDonald <terry.macdonald@cosive.com>
Date: Saturday, October 8, 2016 at 12:37 PM
To: "Bret Jordan (CS)" <Bret_Jordan@symantec.com>
Cc: "cti-taxii@lists.oasis-open.org" <cti-taxii@lists.oasis-open.org>
Subject: Re: [cti-taxii] Restrictions on resource names


 

This seems like a good idea. I say keep the restrictions.
Cheers
Terry MacDonald
Cosive

 

On 9 Oct. 2016 04:00, "Bret Jordan (CS)" < Bret_Jordan@symantec.com > wrote:



All,

 


Previously in the TAXII SC we had talked about and agreed to have some restrictions to the names and lengths of API-Bases and Resource names like "channel names" and "collection names".


 


In STIX we do not have restrictions for the contents of a "string" property.  However, we do have very tight restrictions for property names and custom properties / custom objects.  


 


The current restrictions we have in place and nearly a copy-n-paste from what we do in STIX today, they are:


 



* An API Base MUST be in ASCII and are limited to characters a–z (lowercase ASCII) and dash (-).


* An API Base SHOULD be no longer than 30 ASCII characters in length.


* An API Base MUST have a minimum length of three ASCII characters.


* An API Base MUST be no longer than 256 ASCII characters in length.


 



* Resource names MUST be in ASCII and are limited to characters a–z (lowercase ASCII) and underscore (_).


* Resource names SHOULD be no longer than 30 ASCII characters in length.


* Resource names MUST have a minimum length of three ASCII characters.


* Resource names MUST be no longer than 256 ASCII characters in length.


 


Personally I really like this approach, I believe there to be value in restricting these.  I am, however, curious to know if the SC still feels this is the best way to go.


 


Bret

Good question Allan!.  We need to figure out how best to have a TAXII client tell the TAXII server which version it is using and have the TAXII server be able to tell the client what version is is getting.   There has been some talk about doing this in the native HTTP headers, we will just need to make sure we find a good way of doing this.  If anyone has any suggestions, please let us know.   The use cases: 1) The client needs to tell the TAXII server which version of TAXII it is using.  This need to be present in every GET, POST, PUT, DELETE etc. 2) The client needs to be able to tell the TAXII server the type of content it is sending or that it wants and its version (if applicable).  For example, STIX 2.1 3) The server needs to be able to tell the client not only which version it is using, but also tell it about the content it is getting.   Bret From: Allan Thomson <athomson@lookingglasscyber.com> Sent: Saturday, October 8, 2016 2:13:21 PM To: Terry MacDonald; Bret Jordan (CS) Cc: cti-taxii@lists.oasis-open.org Subject: Re: [cti-taxii] Restrictions on resource names   I generally agree but one thing to think about is future proofing in case we decide that the limit has to change from 256 to 256+X.   How will a legacy (TAXII 2.0 implementation) work with TAXII servers of the future that have different limits?   i.e.   a TAXII server that can support 512 resource names but the client only supports 256 names?   Is that determined as part of the initial version negotiation and then resource names/api that are longer than 256 are not used by the older TAXII implementations?   Something to ponder.   allan   From: <cti-taxii@lists.oasis-open.org> on behalf of Terry MacDonald <terry.macdonald@cosive.com> Date: Saturday, October 8, 2016 at 12:37 PM To: "Bret Jordan (CS)" <Bret_Jordan@symantec.com> Cc: "cti-taxii@lists.oasis-open.org" <cti-taxii@lists.oasis-open.org> Subject: Re: [cti-taxii] Restrictions on resource names   This seems like a good idea. I say keep the restrictions. Cheers Terry MacDonald Cosive   On 9 Oct. 2016 04:00, "Bret Jordan (CS)" < Bret_Jordan@symantec.com > wrote: All,   Previously in the TAXII SC we had talked about and agreed to have some restrictions to the names and lengths of API-Bases and Resource names like "channel names" and "collection names".   In STIX we do not have restrictions for the contents of a "string" property.  However, we do have very tight restrictions for property names and custom properties / custom objects.     The current restrictions we have in place and nearly a copy-n-paste from what we do in STIX today, they are:   * An API Base MUST be in ASCII and are limited to characters a–z (lowercase ASCII) and dash (-). * An API Base SHOULD be no longer than 30 ASCII characters in length. * An API Base MUST have a minimum length of three ASCII characters. * An API Base MUST be no longer than 256 ASCII characters in length.   * Resource names MUST be in ASCII and are limited to characters a–z (lowercase ASCII) and underscore (_). * Resource names SHOULD be no longer than 30 ASCII characters in length. * Resource names MUST have a minimum length of three ASCII characters. * Resource names MUST be no longer than 256 ASCII characters in length.   Personally I really like this approach, I believe there to be value in restricting these.  I am, however, curious to know if the SC still feels this is the best way to go.   Bret

Scrap them all. HTTP and the URI specs all have detailed syntax restrictions on the form of a URI. Trying to introduce new ones seems to have little benefit, and these probably don't mean what you think they mean. An API Base cannot now span multiple path segments in a URI. I have no idea what this restriction is intended to serve. It's reasonable to assume that this would allow a client to use a fixed-length buffer to store a URI string - handy if we're writing TAXII clients in assembly - but this presupposes that the client has checked the lengths of all URI-related parameters given by the server, and a key issue about introducing rules such as these is that one needs to define the error behaviour. Does the client now give up, or - more likely - does it just carry on anyway? Having "SHOULD" <=30 and "MUST" <=256 means people will assume they can ignore the SHOULD - and they can. These rules are written from the point of view of a producer - rewrite them as a consumer and you'll see: * Consumers MUST reject any resource name containing any characters other than lowercase ASCII letters and the underscore character. * Consumers MUST reject any resource name containing fewer than 3 characters. * Consumers MUST reject any resource name containing more than 256 characters. How does one rewrite the SHOULD rule in the terms of a consumer? What must a consumer do when faced with a resource name between 31 and 256 characters long? If it MAY reject them, then that implies the producer MUST NOT generate them. Or can it truncate over-long resource names - can it choose when to truncate anywhere between 30 and 256 characters? Incidentally, I have removed the restriction on ASCII because URIs are always in ASCII. By eliminating "%" and numbers, you've blocked the percent-encoded UTF-8 anyway. On 8 October 2016 at 16:00, Bret Jordan (CS) < Bret_Jordan@symantec.com > wrote: All, Previously in the TAXII SC we had talked about and agreed to have some restrictions to the names and lengths of API-Bases and Resource names like "channel names" and "collection names". In STIX we do not have restrictions for the contents of a "string" property.  However, we do have very tight restrictions for property names and custom properties / custom objects.   The current restrictions we have in place and nearly a copy-n-paste from what we do in STIX today, they are: * An API Base MUST be in ASCII and are limited to characters a–z (lowercase ASCII) and dash (-). * An API Base SHOULD be no longer than 30 ASCII characters in length. * An API Base MUST have a minimum length of three ASCII characters. * An API Base MUST be no longer than 256 ASCII characters in length. * Resource names MUST be in ASCII and are limited to characters a–z (lowercase ASCII) and underscore (_). * Resource names SHOULD be no longer than 30 ASCII characters in length. * Resource names MUST have a minimum length of three ASCII characters. * Resource names MUST be no longer than 256 ASCII characters in length. Personally I really like this approach, I believe there to be value in restricting these.  I am, however, curious to know if the SC still feels this is the best way to go. Bret -- Dave Cridland phone   +448454681066 email   dave.cridland@surevine.com skype   dave.cridland.surevine Participate Collaborate Innovate Surevine Limited, registered in England and Wales with number 06726289. Mailing Address : PO Box 1136, Guildford GU1 9ND If you think you have received this message in error, please notify us.

Lets talk about this on tomorrows call.  Mean while, I will update the document with the current language that was used in STIX.  I just realized that the language in TAXII is older.   Bret From: Dave Cridland <dave.cridland@surevine.com> Sent: Monday, October 10, 2016 3:56:59 AM To: Bret Jordan (CS) Cc: cti-taxii@lists.oasis-open.org Subject: Re: [cti-taxii] Restrictions on resource names   Scrap them all. HTTP and the URI specs all have detailed syntax restrictions on the form of a URI. Trying to introduce new ones seems to have little benefit, and these probably don't mean what you think they mean. An API Base cannot now span multiple path segments in a URI. I have no idea what this restriction is intended to serve. It's reasonable to assume that this would allow a client to use a fixed-length buffer to store a URI string - handy if we're writing TAXII clients in assembly - but this presupposes that the client has checked the lengths of all URI-related parameters given by the server, and a key issue about introducing rules such as these is that one needs to define the error behaviour. Does the client now give up, or - more likely - does it just carry on anyway? Having "SHOULD" <=30 and "MUST" <=256 means people will assume they can ignore the SHOULD - and they can. These rules are written from the point of view of a producer - rewrite them as a consumer and you'll see: * Consumers MUST reject any resource name containing any characters other than lowercase ASCII letters and the underscore character. * Consumers MUST reject any resource name containing fewer than 3 characters. * Consumers MUST reject any resource name containing more than 256 characters. How does one rewrite the SHOULD rule in the terms of a consumer? What must a consumer do when faced with a resource name between 31 and 256 characters long? If it MAY reject them, then that implies the producer MUST NOT generate them. Or can it truncate over-long resource names - can it choose when to truncate anywhere between 30 and 256 characters? Incidentally, I have removed the restriction on ASCII because URIs are always in ASCII. By eliminating "%" and numbers, you've blocked the percent-encoded UTF-8 anyway. On 8 October 2016 at 16:00, Bret Jordan (CS) < Bret_Jordan@symantec.com > wrote: All, Previously in the TAXII SC we had talked about and agreed to have some restrictions to the names and lengths of API-Bases and Resource names like "channel names" and "collection names". In STIX we do not have restrictions for the contents of a "string" property.  However, we do have very tight restrictions for property names and custom properties / custom objects.   The current restrictions we have in place and nearly a copy-n-paste from what we do in STIX today, they are: * An API Base MUST be in ASCII and are limited to characters a–z (lowercase ASCII) and dash (-). * An API Base SHOULD be no longer than 30 ASCII characters in length. * An API Base MUST have a minimum length of three ASCII characters. * An API Base MUST be no longer than 256 ASCII characters in length. * Resource names MUST be in ASCII and are limited to characters a–z (lowercase ASCII) and underscore (_). * Resource names SHOULD be no longer than 30 ASCII characters in length. * Resource names MUST have a minimum length of three ASCII characters. * Resource names MUST be no longer than 256 ASCII characters in length. Personally I really like this approach, I believe there to be value in restricting these.  I am, however, curious to know if the SC still feels this is the best way to go. Bret -- Dave Cridland phone   +448454681066 email   dave.cridland@surevine.com skype   dave.cridland.surevine Participate Collaborate Innovate Surevine Limited, registered in England and Wales with number 06726289. Mailing Address : PO Box 1136, Guildford GU1 9ND If you think you have received this message in error, please notify us.

I updated the restrictions in TAXII to be current with what we do in STIX and fixed the inconsistencies between the API-bases and Resources.  Bret From: Dave Cridland <dave.cridland@surevine.com> Sent: Monday, October 10, 2016 3:56:59 AM To: Bret Jordan (CS) Cc: cti-taxii@lists.oasis-open.org Subject: Re: [cti-taxii] Restrictions on resource names   Scrap them all. HTTP and the URI specs all have detailed syntax restrictions on the form of a URI. Trying to introduce new ones seems to have little benefit, and these probably don't mean what you think they mean. An API Base cannot now span multiple path segments in a URI. I have no idea what this restriction is intended to serve. It's reasonable to assume that this would allow a client to use a fixed-length buffer to store a URI string - handy if we're writing TAXII clients in assembly - but this presupposes that the client has checked the lengths of all URI-related parameters given by the server, and a key issue about introducing rules such as these is that one needs to define the error behaviour. Does the client now give up, or - more likely - does it just carry on anyway? Having "SHOULD" <=30 and "MUST" <=256 means people will assume they can ignore the SHOULD - and they can. These rules are written from the point of view of a producer - rewrite them as a consumer and you'll see: * Consumers MUST reject any resource name containing any characters other than lowercase ASCII letters and the underscore character. * Consumers MUST reject any resource name containing fewer than 3 characters. * Consumers MUST reject any resource name containing more than 256 characters. How does one rewrite the SHOULD rule in the terms of a consumer? What must a consumer do when faced with a resource name between 31 and 256 characters long? If it MAY reject them, then that implies the producer MUST NOT generate them. Or can it truncate over-long resource names - can it choose when to truncate anywhere between 30 and 256 characters? Incidentally, I have removed the restriction on ASCII because URIs are always in ASCII. By eliminating "%" and numbers, you've blocked the percent-encoded UTF-8 anyway. On 8 October 2016 at 16:00, Bret Jordan (CS) < Bret_Jordan@symantec.com > wrote: All, Previously in the TAXII SC we had talked about and agreed to have some restrictions to the names and lengths of API-Bases and Resource names like "channel names" and "collection names". In STIX we do not have restrictions for the contents of a "string" property.  However, we do have very tight restrictions for property names and custom properties / custom objects.   The current restrictions we have in place and nearly a copy-n-paste from what we do in STIX today, they are: * An API Base MUST be in ASCII and are limited to characters a–z (lowercase ASCII) and dash (-). * An API Base SHOULD be no longer than 30 ASCII characters in length. * An API Base MUST have a minimum length of three ASCII characters. * An API Base MUST be no longer than 256 ASCII characters in length. * Resource names MUST be in ASCII and are limited to characters a–z (lowercase ASCII) and underscore (_). * Resource names SHOULD be no longer than 30 ASCII characters in length. * Resource names MUST have a minimum length of three ASCII characters. * Resource names MUST be no longer than 256 ASCII characters in length. Personally I really like this approach, I believe there to be value in restricting these.  I am, however, curious to know if the SC still feels this is the best way to go. Bret -- Dave Cridland phone   +448454681066 email   dave.cridland@surevine.com skype   dave.cridland.surevine Participate Collaborate Innovate Surevine Limited, registered in England and Wales with number 06726289. Mailing Address : PO Box 1136, Guildford GU1 9ND If you think you have received this message in error, please notify us.

I think it would be overly limiting to not allow people to create collection names with non-latin1 characters. People will want to create collection names in their own language. - Jason Keirstead STSM, Product Architect, Security Intelligence, IBM Security Systems www.ibm.com/security www.securityintelligence.com Without data, all you are is just another person with an opinion - Unknown "Bret Jordan (CS)" ---10/10/2016 01:58:42 PM---I updated the restrictions in TAXII to be current with what we do in STIX and fixed the inconsistenc From: "Bret Jordan (CS)" <Bret_Jordan@symantec.com> To: Dave Cridland <dave.cridland@surevine.com> Cc: "cti-taxii@lists.oasis-open.org" <cti-taxii@lists.oasis-open.org> Date: 10/10/2016 01:58 PM Subject: Re: [cti-taxii] Restrictions on resource names Sent by: <cti-taxii@lists.oasis-open.org> I updated the restrictions in TAXII to be current with what we do in STIX and fixed the inconsistencies between the API-bases and Resources. Bret From: Dave Cridland <dave.cridland@surevine.com> Sent: Monday, October 10, 2016 3:56:59 AM To: Bret Jordan (CS) Cc: cti-taxii@lists.oasis-open.org Subject: Re: [cti-taxii] Restrictions on resource names Scrap them all. HTTP and the URI specs all have detailed syntax restrictions on the form of a URI. Trying to introduce new ones seems to have little benefit, and these probably don't mean what you think they mean. An API Base cannot now span multiple path segments in a URI. I have no idea what this restriction is intended to serve. It's reasonable to assume that this would allow a client to use a fixed-length buffer to store a URI string - handy if we're writing TAXII clients in assembly - but this presupposes that the client has checked the lengths of all URI-related parameters given by the server, and a key issue about introducing rules such as these is that one needs to define the error behaviour. Does the client now give up, or - more likely - does it just carry on anyway? Having "SHOULD" <=30 and "MUST" <=256 means people will assume they can ignore the SHOULD - and they can. These rules are written from the point of view of a producer - rewrite them as a consumer and you'll see: * Consumers MUST reject any resource name containing any characters other than lowercase ASCII letters and the underscore character. * Consumers MUST reject any resource name containing fewer than 3 characters. * Consumers MUST reject any resource name containing more than 256 characters. How does one rewrite the SHOULD rule in the terms of a consumer? What must a consumer do when faced with a resource name between 31 and 256 characters long? If it MAY reject them, then that implies the producer MUST NOT generate them. Or can it truncate over-long resource names - can it choose when to truncate anywhere between 30 and 256 characters? Incidentally, I have removed the restriction on ASCII because URIs are always in ASCII. By eliminating "%" and numbers, you've blocked the percent-encoded UTF-8 anyway. On 8 October 2016 at 16:00, Bret Jordan (CS) < Bret_Jordan@symantec.com > wrote: All, Previously in the TAXII SC we had talked about and agreed to have some restrictions to the names and lengths of API-Bases and Resource names like "channel names" and "collection names". In STIX we do not have restrictions for the contents of a "string" property. However, we do have very tight restrictions for property names and custom properties / custom objects. The current restrictions we have in place and nearly a copy-n-paste from what we do in STIX today, they are: * An API Base MUST be in ASCII and are limited to characters a–z (lowercase ASCII) and dash (-). * An API Base SHOULD be no longer than 30 ASCII characters in length. * An API Base MUST have a minimum length of three ASCII characters. * An API Base MUST be no longer than 256 ASCII characters in length. * Resource names MUST be in ASCII and are limited to characters a–z (lowercase ASCII) and underscore (_). * Resource names SHOULD be no longer than 30 ASCII characters in length. * Resource names MUST have a minimum length of three ASCII characters. * Resource names MUST be no longer than 256 ASCII characters in length. Personally I really like this approach, I believe there to be value in restricting these. I am, however, curious to know if the SC still feels this is the best way to go. Bret -- Dave Cridland phone +448454681066 email dave.cridland@surevine.com skype dave.cridland.surevine Participate Collaborate Innovate Surevine Limited, registered in England and Wales with number 06726289. Mailing Address : PO Box 1136, Guildford GU1 9ND If you think you have received this message in error, please notify us.

On 11.10.2016 09:19:00, Jason Keirstead wrote: > I think it would be overly limiting to not allow people to create > collection names with non-latin1 characters. People will want to > create collection names in their own language. > I concur with Jason. -- Cheers, Trey ++--------------------------------------------------------------------------++ Kingfisher Operations, sprl gpg fingerprint: 85F3 5F54 4A2A B4CD 33C4 5B9B B30D DD6E 62C8 6C1D ++--------------------------------------------------------------------------++ -- "No matter how hard you try, you can't make a baby in much less than 9 months. Trying to speed this up *might* make it slower, but it won't make it happen any quicker." --RFC 1925 Attachment: signature.asc Description: Digital signature

And if you add in %-encoding, you can cover everyone's languages. (Ignoring, for the moment, that we're talking about UTF-8 being percent encoded into Latin-1). On 11 October 2016 at 13:40, Trey Darley < trey@kingfisherops.com > wrote: On 11.10.2016 09:19:00, Jason Keirstead wrote: > I think it would be overly limiting to not allow people to create > collection names with non-latin1 characters. People will want to > create collection names in their own language. > I concur with Jason. -- Cheers, Trey ++---------------------------- ------------------------------ ----------------++ Kingfisher Operations, sprl gpg fingerprint: 85F3 5F54 4A2A B4CD 33C4  5B9B B30D DD6E 62C8 6C1D ++---------------------------- ------------------------------ ----------------++ -- "No matter how hard you try, you can't make a baby in much less than 9 months. Trying to speed this up *might* make it slower, but it won't make it happen any quicker." --RFC 1925 -- Dave Cridland phone   +448454681066 email   dave.cridland@surevine.com skype   dave.cridland.surevine Participate Collaborate Innovate Surevine Limited, registered in England and Wales with number 06726289. Mailing Address : PO Box 1136, Guildford GU1 9ND If you think you have received this message in error, please notify us.

Dave Cridland wrote this message on Tue, Oct 11, 2016 at 13:42 +0100: > And if you add in %-encoding, you can cover everyone's languages. > (Ignoring, for the moment, that we're talking about UTF-8 being percent > encoded into Latin-1). We should be using IRI[1][2] for TAXII, which address non-ASCII characters is URLs. [1] https://en.wikipedia.org/wiki/Internationalized_Resource_Identifier [2] https://tools.ietf.org/html/rfc3987 > On 11 October 2016 at 13:40, Trey Darley <trey@kingfisherops.com> wrote: > > > On 11.10.2016 09:19:00, Jason Keirstead wrote: > > > I think it would be overly limiting to not allow people to create > > > collection names with non-latin1 characters. People will want to > > > create collection names in their own language. > > > > > > > I concur with Jason. -- John-Mark

On 14 Oct 2016 23:43, "John-Mark Gurney" < jmg@newcontext.com > wrote: > > Dave Cridland wrote this message on Tue, Oct 11, 2016 at 13:42 +0100: > > And if you add in %-encoding, you can cover everyone's languages. > > (Ignoring, for the moment, that we're talking about UTF-8 being percent > > encoded into Latin-1). > > We should be using IRI[1][2] for TAXII, which address non-ASCII characters is > URLs. > > [1] https://en.wikipedia.org/wiki/Internationalized_Resource_Identifier > [2] https://tools.ietf.org/html/rfc3987 > Judging by the discussion about I18n on the call last week, I think this is the right path - it shows channel names to be IRI path segments, I think, for which we should be able to pass the buck to an existing definition. > > On 11 October 2016 at 13:40, Trey Darley < trey@kingfisherops.com > wrote: > > > > > On 11.10.2016 09:19:00, Jason Keirstead wrote: > > > > I think it would be overly limiting to not allow people to create > > > > collection names with non-latin1 characters. People will want to > > > > create collection names in their own language. > > > > > > > > > > I concur with Jason. > > -- > John-Mark

My only concern with this is the fact it makes it easier to do phishing attacks. IDIs make it easier to make fake DNS names look like real ones (eg make a fake oasis-open.org using an a from a different language). But that is something that network intrusion detection systems need to learn to cope with, and the benefits for internationalisation are important, so it seems like a good idea to do. Cheers Terry MacDonald Cosive On 15 Oct. 2016 21:18, "Dave Cridland" < dave.cridland@surevine.com > wrote: On 14 Oct 2016 23:43, "John-Mark Gurney" < jmg@newcontext.com > wrote: > > Dave Cridland wrote this message on Tue, Oct 11, 2016 at 13:42 +0100: > > And if you add in %-encoding, you can cover everyone's languages. > > (Ignoring, for the moment, that we're talking about UTF-8 being percent > > encoded into Latin-1). > > We should be using IRI[1][2] for TAXII, which address non-ASCII characters is > URLs. > > [1] https://en.wikipedia.org/wiki/ Internationalized_Resource_ Identifier > [2] https://tools.ietf.org/html/ rfc3987 > Judging by the discussion about I18n on the call last week, I think this is the right path - it shows channel names to be IRI path segments, I think, for which we should be able to pass the buck to an existing definition. > > On 11 October 2016 at 13:40, Trey Darley < trey@kingfisherops.com > wrote: > > > > > On 11.10.2016 09:19:00, Jason Keirstead wrote: > > > > I think it would be overly limiting to not allow people to create > > > > collection names with non-latin1 characters. People will want to > > > > create collection names in their own language. > > > > > > > > > > I concur with Jason. > > -- > John-Mark

Terry MacDonald wrote this message on Sun, Oct 16, 2016 at 08:47 +1300: > My only concern with this is the fact it makes it easier to do phishing > attacks. IDIs make it easier to make fake DNS names look like real ones (eg > make a fake oasis-open.org using an a from a different language). The IDN homograph attack is outside the scope of the specification, as that is already a common problem and there are various ways to address that. We are only talking about one path component for TAXII. If an administrator allows the creation of similar names, they are responsible for the confusion as a result. I hope that TAXII servers will not allow arbitrary creation of collections, or that some administrator will handle the curation of that. > On 15 Oct. 2016 21:18, "Dave Cridland" <dave.cridland@surevine.com> wrote: > > > On 14 Oct 2016 23:43, "John-Mark Gurney" <jmg@newcontext.com> wrote: > > > > > > Dave Cridland wrote this message on Tue, Oct 11, 2016 at 13:42 +0100: > > > > And if you add in %-encoding, you can cover everyone's languages. > > > > (Ignoring, for the moment, that we're talking about UTF-8 being percent > > > > encoded into Latin-1). > > > > > > We should be using IRI[1][2] for TAXII, which address non-ASCII > > characters is > > > URLs. > > > > > > [1] https://en.wikipedia.org/wiki/Internationalized_Resource_Identifier > > > [2] https://tools.ietf.org/html/rfc3987 > > > > > > > Judging by the discussion about I18n on the call last week, I think this > > is the right path - it shows channel names to be IRI path segments, I > > think, for which we should be able to pass the buck to an existing > > definition. > > > > > > On 11 October 2016 at 13:40, Trey Darley <trey@kingfisherops.com> > > wrote: > > > > > > > > > On 11.10.2016 09:19:00, Jason Keirstead wrote: > > > > > > I think it would be overly limiting to not allow people to create > > > > > > collection names with non-latin1 characters. People will want to > > > > > > create collection names in their own language. > > > > > > > > > > > > > > > > I concur with Jason. -- John-Mark