AD probes and item datatypes

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

AD probes and item datatypes

lutton

Hi all,

 

I’m looking for guidance on implementing items returned by the Windows Active Directory probes.  In particular, I’m not clear on how some of the attribute ADSTYPEs should be mapped to OVAL data types and sometimes, for OVAL string types, what ‘formatting’ should be used.  I’m hoping there might be some general rules you can point me to.  Here are a couple of examples where I’m uncertain:

 

Returning an ADSTYPE_INTEGER seems to map naturally enough to and OVAL integer.  My question here is whether the integer should be treated as a signed or unsigned quantity.   It turns out the ADSTYPE_INTEGER is actually defined as a DWORD, so I’m assuming that I should be treating the value to be returned as unsigned.  Is this correct?

 

The ADSTYPE_OCTET_STRING, despite having ‘string’ in its name seems to be used to hold an array of bytes.  Is it correct to map this type to and OVAL binary type (N two-byte hex tuples)?

 

It turns out that some attributes of type ADSTYPE_OCTET_STRING actually contain a SID and some attributes of type ADSTYPE_OCTET_STRING actually contain a GUID (e.g. objectSID and objectGUID).  It is tempting to special case these (as ovaldi does) and return a properly formatted SID or GUID as an OVAL string type for such an attribute.  However, the resulting item then has an adstype element with the value ADSTYPE_OCTET_STRING and a value element of OVAL string type (rather than OVAL binary type).  What is the recommended practice here?

 

Attributes of type ADSTYPE_NT_SECURITY_DESCRIPTOR are internally a byte array & length (similar to an ads octet string).   Thus it seems reasonable to return an OVAL binary value for this.  It also seems reasonable to use ConvertSecurityDescriptorToStringSecurityDescriptor and return the resulting SDDL as an OVAL string type value.

 

Some ads types are inherently structured (e.g. ADS_TIMESTAMP, ADS_PATH, AD_POSTALADDRESS, etc.) and well suited to be returned by the activedirectory57_object.  For the activedirectory_object, it might seem tempting to ‘format’ these complex types into a single ‘string’ value.  I’m concerned that such a nicety would be an interoperability problem.  What is the recommended practice here?

 

For activedirectory57 returning attributes that are structured, as in the example above, the question arises as to what field names should be used.  The structure member names in Iads.h for the complex type in question might be some guidance here.  Is there any other guidance?

 

It seems like an attribute value of type ADSTYPE_UTC_TIME should be formatted per http://www.w3.org/TR/NOTE-datetime (YYYY-MM-DDTHH:MM:SSZ).    What is the guidance here?

 

Finally, implicit in a few of the questions above is the question of whether the value of the adstype element implies anything about what the type/formatting of the value element will be.  IOW, if an item has a given adstype value, can I predict the type/formatting (and field names/types/formatting) that I will find in the value elements?

 

Thanks in advance,

Bill L.

 

 

To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email].
Reply | Threaded
Open this post in threaded view
|

Re: AD probes and item datatypes

Danny Haynes
Administrator

Hi Bill,

 

Good question.  Section 5.2.4.5.3 of spec says:

 

The datatype of the OVAL Item Entity describes how the value of the OVAL Item Entity should be interpreted. The valid datatype values for an OVAL Item Entity are listed in the oval:DatatypeEnumeration and restricted as needed in OVAL Component Models. When assigning a datatype to an OVAL Item Entity, there are two cases to consider:

 

1.      The datatype is fixed to a specific datatype value. In this case, the OVAL Item Entity MUST always use the specified datatype value.

 

2. The datatype can be one of several datatype values. In this case, the datatype value that most appropriately describes the value of the OVAL Item Entity SHOULD be used. If an OVAL Item Entity value is not present, the datatype value must be set to the default datatype value specified in corresponding OVAL Component Model.

 

With that said, in case 2, it is up to the tool vendor to decide what is the best datatype to use.

 

I have more comments below regarding your specific questions.  It would be great to hear what others think about this.


Thanks,

Danny

 

From: Bill Lutton [mailto:[hidden email]]
Sent: Sunday, December 02, 2012 12:42 PM
To: oval-developer-list OVAL Developer List/Closed Public Discussion
Subject: [OVAL-DEVELOPER-LIST] AD probes and item datatypes

 

Hi all,

 

I’m looking for guidance on implementing items returned by the Windows Active Directory probes.  In particular, I’m not clear on how some of the attribute ADSTYPEs should be mapped to OVAL data types and sometimes, for OVAL string types, what ‘formatting’ should be used.  I’m hoping there might be some general rules you can point me to.  Here are a couple of examples where I’m uncertain:

 

Returning an ADSTYPE_INTEGER seems to map naturally enough to and OVAL integer.  My question here is whether the integer should be treated as a signed or unsigned quantity.   It turns out the ADSTYPE_INTEGER is actually defined as a DWORD, so I’m assuming that I should be treating the value to be returned as unsigned.  Is this correct?

[djh]: If the ADSTYPE_INTEGER is an 32-bit unsigned value, you should represent it as that in the system-characteristics.  The OVAL integer is defined according to the W3C spec for integers and an unsigned integer would fall within its acceptable range (http://www.w3.org/TR/xmlschema-2/#integer).

The ADSTYPE_OCTET_STRING, despite having ‘string’ in its name seems to be used to hold an array of bytes.  Is it correct to map this type to and OVAL binary type (N two-byte hex tuples)?

 

It turns out that some attributes of type ADSTYPE_OCTET_STRING actually contain a SID and some attributes of type ADSTYPE_OCTET_STRING actually contain a GUID (e.g. objectSID and objectGUID).  It is tempting to special case these (as ovaldi does) and return a properly formatted SID or GUID as an OVAL string type for such an attribute.  However, the resulting item then has an adstype element with the value ADSTYPE_OCTET_STRING and a value element of OVAL string type (rather than OVAL binary type).  What is the recommended practice here?

 

[djh]: I think what inspired me here, when developing the activedirectory_test in the OVAL Interpreter a few years back, was the ldp.exe tool which would present objectSID and objectGUID in a user-friendly fashion as text rather than raw binary data.  However, this is inconsistent if you consider other ADS_OCTET_STRING values that are not SIDs or GUIDs and if not all tools do it.  As a result, representing them strictly as binary data is probably the way to go.  I don’t think we want to keep track of which binary values should be converted to some friendlier format anyways.

 

As a side note (not to justify anything), there is a get-adobject cmdlet and it appears to convert ObjectGUID values to the more human readable format (see Example 6 - http://technet.microsoft.com/en-us/library/ee617198.aspx).    

 

Attributes of type ADSTYPE_NT_SECURITY_DESCRIPTOR are internally a byte array & length (similar to an ads octet string).   Thus it seems reasonable to return an OVAL binary value for this.  It also seems reasonable to use ConvertSecurityDescriptorToStringSecurityDescriptor and return the resulting SDDL as an OVAL string type value.

 

[djh]: I think this would follow whatever we decide above.  I might also add a content authoring tool or tool displaying the results could translate the binary data to the more human-readable format.

 

Some ads types are inherently structured (e.g. ADS_TIMESTAMP, ADS_PATH, AD_POSTALADDRESS, etc.) and well suited to be returned by the activedirectory57_object.  For the activedirectory_object, it might seem tempting to ‘format’ these complex types into a single ‘string’ value.  I’m concerned that such a nicety would be an interoperability problem.  What is the recommended practice here?

 

[djh]: Examples like this are exactly why the activedirectory57_test was added which supports the use of records, however, it seems like it may not be as straightforward as we originally thought (some issues that I highlight below seem to reinforce this statement ;)).  As a result, we added a tracker to look into it more and until then we have un-deprecated the activedirectory_test (http://oval.mitre.org/language/version5.11#28903).  This is definitely something we should take care of for the 5.11 release. 

 

I think if you try to collect one of these structured datatypes with the activedirectory_test that you should report an error and suggest that the activedirectory57_test is used.  The activedirectory_test contains the following documentation:

 

Note that this test supports only simple (string based) value collection. For more complex values see the activedirectory57_test.

 

Also, I don’t think it makes sense to come up with a formatting scheme that fits all the data into a single string if we can help it.  At least not until we figure out if the activelydirectory57_test makes sense or not.

 

For activedirectory57 returning attributes that are structured, as in the example above, the question arises as to what field names should be used.  The structure member names in Iads.h for the complex type in question might be some guidance here.  Is there any other guidance?

 

[djh]: Well, I just spent some time looking into the ADS_POSTALADDRESS type (http://msdn.microsoft.com/en-us/library/windows/desktop/aa772280(v=vs.85).aspx) and it appears it is made up of six strings.  Microsoft also has a note saying that we should look to the Novell NetWare Directory Services Schema Specification Version 1.1 for more information.  In doing that, I found Novell’s eDirectory Schema Reference entry for Postal Address (http://www.novell.com/documentation/developer/ndslib/schm_enu/?page=/documentation/developer/ndslib/schm_enu/data/sdk4800.html) which states:

A value for this attribute is typically composed of selected attributes from the MHS Unformatted Postal O/R Address version 1, according to Recommendation F.401. The address is limited to 6 lines of 30 characters each, including a Postal Country Name.

Normally the information contained in such an address could include an addressee’s name, street address, city, state or province, postal code and possibly a Post Office Box number, depending on the specific requirements of the named object.

NetWare administrative utilities will link the postal address value to the following attributes: Physical Delivery Office Name, Postal Code, Postal Office Box, and Street Address.

The postal address uses the following as default values:

Line 1: The object’s RDN

Line 2: Street Address or Post Office Box Number

Line 3: (no default value)

Line 4: Physical Delivery Office Name, State or Province Name

Line 5: Postal Code

Line 6: Country Name (from the object’s DN)

The second line of the postal address will default to the post office box, if present, or otherwise to the street address. The third line of the postal address should be presented in the utility as the second line of both the post office box and street address. Each line of the postal address is limited to 30 characters. Attribute values are truncated to 30 characters when used in the postal address.

Developers are encouraged to follow these guidelines.

Please note that Novell eDirectory Services was previously known as Novell Directory Services.  We should really see if we can get our hands on that specific specification and reference that since that is what Microsoft says to do, but, I think what we have above illustrates the problem and we can use it as an example for now.  I looked quickly and was having trouble finding the exact specification Microsoft referenced.

 

Does this documentation align with what you saw in iads.h? 

 

Given the above documentation, I don’t think there is a standard name for the different fields and it is probably something that would need to be defined by the community and documented in the OVAL component specification.  For example, we could update the ADSTYPE_POSTAL_ADDRESS documentation from:

 

“The string is of the postal address type.”

 

to something along the lines of:

 

“The string is of the postal address type. When collecting a postal address, the record entity should be populated as follows. Line 1 which contains the object’s RDN must have a field name of “rdn”. Line 2 which contains the street address or po box must have a field name of “address1”. Line 3 must have a field name of “address2”.  Line 4 which contains the physical delivery office name, state, or province must have a field name of “citystateprov”.  Line 5 which contains the postal code must have a field name of “postalcode”.  Line 6 which contains the country must have a field name of “country”.  Please see the Novell Netware Directory Services Schema Specification Version 1.1 for more information.”


It also sounds like you can have the addressee name in there somewhere.  Maybe to include that, you overwrite Line 1 which contains the object’s RDN by default?  Also, I wonder if there is anything stopping you from moving the ordering of the components around (e.g. put the country on line 1) in which case the above approach would not work unless you could look at the values and determine which values correspond to which fields.  Another approach would be to just assign field names of “line1”, “line2”, etc. and leave it up to the content author to know what those fields should be on the system being evaluated.

 

It seems like an attribute value of type ADSTYPE_UTC_TIME should be formatted per http://www.w3.org/TR/NOTE-datetime (YYYY-MM-DDTHH:MM:SSZ).    What is the guidance here?

 

I think it should just be represented as a string value.  It looks like ADSTYPE_UTC_TIME represents two string formats Generalized-Time (http://msdn.microsoft.com/en-us/library/windows/desktop/ms684436(v=vs.85).asp) and UTC-Time (http://msdn.microsoft.com/en-us/library/windows/desktop/ms684456(v=vs.85).aspx).  It also looks like UTC Time does not store the first two digits of the year (http://msdn.microsoft.com/en-us/library/windows/desktop/aa772189(v=vs.85).aspx).  This documentation (http://msdn.microsoft.com/en-us/library/windows/desktop/aa705925(v=vs.85).aspx) shows you how you can print out data that is of the type ADSTYPE_UTC_TIME.

 

Finally, implicit in a few of the questions above is the question of whether the value of the adstype element implies anything about what the type/formatting of the value element will be.  IOW, if an item has a given adstype value, can I predict the type/formatting (and field names/types/formatting) that I will find in the value elements?

 

[djh]: Right now, it all depends on how the tool was implemented.  Given the questions you have raised, it is probably a good indication that we should document the types better such that content authors and tool developers know what to put there.

 

Thanks in advance,

Bill L.

 

 

To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email].

To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email].
Reply | Threaded
Open this post in threaded view
|

Re: AD probes and item datatypes

lutton

Danny, thanks for your comments… I guess nobody else is going to chime in.

 

I’ll try to summarize what I think I heard:

-Use the underlying value’s signed/unsigned nature to guide the formatting of integer values as signed or unsigned values.

-For OCTET_STRING values always use oval binary, no special case strings.

-For other ADS types that are of the style byte[] plus length values always use oval binary, no special case string formatting.

-Don’t try to be cute with returning structured types as cleverly formatted strings for AD (not AD57) items.

-For AD57 items returning structured values there is no ‘standard’ for the field names to be used.

 

Did I interpret what you said correctly?  Just for the record, I think those interpretations are perfectly reasonable.  Though there are two things that I am concerned about.

 

The first area of concern relates to breaking with OVALDI’s handling of OCTET_STRING.  If I remove the special cases of objectSID/objectGUID, I’m concerned that some existing content might ‘break’ using my tool.  Is this a valid concern?

 

My second concern relates to the AD57 field names for structured items.  If there is no standard for field names, I’m concerned that content authors have no way to know how to write AD57 states to test structured values.  Is this a valid concern?

 

Thanks in advance,

Bill L.

 

 

From: Haynes, Dan [mailto:[hidden email]]
Sent: Tuesday, December 04, 2012 2:37 PM
To: [hidden email]
Subject: Re: [OVAL-DEVELOPER-LIST] AD probes and item datatypes

 

Hi Bill,

 

Good question.  Section 5.2.4.5.3 of spec says:

 

The datatype of the OVAL Item Entity describes how the value of the OVAL Item Entity should be interpreted. The valid datatype values for an OVAL Item Entity are listed in the oval:DatatypeEnumeration and restricted as needed in OVAL Component Models. When assigning a datatype to an OVAL Item Entity, there are two cases to consider:

 

1.       The datatype is fixed to a specific datatype value. In this case, the OVAL Item Entity MUST always use the specified datatype value.

 

2. The datatype can be one of several datatype values. In this case, the datatype value that most appropriately describes the value of the OVAL Item Entity SHOULD be used. If an OVAL Item Entity value is not present, the datatype value must be set to the default datatype value specified in corresponding OVAL Component Model.

 

With that said, in case 2, it is up to the tool vendor to decide what is the best datatype to use.

 

I have more comments below regarding your specific questions.  It would be great to hear what others think about this.


Thanks,

Danny

 

From: Bill Lutton [[hidden email]]
Sent: Sunday, December 02, 2012 12:42 PM
To: oval-developer-list OVAL Developer List/Closed Public Discussion
Subject: [OVAL-DEVELOPER-LIST] AD probes and item datatypes

 

Hi all,

 

I’m looking for guidance on implementing items returned by the Windows Active Directory probes.  In particular, I’m not clear on how some of the attribute ADSTYPEs should be mapped to OVAL data types and sometimes, for OVAL string types, what ‘formatting’ should be used.  I’m hoping there might be some general rules you can point me to.  Here are a couple of examples where I’m uncertain:

 

Returning an ADSTYPE_INTEGER seems to map naturally enough to and OVAL integer.  My question here is whether the integer should be treated as a signed or unsigned quantity.   It turns out the ADSTYPE_INTEGER is actually defined as a DWORD, so I’m assuming that I should be treating the value to be returned as unsigned.  Is this correct?

[djh]: If the ADSTYPE_INTEGER is an 32-bit unsigned value, you should represent it as that in the system-characteristics.  The OVAL integer is defined according to the W3C spec for integers and an unsigned integer would fall within its acceptable range (http://www.w3.org/TR/xmlschema-2/#integer).

The ADSTYPE_OCTET_STRING, despite having ‘string’ in its name seems to be used to hold an array of bytes.  Is it correct to map this type to and OVAL binary type (N two-byte hex tuples)?

 

It turns out that some attributes of type ADSTYPE_OCTET_STRING actually contain a SID and some attributes of type ADSTYPE_OCTET_STRING actually contain a GUID (e.g. objectSID and objectGUID).  It is tempting to special case these (as ovaldi does) and return a properly formatted SID or GUID as an OVAL string type for such an attribute.  However, the resulting item then has an adstype element with the value ADSTYPE_OCTET_STRING and a value element of OVAL string type (rather than OVAL binary type).  What is the recommended practice here?

 

[djh]: I think what inspired me here, when developing the activedirectory_test in the OVAL Interpreter a few years back, was the ldp.exe tool which would present objectSID and objectGUID in a user-friendly fashion as text rather than raw binary data.  However, this is inconsistent if you consider other ADS_OCTET_STRING values that are not SIDs or GUIDs and if not all tools do it.  As a result, representing them strictly as binary data is probably the way to go.  I don’t think we want to keep track of which binary values should be converted to some friendlier format anyways.

 

As a side note (not to justify anything), there is a get-adobject cmdlet and it appears to convert ObjectGUID values to the more human readable format (see Example 6 - http://technet.microsoft.com/en-us/library/ee617198.aspx).    

 

Attributes of type ADSTYPE_NT_SECURITY_DESCRIPTOR are internally a byte array & length (similar to an ads octet string).   Thus it seems reasonable to return an OVAL binary value for this.  It also seems reasonable to use ConvertSecurityDescriptorToStringSecurityDescriptor and return the resulting SDDL as an OVAL string type value.

 

[djh]: I think this would follow whatever we decide above.  I might also add a content authoring tool or tool displaying the results could translate the binary data to the more human-readable format.

 

Some ads types are inherently structured (e.g. ADS_TIMESTAMP, ADS_PATH, AD_POSTALADDRESS, etc.) and well suited to be returned by the activedirectory57_object.  For the activedirectory_object, it might seem tempting to ‘format’ these complex types into a single ‘string’ value.  I’m concerned that such a nicety would be an interoperability problem.  What is the recommended practice here?

 

[djh]: Examples like this are exactly why the activedirectory57_test was added which supports the use of records, however, it seems like it may not be as straightforward as we originally thought (some issues that I highlight below seem to reinforce this statement ;)).  As a result, we added a tracker to look into it more and until then we have un-deprecated the activedirectory_test (http://oval.mitre.org/language/version5.11#28903).  This is definitely something we should take care of for the 5.11 release. 

 

I think if you try to collect one of these structured datatypes with the activedirectory_test that you should report an error and suggest that the activedirectory57_test is used.  The activedirectory_test contains the following documentation:

 

“Note that this test supports only simple (string based) value collection. For more complex values see the activedirectory57_test.”

 

Also, I don’t think it makes sense to come up with a formatting scheme that fits all the data into a single string if we can help it.  At least not until we figure out if the activelydirectory57_test makes sense or not.

 

For activedirectory57 returning attributes that are structured, as in the example above, the question arises as to what field names should be used.  The structure member names in Iads.h for the complex type in question might be some guidance here.  Is there any other guidance?

 

[djh]: Well, I just spent some time looking into the ADS_POSTALADDRESS type (http://msdn.microsoft.com/en-us/library/windows/desktop/aa772280(v=vs.85).aspx) and it appears it is made up of six strings.  Microsoft also has a note saying that we should look to the Novell NetWare Directory Services Schema Specification Version 1.1 for more information.  In doing that, I found Novell’s eDirectory Schema Reference entry for Postal Address (http://www.novell.com/documentation/developer/ndslib/schm_enu/?page=/documentation/developer/ndslib/schm_enu/data/sdk4800.html) which states:

A value for this attribute is typically composed of selected attributes from the MHS Unformatted Postal O/R Address version 1, according to Recommendation F.401. The address is limited to 6 lines of 30 characters each, including a Postal Country Name.

Normally the information contained in such an address could include an addressee’s name, street address, city, state or province, postal code and possibly a Post Office Box number, depending on the specific requirements of the named object.

NetWare administrative utilities will link the postal address value to the following attributes: Physical Delivery Office Name, Postal Code, Postal Office Box, and Street Address.

The postal address uses the following as default values:

Line 1: The object’s RDN

Line 2: Street Address or Post Office Box Number

Line 3: (no default value)

Line 4: Physical Delivery Office Name, State or Province Name

Line 5: Postal Code

Line 6: Country Name (from the object’s DN)

The second line of the postal address will default to the post office box, if present, or otherwise to the street address. The third line of the postal address should be presented in the utility as the second line of both the post office box and street address. Each line of the postal address is limited to 30 characters. Attribute values are truncated to 30 characters when used in the postal address.

Developers are encouraged to follow these guidelines.

Please note that Novell eDirectory Services was previously known as Novell Directory Services.  We should really see if we can get our hands on that specific specification and reference that since that is what Microsoft says to do, but, I think what we have above illustrates the problem and we can use it as an example for now.  I looked quickly and was having trouble finding the exact specification Microsoft referenced.

 

Does this documentation align with what you saw in iads.h? 

 

Given the above documentation, I don’t think there is a standard name for the different fields and it is probably something that would need to be defined by the community and documented in the OVAL component specification.  For example, we could update the ADSTYPE_POSTAL_ADDRESS documentation from:

 

“The string is of the postal address type.”

 

to something along the lines of:

 

“The string is of the postal address type. When collecting a postal address, the record entity should be populated as follows. Line 1 which contains the object’s RDN must have a field name of “rdn”. Line 2 which contains the street address or po box must have a field name of “address1”. Line 3 must have a field name of “address2”.  Line 4 which contains the physical delivery office name, state, or province must have a field name of “citystateprov”.  Line 5 which contains the postal code must have a field name of “postalcode”.  Line 6 which contains the country must have a field name of “country”.  Please see the Novell Netware Directory Services Schema Specification Version 1.1 for more information.”


It also sounds like you can have the addressee name in there somewhere.  Maybe to include that, you overwrite Line 1 which contains the object’s RDN by default?  Also, I wonder if there is anything stopping you from moving the ordering of the components around (e.g. put the country on line 1) in which case the above approach would not work unless you could look at the values and determine which values correspond to which fields.  Another approach would be to just assign field names of “line1”, “line2”, etc. and leave it up to the content author to know what those fields should be on the system being evaluated.

 

It seems like an attribute value of type ADSTYPE_UTC_TIME should be formatted per http://www.w3.org/TR/NOTE-datetime (YYYY-MM-DDTHH:MM:SSZ).    What is the guidance here?

 

I think it should just be represented as a string value.  It looks like ADSTYPE_UTC_TIME represents two string formats Generalized-Time (http://msdn.microsoft.com/en-us/library/windows/desktop/ms684436(v=vs.85).asp) and UTC-Time (http://msdn.microsoft.com/en-us/library/windows/desktop/ms684456(v=vs.85).aspx).  It also looks like UTC Time does not store the first two digits of the year (http://msdn.microsoft.com/en-us/library/windows/desktop/aa772189(v=vs.85).aspx).  This documentation (http://msdn.microsoft.com/en-us/library/windows/desktop/aa705925(v=vs.85).aspx) shows you how you can print out data that is of the type ADSTYPE_UTC_TIME.

 

Finally, implicit in a few of the questions above is the question of whether the value of the adstype element implies anything about what the type/formatting of the value element will be.  IOW, if an item has a given adstype value, can I predict the type/formatting (and field names/types/formatting) that I will find in the value elements?

 

[djh]: Right now, it all depends on how the tool was implemented.  Given the questions you have raised, it is probably a good indication that we should document the types better such that content authors and tool developers know what to put there.

 

Thanks in advance,

Bill L.

 

 

To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email].

To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email].

To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email].