[TAXII] General comments on 1.1 Syntax Requirements

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

[TAXII] General comments on 1.1 Syntax Requirements

Dave Cridland
Some comments on the specification, and in particular the requirements it places on syntax.

1) URN syntax.

The URN syntax used is illegal according to RFC 2141; this gives the syntax for the NID (the second component of a URN) as up to 31 characters, and each character may be an ASCII letter or digit or - aside from the first - a hyphen. Dots aren't allowed.

The URNs used in TAXII are within a NID of "taxii.mitre.org"; the dots here are the problem. A strict parser may well reject these as invalid, which seems unhelpful.

Furthermore, a NID needs to be registered with IANA; NIDs of this form (as opposed to the ugly numeric ones) require IETF Consensus, which in practical terms means they need creation via an RFC publication; an example is RFC 4854.

However, all this said, it's really not clear that URNs are needed in most cases I've seen them. For example, I can't really believe we need to support versions that aren't TAXII versions, nor what it might mean if we did.

2) Identifiers as URIs.

Message, Subscription, and Result IDs have been required to be URIs - this seems fairly unhelpful. I see two possible uses for having a URI here. Firstly, it gives a restrictive syntax likely to be reasonable easy to embed in a number of wire protocols (ie, mappings). Secondly, it allows a consistent resolvable reference. Clearly the reuse rules are such that using these for resolution would be problematic, and given that there's no scheme given the URIs don't contain any resolution information - they're simply an opaque identifier.

I suggest that a simple restrictive syntax is used here instead; perhaps printable ASCII characters (or letters/digits/hyphen).

I note that Bret Jordan's examples don't use URIs here anyway; instead they're using numeric identifiers (this is valid syntax as a relative reference, but given the lack of base URI it's a technicality at best).

There are some other cases where URIs are used as globally unique identifiers which can be minted by any party - these cases are quite useful, but it may be beneficial to distinguish between standard identifiers and vendor-specific ones, and possibly include vendor-specific identifiers as "detail" to a standard identifier.

3) Timestamps which are not timestamps.

§4.1.4 I found deeply confusing. Because a timestamp label need not bear any relationship to chronological time, it looks like a very complex way of expressing a strictly monotonically increasing value. Worse, because back ends are required, in effect, to support arbitrary precision this seems like a recipe for some nasty bugs.

Unlike most of the other issues, it's not clear to me this can be fixed since it's relatively low-level; but I'd hope it can be.

4) Extension data.

As I alluded to in another message, one of the benefits of XML is that it has namespacing built-in, which allows for some fairly useful constructs. XMPP uses this heavily, as one might expect from a XML-native protocol, but I suspect it would be possible to use something fairly similar in §4.1.5 and similar places. I'd go so far as to say that extended headers, for example, would be best defined as a tuple of namespace, local name, and value, as with XML Namespaces, since that will map to both XML and JSON neatly - but be significantly more compact in XML.

Reply | Threaded
Open this post in threaded view
|

Re: [TAXII] General comments on 1.1 Syntax Requirements

mdavidson

Dave,

 

Sorry for the delayed response. I’ll respond to your points individually.

 

# 1) The URN syntax used is illegal according to RFC 2141

The TAXII Services Spec 1.1 references RFC 3986, Uniform Resource Identifier (URI): Generic Syntax, indicating that Message IDs, Data Collection Names, and some other items must conform to URI (not to be confused with URN) formatting rules. TAXII doesn’t have any URN-specific conformance rules. However, if you feel that something seems inconsistent or counter-intuitive, it is worth discussing.

 

# 2) Identifiers as URIs

You are correct that “restrictive syntax likely to be reasonable easy to embed in a number of wire protocols” was the intent. The resolvable reference is not important (to TAXII), as evidenced by the “… conform to URI formatting rules”, instead of requiring that they be resolvable URIs. I’ve opened an issue for this on GitHub [1], and referenced your email as the source.

 

# 3) Timestamps which are not timestamps

I’ve updated an existing issue with your comment [2]

 

# 4) Extension data.

I’ve updated an issue with your comment [3].

 

Thank you.

-Mark

 

[1] https://github.com/TAXIIProject/TAXII-Specifications/issues/66

[2] https://github.com/TAXIIProject/TAXII-Specifications/issues/37

[3] https://github.com/TAXIIProject/TAXII-Specifications/issues/65

 

From: Dave Cridland [mailto:[hidden email]]
Sent: Monday, March 09, 2015 10:58 AM
To: taxii-discussion-list Trusted Automated Exchange of Indicator In
Subject: [TAXII] General comments on 1.1 Syntax Requirements

 

Some comments on the specification, and in particular the requirements it places on syntax.

 

1) URN syntax.

 

The URN syntax used is illegal according to RFC 2141; this gives the syntax for the NID (the second component of a URN) as up to 31 characters, and each character may be an ASCII letter or digit or - aside from the first - a hyphen. Dots aren't allowed.

 

The URNs used in TAXII are within a NID of "taxii.mitre.org"; the dots here are the problem. A strict parser may well reject these as invalid, which seems unhelpful.

 

Furthermore, a NID needs to be registered with IANA; NIDs of this form (as opposed to the ugly numeric ones) require IETF Consensus, which in practical terms means they need creation via an RFC publication; an example is RFC 4854.

 

However, all this said, it's really not clear that URNs are needed in most cases I've seen them. For example, I can't really believe we need to support versions that aren't TAXII versions, nor what it might mean if we did.

 

2) Identifiers as URIs.

 

Message, Subscription, and Result IDs have been required to be URIs - this seems fairly unhelpful. I see two possible uses for having a URI here. Firstly, it gives a restrictive syntax likely to be reasonable easy to embed in a number of wire protocols (ie, mappings). Secondly, it allows a consistent resolvable reference. Clearly the reuse rules are such that using these for resolution would be problematic, and given that there's no scheme given the URIs don't contain any resolution information - they're simply an opaque identifier.

 

I suggest that a simple restrictive syntax is used here instead; perhaps printable ASCII characters (or letters/digits/hyphen).

 

I note that Bret Jordan's examples don't use URIs here anyway; instead they're using numeric identifiers (this is valid syntax as a relative reference, but given the lack of base URI it's a technicality at best).

 

There are some other cases where URIs are used as globally unique identifiers which can be minted by any party - these cases are quite useful, but it may be beneficial to distinguish between standard identifiers and vendor-specific ones, and possibly include vendor-specific identifiers as "detail" to a standard identifier.

 

3) Timestamps which are not timestamps.

 

§4.1.4 I found deeply confusing. Because a timestamp label need not bear any relationship to chronological time, it looks like a very complex way of expressing a strictly monotonically increasing value. Worse, because back ends are required, in effect, to support arbitrary precision this seems like a recipe for some nasty bugs.

 

Unlike most of the other issues, it's not clear to me this can be fixed since it's relatively low-level; but I'd hope it can be.

 

4) Extension data.

 

As I alluded to in another message, one of the benefits of XML is that it has namespacing built-in, which allows for some fairly useful constructs. XMPP uses this heavily, as one might expect from a XML-native protocol, but I suspect it would be possible to use something fairly similar in §4.1.5 and similar places. I'd go so far as to say that extended headers, for example, would be best defined as a tuple of namespace, local name, and value, as with XML Namespaces, since that will map to both XML and JSON neatly - but be significantly more compact in XML.

 

Reply | Threaded
Open this post in threaded view
|

Re: [TAXII] General comments on 1.1 Syntax Requirements

Jordan, Bret
Mark, 

I think part of the confusion might be from the TAXII Binding Version ID, the fact that it uses a "urn" prefix.

urn:taxii.mitre.org:message:xml:1.1


Thanks,

Bret



Bret Jordan CISSP
Director of Security Architecture and Standards | Office of the CTO
Blue Coat Systems
PGP Fingerprint: 62A6 5999 0F7D 0D61 4C66 D59C 2DB5 111D 63BC A303
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg." 

On Mar 31, 2015, at 8:14 AM, Davidson II, Mark S <[hidden email]> wrote:

Dave,
 
Sorry for the delayed response. I’ll respond to your points individually.
 
# 1) The URN syntax used is illegal according to RFC 2141
The TAXII Services Spec 1.1 references RFC 3986, Uniform Resource Identifier (URI): Generic Syntax, indicating that Message IDs, Data Collection Names, and some other items must conform to URI (not to be confused with URN) formatting rules. TAXII doesn’t have any URN-specific conformance rules. However, if you feel that something seems inconsistent or counter-intuitive, it is worth discussing.
 
# 2) Identifiers as URIs
You are correct that “restrictive syntax likely to be reasonable easy to embed in a number of wire protocols” was the intent. The resolvable reference is not important (to TAXII), as evidenced by the “… conform to URI formatting rules”, instead of requiring that they be resolvable URIs. I’ve opened an issue for this on GitHub [1], and referenced your email as the source.
 
# 3) Timestamps which are not timestamps
I’ve updated an existing issue with your comment [2]
 
# 4) Extension data.
I’ve updated an issue with your comment [3].
 
Thank you.
-Mark
 
 
From: Dave Cridland [[hidden email]] 
Sent: Monday, March 09, 2015 10:58 AM
To: taxii-discussion-list Trusted Automated Exchange of Indicator In
Subject: [TAXII] General comments on 1.1 Syntax Requirements
 
Some comments on the specification, and in particular the requirements it places on syntax.
 
1) URN syntax.
 
The URN syntax used is illegal according to RFC 2141; this gives the syntax for the NID (the second component of a URN) as up to 31 characters, and each character may be an ASCII letter or digit or - aside from the first - a hyphen. Dots aren't allowed.
 
The URNs used in TAXII are within a NID of "taxii.mitre.org"; the dots here are the problem. A strict parser may well reject these as invalid, which seems unhelpful.
 
Furthermore, a NID needs to be registered with IANA; NIDs of this form (as opposed to the ugly numeric ones) require IETF Consensus, which in practical terms means they need creation via an RFC publication; an example is RFC 4854.
 
However, all this said, it's really not clear that URNs are needed in most cases I've seen them. For example, I can't really believe we need to support versions that aren't TAXII versions, nor what it might mean if we did.
 
2) Identifiers as URIs.
 
Message, Subscription, and Result IDs have been required to be URIs - this seems fairly unhelpful. I see two possible uses for having a URI here. Firstly, it gives a restrictive syntax likely to be reasonable easy to embed in a number of wire protocols (ie, mappings). Secondly, it allows a consistent resolvable reference. Clearly the reuse rules are such that using these for resolution would be problematic, and given that there's no scheme given the URIs don't contain any resolution information - they're simply an opaque identifier.
 
I suggest that a simple restrictive syntax is used here instead; perhaps printable ASCII characters (or letters/digits/hyphen).
 
I note that Bret Jordan's examples don't use URIs here anyway; instead they're using numeric identifiers (this is valid syntax as a relative reference, but given the lack of base URI it's a technicality at best).
 
There are some other cases where URIs are used as globally unique identifiers which can be minted by any party - these cases are quite useful, but it may be beneficial to distinguish between standard identifiers and vendor-specific ones, and possibly include vendor-specific identifiers as "detail" to a standard identifier.
 
3) Timestamps which are not timestamps.
 
§4.1.4 I found deeply confusing. Because a timestamp label need not bear any relationship to chronological time, it looks like a very complex way of expressing a strictly monotonically increasing value. Worse, because back ends are required, in effect, to support arbitrary precision this seems like a recipe for some nasty bugs.
 
Unlike most of the other issues, it's not clear to me this can be fixed since it's relatively low-level; but I'd hope it can be.
 
4) Extension data.
 
As I alluded to in another message, one of the benefits of XML is that it has namespacing built-in, which allows for some fairly useful constructs. XMPP uses this heavily, as one might expect from a XML-native protocol, but I suspect it would be possible to use something fairly similar in §4.1.5 and similar places. I'd go so far as to say that extended headers, for example, would be best defined as a tuple of namespace, local name, and value, as with XML Namespaces, since that will map to both XML and JSON neatly - but be significantly more compact in XML.


signature.asc (858 bytes) Download Attachment