Some Issues and observations with the son of 2459

We will have two sets of semantics under which certificates can be issued - RFC 2459, and son of RFC 2459, and two sets of rules for processing those chains. In moving forward, two objectives which we must meet are:

At the root of the problem is the clarification of what a new son of 2459 client must do if it encounters a chain which does not comply with the more restrictive son of 2459 policy rules. If that chain was issued under the new rules, it is indeed a bad chain and verification should fail. If it was build under the 2459 rules, it is a "legacy chain" which is still valid.

There must be some mechanism to indicate if a certificate was issued under son of 2459 rules. A possible solution to this would be to assign a "policy semantics version" OID which must be included in every non self signed certificate issued under the new rules in the policy extension. A single 2459 certificate in a chain potentially downgrades the chain to 2459 rules. We can continue to process policy as currently defined, but if we end up with an empty set, and one of the certificates in the chain does not contain the policy version OID, we return that verification was successful with an empty policy set. There are other possibilities for how to distinguish the certificates such as assigning a new OID to the policy extension and include both extensions in issued certificates, but at this stage, they seem more expensive so I would like to see a very strong case in there favour before I would consider them.

The current draft does not deal with the case where a certificate contains a name in an unconstrained namespace. The current wording in the draft in effect means that if a namespace has not constrained, it is allowed. I would prefer to move to a model where the CA must explicitly state which namespaces it wishes to allow, and all others are rejected.

Another problem with Name constraints is the relationships between namespaces is not considered. Many namespaces can be traced back to DNS names or IP addresses. URIs are a case in point. The host potion of a URI (e.g. the name between the second and third forward slashes) can be either a DNS name or an IP address. When a restriction on a DNS name or IP address is made, then any other form of that same address (i.e. the host address in a URI) must conform to the larger rule. The same may equally be said of email addresses.

EKU is an extension of policy. Having let the genie out of the bottle, it will take some time to get it back in. To be consistent with the new rule, I propose to make it a requirement that under son of 2459 rules, any OID in the EKU extension must also be present in the policy extension. Any certificate issued under the new rules where this rule is not met, is to be considered invalid. Application developers can now migrate to using the policy extension in stead of the EKU extension, and in time the EKU extension can be phased out. Policy in the EKU extension will be consistent with the other policy requirements. In the mean time, existing applications will not break.

There are only two defined policy qualifiers in the current draft. We have encountered two instances where other qualifiers are useful. I offer this observation, for others who may also find them useful and hence like them to them being more generally used and therefore including them in the draft.

The first is in restricting the scope of a RA by using a name constraint as a qualifier on the RA policy OID. This allows the CA to verify the RAs ability to act for the subject for any given policy.

The other case is providing some hint to relative authentication strength of a certificate. If a user has a medium and a strong authentication certificate which can both be used fro the same application e.g. client authentication, then it provides a hint which certificate to use to the client . Having a policy qualifier with a integer for the relative values allows the client to know which was issued with the stronger authentication policy without any other out of band information.