On 12/1/09 22:20, Paul Hoffman wrote:
At 10:07 PM +0100 1/12/09, Ian G wrote:
  *  RFC5280 is an implementation document and doesn't do
     semantics much, if at all.
  *  It does not define the meaning of expiry or revocation.
  *  By _meaning_, I mean semantics, what outsiders should take
     as the message being delivered, implying some hint as to
     action.

So far, you are zero for three. RFC 5280 does indeed say what semantics a 
relying party should use with respect to things like revocation and expiration. 
(You did get as far as section 6, didn't you?)


OK, so I'm wrong. I'd invite you and anyone to read section 6 in RFC 5280 and to point out, in its words, what a relying party is supposed to do when expiry and revocation is detected? Some notes:

   * With special emphasis on the differences....
   * it has to mean something to an end-user.

If you can find it, then I'll accept that I'm wrong, but even then:

   * let's see these semantics?
   * RFC5280 is murky beyond belief,
   * cannot be relied upon for end-user semantics,
   * RFC3647 clearly puts it in the CPS

That's a tough barrier to climb.

I believe I've made my case, in that

   1. expiration means approx the same thing as revocation,
   2. if you want to define it differently, do it in the CPS,
   3. but it is pointless and distracting to do that,
   4. nobody else will likely support your difference.

iang









================for completeness:
  *  RFC5280 does suggest that they work together.

I have no idea what this means.


Revocation works together with expiry, in some sense. In terms of semantic signals to the users, their functions are highly linked, so we can assume that the meanings are close if not exact.


  *  (I conclude that) RFC5280 suggests that:

         *revocation and out-of-validation have the same meaning*.

Revocation is an action taken by a CA. Expiration happens when time elapses. 
Notice how different those are.


I don't care what the action is that causes this meaning, I care what the meaning is.

A flashing orange light on the right hand side of a car, and a right hand extended out the window, both have the same semantics:

   "car about to turn right"

(leaving aside some complications for the steering wheel side.)

Or another example, more about actors and meanings. Alice shoots Bob. Bob falls under a train. These are different actions, same results. Bob is dead, we are unhappy, and no more contracts in Bob's name.




I'm skipping the rest because it is clear we read the same base document 
completely differently.

We're obviously reading at crosspurposes. What RFC5280 says is how to get a reason code. Versus check expiry. Where does it go beyond that? With your hint, here we go. Sentence by sentence:

=====================================
"6.  Certification Path Validation

   Certification path validation procedures for the Internet PKI are
   based on the algorithm supplied in [X.509].
(*implementation*)

   Certification path
   processing verifies the binding between the subject distinguished
   name and/or subject alternative name and subject public key.
(*relevant to question* but unclear semantics.)

   The
   binding is limited by constraints that are specified in the
   certificates that comprise the path and inputs that are specified by
   the relying party.
(*refers to something else*, "constraints")

   The basic constraints and policy constraints
   extensions allow the certification path processing logic to automate
   the decision making process.
(*implementation*)

   This section describes
(entire para is *implementation*)...

   The selection of a trust anchor...
(interesting, admits policy)

OK, skipping ahead because we've already lost all the others:

"   Therefore, the algorithm only includes checks to verify that the
   certification path is valid according to X.509 and does not include
   checks to verify that the certificates and CRLs conform to this
   profile.
(this is an *implementation*)

"   The primary goal of path validation is to verify the binding between
   a subject distinguished name or a subject alternative name and
   subject public key, as represented in the target certificate, based
   on the public key of the trust anchor.
(ok, interesting, but silent on semantics of invalid binding.)

"   If check (a), (k), (l), (n), or (o) fails, the procedure terminates,
   returning a failure indication and an appropriate reason.
(*implementation*)
_______________________________________________
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Reply via email to