Subject: Re: Certificate Policy Standardization

From: [email-masked] (Peter Gutmann)
Date: Sat, 6 Dec 2003 02:39:56 +1300

I wrote:

>The feeling here was that a ToS-style policy might violate (at least NZ)
>consumer protection legislation, however since a number of large
>organisations relied on these types of agreements there would probably be a
>spirited defence of them in court and/or existing case law upholding them.

I've now checked this with a lawyer to see what the story is.  Disclaimer: Not
legal advice, merely an informal chat, and since it's been filtered through a
non-lawyer (me) it's even less legally useful.  Anyway, it pretty much follows
what I said earlier: It's a grey area (meaning that few have ever tried to
challenge it so there's not much precedent), but widely used in many parts of
the world.  For example when you sign up as an Oracle development partner you
get a short paper document to sign, and that refers you to a much longer
online document that you're expected to check regularly ("say, once a month,
although no-one does").  This is probably the closest real-world analogy to
the cert policy extension and policy URL, and has presumably undergone
intensive scrutiny by lawyers working for some fairly serious players on both
sides of the equation.  The one thing you'd have to do (at least to keep a NZ
court happy) is notify users of changes, for example by sending them email to
tell them to check the online T&C (terms and conditions), although I forgot to
ask whether you could get away with a "Our T&C have changed", a "The privacy
section of our T&C has changed", or a full "These exact changes have been made
to our T&C".  So my original comments:

  So what you do is define a policy OID that points to whatever the policy is
  this week, and if you need to change anything you alter your policy, which
  customers are expected to check by downloading it from an undocumented
  location in an LDAP directory on a server in a locked filing cabinet in a
  disused lavatory in the cellar with a sign on the door saying "Beware of the
  Leopard", as explained in section 43, subsection 18, clause 4(a).13,
  paragraph 227.a of said policy.  The policy extension seems almost designed
  for this use, it has provisions for specifying an OID and a means of
  pointing to the policy of the week, which is just what you need.

  The reason why this is approach is used is that if you changed your OID when
  your policy changes, you'd have to re-issue all your certs, which no-one
  wants to do.  So you define your policy to be a mutable object, push
  responsibility for checking for changes onto the user in the standard
  manner, and you're set.

still stand, you just need to apply the appropriate amount of legal time to
get it set up in a satisfactory manner.

Peter.

---

From: Andreas Mitrakas <[email-masked]>
Date: Fri, 05 Dec 2003 15:54:29 +0100

Peter,

I reckon the underlying question is whether you want legal certainty to be
associated with the certificate or with the CA. By changing the OID to indicate a
new version of the CP, trust is vested in the certificate because the RP has a
better chance to know which terms apply to that specific cert . Else, by sticking
to one single OID for the CA policy lifetime, you assume that the CA will act
dilligently in notifying the RP of applicable changes, post the right version on
the right repository in the little disused lavatory of yours -- let alone posting
the hash of that CP possibly on a third party repository keeping someone else's
leopard busy to guard it.

By changing a policy OID when the policy changes, the issuer might choose to apply
those changes to certificates issued in the future only, which spares the CA from
re-issuing all certs all over again while linking the specific CP terms to certs
issued in the future. This approach seems to be fair for the subscriber because a
subscriber agrees on  one specific set of terms that do not necessarily have to be
unilaterally reviewed and updated during the term of service, at least for no
reason. The result in this case would be that same class certs will be issued at
different CP speeds.

A relying party might have to periodically update his signature policy to include
all new OIDs and reference the certificate polices that govern the certs he
accepts. For the small time RP there seems to be no other specific remedy than
rule nr. 1 in the RP Commandments, that reads: "thou shall always check the CP of
the certs you accept".

Having said that it appears that shifting too much responsibility to the side of
the end user who happens to also be a consumer might be tough to defend. On the
other hand notifying a large population of subscribers on changes say three times
a year might also be challenging. At the end of the day it might be plain simpler
to accept that certs of the same class might be governed by different CPs.

A possible work around to alleviate negative effects would be to determine two
sets of terms of a CP:
- those that are etched in stone and do not change unless somehting extraordinary
happens
- those that are non essential and periodic changes are permitted.

I suppose there is no easy answer to this one and both options have their merits.

andreas

---

From: "Hans Nilsson" <[email-masked]>
Date: Fri, 5 Dec 2003 15:42:09 +0100

Very funny, as usual, Peter. However, let me just spoil your joke a bit.
It's not THAT bad...

1. A well-written CP/CPS should include a description of its change process
and its  distribution. Extract from RFC 3647: 

9.12.1 Procedure for Amendment              8.1
   ------------------------------------------------------
   9.12.2 Notification Mechanism
          and Period                           8.1

So if the original CP/CPS contains your description 
>   Leopard",
Well, they better beware of the certificates in the first place....

2. You also say:

>   wants to do.  

Why re-issue?? Old certs with old policy-OID are still fine and valid, but
from now on the CA just issues new certs according to its new policy, with
new OID.

Hans Nilsson

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
On
> Behalf Of Peter Gutmann
> Sent: Friday, December 05, 2003 2:40 PM
> To: [email-masked]; [email-masked];
[email-masked]
> Subject: Re: Certificate Policy Standardization
> 
> 
> I wrote:
>