Subject: OMA's signText: No Policy OID

From: "Anders Rundgren" <[email-masked]>
Date: Thu, 26 Feb 2004 19:53:57 +0100

"signText" which is the only on-line signature standard
there is, which has been defined by the Open Mobile Alliance
(backed by all the big guys) supports client certificate
filtering based on CA, but not on Policy OID.

I'm sorry for being such a PITA but it might be of some value
for implementers of CAs to know that multi-policy PKIs
(in contrast to having separate CAs each supporting
a single policy) indeed have some practical issues.

Current multi-policy-CA incompatibility list:
- Major off-the shelf software (IE, Outlook, IIS)
- SSL/TLS
- signText
- Most trust store management systems
- Common PKI knowledge level
- Streamlined administration support

Anders R

---

From: Stephen Kent <[email-masked]>
Date: Fri, 27 Feb 2004 12:04:01 -0500

>- Streamlined administration support

Well, it's good to know that even you characterize yourself as a PITA.

The cited examples above are, as I have come to expect, a hodge 
podge.  You may factually cite a specific, non-compliant 
implementation of a specified protocol as evidence in support of your 
notion that we don't need policy OID support, but  the last two 
bullets above merely represent your perception. The claim that 
SSL/TLS do not support policy OIDs is based on an interpretation of 
one feature of these protocols, i.e., their ability to inform a 
client of the CAs that a server is prepared to use in validating 
client certs.  However, the folks who have extensive experience with 
these protocols have made it clear that the reasons for doing this 
are historical, not an architected feature. Then there's your 
"signtext" example, which is just an instance of a vendor consortium 
suggesting something for their environment.  That has all the glitter 
of WAP!

In summary, your argument is more or less:
	- non-compliant implementations do X.
	- some vendors got together and decided to do X explicitly.
	- some protocols are silent on use of X, for historical reasons
	- thus X should be removed from IETF standards

I am not persuaded by an argument of this form.

Steve