I'm concerned that this would be a distraction. Can we slate this for a
future version? If everyone were using certs (I've been waiting since like
1992) then my answer would be different.
--Jeff
----- Original Message -----
From:
Mark Curphey
To: Peter ;
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:]
Sent: Tuesday, April 20, 2004 2:45
PM
To:
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.
