Subject: Reason codes vs Reason flags

From: [email-masked]
Date: Tue, 12 Jan 1999 10:37:25 -0500

The reason code field in a CRL encodes the reason for a revocation as an
enumerated type;  the CMP revocation request field encodes it as a bitstring.

What should a CA do if it receives a CMP revocation request with more than one
reason bit set?  Should it somehow prioritize the reasons, and put only the
"most important reason" into the CRL?  Should it put multiple revocation entries
in the CRL, one for each requested reason?  Should it reject the request as
mal-formed?  Should CMP use CRLReason instead of ReasonFlags?

John

---

From: Juergen Walter <[email-masked]>
Date: Wed, 13 Jan 1999 14:02:27 +0100

John,

I think, that reasonFlags should be used for the purpose of encoding
revocationReasons for more than one CertTemplate. Therefore, the setting
of more than one flag may be appropriate (see CRL profile in PKIX part
1). The current CMP draft has mapped one CertTemplate to one
reasonFlags. In addition, ReasonCodes are contained in the optional
Extensions.

My suggestion:

  RevReqContent ::= SEQUENCE {

      revocationReason    ReasonFlags      OPTIONAL, 
      -- the reason that revocation is requested
      revReqDetails SEQUENCE OF RevDetails }

  RevDetails ::= SEQUENCE { 
      certDetails         CertTemplate, 
      -- allows requester to specify as much as they can about 
      -- the cert. for which revocation is requested 
      -- (e.g., for cases in which serialNumber is not available)
      badSinceDate        GeneralizedTime  OPTIONAL, 
      -- indicates best knowledge of sender 
      crlEntryDetails     Extensions       OPTIONAL
      -- requested crlEntryExtensions 
  }
 
So, the requester may send more than one CertTemplate. For each
CertTemplate the requester may give a revocation reason in the
crlEntryDetails structure. Then ReasonFlags may be set in the following
way:

 Flag A is set if and only if there exists a CertTemplate that is
requested to be revoked due to reason A.
 
This may be done independently of reason codes optionally contained in
crlEntryDetails. But I would prefer the following usage:
If the revocation request contains more than one certificate templates
and the corresponding revocation reasons are different, then reason
codes (housed in the crlEntryDetails field) must be used. Optionally,
reason flags may be set as above described. But if the revocation
request contains only one certificate then the reason flag and/or the
reason code may be encoded. Otherwise, if the revocation request
contains more than one certificate templates and the corresponding
revocation reason is in each case the same, then the appropriate flag of
reason flag may be set. 

Futhermore, if there are any ambiguities with respect to revocation
reasons, then the CA has to issue a CRL, where the worst case reason
encoded in the request is referenced.

---

From: Al Arsenault <[email-masked]>
Date: Wed, 13 Jan 1999 10:21:27 -0500

Juergen,

        Whoa!  While I appreciate your approach, I think it makes things way
more complicated than they need to be.  Why, for example, should my software
have to deal with a single reasonFlags and multiple certTemplates, when I'll
just have to go in and parse each certificate to see what reason it was revoked
for, anyway?  It doesn't seem to be any benefit to me to know that "of the
following six certificates, one or more was revoked for keyCompromise, one or
more for affiliationChanged, one or more for superseded, and one or more for
certificateHold".  I'm going to have to look at each individual certificate to
see why it specifically should be revoked, so the extra reasonFlags doesn't buy
me anything.

        The only time when I can see something like that being useful is if you
consider one particular reason to be 'worse" than the others.  For example, in
some situations, keyCompromise may be more "important" than all the other
reasons (that's clearly not always true, but it may well be in some
circumstances).  Thus, you could look at the initial reasonFlags to see if you
had any keyCompromises, and if so, expedite processing of this revocation
request.  Other than that, I don't see a win, and I do see more complicated
code.

        I looked at this differently.  When John posed his question about
whether any certificate should be revoked for multiple reasons, I looked at the
reason codes listed in PKIX-1.  They are:

        CRLReason ::= ENUMERATED { 
                unspecified (0), 
                keyCompromise (1), 
                cACompromise (2), 
                affiliationChanged (3), 
                superseded (4), 
                cessationOfOperation (5), 
                certificateHold (6), 
                removeFromCRL (8) }

Now, it doesn't make sense to me to revoke a certificate for a reason of
"unspecified" AND for another, specified reason at the same time.  Besides,
PKIX-1 discourages the use of "unspecified", anyway, so I think we can
eliminate any combinations including "unspecified".

Next, keyCompromise.  I suppose it is possible to revoke a certificate because
its private key and the private key of its issuer were simultaneously
compromised, but only if the CRL-issuer is using a different key.  Otherwise,
in an event where the key was compromised at the same time the user's
affiliation changed or the certificate was superseded (by one with a new key, I
would hope :-), I would suggest that the requester just pick one - whichever is
more important in her environment.

Similarly, looking at other possible pairs, very few of them make sense.  For
example, I can't see where you would simultaneously want to revoke a
certificate because it was superseded AND because of cessation of operations.  

Because of this, I'd prefer that CMP use CRLReason vice reasonFlags so that the
sender can only specify one reason, but I'm willing to keep things the way they
are so as not to delay CMP any further.

So, from the standpoint of making everything interoperate, and making the
software simpler to develop, I propose the following:
- Senders of CMP revocation requests SHOULD only include one reason for each
certificate in the request.  (I'd personally prefer MUST, but I'm willing to
accept that there might be some rare cases when two or more things pop up at
once, and you want to let the recipient know all of the reasons.)  Senders
SHOULD choose the reason that is most important in their system, if there is a
way of ranking them in importance.  If not, senders SHOULD pick any one.

- Recipients of CMP revocation requests MUST accept messages with multiple
reasonFlags selected.  If the request is accepted, the revoked certificate MUST
only be placed on the CRL once, for one reason.  If one reason is deemed to be
more important than others in the revoker's environment, the revoker SHOULD
choose that reason; otherwise, the revoker can choose any reason for
revocation.

Any changes based on this can be made later; for now, this can be left as
"yeah, we implementers understand that this should happen this way."  Hey -
maybe it can even go in another version of the Roadmap. :-)

Comments?

                                Al Arsenault

-- these are my opinions only. They do not necessarily reflect the 
opinions of my employer, or of any other organization with which I have a 
relationship.

---

From: Juergen Walter <[email-masked]>
Date: Wed, 13 Jan 1999 19:06:14 +0100

Al, John

Al Arsenault wrote:
> more complicated than they need to be.  

I apologize. This was the result of doing mathematics during lunch time
and thinking about reason codes vs reason flags afterwards. :-)

>Why, for example, should my software
> for, anyway?

Firstly, a huge number of certTemplates with identically revocation
reasons, secondly ... (see below)

> It doesn't seem to be any benefit to me to know that "of the

This is exactly the situation with respect to the current CMP draft. To
each certTemplate one may find two sources of revocation reasons. Taking
this into consideration I suggested that reason codes should be chosen.

> request.  Other than that, I don't see a win, and I do see more complicated

..., secondly ... exactly as you described.

I see. Indeed, the only advantage may be a situation whereby CA´s
operator is bombarded with long revocation request sent by many RAs at
the same time. A reason flags in front of the sequence of revocation
details may help the operator to select the priority, provided that
there is a ranking in the considered environment.

> certificate because it was superseded AND because of cessation of operations.

I agree. Otherwise, one may add other reasons when people ask for it. 

> are so as not to delay CMP any further.

So, CA´s operators software has to be aware of both the reason flags and
the reason codes. For clarity, I would prefer that CMP did not use
reason flags assigned to each certTemplate. Dropping of reason flags
would be fine, because if there are any ambiguities between these two
reason data, you will need a ranking of revocation reasons.
Alternatively, the unkown code may be approriate to this case.

> software simpler to develop,

I completely agree with this standpoint.

> I propose the following:

I would prefer that PKIX uses only one revocation reasons encoding
throughout all drafts, i.e. the usage of reason codes. This gives
consistancy. The reason codes may be enlarged if required. In order to
implement this, combinations of elementary reasons could be enumerated.
Therefore, I propose that reason flags should be dropped. (I do not know
the history of CMP. So, I do not know whether the reason flags are
prehistoric vehicles or not. There is at least a second place where
reason flags is specified. You can find them in the CRL profile in
PKIX-1.)

Furthermore, one may think about reason flags in front of "long vehicle"
revocation requests. Firstly, this may help the CA´s operator to set a
priority of revocation request, when the revocation waiting queue is
overcrowded. Secondly, one may save bits in the case of multiple
certTemplates assigned to identical revocation reasons. This can be left
to further work. If this change will not lead to those advantages that I
have seen at a first glance, then it should not be done.

---

From: Tony Bartoletti <[email-masked]>
Date: Wed, 13 Jan 1999 11:25:47 -0800

Apologies for the naive suggestion:

If expedited processing is a major goal, why not require that any "bundled"
(multi-cert-template) revocation request be allowed only if all elements
of the bundle have the same (primary) reason code?

This way, perhaps for some codes, the individual reason flags may either be
ignored entirely, or for other codes, inspected individually as a second step.

Then, I suppose, "unspecified" would indicate that every individual must
be looked at separately.

Just a thought.

___tony___

Tony Bartoletti                                             LL
SPI-NET GURU                                             LL LL
Computer Security Technology Center                   LL LL LL
Lawrence Livermore National Lab                       LL LL LL
PO Box 808, L - 303                                   LL LL LLLLLLLL
Livermore, CA 94551-9900                              LL LLLLLLLL
email: [email-masked]   phone: 925-422-3881             LLLLLLLL