Subject: RE: OMA's signText: No Policy OID

From: "Al Arsenault" <[email-masked]>
Date: Mon, 1 Mar 2004 07:59:51 -0500

Actually, Steve's more correct than he may realize. :-)

The WAP Forum got merged into the Open Mobile Alliance about a year ago.
The "signText" work was done by WAP, in something like 1999/2000, and has
just been carried forward since then. OMA seems to me to mostly have been
about DRM rather than security in the last year.

Bearing in mind that the whole WAP agenda was to develop a "wireless web"
for small phones and small networks that couldn't handle the Internet-style
overhead (for instance, TCP/TLS were far too heavyweight), the goal was to
develop a PKI profile that provided some semblance of security while being
small in terms of processing required and even smaller in bits transmitted
across the network and especially in roundtrips.

So given that requirement, and the timeframe in which it was designed, it's
no wonder that signText doesn't have any of the policy or other baggage.

Thus, I don't think it's a relevant example to bring before PKIX.

(Please don't make me go back and re-hash the WAP years any more than this.
It's just too, too painful.  :-)

			Al Arsenault

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Stephen Kent
> Sent: Friday, February 27, 2004 12:04 PM
> To: Anders Rundgren
> Cc: [email-masked]
> Subject: Re: OMA's signText: No Policy OID
>
>
>
> At 19:53 +0100 2/26/04, Anders Rundgren wrote:
> >"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
>
> 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

---

From: "Anders Rundgren" <[email-masked]>
Date: Mon, 1 Mar 2004 14:41:49 +0100

>It's just too, too painful.  :-)

You are right about WAP.  "signText" is really not that great.
OTOH, it is the *only* on-line signature standard that the
entire PKI community, including governments, vendors, and
standards organizations has been able to come up with to date
in spite of eons of time spent on discussing "digital signatures"
in various contexts.  That gives sort of another dimension to
your statement about being "painful" :-)

You are probably less right on the issue whether it is really
a major advantage by having a single CA supporting multiple
policies compared to having a separate trust anchor for
each implicit or explicit policy.  That is, if you take the
*whole* trust network in consideration and not only the CA.

The mere existence of QCStatements and Warranty Extensions
IMHO indicates that the PKIX policy framework is unsuitable
even for dealing with a SINGLE policy.  These PKIX-defined
items actually create a 3-dimensional(!) trust setting system.

But if the "market" is prepared to forever be dependent
on fairly pricey consultants, this is indeed the way to go.

Anders