----- Original Message -----
Sent: Sunday,
April 25, 2004 8:26 PM
Subject: RE:
[was] digital signing of vuln documents
I think this would
be excellent and allow companies to build more granular trust models of data
updates and distribution.
From: Peter
[mailto:peter@fortifysoftware.com]
Sent: Tuesday, April 20, 2004 2:45
PM
To: was@lists.oasis-open.org
Subject: [was] digital signing of vuln
documents
Summary:
The digital signing
of vuln documents was shortly discussed at the face to face meeting last
month. He is an proposal to continue this discussion. It describes how to
add signing as an optional feature of WAS specification without greatly
increasing complexity.
There is a need for
signing at both document root level and sub-tree level.
E.g. the creating
entity, company "A" may want to sign the whole document that describes a new
vulnerability. A different entity, company "B" that may be auditing
information within the vuln description may want to sign a portion of the
document represented by a sub-tree.
Using traditional
PKI infrastructure, the entities exchanging vulnerability database can check
the credentials of the signees and thus use the appropriate level of trust
when dealing with vulnerability databases, whether they are public and
downloadable by anyone or their distribution is limited to a group of
companies or a company and its security contractor.
While there are
several alternatives to vulnerability document signing, the one described
here is simple, convenient and proven in practice: it's the approach taken
by the SAML specification. It uses xmlsig OASIS
specification.
This is xmlsig in
SAML:
<?xml
version="1.0" encoding="UTF-8"?>
<schema
targetNamespace="urn:oasis:names:tc:SAML:1.0:assertion"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion"
xmlns="http://www.w3.org/2001/XMLSchema" elementFormDefault="unqualified"
attributeFormDefault="unqualified" version="1.1">
<import namespace="http://www.w3.org/2000/09/xmldsig#"
schemaLocation="http://www.w3.org/TR/xmldsig-core/xmldsig-core-schema.xsd"/>
...
...
<complexType name="AssertionType">
<sequence>
<element ref="saml:Conditions" minOccurs="0"/>
<element ref="saml:Advice" minOccurs="0"/>
<choice maxOccurs="unbounded">
<element ref="saml:Statement"/>
<element ref="saml:SubjectStatement"/>
<element ref="saml:AuthenticationStatement"/>
<element ref="saml:AuthorizationDecisionStatement"/>
<element ref="saml:AttributeStatement"/>
</choice>
<element ref="ds:Signature" minOccurs="0"/>
</sequence>
<attribute name="MajorVersion" type="integer"
use="required"/>
<attribute name="MinorVersion" type="integer"
use="required"/>
<attribute name="AssertionID" type="ID"
use="required"/>
<attribute name="Issuer" type="string"
use="required"/>
<attribute name="IssueInstant" type="dateTime"
use="required"/>
</complexType>
Proposed xmlsig in
was-core:
<?xml
version="1.0" encoding="UTF-8"?>
<xsd:schema
targetNamespace="http://www.oasis.org/was"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns="http://www.oasis.org/was"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#" elementFormDefault="qualified"
attributeFormDefault="unqualified" version="1.0"
id="WAS">
<import namespace="http://www.w3.org/2000/09/xmldsig#"
schemaLocation="http://www.w3.org/TR/xmldsig-core/xmldsig-core-schema.xsd"/>
...
...
<xsd:complexType name="metaData">
<xsd:complexContent>
<xsd:restriction base="xsd:anyType">
<xsd:sequence>
<xsd:element name="ID" type="ID">
...
...
<element ref="ds:Signature" minOccurs="0"/>
</xsd:sequence>
</xsd:restriction>
</xsd:complexContent>
</xsd:complexType>
This will provide a
means for optional signature (ds:Signature element)
A similar approach
can be used to sign other parts of the document, such as history entries
added by different entities.
This would require
moving the history element out the of the metaData
element.