Subject: Application processing of NR indictators

From: "Bob Jueneman" <[email-masked]>
Date: Fri, 13 Aug 1999 12:42:17 -0600

Larry Leyton referred to some discussion of what an application should do 
when it encountered a NR certificate.  However, as I recall that discussion
took place on the cert-talk list, so it might be worth summarising
here.

Since I responded to Hans Neilson on the same subject, I hope he won't mind my
posting his observation and my response to the list:

>>> Hans Nilsson <[email-masked]> 08/13/99 02:27AM >>>
Bob,

A short response to your long posting:

In the EESSI project we discussed, and Denis Pinkas convinced us, that "type
of commitment" indicated by the signature is something that should be
encoded into the "electronic signature token", i.e. in the CMS (or whatever
encoding that is used) structure of the signed message, together with a
reference to a Signing Policy. Today, I may use my NR key to sign an
electronic contract, tomorrow I may use it to send you something "FYI",
without feeling bound to it.

Hans

Hans,

Thanks for your note. I agree with you, but only partially.

I agree that some "type of commitment" indication is needed in CMS.
I think that X9 was going down the same path with some kind of a "purpose"
indicator, but I'm not sure that ever went anywhere.

The concern I have about using only one indicator is that it isn't as fail 
safe as my friends in the legal community seem to feel is required.
At least, when I have proposed using a single indicator, that didn't seem
to satisfy them that sufficient consumer protection had been provided.

From my perspective, certificates are cheap (and if they aren't, once the
basic due diligence has been done, you ought to find another CA).  I therefore
don't see any particular need to use the same certificate for both casual, FYI
correspondence as for a contract, and in fact think that would be quite
undesirable.

If I can show that I invariably use one NR certificate (corresponding to my 
fancy fountain pen) for contracts, and consistently use another, lighter-weight
DS only certificate (my "Bic" ball-point pen) for casual purposes, including 
authenticated FYI correspondence, then I believe that is a lot safer.

So I might use a software-based encryption private key, encrypted in my not
terribly secure password, for my casual messages, and then pull out my 
"Danger! Danger!" red-flag, binding legal commitment smart card for the 
serious stuff.

In other words, the NR bit in the certificate should be required to ENABLE the 
NR bit in the message. If the two don't match, the signature might very well still 
be binding, but it would presumably be harder to prove intent, and from 
the standpoint of protecting the user against misattribution, that is exactly what I
want to ensure.

The two bits might serve some other purposes as well.  The NR bit in the 
certificate could be used as a signal to the relying party software that the certificate 
chain should be appropriately timestamped and archived along with the CRL or 
OCSP response, for example.

And turning on the NR bit in the CMS header would require invoking a more 
ceremonial, "Are you really, really sure that you want to be legally bound by this?" 
type of message within the application.

Although traditionally the IETF doesn't get into the API business, much less the 
look and feel of an application, this particular issue is so important for business 
uses of PKI that I don't think we have a choice.  Describing what we want to 
have happen in the semantics of these bits is the only way we can achieve the 
desired result.

BTW, allow me to once again express my considerable scepticism regarding the 
efficacy of Signing Policies, policy OIDs, and policy constraints in general.  I don't 
believe they are workable, except perhaps in a small, closed community.

To date, I haven't seen any application software implement any of these constraints, 
and with the expected proliferation of CA policies, I can't imagine how a vendor
could possibly keep up with all of the different flavors that might be defined.

The CA may be able to define some of these policies in their contract, although 
in the case of "click-wrapped" subscriber agreements I have considerable doubts 
as to whether such an agreement is enforceable even against the subscriber, much 
less the relying party.

But I really, really doubt that the CAs are going to be able to convince the various 
vendors that they should code their application packages in such a was as to 
enforce a particular policy.  To put it more personally, as the security architect 
responsible for defining the technical requirements for Novell software in this area, 
I certainly haven't been convinced that there is a sufficient business case to 
justify doing this, even if I could decide what should be done.

That's why I think we need a standard, instead of relying on CA's CSPs in 
this area.  Otherwise, it won't go anywhere.

Bob