[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 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. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]