Proposal on using signatures to track check-file versions

2 messages Options
Embed this post
Permalink
Charles Schmidt (MITRE)

Proposal on using signatures to track check-file versions

Reply Threaded More More options
Print post
Permalink
Hello all,

One of the discussion topics of the October 29 developer teleconference regarded concerns raised via the mailing list regarding the earlier proposal for utilizing checking-language version information in references. These and other issues were discussed and the result is an alternate proposal for accomplishing the original objectives.

Briefly, the concern was that the behavior of definitions can be changed by tweaks many references away within the OVAL language. As such, assuming that such changes in behavior are found and noted with a version change may be an unreliable assumption. The October 29 audience suggested that digital signatures/hashes of check files would be the best way to accomplish this goal. The previous developer discussion had rejected the use of hashes so the two version will need to be reconciled. I believe the developer discussion on October 7 was rejecting hashes of individual checks and the current proposal's use of file-wide hashes might be acceptable. I hope that those who voiced concerns about the use of hashes on October 7 can speak up here and let us know if those concerns still remain.

The attached proposal uses the XML Signature schema to hold digest and signature information. I should probably admit that this is the first contact I have had with this schema so if there is anyone with more experience using this standard your input and comments would be greatly appreciated.

I look forward to the community's comments on this proposal.

Thanks,
Charles


ExplicitVersioningProposal_v2.pdf (360K) Download Attachment
Travis Spann

RE: Proposal on using signatures to track check-file versions

Reply Threaded More More options
Print post
Permalink

Dear Charles
Thanks for the notes.

If any specific signature algorithms, key sizes, and hashes are going to be
delineated please ensure that they are consistent with upcoming algorithm
transitions being discussed by NIST CAVP/ CMVP.
http://csrc.nist.gov/groups/ST/key_mgmt/documents/Transitioning_CryptoAlgos_
070209.pdf

For example, there are algorithms appropriate for use today that likely no
longer be allowable in the not so distant future (end of 2010).

Sincerely,

--------------------------------
Travis Spann - President, Laboratory Director
ÆGISOLVE, INC.
1400 Railroad St.  Ste: 101
Paso Robles, CA.   93446
805.239.2043  tel
805.239.1743  fax
aegisolve.com
 
--------------------------------------Confidentiality
Notice----------------------------------------
This email and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed.
If you are not the intended recipient you are notified that disclosing,
copying, distributing or taking any action in reliance on the contents of
this information is strictly prohibited.
----------------------------------------------------------------------------
-----------------------------
 

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Schmidt,
Charles M.
Sent: Friday, November 06, 2009 10:23 AM
To: Multiple recipients of list
Subject: Proposal on using signatures to track check-file versions

Hello all,

One of the discussion topics of the October 29 developer teleconference
regarded concerns raised via the mailing list regarding the earlier proposal
for utilizing checking-language version information in references. These and
other issues were discussed and the result is an alternate proposal for
accomplishing the original objectives.

Briefly, the concern was that the behavior of definitions can be changed by
tweaks many references away within the OVAL language. As such, assuming that
such changes in behavior are found and noted with a version change may be an
unreliable assumption. The October 29 audience suggested that digital
signatures/hashes of check files would be the best way to accomplish this
goal. The previous developer discussion had rejected the use of hashes so
the two version will need to be reconciled. I believe the developer
discussion on October 7 was rejecting hashes of individual checks and the
current proposal's use of file-wide hashes might be acceptable. I hope that
those who voiced concerns about the use of hashes on October 7 can speak up
here and let us know if those concerns still remain.

The attached proposal uses the XML Signature schema to hold digest and
signature information. I should probably admit that this is the first
contact I have had with this schema so if there is anyone with more
experience using this standard your input and comments would be greatly
appreciated.

I look forward to the community's comments on this proposal.

Thanks,
Charles



__________ Information from ESET NOD32 Antivirus, version of virus signature
database 4580 (20091106) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

 

__________ Information from ESET NOD32 Antivirus, version of virus signature
database 4580 (20091106) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com
 



---------------------------------------------------------------

To unsubscribe from this mailing list, please send an e-mail to
[hidden email] with the words "unsubscribe xccdf-dev" in the
body. You will need to send this from the email account that you
used to initially subscribe to xccdf-dev.