Parsing shouldn't be a problem if we "standardize" how the value (or
values, if a multi-value attribute) are encoded.
Now the second part, the "interpretation" could be an issue. For FIPS
certifications, the hash fingerprints are a matter of public
record and a plug-in could just record the correct fingerprint values
and do a comparison.
Likewise, for any other type of certification, it would help if the
"value(s)" that are encoded are a matter of public record, preferably
in some type of registry (as is maintained by NIST and other
agencies), or some other type of publicly accessible database.
Randy
On Jun 19, 2009, at 2:16 PM, Farrell, Lee wrote:
> Hi Randy,
>> I think the concern from mike fenelon was not so much about what
> kind of
> values might be used for the certification state -- but how a
> validator
> might know how to parse and interpret it. He seemed to be concerned
> that different vendors --and different products -- would/could use
> very
> different values and encodings.
>> Of course, mike would be the right one to elaborate.
>> lee
>>> -----Original Message-----
>> From: ids-bounces at pwg.org [mailto:ids-bounces at pwg.org] On
>> Behalf Of Randy Turner
>> Sent: Thursday, June 18, 2009 5:14 PM
>> To: ids at pwg.org>> Subject: [IDS] 6/18 teleconference call minutes
>>>>>> Hi All,
>>>> I noticed in the meeting minutes from the 6/18 teleconference
>> that there was a discussion on vendor-specific attributes -
>> these are definitely handled by a vendor-specific plug-in,
>> however, in the case of the attribute
>> HCD_Certification_State, we may can draw on how the OpenSSL
>> project handles a similar value.
>>>> For FIPS 140-2 certification, a specific version of source
>> code was submitted, including instructions for how to build a
>> "FIPS" version of the codebase.
>>>> In addition, a SHA-1 fingerprint for this specific set of
>> source code is generated - source code fingerprints are
>> fairly common for security- related open source projects.
>>>> In addition, during the build process, the individual object
>> files are fingerprinted as well.
>>>> There is an additional integrity check performed at runtime.
>>>> So there is a source-level, link-time, and runtime
>> verification performed to make sure that the code that is
>> compiled, built, and run, is the exact same code that was
>> certified by the FIPS laboratory.
>>>> The runtime check is made by the code calling
>> fips_mode_set(), and the compiler/build-system must be able
>> to order the OpenSSL FIPS code always in the same order (with
>> respect to relocatable addresses), so that the runtime
>> fingerprint generated by the FIPS Lab is the same as is
>> generated each time the code runs.
>>>> The value of the FIPS fingerprint could be an example of the
>> HCD_Certification_State value.
>>>> This is a concrete example of how we might think of the
>> HCD_Certification_State attribute.
>>>> Comments?
>>>> Randy
>>>>>>>>>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2433 bytes
Desc: not available
URL: <http://www.pwg.org/pipermail/ids/attachments/20090620/ff53f973/attachment.p7s>