RE: Some Issues and observations with the son of 2459

[Sharon Boeyen <sharon.boeyen@xxxxxxxxxxx>]

Some views on Trevor's suggestions:
 
1) RFC 2459 chains vs son of RFC 2459 chains
Until recently I wasn't convinced this would be an issue, but have changed
my view and now agree that in some environments, this could present a 
problem. The recommendation made by Trevor seems reasonable. Just to be sure
I understand it properly, I'll rephrase. Trevor, please correct me if 
I've misinterpreted.
 
A special OID would be assigned (perhaps similar to how the 'anyPolicy' OID
was assigned). This special value, if included in the certificatePolicies
extension indicates that the certificate should be processed under the new
rules. This special OID would act as a trigger only and would not be
returned
to an application as a certificatePolicy value under which a path had
validated. We've looked at a number of alternative solutions, but the one
proposed 
by Trevor seems to have the least amount of associated problems.
 
2)  Name constraints
We're still reviewing these proposals and working through all the different
scenarios. Will send something later on this. We have determined at least 
that the current text could benefit from some more detail about processing
this extension.
 
3) EKU Policy
Seems like a perfectly reasonable strategy. No objections.
 
4) Other Policy qualifiers
No objections here either.
 

-----Original Message-----
From: Trevor Freeman [mailto:trevorf@Exchange.Microsoft.com]
Sent: Sunday, January 23, 2000 5:12 PM
To: Pkix List (E-mail)
Subject: Some Issues and observations with the son of 2459


RFC 2459 chains vs. son of RFC 2459 chains
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:

*	When a new son of 2459 client is deployed into an existing 2459 PKI
it must not break with the deployed population of certificates 

*	There must be no requirement to reissue certificates in order to
deploy the new clients.


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.
Name Constraint Processing
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 Policy
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.
Other Policy Qualifiers
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.
 
Trevor Freeman
Program Manager
Tel: 425-936-847
Pager: 800-759-8352, id#1631457
Pager email:  <mailto:1631457@skytel.com> 1631457@skytel.com