OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

was message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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 -----
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.

 

 

 

 

 

 

 

 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]