Subject: [pkix] 5280bis CRL problem poll results

From: Stephen Kent <[email-masked]>
Date: Tue, 02 Oct 2012 12:24:47 -0400

Folks,

It is apparent from the straw poll that there is no WG consensus on this 
topic.

I propose the following text, in lieu of the current "new second 
paragraph" that appears in Section 4 of 
draft-ietf-pkix-rfc5280-clarifications-09.txt:

A critical extension in the crlEntryExtensions field of an entrySHALL 
affect only the certificate specified in that entry, unless there is a 
related critical extension in the crlExtensions field that advertises a 
special treatment for it. If a relying party is unable to process both a 
critical crlEntryExtension and a related critical crlExtension, the 
relying party is faced with a difficult choice.

1-The relying party may assume that the the CRLEntry is associated with 
the CA that issued the CRL, and thus treat that certificate as revoked. 
If the CRLEntry refers to a certificate issued by a different CA, the 
relying party will treat a valid certificate as being revoked.

2-The relying party, realizing that it cannot accurately determine if 
the CRLEntry is associated with the CA that issued the CRL, may choose 
to treat that certificate as having an undetermined revocation status. 
If the relying party is able to consult other sources of certificate 
revocation status (e.g., OCSP) it may use those sources instead. If not, 
the relying party may accept or reject the certificate as a matter of 
local policy.

3-The relying party may view the CRLEntry as being associated with an 
undetermined CA, and treat all certificates with that serialNumber as 
being revoked. This behavior runs the risk of treating a number of valid 
certificates as revoked.

Because each of these options has associated risks, this document does 
not specify relying party behavior under the circumstances noted above. 
A relying party may accept or reject certificates with the indicated 
serialNumber as a matter of local policy.

How does the WG feel about this alternate text?

Steve

---

From: [email-masked]
Date: Tue, 2 Oct 2012 19:20:06 +0200

Steve,

First of all, it is nice from you to provide a strawman text proposal.

I don't understand why the following sentence has been deleted in the new 
text proposal:

" In order to use such a CRL, the relying party MUST be able to process 
both 
the crlEntryExtension and the related crlExtension".

I believe it should stay. Then, the proposed text states:
If a relying party is unable to process both a critical crlEntryExtension 
and 
a related critical crlExtension, the relying party is faced with a 
difficult choice

My question is the following: if a relying party is unable to process both 
a critical crlEntryExtension and 
a critical crlExtension, how can he know that they are related ?

Denis

De :    Stephen Kent <[email-masked]>
A :     pkix <[email-masked]>
Date :  02/10/2012 18:25
Objet : [pkix] 5280bis CRL problem poll results
Envoyé par :    [email-masked]

Folks,

I propose the following text, in lieu of the current “new second 
paragraph” that appears in Section 4 of 
draft-ietf-pkix-rfc5280-clarifications-09.txt:
 
A critical extension in the crlEntryExtensions field of an entry SHALL 
 
1-  The relying party may assume that the the CRLEntry is associated with 
the CA that issued the CRL, and thus treat that certificate as revoked. If 
the CRLEntry refers to a certificate issued by a different CA, the relying 
party will treat a valid certificate as being revoked.

2-  The relying party, realizing that it cannot accurately determine if 
the CRLEntry is associated with the CA that issued the CRL, may choose to 
treat that certificate as having an undetermined revocation status. If the 
relying party is able to consult other sources of certificate revocation 
status (e.g., OCSP) it may use those sources instead. If not, the relying 
party may accept or reject the certificate as a matter of local policy.

3-  The relying party may view the CRLEntry as being associated with an 
undetermined CA, and treat all certificates with that serialNumber as 
being revoked. This behavior runs the risk of treating a number of valid 
certificates as revoked.
 
Because each of these options has associated risks, this document does not 
specify relying party behavior under the circumstances noted above. A 
relying party may accept or reject certificates with the indicated 
serialNumber as a matter of local policy.

Steve_______________________________________________
pkix mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pkix

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 2 Oct 2012 10:23:03 -0700

On Oct 2, 2012, at 9:24 AM, Stephen Kent <[email-masked]> wrote:

> Folks,
>  
> It is apparent from the straw poll that there is no WG consensus on this topic.
>  
> I propose the following text, in lieu of the current “new second paragraph” that appears in Section 4 of draft-ietf-pkix-rfc5280-clarifications-09.txt:
>  
> A critical extension in the crlEntryExtensions field of an entry SHALL affect only the certificate specified in that entry, unless there is a related critical extension in the crlExtensions field that advertises a special treatment for it. If a relying party is unable to process both a critical crlEntryExtension and a related critical crlExtension, the relying party is faced with a difficult choice.
>  
> 1-  The relying party may assume that the the CRLEntry is associated with the CA that issued the CRL, and thus treat that certificate as revoked. If the CRLEntry refers to a certificate issued by a different CA, the relying party will treat a valid certificate as being revoked.
> 
> 2-  The relying party, realizing that it cannot accurately determine if the CRLEntry is associated with the CA that issued the CRL, may choose to treat that certificate as having an undetermined revocation status. If the relying party is able to consult other sources of certificate revocation status (e.g., OCSP) it may use those sources instead. If not, the relying party may accept or reject the certificate as a matter of local policy.
> 
> 3-  The relying party may view the CRLEntry as being associated with an undetermined CA, and treat all certificates with that serialNumber as being revoked. This behavior runs the risk of treating a number of valid certificates as revoked.
>  
> Because each of these options has associated risks, this document does not specify relying party behavior under the circumstances noted above. A relying party may accept or reject certificates with the indicated serialNumber as a matter of local policy.
> 

That seems like a good approach, given the lack of consensus. One editorial suggestion for the last sentence of item 2: change "the relying party may accept or reject" to "the relying party then accepts or rejects". The active tense is important here to indicate that the local policy is already in place.

--Paul Hoffman

---

From: Santosh Chokhani <[email-masked]>
Date: Tue, 2 Oct 2012 14:26:14 -0400

Steve,

I am confused by your proposal.

I thought there is an agreement that if the CRL extension cannot be processed, the CRL MUST be rejected.

I thought we are debating what to do when there is only a critical CRL entry extension and no related CRL extension, we know that the CRL entry extension only affects the entry.  And the question is whether to use the entry or not.  That is what we need to decide.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Hoffman
Sent: Tuesday, October 02, 2012 1:23 PM
To: Stephen Kent
Cc: pkix
Subject: Re: [pkix] 5280bis CRL problem poll results

On Oct 2, 2012, at 9:24 AM, Stephen Kent <[email-masked]> wrote:

> I propose the following text, in lieu of the current "new second paragraph" that appears in Section 4 of draft-ietf-pkix-rfc5280-clarifications-09.txt:
>  

--Paul Hoffman
_______________________________________________
pkix mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pkix

---

From: Piyush Jain <[email-masked]>
Date: Tue, 2 Oct 2012 20:14:28 +0000

Steve,

The only thing that we need to convey in the text is that if a the certificate referred to by a unknown critical CRL entry extension should be treated as 'revoked' or 'unknown'.
I like your idea of letting local policy dictate this.

So here are my changes to your proposed text.

A critical extension in the crlEntryExtensions field of an entry SHALL affect only the certificate specified in that entry, unless there is a related critical extension in the crlExtensions field that advertises a special treatment for it.
If the relying party cannot process a critical CRL Entry extension, it may consider the status of the certificate referred to by this CRL entry as either revoked or unknown as a matter of local policy.

Please note the following changes to your proposed text

DELETED - "If a relying party is unable to process both a critical crlEntryExtension and a related critical crlExtension, the relying party is faced with a difficult choice".

This is incorrect. If a critical CRL extension cannot be processed, the CRL MUST be rejected

   DELETED the choices. - RPs won't get to making those choices. If the RP processes the CRL extension, it should also process the related CRL entry extension.

ADDED  -  "If the relying party cannot process a critical CRL Entry extension, it may consider the status of the certificate referred to by this CRL entry as either revoked or unknown as a matter of local policy."

This deals with the scenario where there are no unrecognized CRL extensions but unrecognized CRL entry extensions.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Stephen Kent
Sent: Tuesday, October 02, 2012 9:25 AM
To: pkix
Subject: [pkix] 5280bis CRL problem poll results

Folks,

---

From: Russ Housley <[email-masked]>
Date: Tue, 2 Oct 2012 17:43:00 -0400

The lack of consensus is troubling, but I have two concerns with the proposed text.

First, if a critical CRL Entry Extension is unrecognized, then the relying party cannot know that it is associated with particular CRL Extension.  Your text assumes that the only thing that such an extension might convey is the issuing CA.  This is true for the extensions that PKIX has discussed to date, but I am not convinced that will be true for all time.

Second, I do not think there is a lack of consensus on this statement: A relying party MUST reject a CRL that contains an unrecognized critical extension, regardless of the extension being a CRL Extension or a CRL Entry Extension.

Russ

---

From: [email-masked]
Date: Wed, 3 Oct 2012 09:56:52 +0200

Russ,

While I agree with your first statement, i.e. ; "if a critical CRL Entry 
Extension is unrecognized, 
then the relying party cannot know that it is associated with particular 
CRL Extension", since 
it directly relates to the question I asked to Steve.

However, I disagree with your last statement, i.e. "A relying party MUST 
reject a CRL that contains 
an unrecognized critical extension, regardless of the extension being a 
CRL Extension or a CRL Entry Extension.

The sentence should be changed into: "A relying party MUST reject a CRL 
that contains 
an unrecognized critical extension in a CRL Extension".

Denis

De :    Russ Housley <[email-masked]>
A :     Stephen Kent <[email-masked]>
Cc :    pkix <[email-masked]>
Date :  02/10/2012 23:43
Objet : Re: [pkix] 5280bis CRL problem poll results
Envoyé par :    [email-masked]

The lack of consensus is troubling, but I have two concerns with the 
proposed text.

First, if a critical CRL Entry Extension is unrecognized, then the relying 
party cannot know that it is associated with particular CRL Extension. 
Your text assumes that the only thing that such an extension might convey 
is the issuing CA.  This is true for the extensions that PKIX has 
discussed to date, but I am not convinced that will be true for all time.

Second, I do not think there is a lack of consensus on this statement: A 
relying party MUST reject a CRL that contains an unrecognized critical 
extension, regardless of the extension being a CRL Extension or a CRL 
Entry Extension.

Russ

Folks,

 

 

Steve

---

From: Piyush Jain <[email-masked]>
Date: Wed, 3 Oct 2012 15:30:08 +0000

Russ,

There is consensus on the statement that the relying party must reject the CRL if it encounters an unknown critical CRL extension.
And I think (based on discussion over past few weeks) that most folks here believe that the whole CRL should NOT be rejected because of an unknown critical CRL entry extension.

The only point of contention is that if the certificate referred to by such a CRL entry should be treated as 'revoked' or 'unknown'.

-Piyush

From: [email-masked] [mailto:[email-masked]] On Behalf Of Russ Housley
Sent: Tuesday, October 02, 2012 2:43 PM
To: Stephen Kent
Cc: pkix
Subject: Re: [pkix] 5280bis CRL problem poll results

Russ

Folks,

[email-masked]<mailto:[email-masked]>

---

From: Russ Housley <[email-masked]>
Date: Wed, 3 Oct 2012 13:07:58 -0400

I recognize that people want the critical CRL entry extension to only mean that that entry cannot be used.  But RFC 5280 already says otherwise.  Section 5.3 says:

  ... If a CRL
  contains a critical CRL entry extension that the application cannot
  process, then the application MUST NOT use that CRL to determine the
  status of any certificates. ...

The clarifications document cannot reverse this MUST statement.

Russ

On Oct 3, 2012, at 11:30 AM, Piyush Jain wrote:

> The only point of contention is that if the certificate referred to by such a CRL entry should be treated as ‘revoked’ or ‘unknown’.
>  
> -Piyush
>

---

From: Russ Housley <[email-masked]>
Date: Wed, 3 Oct 2012 13:34:35 -0400

Denis:

While I think that we should move to a more granular handling of CRL Entry Extensions, that cannot be done in an informational clarifications document.  That would require a standards-track update to RFC 5280.

RFC 5280 is pretty clear in Section 5.3:

  ... If a CRL

Russ

On Oct 3, 2012, at 3:56 AM, [email-masked] wrote:

> Russ, 
> 
> While I agree with your first statement, i.e. ; "if a critical CRL Entry Extension is unrecognized, 
> then the relying party cannot know that it is associated with particular CRL Extension", since 
> However, I disagree with your last statement, i.e. "A relying party MUST reject a CRL that contains 
> an unrecognized critical extension, regardless of the extension being a CRL Extension or a CRL Entry Extension. 
> 
> The sentence should be changed into: "A relying party MUST reject a CRL that contains

---

From: Stephen Kent <[email-masked]>
Date: Wed, 03 Oct 2012 14:11:23 -0400

Russ,

This is a standards track doc, and has been marked as such since at least
the -01 version.  So it is legitimate to rescind the MUST with this doc.

Steve

---

From: Russ Housley <[email-masked]>
Date: Wed, 3 Oct 2012 14:19:20 -0400

Ooops.  I see that the most recent version <draft-ietf-pkix-rfc5280-clarifications-09.txt> is aimed at standards track.

Sorry for the confusion,
Russ

---

From: Russ Housley <[email-masked]>
Date: Wed, 3 Oct 2012 17:33:20 -0400

It seems that the PKIX WG is faced with a difficult choice.  I see three ways we could go regarding the update to Section 5.3 of RFC 5280.

(1) Stick with the text in RFC 5280.  At one point in time, there was consensus for it.  Ignoring a CRL with an unrecognized CRL Entry Extension is not aligned with the most recent version of X.509, but it is a safe thing to do.

(2) Build consensus for the text in the current I-D.  We have been working toward that for several weeks, and we are not making progress.

(3) Build consensus around some alternate text.  Steve put forward some alternate text, but it does not seem to have any more consensus than the text in the current I-D.  Can Steve's text be changed in a way that gets us to consensus?  So far, I have seen two major concerns raised that need to be resolved if this is the way forward.

Russ

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 3 Oct 2012 22:46:21 +0100

> It seems that the PKIX WG is faced with a difficult choice.  I see three ways we could go regarding the update to Section 5.3 of RFC 5280.

I'd say #1 is fine. The world has survived with 5280 and I'm not sure how many of those suggesting changes have significant running code. (And nor do I so I'm happy to defer to anyone who does and who cares.)

S

---

From: Denis Pinkas Bull <[email-masked]>
Date: Fri, 05 Oct 2012 11:24:51 +0200

Russ,

You said: "

Steve put forward some alternate text, but it does not seem to have any more consensus
than the text in the current I-D.  Can Steve's text be changed in a way that gets us to consensus? "

Here is a new proposal for changing Steve's text.

===========================================================================

    The CRL entry extensions defined by ISO/IEC, ITU-T, and ANSI X9
    for X.509 v2 CRLs provide methods for associating additional
    attributes with CRL entries [X.509] [X9.55].  The X.509 v2 CRL
    format also allows communities to define private CRL entry
    extensions to carry information unique to those communities.
    Each extension in a CRLentry may be designated as critical or
    non-critical.  A critical extension in the crlEntryExtensions
    field of an entry SHALL affect only the certificate identified
    in that entry, unless there is a related critical extension in
    the crlExtensions field that advertises a special treatment for
    it.

    If a CRL contains a critical CRL entry extension that the
    application cannot process, then the relying party SHOULD use,
    if possible, other sources of certificate revocation status
    (e.g. OCSP) to accurately the revocation status of the
    certificate identified in that CRLEntry.
    
    If the relying party is able to know (using a local policy)
    that the CRLEntry is associated with the CA that issued the CRL,
    then the relying party SHALL consider that the revocation status
    of the certificate is revoked.

    If the relying party is unable to know whether the CRLEntry
    is associated with the CA that issued the CRL, then the relying
    party SHOULD consider that the revocation status of the
    certificate is revoked.

    Note: In the last case, the relying party may treat a valid
          certificate as being revoked.  However, since most CAs are
          currently using large random certificate serial numbers,
          a collision between such numbers is rather unlikely.
          So it is more likely that the certificate serial number
          identified in the CRLentry relates to the right CA.

===========================================================================

The Note above could be transformed and placed in the security considerations section.
It is taking care of a situation that is likely to happen one out of a zillion of zillion cases.

It is one of the reasons why I have not kept the "dramatic" sentence from Steve's proposal:
"the relying party is faced with a difficult choice".

---

From: [email-masked] (Martin Rex)
Date: Fri, 5 Oct 2012 21:16:43 +0200 (CEST)

Stephen Farrell wrote:
> 
> Russ Housley wrote:
> 
>> It seems that the PKIX WG is faced with a difficult choice.
>> I see three ways we could go regarding the update to Section 5.3 of RFC 5280.
>>
>> (1) Stick with the text in RFC 5280.  At one point in time, there was
>> consensus for it.  Ignoring a CRL with an unrecognized CRL Entry Extension
>> is not aligned with the most recent version of X.509, but it is a safe
>> thing to do.
> 
> I'd say #1 is fine. The world has survived with 5280 and I'm not sure
> how many of those suggesting changes have significant running code.
> (And nor do I so I'm happy to defer to anyone who does and who cares.)

In principle, I would whole-heartedly agree, when just looking at this
rfc5280 requirement:

>  status of any certificates. ...

but I see two issues (A,B) with this that deserve clarification,
and I believe that the inconsitency (A) should be fixed and
the defective CRL processing rules in the 08/2005 version of X.509
should be mentioned and its use discouraged.

(A) there is this contradiction in rfc5280 with section 5.2.5,
last (two) sentences of first paragraph:
   http://tools.ietf.org/html/rfc5280#section-5.2.5

                                               Although the extension is
   critical, conforming implementations are not required to support this
   extension.  However, implementations that do not support this
   extension MUST either treat the status of any certificate not listed
   on this CRL as unknown or locate another CRL that does not contain
   any unrecognized critical extensions.

Where the wording of the last sentence suggests that it is OK for apps
that do not support the critical crlExtension "IssuingDistributionPoint"
to use this CRL anyhow to determine the status of certs that _are_
listed in the CRL.  I like Piyush's suggested fix here:
  http://www.ietf.org/mail-archive/web/pkix/current/msg31734.html

(B)  the general guidance in rfc5280 section 6.1 "Basic Path Validation"
     (3rd paragraph):

   http://tools.ietf.org/html/rfc5280#section-6.1

   While the certificate and CRL profiles specified in Sections 4 and 5
   of this document specify values for certificate and CRL fields and
   extensions that are considered to be appropriate for the Internet
   PKI, the algorithm presented in this section is not limited to
   accepting certificates and CRLs that conform to these profiles.
   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.  While the algorithm could be extended to include checks for
   conformance to the profiles in Sections 4 and 5, this profile
   RECOMMENDS against including such checks.

This text in rfc5280 explicitly recommends to disregard (the more correct)
processing rule in Section 5 (including the statement from section 5.3),
and recommends using the processing rules specified by X.509 instead.
Now the problem with this is, that rfc5280 refers to X.509 08/2005,
a document where the CRL processing rules are significantly broken,
rather than X.509 11/2008, which contains a corrected&reasonable set
of CRL processing rules.

-Martin

---

From: Russ Housley <[email-masked]>
Date: Tue, 9 Oct 2012 12:08:00 -0400

Denis:

I do not support this alternate text.  If there is an unrecognized CRL Entry Extension, then the replying party cannot know whether the entry applies to a particular certificate or not.  Certificates are identified by an issuer and serial number.  An unrecognized CRL Entry Extension can change the issuer portion of the tuple.

The relying party can always try an alternate CRL or and alternate protocol like OCSP to check out the certificate of interest.  This would be true for any type of CRL validation trouble.

I am unclear how local policy can be helpful here.  If there is an unrecognized CRL Entry Extension, the relying party knows that it cannot use the entry.

If the relying party does not know the issuer associated with a particular CRL entry, then it does not know whether that entry is associated with the certificate of interest or not.  Given this situation, I think that the appropriate action is not to treat the certificate as revoked; instead, the CRL is providing no useful information to make such a decision.

Russ

---

From: "Piyush Jain" <[email-masked]>
Date: Tue, 9 Oct 2012 12:48:56 -0700

Not that I support Denis's proposal but I also disagree with this

"If there is an unrecognized CRL Entry Extension, then the replying party
cannot know whether the entry applies to a particular certificate or not.
Certificates are identified by an issuer and serial number.  An unrecognized
CRL Entry Extension can change the issuer portion of the tuple"

This is only true if there is a critical CRL extension which allows such
behavior.

If the RP can process the CRL extension, it should also process the CRL
entry extension which implies that the CRL entry extension is NOT
unrecognized.

If the RP cannot process the critical CRL extension, it'll reject the CRL
and the question of what to do with CRL entry with unrecognized extensions
becomes moot.

CRL extensions affect the whole CRLs.

CRL entry extensions affect only the CRL entry unless indicated by a related
CRL extension.

The point of contention is that 5280 says that whole CRL should be rejected
if an unrecognized critical CRL entry extension is encountered.

This is what we need to do"

-         Make it explicit that that if RP processes IDP it should also
process "Certificate Issuer"

-         Change the text to say that RP should treat the certificate
referred to by a CRL entry with unknown critical extension as "revoked".
(Same as X.509)

All these proposals are assuming that a future CRL entry extension can
affect the whole CRL on its own. I'm sure if someone comes up with such an
extension he won't find any support in this WG or any other WG.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Russ
Housley
Sent: Tuesday, October 09, 2012 9:08 AM
To: Denis Pinkas Bull
Cc: [email-masked]
Subject: Re: [pkix] 5280bis CRL problem poll results

Denis:

I do not support this alternate text.  If there is an unrecognized CRL Entry
Extension, then the replying party cannot know whether the entry applies to
a particular certificate or not.  Certificates are identified by an issuer
and serial number.  An unrecognized CRL Entry Extension can change the
issuer portion of the tuple.

The relying party can always try an alternate CRL or and alternate protocol
like OCSP to check out the certificate of interest.  This would be true for
any type of CRL validation trouble.

I am unclear how local policy can be helpful here.  If there is an
unrecognized CRL Entry Extension, the relying party knows that it cannot use
the entry.

If the relying party does not know the issuer associated with a particular
CRL entry, then it does not know whether that entry is associated with the
certificate of interest or not.  Given this situation, I think that the
appropriate action is not to treat the certificate as revoked; instead, the
CRL is providing no useful information to make such a decision.

Russ

Russ,

You said: " 

Steve put forward some alternate text, but it does not seem to have any more
consensus 
than the text in the current I-D.  Can Steve's text be changed in a way that
gets us to consensus? "

 

 

 
The Note above could be transformed and placed in the security
considerations section.
It is taking care of a situation that is likely to happen one out of a
zillion of zillion cases.
 
It is one of the reasons why I have not kept the "dramatic" sentence from
Steve's proposal: 
"the relying party is faced with a difficult choice".

It seems that the PKIX WG is faced with a difficult choice.  I see three
ways we could go regarding the update to Section 5.3 of RFC 5280.
 
(1) Stick with the text in RFC 5280.  At one point in time, there was
consensus for it.  Ignoring a CRL with an unrecognized CRL Entry Extension
is not aligned with the most recent version of X.509, but it is a safe thing
to do.
 
(2) Build consensus for the text in the current I-D.  We have been working
toward that for several weeks, and we are not making progress.
 
(3) Build consensus around some alternate text.  Steve put forward some
alternate text, but it does not seem to have any more consensus than the
text in the current I-D.  Can Steve's text be changed in a way that gets us
to consensus?  So far, I have seen two major concerns raised that need to be
resolved if this is the way forward.
 
Russ

---

From: "Henry B. Hotz" <[email-masked]>
Date: Wed, 10 Oct 2012 13:15:13 -0700

It makes no sense to me that a single CRL *entry* extension could cause the entire CRL to be rejected.

On Oct 9, 2012, at 12:48 PM, Piyush Jain wrote:

> Not that I support Denis’s proposal but I also disagree with this
> “If there is an unrecognized CRL Entry Extension, then the replying party cannot know whether the entry applies to a particular certificate or not.  Certificates are identified by an issuer and serial number.  An unrecognized CRL Entry Extension can change the issuer portion of the tuple”
>  
> This is only true if there is a critical CRL extension which allows such behavior.
> If the RP can process the CRL extension, it should also process the CRL entry extension which implies that the CRL entry extension is NOT unrecognized.
> If the RP cannot process the critical CRL extension, it’ll reject the CRL and the question of what to do with CRL entry with unrecognized extensions becomes moot.
>  
> CRL entry extensions affect only the CRL entry unless indicated by a related CRL extension.
>  
> The point of contention is that 5280 says that whole CRL should be rejected if an unrecognized critical CRL entry extension is encountered.
> This is what we need to do”
> -         Make it explicit that that if RP processes IDP it should also process “Certificate Issuer”
> -         Change the text to say that RP should treat the certificate referred to by a CRL entry with unknown critical extension as “revoked”. (Same as X.509)
>  
> All these proposals are assuming that a future CRL entry extension can affect the whole CRL on its own. I’m sure if someone comes up with such an extension he won’t find any support in this WG or any other WG.
> 

------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[email-masked], or [email-masked]