scap 1.3 certification vs datastream signature verification
52 views
Skip to first unread message
Matej Tyc
Feb 4, 2021, 10:21:17 AM2/4/21
to scap...@list.nist.gov
Hello everybody,
we are contemplating support for the SCAP 1.3 standard, and the
requirement No. 900 (The product SHALL be able to validate digitally
signed SCAP source data streams and MAY reject source content that has
an invalid signature.) caught our attention.
It is quite easy to look at a signed datastream, look up the embedded
public key or certificate, and verify that the signature matches.
However, in order for the signature to be relevant, public keys or
certificate authorities should be somehow authorized. If that's not the
case, anybody could take a signed datastream, alter it, sign the it
using their own keys, and replace the old signature with the new one. At
the end, there would still be a signed datastream.
The SCAP 1.3 Validation Program Test Requirements document doesn't
specify anything in that regard. However, the TMSAD specification points
this question of trust out in section 1 and section 6.2.2.
So I have following two questions:
1. Is there any implied certification requirement regarding handling
trustworthiness of keys and certificates?
2. How is the scanner supposed to collect public keys and certificates?
The simplest case would be that they are embedded in the datastream,
under the KeyInfo element, but that doesn't have to be the case, KeyInfo
can point to other key locations. Is the scanner supposed to handle that
as well?
Cheers,
Matej Tyc
we are contemplating support for the SCAP 1.3 standard, and the
requirement No. 900 (The product SHALL be able to validate digitally
signed SCAP source data streams and MAY reject source content that has
an invalid signature.) caught our attention.
It is quite easy to look at a signed datastream, look up the embedded
public key or certificate, and verify that the signature matches.
However, in order for the signature to be relevant, public keys or
certificate authorities should be somehow authorized. If that's not the
case, anybody could take a signed datastream, alter it, sign the it
using their own keys, and replace the old signature with the new one. At
the end, there would still be a signed datastream.
The SCAP 1.3 Validation Program Test Requirements document doesn't
specify anything in that regard. However, the TMSAD specification points
this question of trust out in section 1 and section 6.2.2.
So I have following two questions:
1. Is there any implied certification requirement regarding handling
trustworthiness of keys and certificates?
2. How is the scanner supposed to collect public keys and certificates?
The simplest case would be that they are embedded in the datastream,
under the KeyInfo element, but that doesn't have to be the case, KeyInfo
can point to other key locations. Is the scanner supposed to handle that
as well?
Cheers,
Matej Tyc
David Solin
Feb 5, 2021, 11:38:05 AM2/5/21
to Matej Tyc, scap...@list.nist.gov
Hi Matej,
Joval has already undergone SCAP 1.3 certification, so it may be helpful if I comment on our experience/approach.
Joval has the ability to read X.509 certificates that are embedded in XML digital signatures. It also has the ability for users to provide a certificate key store, where it can look up named certificates to retrieve public keys. The KeyStore must also contain the public keys for root certificates appearing in certificate chains, or else validation will fail. In practice, the validation content all embeds the certificates in the XML.
The question of whether or not an end-user actually wants to trust a particular signer is… left as an exercise for them to solve. Our contract as a validated module, we believe, is only to insure that the XML wasn’t tampered with since being signed, which happens to also be all that is explicitly required by the certification program.
Best regards,
—David Solin
> --
> To post to this group, send email to scap...@list.nist.gov
> To unsubscribe from this group, send email to scap-dev+u...@list.nist.gov
> Visit this group at https://list.nist.gov/scap-dev
> --- To unsubscribe from this group and stop receiving emails from it, send an email to scap-dev+u...@list.nist.gov.
>
Joval has already undergone SCAP 1.3 certification, so it may be helpful if I comment on our experience/approach.
Joval has the ability to read X.509 certificates that are embedded in XML digital signatures. It also has the ability for users to provide a certificate key store, where it can look up named certificates to retrieve public keys. The KeyStore must also contain the public keys for root certificates appearing in certificate chains, or else validation will fail. In practice, the validation content all embeds the certificates in the XML.
The question of whether or not an end-user actually wants to trust a particular signer is… left as an exercise for them to solve. Our contract as a validated module, we believe, is only to insure that the XML wasn’t tampered with since being signed, which happens to also be all that is explicitly required by the certification program.
Best regards,
—David Solin
> To post to this group, send email to scap...@list.nist.gov
> To unsubscribe from this group, send email to scap-dev+u...@list.nist.gov
> Visit this group at https://list.nist.gov/scap-dev
> --- To unsubscribe from this group and stop receiving emails from it, send an email to scap-dev+u...@list.nist.gov.
>
David Solin
Apr 27, 2021, 10:19:58 AM4/27/21
to Michael Epley, Matej Tyc, scap...@list.nist.gov
Signing is optional, but having the ability to validate the signature of a signed XML datastream is a requirement.
On Apr 27, 2021, at 9:13 AM, Michael Epley <mep...@redhat.com> wrote:Hi David,I am evaluating the requirements for signing SCAP 1.3 content. I wanted to see if you (or anyone) can clarify your remarks here -- in particular what exactly is "explicitly required by the certification program"; my read of the spec indicates that signing is an optional requirement (section 3.11 -- "May") and even validation is only a recommended (sec. 4.2 -- "Should") requirement.Thanks!Michael Epley
Chief Architect and Security Strategist, Public Sector
571.218.5151 (mobile) | mep...@redhat.com | michae...@gmail.com
Reply all
Reply to author
Forward
0 new messages