On the Need for Signing Policy URNs

• Current CA's don't mingle well
• Islands of trust should come together
• Different signing technologies should be merged
• PGP signing practice is too unpredictable for commercial applications

Requirements for Signing Policy URNs

• Must unite many signers' policies
• Must provide certainty to validating parties
• Must be standard throughout the Internet
• Must have composable parts, which are strictly additive in nature
• Must support consensus-based extensions to the policy set
• Must provide unique and readable policy modules
• Must support the use of parameters that can be filled in during signing

Policy modules

Policies are defined as separate modules that add to each other's certainties. This is intended to capture differences in policies, without the need to know more policies than required to fulfill one's validating requirements. This makes it possible to detach from newly developed policies. A few simple ground rules make this detachment possible.

First, a policy provides guarantees. Since it is assumed that a validating party has read the policy, it is allowed to provide such guarantees under the condition that certain other policy modules are added, or even that they are not added to the policy set. Such policy modules MUST be referenced by their <name> and they MAY specify constraints to the <params> in addition to that. When validators instruct their software what constraints make a signature's policy acceptable, these constraints can be specified to achieve the desired guarantees.

Second, it is never allowed for one policy module to undermine the guarantees provided by another policy module. For example, policy module A may not state that guarantee 4 from policy module B is withdrawn or rendered uncertain. If such things would be the case, then policy module B must specify this as a condition on guarantee 4.

Besides these formal constraints, a policy module can specify the guarantees provided in plain English terms. Unless the policy name <module> starts with x-, this text must be specified in an RFC through the IETF process to achieve consensus. The <module> variety with x- prefix is intended for local variations which have not been globally accepted.

The + symbol in the URN format is the composition operator on policy modules; it indicates that policy modules are combined. It is associative, commutative and idempotent. Furthermore, it is possible to rewrite lists of policy modules based on the semantics of their version numbers.

Local Policy Specifications

Two mechanisms have been defined to define local or internal policies. Such policies are supposed to be agreed upon via other means than the Internet community, and are specifically targeted at the use in a closed community. One example of a closed community is the internal network of a company, another is a group of developers working on a new signing policy.

The first system introduces a x- prefix in from of a policy module name that may be picked arbitrarily. Such names are not guaranteed to be globally unique, and they need not be registered anywhere. The version system can be applied to such names.

The second system can be used globally, but also does not require registration. What it does is take the name of a hashing algorithm as introduced in an RFC, map it to an alphanumeric lowercase string and append its outcome, an = sign and the hexadecimal representation of the outcome of that hashing algorithm.

Parameters

Problem with parameters: how to specify which parameters are acceptable?

• For strings: equality, substrings, maybe even pattern matching?
• For numbers: equality, minimum, maximum, ranges, ...
• More advanced formats? (e.g. dates and times)

TODO: How to specify all this?

Examples of Compatible Specifications

All of the following specifications all equivalent based on the above semantical observations:

urn:signpolicy:idchecked(type=passport)+twopaths
urn:signpolicy:twopaths+idchecked(type=passport)

When bound into a signature, it is furthermore equivalent to:

urn:signpolicy:twopaths+idchecked(type=passport)+idchecked(type=drivlic)
urn:signpolicy:twopaths+idchecked(type=passport)+equivid

On the other hand, when not bound into a signature but specified in policy- aware signature validating software, the first list under this subsection is also equivalent to:

urn:signpolicy:twopaths
urn:signpolicy:idchecked(type=passport)

OpenPGP

The current standard RFC 2440 defines a subpacket for a Policy URL. In the current internet draft from the IETF openpgp working group that will eventually replace RFC 2440, this has been replaced with a Policy URI, allowing usage of a Policy URN.

Note that the maximum size of a Policy URI in OpenPGP is limited: even though each signature subpacket can have sizes up to 2^32-1 bytes, the total size of all signed signature subpackets within one signature is encoded in two bytes, limiting this to 65535 bytes including header and length bytes for all signature subpackets on a signature in total. What needs to be done when Policy URIs with a lot of parameters exceed this length is an open problem.

The X.509 Profile for the Internet

The profile of X.509 for the Internet is specified in RFC 3280. This document defines support for policies with the following ASN.1 declarations:

id-pkix OBJECT IDENTIFIER ::= {
    iso(1) identified-organization(3) dod(6) internet(1)
    security(5) mechanisms(5) pkix(7) }
id-qt OBJECT IDENTIFIER ::= { id-pkix 2 }
id-qt-cps OBJECT IDENTIFIER ::= { id-qt 1 }

PolicyQualifierInfo ::= SEQUENCE {
    policyQualifierId PolicyQualifierId,
    qualifier ANY DEFINED BY policyQualifierId }

PolicyQualifierId ::= OBJECT IDENTIFIER ( id-qt-cps | id-qt-unotice )

CPSuri ::= IA5String

In other words, this profile specifies full support for URIs, and therefore for URNs, detailing policies. Do note that all this falls under id-pkix, which means that it is a dedicated property of the Internet profile of X.509. Since this specification concerns Internet-wide usable policy references, that is just the right scope.

CMS (Cryptographic Message Syntax)

Unlike OpenPGP where Policy URIs can be used both in certificate signatures and in document signatures, this is different in the X.509 world.

Documents are signed using CMS, which is defined in RFC 3852. In CMS there is no predefined place for Policy URIs, but in the SignerInfo there is a place for attributes:

SignedData ::= SEQUENCE {
    version CMSVersion,
    digestAlgorithms DigestAlgorithmIdentifiers,
    encapContentInfo EncapsulatedContentInfo,
    certificates [0] IMPLICIT CertificateSet OPTIONAL,
    crls [1] IMPLICIT RevocationInfoChoices OPTIONAL,
    signerInfos SignerInfos }

SignerInfo ::= SEQUENCE {
    version CMSVersion,
    sid SignerIdentifier,
    digestAlgorithm DigestAlgorithmIdentifier,
    signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL,
    signatureAlgorithm SignatureAlgorithmIdentifier,
    signature SignatureValue,
    unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL }

SignedAttributes ::= SET SIZE (1..MAX) OF Attribute

Attribute ::= SEQUENCE {
    attrType OBJECT IDENTIFIER,
    attrValues SET OF AttributeValue }

AttributeValue ::= ANY

Specifically the Policy URI can be implemented as a (signed) Attribute, with attrType set to OID to be specified and attrValue of type IA5String.

XML Signing and Policy Incorporation

The XML Signature Syntax and Processing set out in RFC 3275 does not explicitly support signing policies of any kind. Instead, it expects such information to be incorporated into the signed data of the <SignedInfo/> element as a reference URI, using a <Reference/> element.

TODO: Is there really no way to standardise/register a particular reference kind for the purpose of policy specification? Would it be smart to leave that to future specifications that may incorporate signing applications? Probably not...

Updates

Your feedback and improvements are welcome!

edit this page