Randy,
Yes, I should have used ConfigurationState as the example.
No, your interpretation of CertificationState is correct (and better
thought out than our original) and we do need some specifier for it to
work. This would be a phase 2 work item for the IDS group. However, note
that this *could* be a CertificationState if so defined.
In the example I was just trying to point out the usefulness of these
elements and why I think they should remain the specification. They can
provide a level of remote attestation that, I think, would be useful.
dhw
David H. Whitehead
Development Engineer
Lexmark International, Inc.
859.825.4914
davidatlexmarkdotcom
Randy Turner <rturner at amalfisystems.com>
Sent by: ids-bounces at pwg.org
06/23/09 07:17 PM
To
ids at pwg.org
cc
Subject
Re: [IDS] CertificationState and remote attestation
Hi Dave,
I always thought "certification state" was some value that was
"approved" by some 3rd party certification organization.
And I thought "configuration state" might be something akin to what
you have derived below.
"Certification State" was something similar to what I included in a
previous email regarding FIPS certification. For "products" that are
certified, the certification is for a particular model number and
software version. If you're just certifying a software module (like
openssl), then you would provide the cert lab with a version and
either source or binary module, pre-configured to execute the cert
tests.
That's why I stressed that any "validation module" that wants to
verify the HCD_configuration_state needs to know "WHICH" certification
that this value reflects, and WHAT the correct value should be. For a
FIPS certification, this would be "FIPS 140-2" and "FF02CH001F00" (a
sample hash/fingerprint)
Example certifications might be:
Common Criteria (possibly multiple certifications)
FIPS
ICSA (for firewall/security appliances)
"Works with Vista" or any of the half-dozen Microsoft logo certs you
can test against
My interpretations of these HCD_configuration and HCD_certification
states are based on what I think are the original rationale (going way
back) for these values...
Based on my understanding of "certification state", we would need to
support "one or more" certification states, depending upon how many
different types of certifications
are maintained by the device.
If my interpretation of the rationale for certification and
configuration states differs from the group, I'm sure someone will let
me know :)
Randy
On Jun 23, 2009, at 8:39 AM, Dave Whitehead wrote:
>> So, would something like the following be of use?
>>> Device with device certificate and key pair. (Same for SHV)
>> Device also has certificate of SHV. (and vise versa)
>> CertificationState = Hash(all required HCD attributes)
>> CertificationStatement = CurrentDataTime + CertificationState
>> CertificationIntegrity = Sign(CertificationStatement, Device[PrivKey])
>> HCD_CertificationState = Encrypt(CertificationIntegrity, SHV[PubKey])
>>> Just wondering ...
>> dhw
>> David H. Whitehead
> Development Engineer
> Lexmark International, Inc.
> 859.825.4914
> davidatlexmarkdotcom
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean. _______________________________________________
> ids mailing list
>ids at pwg.org>https://www.pwg.org/mailman/listinfo/ids
_______________________________________________
ids mailing list
ids at pwg.orghttps://www.pwg.org/mailman/listinfo/ids
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ids/attachments/20090624/cbd48117/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/octet-stream
Size: 2433 bytes
Desc: not available
URL: <http://www.pwg.org/pipermail/ids/attachments/20090624/cbd48117/attachment.obj>