Sure, but then watch what happens to all the tools that have to parse and
use this stuff. I just don't see the value for the complexity right
now.
----- Original Message -----
From:
Mark Curphey
To: Jeff Williams ; Peter ;
Sent: Sunday, April 25, 2004 11:13
PM
Subject: RE: [was] digital signing of
vuln documents
Is there really any
more work? Don’t we just direct people to sign an element or a group of
elements and that it, point them to the xmlsig standard ?
From: Jeff
Williams [mailto:]
Sent: Sunday, April 25, 2004 11:06
PM
To: Mark Curphey; Peter;
Subject: Re: [was] digital signing of
vuln documents
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.
