Subject: Re: Reason codes vs Reason flags

From: "Carl Wallace" <[email-masked]>
Date: Wed, 13 Jan 1999 22:18:32 -0500

Why not use the reasonCode extension in the crlEntryDetails field and
eliminate the revocationReason field all together?  Same goes for the
invalidityDate extension and badSinceDate field.

-----Original Message-----
From: Juergen Walter <[email-masked]>
To: Al Arsenault <[email-masked]>; [email-masked]
<[email-masked]>; ietf-pkix <[email-masked]>; Carlisle Adams
<[email-masked]>; farrell <[email-masked]>
Date: Wednesday, January 13, 1999 1:16 PM
Subject: Re: Reason codes vs Reason flags

>Al, John
>
>Al Arsenault wrote:
>>
>> Juergen,
>>
>>         Whoa!  While I appreciate your approach, I think it makes things
way
>> 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
>> 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?
>
>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
>> 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.
>
>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.
>
>>
>>         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.
>
>..., 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.
>
>
>>
>>         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.
>
>I agree. Otherwise, one may add other reasons when people ask for it.
>
>>
>> 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, 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.
>
>>
>> So, from the standpoint of making everything interoperate, and making the
>> software simpler to develop,
>
>I completely agree with this standpoint.
>
>> 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.
>
>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.
>
>>
>> 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: Al Arsenault <[email-masked]>
Date: Thu, 14 Jan 1999 08:03:12 -0500

>invalidityDate extension and badSinceDate field.

I think that makes three of us so far that agree with that approach.  

Carlisle & Stephen,

	Any comments as to why you chose the ReasonFlags structure in section
3.3.9 of CMP, vice CRLReason?

Side note:  here's an interesting point.  I was just checking PKIX-1 again
for a couple of things, and looked at the definitions of ReasonFlags and
CRLReason.  The difference (other than the obvious one of BIT STRING vs.
ENUMERATED) is that ReasonFlags does not define the "removeFromCRL   (8)"
option that's in CRLReason.  Thus, if you have a cert on hold and you want
to take it off hold - i.e., remove it from the CRL - you can't use a
ReasonFlags object to do it, anyway.

Dave, Russ, Tim, and Warwick - is that intentional, or an editorial
oversight in PKIX-1?  If it was intentional, what was the reason?

						Al Arsenault

---

From: Juergen Walter <[email-masked]>
Date: Thu, 14 Jan 1999 17:37:07 +0100

Al,

in PKIX-1 the usage of reasonFlags is restricted to
cRLDistributionPoints extension, so there is no need for this flag. I
would expect that I will found the delta-crl where I have found the crl
containing the certificateHold revocation, i.e. the certificateHold flag
is set.

Juergen   

[snip]

---

From: Russ Housley <[email-masked]>
Date: Sat, 16 Jan 1999 12:37:21 -0500

>oversight in PKIX-1?  If it was intentional, what was the reason?

First, the structures are exactly those defind in X.509.

Second, the removeFromCRL value of ReasonFlags only appears on delta-CRLs.
In a full CRL, removal from hold is accomplished by removing the entry from
the CRL.  No trace of the previous hold status remains on the CRL.
Therefore, I do not see a case where a CRLDistributionPoint would have a
need to include this reason.

Russ