Randy,
I was going to originally be very tongue in cheek and indicate
Certification State as "possibly, maybe eventually to be defined". I
think that best indicates the current (background) thinking on what
Certification State is/will be. It is more a standardized common
criteria certification that the generic configuration change detection
mechanism of Configuration State. Could there be some overlap? Yes.
Will there be? Depends on the vendor, but I would suspect the answer
would be yes for at least a few parameters.
Joe
Hi Joe,
I think I understand "Configuration State", but to your point, I still
don't completely understand what "Certification State" is supposed to
represent. Do the parameters that are used to calculate the
"Configuration State" overlap or intersect with the parameters that are
used to calculate "Certification State", or are these parameters
disjoint? Or can the parameter sets used for Configuration State and
Certification State be identical?
Randy
On Aug 15, 2008, at 12:02 PM, Murdock, Joe wrote:
Randy,
Don't confuse the explicitly vendor specific opaque "Configuration
State" value with the to be defined "Certification State".
Configuration State is not necessarily intended to be remediated
(except, perhaps, by some vendor supplied mechanism). Certification
State may, depending on its final definition, be remediable.
Joe Murdock
Sharp Labs of America
Hi Dave,
In the proposal, I just indicated that the "value" is a hash - it's
currently 32 bytes which only allows for a 256-bit hash. If we mandate
that it should be able
to hold a SHA-512 as well, we'll have to double it's length. I think
just getting agreement for the existence of the attribute is the goal,
we can flex the size of the
field once we have consensus on the acceptance of the attribute.
I agree with your comment about which values to include in the hash, but
from a protocol perspective, the mechanisms would work pretty much the
same way.
Even though a vendor could allow customers to indicate which parameters
are included in the hash, the "management tool in the sky" would have to
know which
parameters make up the hash, on a per-device basis, in order to
potentially remediate the situation. Given this constraint, I think
vendors should supply a factory
default set of params that make up the hash, a set that makes sense in
the majority of cases, and allow customers to override this, provided
they "sync up" their
remediation infrastructure with the same info...
Randy
On Aug 15, 2008, at 10:31 AM, Dave Whitehead wrote:
Randy,
Looks good. Two comments about Configuration State:
1> We should mandate the use of a cryptographically secure hash
function (SHA256/512)
2> Vendors provide the set of available configuration items but the
customer selects which items to include in the hash -- some they care
about, some they don't.
David H. Whitehead
Development Engineer
Lexmark International, Inc.
859.825.4914
davidatlexmarkdotcom
Randy Turner <rturner at amalfisystems.com>
Sent by: owner-ids at pwg.org
08/15/08 04:02 AM
To
ids at pwg.org
cc
Subject
IDS> DRAFT: IETF NEA proposal
Hi All,
Please read the attached RTF and provide any feedback you may have...
Please excuse the VERY simple, raw formatting I'm using - this has to be
in the simplest ASCII text form possible for eventual emailing to the
NEA
mailing list.
For now, just concentrate on the content :) :)
Thanks!
Randy
[attachment "draft-nea-proposal.rtf" deleted by Dave
Whitehead/Lex/Lexmark]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.pwg.org/archives/ids/attachments/20080815/4f8257e4/attachment.html