Subject: Re: [sacm] A thought and three related questions regarding the SWID M&A draft

From: "Waltermire, David A. (Fed)" <[email-masked]>
Date: Mon, 21 Mar 2016 22:05:33 +0000

A few of us have been working together on a concise binding of SWID tags using CBOR, which was just posted as draft-birkholz-sacm-coswid-00. This message is very appropriate considering this. There has been some concerns raised around XML and its related size, both for storage and exchange. We are hoping that this concise representation will address these concerns while promoting the further adoption and use of SWID tags in both traditional and constrained environments.

We would appreciate review and comments from the working group on this fairly short draft.

https://datatracker.ietf.org/doc/draft-birkholz-sacm-coswid/

Answers to your specific questions are below.

Regards,
Dave

> -----Original Message-----
> From: sacm [mailto:[email-masked]] On Behalf Of Lisa Lorenzin
> Sent: Monday, March 21, 2016 2:14 PM
> To: [email-masked]
> Subject: [sacm] A thought and three related questions regarding the SWID
> M&A draft
> 
> Hi all,
> 
> I must admit I was a little overwhelmed by all the OVAL drafts that were
> posted for the virtual interim!  Looking back at the virtual interim notes, it
> looks like we agreed to focus our reviews first on the Endpoint Compliance
> Profile and SWID Message and Attributes drafts, which was a bit of a relief. :)
> So I've been thinking about SWID M&A in relation to the vulnerability
> assessment scenario.

Thanks.

> One thought that occurs to me is that the current SWID M&A draft addresses
> XML formatted messages and assumes an XML binding; I've gotten a good
> less in the pitfalls of having XML as the only standard binding from my work
> with TNC IF-MAP, and I think it's a good idea to have more options in this
> arena.  I'd like us to consider additional encoding options - JSON and CBOR
> seem like two obvious choices to me - and adding some kind of negotiation
> to enable selection among them.
> 
> Three questions:
> 
> 1) Does this seem useful?  Are there pitfalls I'm not considering to expanding
> beyond one binding?

This seems reasonable. Minimally, we could have both the XML and CBOR bindings. This solution might also address revisions in existing formats and future formats as well.

> 2) If we do expand to multiple encoding options, what mechanism(s) would
> be most appropriate in this usage for negotiation of which encoding option to
> use?

We might want to use something like mime types to address this.

> 3) Are there additional encoding options beyond JSON and CBOR that should
> be considered?  Since this is outside my primary experience, I'd love to hear
> what others think should be included.

Me too. :-)

> 
> 							Regards,
> 
> 								Lisa
> 
> 
> --
> Lisa Lorenzin    /    Principal Solutions Architect
> [email-masked]    /    919-384-7275
> 
> Pulse Secure    /    https://www.pulsesecure.net
> Facebook: https://www.facebook.com/pulsesecure1
> LinkedIn: https://www.linkedin.com/company/pulse-secure
> Twitter: https://twitter.com/PulseSecure1
> 
> 
> 
> 
> _______________________________________________
> sacm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sacm

---

From: "Haynes, Dan" <[email-masked]>
Date: Tue, 22 Mar 2016 18:28:25 +0000

I know the size of XML documents has been a challenge with respect to OVAL over the years.

Personally, I like the idea of supporting multiple interoperable data bindings (XML, JSON, CBOR, etc.) because it provides vendors with options and they can pick the one that makes the most sense for them.  However, I am not sure how well this works in practice as my experience comes from an XML data model :).  How do WGs in the IETF typically deal with this?  Do they typically select a single data binding and use that for all their data models?  Do they support multiple data bindings across multiple data models, but, then pick one data binding for each data model that is mandatory-to-implement?

Thanks,

Danny

> From: sacm [mailto:[email-masked]] On Behalf Of Waltermire, David
> A. (Fed)
> Sent: Monday, March 21, 2016 6:06 PM
> To: Lisa Lorenzin <[email-masked]>; [email-masked]
> Subject: Re: [sacm] A thought and three related questions regarding the
> SWID M&A draft
> 
> A few of us have been working together on a concise binding of SWID tags
> using CBOR, which was just posted as draft-birkholz-sacm-coswid-00. This
> message is very appropriate considering this. There has been some concerns
> raised around XML and its related size, both for storage and exchange. We
> are hoping that this concise representation will address these concerns while
> promoting the further adoption and use of SWID tags in both traditional and
> constrained environments.
> 
> > Subject: [sacm] A thought and three related questions regarding the
> > SWID M&A draft
> >
> > Hi all,
> >
> > I must admit I was a little overwhelmed by all the OVAL drafts that
> > were posted for the virtual interim!  Looking back at the virtual
> > interim notes, it looks like we agreed to focus our reviews first on
> > the Endpoint Compliance Profile and SWID Message and Attributes
> > drafts, which was a bit of a relief. :) So I've been thinking about
> > SWID M&A in relation to the vulnerability assessment scenario.
> 
> Thanks.
> 
> > One thought that occurs to me is that the current SWID M&A draft
> > addresses XML formatted messages and assumes an XML binding; I've
> > gotten a good less in the pitfalls of having XML as the only standard
> > binding from my work with TNC IF-MAP, and I think it's a good idea to
> > have more options in this arena.  I'd like us to consider additional
> > encoding options - JSON and CBOR seem like two obvious choices to me -
> > and adding some kind of negotiation to enable selection among them.
> >
> > Three questions:
> >
> > 1) Does this seem useful?  Are there pitfalls I'm not considering to
> > expanding beyond one binding?
> 
> This seems reasonable. Minimally, we could have both the XML and CBOR
> bindings. This solution might also address revisions in existing formats and
> future formats as well.
> 
> > 2) If we do expand to multiple encoding options, what mechanism(s)
> > would be most appropriate in this usage for negotiation of which
> > encoding option to use?
> 
> > 3) Are there additional encoding options beyond JSON and CBOR that
> > should be considered?  Since this is outside my primary experience,
> > I'd love to hear what others think should be included.
> 
> Me too. :-)
> 
> >
> > 							Regards,
> >
> > 								Lisa
> >
> >
> > --

---

From: Gunnar Engelbach <[email-masked]>
Date: Tue, 22 Mar 2016 14:50:27 -0400

Depends on how import interoperability is -- which, it seems to me, is 
the point of having standards.

No one binding is going to be ideal for all situations, so I like to 
have some options.  But having to support all of them on all devices, 
especially for legacy and resource-constrained devices, creates a 
barrier to adoption.

If there's a single MTI (Mandatory To Implement) with an allowance for 
other options and a facility to negotiate between two devices, you 
preserve interoperability but still allow for flexibility.

That still means that the single MTI creates problems for some devices, 
so it could also be that the MTI is one from among a short list of 
possibilities.  That, unfortunately, creates a situation where some 
devices just can't communicate with others.

With that in mind, I'm fine with XML being the single MTI.  Yeah, it can 
be very bloaty, which is exacerbated by people trying to make documents 
human-friendly, but I find it very flexible and easy to work with and 
good libraries are available for a wide range of platforms.  But I don't 
feel compelled to advocate for XML ahead of any other options.

I suspect that, no matter what is selected, once that meets actual 
implementation and use we'll find shortcomings.  Make the best selection 
now for a single MTI, allow for the use of other bindings, and once 
there's some actual experience revisit with the possibility of updating 
to a different MTI (or adding a second).

--gun

---

From: "Landfield, Kent B" <[email-masked]>
Date: Tue, 22 Mar 2016 18:55:41 +0000

+1 
We need a mandatory to implement. There is nothing that says other bindings could not be supported. I too am fine with XML being the MTI.
---
Kent Landfield
+1.817.637.8026

---

From: "Jim Schaad" <[email-masked]>
Date: Tue, 22 Mar 2016 18:02:30 -0700

I have a problem with the way that you have phased the question in one
aspect.

To me, XML is a serialization and not a data model.  So saying that you are
working with multiple data models because you are working with multiple
serializations is a problem.  I see the serialization as being tied to a
specific interface protocol and not to the data model.  A single data model
can be serialized in different ways, but still be the same data model (i.e.
this is the field name and this is the type).  

I would say that the serialization is going to be dependent on what the
interface is.  I do not know if we are talking about using the same
interface between a hardware component that is reporting the properties that
make up its state as opposed to between two different data stores that are
propagating data forward or between a data store and a consumer where there
is a large amount of query style operations that are going to be occurring.

I will admit that I have a preference for CBOR, but then I also have a
preference for ASN.1.  In neither case do I find the argument of - but it is
human readable - to be overly compelling given the size problems that can
crop up from being human readable.  Additionally, I find the security
message functionality to be far better for CBOR than for JSON or XML where
size and canonicalization can be issues when dealing with things.  

That said, I believe that the serialization should be different for
different interfaces so that having one MTI does not make sense to me.  But
if you say that data model and serialization are part of the same thing then
I would get very lost in trying to answer the question.

Jim

> From: sacm [mailto:[email-masked]] On Behalf Of Haynes, Dan
> Sent: Tuesday, March 22, 2016 11:28 AM
> To: Waltermire, David A. (Fed) <[email-masked]>; Lisa Lorenzin
> <[email-masked]>; [email-masked]
SWID
> Personally, I like the idea of supporting multiple interoperable data
bindings
> (XML, JSON, CBOR, etc.) because it provides vendors with options and they
can
> pick the one that makes the most sense for them.  However, I am not sure
how
> well this works in practice as my experience comes from an XML data model
:).
> How do WGs in the IETF typically deal with this?  Do they typically select
a single
> data binding and use that for all their data models?  Do they support
multiple
> data bindings across multiple data models, but, then pick one data binding
for
> each data model that is mandatory-to-implement?
> 
> Thanks,
> 
> Danny
> 
> 
> > From: sacm [mailto:[email-masked]] On Behalf Of Waltermire,
> > David A. (Fed)
> > Subject: Re: [sacm] A thought and three related questions regarding
> > the SWID M&A draft
> >
> > A few of us have been working together on a concise binding of SWID
> > tags using CBOR, which was just posted as
> > draft-birkholz-sacm-coswid-00. This message is very appropriate
> > considering this. There has been some concerns raised around XML and
> > its related size, both for storage and exchange. We are hoping that
> > this concise representation will address these concerns while
> > > gotten a good less in the pitfalls of having XML as the only
> > > standard binding from my work with TNC IF-MAP, and I think it's a
> > > good idea to have more options in this arena.  I'd like us to
> > > consider additional encoding options - JSON and CBOR seem like two
> > > obvious choices to me - and adding some kind of negotiation to enable
> selection among them.
> > >
> > > Three questions:
> > >
> > bindings. This solution might also address revisions in existing
> > formats and future formats as well.
> >

---

From: "Waltermire, David A. (Fed)" <[email-masked]>
Date: Fri, 25 Mar 2016 20:13:34 +0000

Jim,

I am not following your distinction between the interface serialization and a data model. I would call formats like XML, CBOR, and JSON a serialization format. In my view, a data model is a binding to a serialization format such as an XML schema, CDDL, or similar. Each of these bindings are a representation of the common SWID tag information model.

The operational model around SWID tags is to create a serialized instance of a SWID tag at build or packaging time, that is included in the installation package of the corresponding software. This serialized instance can be signed using an appropriate signature implementation for the serialization format (e.g., XMLDSig, COSE, JOSE), which is then embedded in the signed SWID tag. This means that the data model binding must provide a place in the data model for the signature. During installation the SWID is installed along with the software, replacing an existing SWID tag if the software is being updated.

In SWID Messages for PA, a SWID tag can be exchanged in full or only using the tagId from within the SWID tag. In the former case, the actual bytes of the serialized form stored on the endpoint need to be exchanged. The transport is effectively agnostic to the serialization format of these bytes. This is necessary to preserve the signed form of the SWID tag from the client to support signature validation by the validator on the server. If a different serialization is used for the transport, as compared to what is used to store the SWID tag, then signature validation would not be possible due to differing signature semantics and digest calculations.

Considering this, I wonder if an MTI is needed for the transport? Where an MTI is needed is to drive the application code on either end. The collector needs to be able to parse SWID tags found on the device to minimally detect changes in the SWID tag and to parse out the tagId. The validator needs to be able to parse the SWID tag to map the bound data model to the SWID tag information model to satisfy evaluation use cases. Perhaps this could be handled in the Endpoint Compliance Profile?

We also have a few other engineering challenges:
1)  It is possible that a given endpoint may have software A represented by a CBOR binding, and software B represented as an XML binding. SWID messages assumes a single binding format. Do we need to update it to support multiple binding formats to allow both A and B to be exchanged?
2) An installer may install a SWID tag serialized using more than one binding. Do we need a way to negotiate a preference?
3) How do we organize MTIs? By device type?

Regards,
Dave

> From: sacm [mailto:[email-masked]] On Behalf Of Jim Schaad
> Sent: Tuesday, March 22, 2016 9:03 PM
> To: 'Haynes, Dan' <[email-masked]>; [email-masked]
> serializations is a problem.  I see the serialization as being tied to a specific
> interface protocol and not to the data model.  A single data model can be
> serialized in different ways, but still be the same data model (i.e.
> interface is.  I do not know if we are talking about using the same interface
> between a hardware component that is reporting the properties that make
> up its state as opposed to between two different data stores that are
> propagating data forward or between a data store and a consumer where
> there is a large amount of query style operations that are going to be
> occurring.
> 
> That said, I believe that the serialization should be different for different
> interfaces so that having one MTI does not make sense to me.  But if you say
> that data model and serialization are part of the same thing then I would get
> very lost in trying to answer the question.
> 
> Jim
> 
> 
> > To: Waltermire, David A. (Fed) <[email-masked]>; Lisa
> > Lorenzin <[email-masked]>; [email-masked]
> > the
> > > promoting the further adoption and use of SWID tags in both
> > > traditional
> and
> > > > Subject: [sacm] A thought and three related questions regarding
> > > > the SWID M&A draft
> > > >
> > > > Hi all,
> > > >
> > > > I must admit I was a little overwhelmed by all the OVAL drafts
> > > > that were posted for the virtual interim!  Looking back at the
> > > > virtual interim notes, it looks like we agreed to focus our
> > > > reviews first on the Endpoint Compliance Profile and SWID Message
> > > > and Attributes drafts, which was a bit of a relief. :) So I've
> > > > been thinking about SWID M&A in relation to the vulnerability
> assessment scenario.
> > >
> > > Thanks.
> > >
> > > > 1) Does this seem useful?  Are there pitfalls I'm not considering
> > > > to expanding beyond one binding?
> > >
> > > This seems reasonable. Minimally, we could have both the XML and
> > > CBOR bindings. This solution might also address revisions in
> > > existing formats and future formats as well.
> > >
> > > > should be considered?  Since this is outside my primary
> > > > experience, I'd love to hear what others think should be included.
> > >
> > > Me too. :-)
> > >
> > > >
> > > > 							Regards,
> > > >
> > > > 								Lisa
> > > >
> > > >
> > > > --

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 28 Mar 2016 15:43:25 -0700

Dave,

In many cases I find that the IM, the DM and the serializations end up being
undistinguishable.  In other cases, there are some distinctions that can be
draw.  Here are some examples:

The field is defined as being in the IM as a generic integer.  This could be
defined in the DM as being a 64-bit integer.  For a serialization, this
would then be defined as any of the following:  a network order bit string,
a little-endian bit string, a base64 encoded network bit string, a hex
encoded network bit string, a base10 text string.  Depending on what you are
using for serialization, multiple of these serializations could be
permitted.

The IM says that the field is an IPv4 address.   The DM has the option of
using a string, a single 64-bit integer or an array of 4 8-bit integers.  If
masking or wild cards are included, then there may be a second field that
goes with the first defining the mask (i.e.  1.2.3.0, 255.255.255.0).  Again
the serialization could be a direct representation of the DM value or it
could be anything that the server can parse correctly into the DM version.
This could be a complex string format such as allowing "1.2.3" as being the
same as the previous value.

I need to read the SWIG document (hopefully tomorrow), but the fact that you
have a single SWIG DM that is being represented by two serializations (XML
and CBOR) but where the encoding on the wire is different, but the types of
the data is the same (i.e. the DM).

In looking at what you are talking about for MTI transports, I am not seeing
the world in the same way.  I see this as the service needs to be able to
deal with the data and it needs to have a transport it can talk to on the
other side.  However, the transport itself might not need to understand what
the form of the SWID tag is, but allows it to be transmitted as a single
blob. 

I do not know that the SWID tag DM cares about what the different
serializations are.   The exact serialized form would be part of the
providence of each field in the DM.  However, one could do queries or ask
for specific fields of the DM to be retrieved without asking for all of the
fields of the SWID.

Jim

> From: sacm [mailto:[email-masked]] On Behalf Of Waltermire, David
A.
> (Fed)
> Sent: Friday, March 25, 2016 1:14 PM
> To: Jim Schaad <[email-masked]>; 'Haynes, Dan'
<[email-masked]>;
SWID
> M&A draft
> 
> Jim,
> 
> I am not following your distinction between the interface serialization
and a
> data model. I would call formats like XML, CBOR, and JSON a serialization
> format. In my view, a data model is a binding to a serialization format
such as an
> XML schema, CDDL, or similar. Each of these bindings are a representation
of
> the common SWID tag information model.
> 
> The operational model around SWID tags is to create a serialized instance
of a
> SWID tag at build or packaging time, that is included in the installation
package
> of the corresponding software. This serialized instance can be signed
using an
> appropriate signature implementation for the serialization format (e.g.,
> XMLDSig, COSE, JOSE), which is then embedded in the signed SWID tag. This
> means that the data model binding must provide a place in the data model
for
> the signature. During installation the SWID is installed along with the
software,
> replacing an existing SWID tag if the software is being updated.
> 
> In SWID Messages for PA, a SWID tag can be exchanged in full or only using
the
> tagId from within the SWID tag. In the former case, the actual bytes of
the
> serialized form stored on the endpoint need to be exchanged. The transport
is
> effectively agnostic to the serialization format of these bytes. This is
necessary
> to preserve the signed form of the SWID tag from the client to support
signature
> validation by the validator on the server. If a different serialization is
used for
> the transport, as compared to what is used to store the SWID tag, then
> signature validation would not be possible due to differing signature
semantics
> and digest calculations.
> 
> Considering this, I wonder if an MTI is needed for the transport? Where an
MTI
> is needed is to drive the application code on either end. The collector
needs to
> be able to parse SWID tags found on the device to minimally detect changes
in
> the SWID tag and to parse out the tagId. The validator needs to be able to
parse
> the SWID tag to map the bound data model to the SWID tag information model
> to satisfy evaluation use cases. Perhaps this could be handled in the
Endpoint
> Compliance Profile?
> 1)  It is possible that a given endpoint may have software A represented
by a
> CBOR binding, and software B represented as an XML binding. SWID messages
> assumes a single binding format. Do we need to update it to support
multiple
> binding formats to allow both A and B to be exchanged?
> 2) An installer may install a SWID tag serialized using more than one
binding. Do
> we need a way to negotiate a preference?
> > To me, XML is a serialization and not a data model.  So saying that
> > you are working with multiple data models because you are working with
> > multiple serializations is a problem.  I see the serialization as
> > being tied to a specific interface protocol and not to the data model.
> > A single data model can be serialized in different ways, but still be
the same
> data model (i.e.
> > I would say that the serialization is going to be dependent on what
> > the interface is.  I do not know if we are talking about using the
> > same interface between a hardware component that is reporting the
> > properties that make up its state as opposed to between two different
> > data stores that are propagating data forward or between a data store
> > and a consumer where there is a large amount of query style operations
> > that are going to be occurring.
> >
> > preference for ASN.1.  In neither case do I find the argument of - but
> > it is human readable - to be overly compelling given the size problems
> > that can crop up from being human readable.  Additionally, I find the
> > security message functionality to be far better for CBOR than for JSON
> > or XML where size and canonicalization can be issues when dealing with
> things.
> >
> > different interfaces so that having one MTI does not make sense to me.
> > But if you say that data model and serialization are part of the same
> > thing then I would get very lost in trying to answer the question.
> >
> > Jim
> >
> >
> > > > Subject: Re: [sacm] A thought and three related questions
> > > > regarding the SWID M&A draft
> > > >
> > > > A few of us have been working together on a concise binding of
> > > > SWID tags using CBOR, which was just posted as
> > > > considering this. There has been some concerns raised around XML
> > > > and its related size, both for storage and exchange. We are hoping
> > > > that this concise representation will address these concerns while
> > > > > reviews first on the Endpoint Compliance Profile and SWID
> > > > > Message and Attributes drafts, which was a bit of a relief. :)
> > > > > addresses XML formatted messages and assumes an XML binding;
> > > > > I've gotten a good less in the pitfalls of having XML as the
> > > > > only standard binding from my work with TNC IF-MAP, and I think
> > > > > it's a good idea to have more options in this arena.  I'd like
> > > > > us to consider additional encoding options - JSON and CBOR seem
> > > > > like two obvious choices to me - and adding some kind of
> > > > > negotiation to enable
> > > selection among them.
> > > > >
> > > > > Three questions:
> > > > >
> > > > > 1) Does this seem useful?  Are there pitfalls I'm not
> > > > > considering to expanding beyond one binding?
> > > >
> > > > > 2) If we do expand to multiple encoding options, what
> > > > > mechanism(s) would be most appropriate in this usage for
> > > > > negotiation of which encoding option to use?
> > > >
> > > > > 3) Are there additional encoding options beyond JSON and CBOR
> > > > > that should be considered?  Since this is outside my primary