Subject: RE: RSA: 00: draft-ietf-pkix-rsa-pkalgs-00.txt

From: "Manger, James H" <[email-masked]>
Date: Tue, 4 Mar 2003 10:11:43 +1000

> I want the PKI standards to become stable, permitting development and deployment.

draft-ietf-pkix-rsa-pkalgs-00.txt does not offer stability.  By defining new public key alg ids for 2 algorithms (RSASA-PSS signatures & RSAES-OAEP encryption) it immediately means new versions of every other existing public key alg id need to be defined so they also support the algorithm constraint concept.  A precession of new public key alg ids (for existing keys and existing algs) can hardly be called "stability".

> [can] PKI components more easily accept a new algorithm OID or a new extension definition

The question should be "can PKI components more easily accept a procession of new algorithm OIDs over an indefinite period or a new extension".

A new extension should be easier to accepted as the rules for processing unrecognised extensions are already well defined, understood & implemented.

> an impact on certification path validation logic  ..  LESS ripple impact

I am not sure what you mean.  Could you give an example?

> the algorithm OID is "fail safe."

Marking an extension as critical is just as fail safe as using a new public key alg id.  The extension approach gives certificate issuers the option to choose (on a per-certificate basis) to enforce algorithm constraints in a fail safe or more lenient manner.  This is a benefit of extensions, not a disadvantage.

Sensible security policies might be:
1* Any application or protocol must be able to support multiple algorithms (in case weaknesses are discovered in one).
2* Any particular key should only be used with one algorithm.
The policies should be independent.  However, the approach of draft-ietf-pkix-rsa-pkalgs-00.txt ties them together.  If you enforce policy 2 the only available signature algorithm would be RSASA_PSS.

RFC 3279 (published less than a year ago) would have to be completely rewritten as none of the public key alg ids that it specifies allow support algorithm constraints.

> 	----------
> 	From: 	Russ Housley [mailto:[email-masked]] 
> 	Sent:	Wednesday, 26 February 2003 6:41 AM
> 	To:	Manger, James H
> 	Cc:	[email-masked]
> 
> 	James:
> 
> 	This is a matter of crystal ball gazing as well as risk assessment.
> 
> 	I want the PKI standards to become stable, permitting development and deployment.  So, the question is whether one believes that PKI components can more easily accept a new algorithm OID or a new extension definition.  My view is that an algorithm OID is much easier.  These OIDs do not ever have an impact on certification path validation logic.  This is not true for extensions.  This observation leads me to the conclusion that the introduction of additional algorithm OIDs will have LESS ripple impact.
> 
> 	FURTHER, when the certified public key is an end-entity key, the application is impacted.  If the algorithm OID approach is used, the application may be unable to use a "constrained public key" until it is modified to understand the OID.  If the extension approach is used, then the application that is unfamiliar with the extension, assuming that it is non-critical, could ignore it.  On the other hand, a critical extension, has the same end result as a separate algorithm OID.  In my view, the algorithm OID is "fail safe."
> 
> 	Maybe there are other dimensions to the trade off discussion, but these are the two aspects that I considered before writing draft-ietf-pkix-rsa-pkalgs-00.
> 
>