On Oct 17, 2006, at 11:22 AM, Eliot Lear wrote:
I would think that five or six values are appropriate:
1. Vendor name (string)
2. Vendor engine version (integer)
3. Vendor virus definitions version (integer)
4. Enabled? (binary)
5. Buggered? (binary)
6. Other gobbledigook the vendor wants to include that might get
standardized later. (blob)
This still seems like too much. Information offered for access can
be contained within one or more certificates. The information
within these certificates should be limited to a minimal set of values:
1) creator
2) class
3) user-host
4) time-stamp
5) update resources
The essential information would be the creator/class/user-host/time-
stamp fields. When protection is not enabled or is buggered, then a
newer certificate should not be offered. The virus definitions or
patch updates can be deduced from the time-stamp or by extensions
added to class, i.e. AVX-VISTA-37. If a vulnerability is reported
subsequent to the time-stamp regarding the creator/class of service,
then a new certificate could be required. This would simplify
tracking at the access point. By keeping the information exchanged
and decisions limited to this minimal information, NEA should provide
a valuable services in many environments.
Perhaps there should be some consideration given regarding which sets
of certificates are offered in various environments. Allowing the
certificates to be accessed beyond an authentication process seems to
increase security exposures. As this information is not trustworthy,
there would be also little gained sharing this information
elsewhere. In fact, sharing this information may increase infection
rates when this aids malware.
-Doug
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf