NIST.IR.8060 GEN-15 requires @version for File

[adelton]

The requirement is "include value if on exists for the file" but swidval reports

ERROR GEN-15-2: The <File> element with the @name 'alias' has a blank @version attribute value.

if the attribute is not used or is set to empty string so it is not easy to silence it with empty string.
Since there is no reasonable version value and the type is xs:string, using 'none'.

[strongX509]

Hi Jan, NIST.IR.8060 explicitly says: "include value if on exists for the file" so I'm not ready to use a default value of type 'none'. The linux-image and linux-header packages comprise several thousands files, so I don't want any default version strings to be included. Best regards Andreas

On 10.07.2018 16:42, Jan Pazdziora wrote: The requirement is "include value if on exists for the file" but swidval reports |ERROR GEN-15-2: The <File> element with the @name 'alias' has a blank @Version attribute value. | if the attribute is not used or is set to empty string so it is not easy to silence it with empty string. Since there is no reasonable version value and the type is |xs:string|, using 'none'.

====================================================================== Andreas Steffen andreas.steffen@strongswan.org strongSwan - the Open Source VPN Solution! www.strongswan.org Institute for Networked Solutions HSR University of Applied Sciences Rapperswil CH-8640 Rapperswil (Switzerland) ===========================================================[INS-HSR]==

[adelton]

NIST.IR.8060 explicitly says: "include value if on exists for the file" so I'm not ready to use a default value of type 'none'. The linux-image and linux-header packages comprise several thousands files, so I don't want any default version strings to be included.

Undestood. What is you opinion about NIST's swidval's behaviour when it produces GEN-15-* errors unconditionally, without really taking into account the "if one exists for the file", while not allowing us to specify empty attribute value to show that we know that the attribute should be specified but no value for the file exists? Would something different than the string none be acceptable for swid_generator?

[adelton]

Let me now propose approach with command line parameter --default-file-version which allows the user to specify the value in runtime while not changing the default output -> f8615fe.

[tobiasbrunner]

I think the GEN-15-2 check in SWIDVal is wrong. If you have a look at requirements.xml in swidval-0.5.0.jar you see the two relevant derived-requirements, which in readable form look like this:

<derived-requirements>
  <derived-requirement id="GEN-15-1" type="MUST" conditional="true">
    <statement>
      Every <File> element provided within a <Payload> or <Evidence> element MUST provide a @version attribute.
    </statement>
    <message>
      The <File> element with the @name ''{0}'' does not provide a @version attribute
    </message>
  </derived-requirement>
  <derived-requirement id="GEN-15-2" type="MUST">
    <statement>
      If a <File> element provided within a <Payload> or <Evidence> element includes a @version attribute, this attribute must be non-blank.
    </statement>
    <message>
      The <File> element with the @name ''{0}'' has a blank @version attribute value.
    </message>
  </derived-requirement>
</derived-requirements>

GEN-15-1 is marked conditional, which I guess means it doesn't apply if the version attribute is absent (since you don't get an error for this that seems to work fine - although the requirement is kinda useless this way - then again, I don't really know how this verification is implemented). However, that's not the case for GEN-15-2, although its statement clearly says it only applies if there actually is a version attribute i.e. if one is there it MUST not be empty, but there is no restriction if the attribute is omitted (this seems to agree with the "if one exists for the file" part in NIST.IR.8060).

So to me it seems that second requirement is too restrictive, it should just not apply if the attribute is not there (not sure if simply adding conditional="true" would fix that). By the way, there are other requirements with the same construct (COR-2-1/2, PRI-2-1/2, PRI-4-1/2) where also only the first derived-requirement is marked conditional.

[adelton]

Thank you for the analysis. Have you guys talked to NIST about it or should we try to bring it up?

[tobiasbrunner]

We currently have no plans to contact NIST about this. Thanks.