From: Randy Turner (rturner@amalfisystems.com)
Date: Fri Aug 15 2008 - 15:40:08 EDT
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@amalfisystems.com>
> Sent by: owner-ids@pwg.org
> 08/15/08 04:02 AM
>
> To
> ids@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]
>
>
This archive was generated by hypermail 2.1.4 : Fri Aug 15 2008 - 15:40:18 EDT