ACTION-117: New KeyValue proposal

I'm writing this up as indifferent to the question of whether it's a 1.1
thing or a 2.0 thing, but I think you can treat this as a 1.1 proposal.

My sense is that the issue of how 2.0 relates to the 1.x schema and what
namespace or schema changes we'll make is very open right now, so I'm
thinking in terms of how I would handle this for addition to 1.1, much like
any new algorithms would be handled.

So, because the ds:KeyValueType content model includes a wildcard, I would
propose a new schema/namespace be developed as follows. The namespace is
obviously arbitrary. I also took the approach of copying the current
specification and defining elements for RSA and DSA, rather than a single
element delineated by a Type attribute. I can go either way on that. I did
add an Id attribute, which as I noted earlier is missing from various
KeyInfo child elements now.

My element names are chosen pursuant to the idea that the
SubjectPublicKeyInfo/DER encoding isn't an assumption but a particular
decision for the encoding of thse two key types, and that other encodings
might be better for other key types, so I just used the term "Encoded" to
represent that the key wasn't "unbundled".

-----

<schema xmlns="http://www.w3.org/2001/XMLSchema"
	xmlns:ds11="http://www.w3.org/2008/01/xmldsig#"
	version="1.1"
	targetNamespace="http://www.w3.org/2008/01/xmldsig#"
	elementFormDefault="qualified"
	attributeFormDefault="unqualified"
	blockDefault="substitution">

<complexType name="EncodedKeyValueType">
	<simpleContent>
		<extension base="base64Binary">
			<attribute name="Id" type="ID" use="optional"/>
		</extension>
	</simpleContent>
</complexType>

<element name="EncodedDSAKeyValue" type="ds11:EncodedKeyValueType"/>
<element name="EncodedRSAKeyValue" type="ds11:EncodedKeyValueType"/>

</schema>

----

The proposed text to describe the syntax would either be in a stand-alone
document, or could be inserted as sections 4.4.2.3 and 4.4.2.4 of the
current "second edition" specification. My proposal is to normatively
reference RFC 3279 for the SubjectPublicKeyInfo structure for RSA and DSA
keys included in a certificate. This is a DER encoding of the key algorithm
and the key components. It is then base-64 encoded. OpenSSL, at least,
supports both the DER and base64-encoded DER forms directly for input and
output.

Proposed text follows:

4.4.2.3 The EncodedDSAKeyValue Element

Identifier
    Type="http://www.w3.org/2008/01/xmldsig#EncodedDSAKeyValue"
    (this can be used within a RetrievalMethod or Reference element to
identify the referent's type)

The DSA algorithm and key are DER-encoded as described by section 2.3.2 of
[RFC3279], and then base64-encoded.

Schema Definition:
(see above)

DTD Definition:
TBD

4.4.2.4 The EncodedRSAKeyValue Element

Identifier
    Type="http://www.w3.org/2008/01/xmldsig#EncodedRSAKeyValue"
    (this can be used within a RetrievalMethod or Reference element to
identify the referent's type)

The RSA algorithm and key are DER-encoded as described by section 2.3.1 of
[RFC3279], and then base64-encoded.

Schema Definition:
(see above)

DTD Definition:
TBD

-- Scott

Received on Friday, 19 December 2008 19:27:38 UTC