Subject: [pkix] [Technical Errata Reported] RFC5912 (3623)

From: RFC Errata System <[email-masked]>
Date: Thu, 16 May 2013 04:07:51 -0700 (PDT)

The following errata report has been submitted for RFC5912,
"New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=5912&eid=3623

--------------------------------------
Type: Technical
Reported by: Carl Wallace <[email-masked]>

Section: 14

Original Text
-------------
   -- CRL number extension OID and syntax
   ext-CRLNumber EXTENSION ::= {SYNTAX
       INTEGER (0..MAX) IDENTIFIED BY id-ce-cRLNumber }
   id-ce-cRLNumber OBJECT IDENTIFIER ::= { id-ce 20 }

   CRLNumber ::= INTEGER (0..MAX)

Corrected Text
--------------
   -- CRL number extension OID and syntax
   CRLNumber ::= INTEGER 

   ext-CRLNumber EXTENSION ::= {SYNTAX
       CRLNumber IDENTIFIED BY id-ce-cRLNumber }
   id-ce-cRLNumber OBJECT IDENTIFIER ::= { id-ce 20 }

Notes
-----
The CRLNumber extension was not defined to use the CRLNumber type.  The CRLNumber type uses MAX to limit the maximum value.  This limitation is inconsistent with section 5.2.3 and Appendix B, which allow CRLNumber values up to 20 octets in length.

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC5912 (draft-ietf-pkix-new-asn1-08)
--------------------------------------
Title               : New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)
Publication Date    : June 2010
Author(s)           : P. Hoffman, J. Schaad
Category            : INFORMATIONAL
Source              : Public-Key Infrastructure (X.509)
Area                : Security
Stream              : IETF
Verifying Party     : IESG

---

From: "Jim Schaad" <[email-masked]>
Date: Thu, 16 May 2013 16:22:00 +0100

Reject

The serial number MUST be a positive integer assigned by the CA to
   each certificate.

> -----Original Message-----
> From: RFC Errata System [mailto:[email-masked]]
> Sent: Thursday, May 16, 2013 12:08 PM
> To: [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: [Technical Errata Reported] RFC5912 (3623)
> 
> The following errata report has been submitted for RFC5912, "New ASN.1
> Modules for the Public Key Infrastructure Using X.509 (PKIX)".
> 
> The CRLNumber extension was not defined to use the CRLNumber type.  The
> CRLNumber type uses MAX to limit the maximum value.  This limitation is
> inconsistent with section 5.2.3 and Appendix B, which allow CRLNumber
> values up to 20 octets in length.
> 
> Instructions:
> -------------
> This errata is currently posted as "Reported". If necessary, please use
"Reply
> All" to discuss whether it should be verified or rejected. When a decision
is
> reached, the verifying party (IESG) can log in to change the status and
edit the
> report, if necessary.
> Title               : New ASN.1 Modules for the Public Key Infrastructure
Using
> X.509 (PKIX)

---

From: Carl Wallace <[email-masked]>
Date: Thu, 16 May 2013 11:37:05 -0400

The errata has multiple parts if you feel the MAX limit is unacceptable accept the type issue independently.

 Suggested limit change aligns with similar certificate serial number definition.

---

From: Erwann Abalea <[email-masked]>
Date: Thu, 16 May 2013 18:01:19 +0200

The certificate serialNumber is limited to [0 .. 256^20] in value.
The CRLNumber is limited to [-256^20 .. 256^20], it's not said to be a
positive integer.

2013/5/16 Jim Schaad <[email-masked]>:
> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix

--
Erwann.

---

From: Carl Wallace <[email-masked]>
Date: Thu, 16 May 2013 12:38:11 -0400

Independent of limit, this should change to use CRLnumber type to
facilitate satisfying the requirement for a big integer.  The CRLNumber
type is used in the prose describing the extension, but not in its
definition.  It is used in the DeltaCRLIndicator definition.

---

From: Erwann Abalea <[email-masked]>
Date: Thu, 16 May 2013 20:01:45 +0200

My bad. X.509 already defines CRLNumber as an INTEGER(0..MAX), so a
positive number.

--
Erwann.

---

From: [email-masked] (Martin Rex)
Date: Thu, 16 May 2013 20:27:36 +0200 (CEST)

Carl Wallace wrote:
>
> The errata has multiple parts if you feel the MAX limit is
> unacceptable accept the type issue independently.

The change about the MAX part looks inappropriate.

The change within the definition ext-CRLNumber is a defect in rfc5912.
It's silly to create such an orphan.

The ASN.1 definition in ITU-T Rec. X.509 08/1997 (Section 12.5.2.1 page 35):

  12.5.2.1 CRL number field

  This CRL extension field conveys a monotonically increasing sequence
  number for each CRL issued by a given CRL issuer through a given CA
  directory attribute or CRL distribution point. It allows a CRL user
  to detect whether CRLs issued prior to the one being processed were
  also seen and processed. This field is defined as follows:

  cRLNumber EXTENSION ::= {
        SYNTAX CRLNumber
        IDENTIFIED BY id-ce-cRLNumber }
  CRLNumber ::= INTEGER (0..MAX)

  This extension is always non-critical.

and verbatim the same in ITU-T Rec. X.509 11/2008 (Section 8.5.2.1, page 35)

Given how the original purpose of this field is defined in X.509,
the 20 octets limit in rfc5280 5.2.3 is pretty clueless on my scorecard.

What X.509 says implies that a CA must start CRLNumber at 0 and issue
CRLs without creating holes in the CRLNumber space.

Reality check:

  1 CRL per second, 50 years of issuance:

  50*366*86400 = 1,581,120,000   < 2^31

-Martin

---

From: Carl Wallace <[email-masked]>
Date: Thu, 16 May 2013 14:32:16 -0400

>It's silly to create such an orphan.

Correct.  I over-read an error message from the compiler I was using re:
MAX limit bit.  The type issue should be fixed.

---

From: Erwann Abalea <[email-masked]>
Date: Thu, 16 May 2013 21:14:09 +0200

2013/5/16 Martin Rex <[email-masked]>:
[...]
> CRLs without creating holes in the CRLNumber space.

{0, 2, 4, 5, 10, 35, 42} is a monotonically increasing sequence. Each
term is greater than the previous one, the "no hole" property isn't
wanted.
If it was, then the sequence number would be issued from an arithmetic
progression with common difference of 1 (I'm not sure of the
translation, we call it "suite arithmétique de raison 1" in french).

The first CRL does not need to be numbered 0 either.

--
Erwann.

---

From: [email-masked] (Martin Rex)
Date: Thu, 16 May 2013 21:26:07 +0200 (CEST)

Erwann Abalea wrote:
[ Charset UTF-8 unsupported, converting... ]
> The first CRL does not need to be numbered 0 either.

You failed to read X.509.

Look at the DEFINED purpose of the CRLNumber in X.509 again.

The stated purpose of CRLNumber is:

  It allows a CRL user to detect whether CRLS issued prior to the one being
  processed were also seen and processed.

This is _not_ about a human doing research!

A CA starting at a number > 0 or a that creates holes in the CRLNumber
space would preclude (and enforce) the "were also seen an processed"
for the CRL user, so both would be formally provable incompatible with
the one and only explicitly stated purpose of CRLNumber.

That there is no "shall" language on both issues in X.509 is a
formally provable defect of X.509 -- of which there are *many*.

-Martin

---

From: [email-masked] (Martin Rex)
Date: Thu, 16 May 2013 23:34:55 +0200 (CEST)

Some of my previous message seems garbled.

>   processed were also seen and processed.

means that a "CRL user" aka "Relying Party" may REQUIRE (whenever it feels
like it) to have seen and processed *ALL* prior CRLs of a CA before
considering a cert from that CA as valid.

The CA is prohibited from doing anything that would interfere with RPs
that want to make use of that guarantee from X.509, so formal logic
deduction requires that a CA MUST issue their first CRL with number 0
and MUST NOT issue a CRL with CRLNumber (n+1) when it has not previously
issued a CRLNumber (n) (and n is a valid number for a CRL to have).

Speaking of rfc5280 section 5.2.3:
What sections 5.2.3 CRLNumber and 5.2.4 Delta CRL Indicator of rfc5280
say about CRLNumbers of Delta CRLs looks incomprehensible to me
and contains ambiguities and self-contraditions.  It looks like a
huge mess to me, containing formally provable logical fallacies.

X.509 (11/2008) is also confusing, e.g. X.509 says:

                                        However, the cRLNumber referenced
    in the BaseRevocationInfo field of a dCRL shall be less than or equal
    to the cRLNumber of the most recently issued CRL that is complete for
    the applicable scope.

which looks bogus and I assume really should have said:

                                        However, the CRLNumber referenced
    in the BaseRevocationInfo field cRLNumber of a dCRL shall be less than
    or equal to the CRLNumber of the most recently issued CRL that is
    complete for the applicable scope.

based on the accompanying ASN.1 definitions:

  BaseRevocationInfo ::= SEQUENCE {
        cRLStreamIdentifier  [0]    CRLStreamIdentifier OPTIONAL,
        cRLNumber            [1]    CRLNumber,
        baseThisUpdate       [2]    GeneralizedTime }

Rfc5912 is slightly better by using "ext-CRLNumber" rather than
"cRLNumber" for the extension type.

I'm still an ASN.1 layman for most parts of ASN.1, and the correct
terminology.  Frankly, to me it looks like ASN.1 is at least a
magnitude too difficult that it can be used in an error-free fashion
in practice...

I'm unaware of any non-trivial ASN.1-based protocol definition
that is (a) error-free and (b) describes the actual behaviour of
the installed base.

-Martin

---

From: "Piyush J.comain" <[email-masked]>
Date: Thu, 16 May 2013 15:26:28 -0700

> considering a cert from that CA as valid.

[Piyush] Why the CRL user needs to detect if all prior CRLs were processed
is an open question and there may be legitimate use cases that can be
addressed by doing so.
But I cannot fathom why an RP will require that all prior CRLs be processed
before considering a cert from that CA valid.

One genuine use case that comes to mind is providing time based validation
i.e. checking revocation status of a currently  expired certificate at some
time in the past. If the RP has missed a few prior CRLs, it cannot be sure
if a now expired certificate was revoked at some point in the past and then
removed from the CRL because it expired.

So I agree with you that CRL Numbers should be in arithmetic progression
with difference between consecutive numbers being 1.
It is also easier to issue the first CRL with number 0 so it is implicit to
the client that CRL with number 0 is the first CRL. However, the standard
does not preclude the CA from issuing the first CRL with number 29678 and
communicating this number of the first CRL to the RPs out of band. But these
are theoretical discussions. I can't imagine an implementation that
generates CRL numbers using geometric progression or even using arithmetic
progression with difference being more than 1 unless the implementer is
trying to reveal his sense of humor.

> The CA is prohibited from doing anything that would interfere with RPs
that
> want to make use of that guarantee from X.509, so formal logic deduction
> requires that a CA MUST issue their first CRL with number 0 

As I said above CA may use any number for first CRL and publish that number
as the one associated with the first CRL.

>and MUST NOT
> issue a CRL with CRLNumber (n+1) when it has not previously issued a
> CRLNumber (n) (and n is a valid number for a CRL to have).

True.

> What sections 5.2.3 CRLNumber and 5.2.4 Delta CRL Indicator of rfc5280 say
> about CRLNumbers of Delta CRLs looks incomprehensible to me and contains
> ambiguities and self-contraditions.  It looks like a huge mess to me,
> containing formally provable logical fallacies.
> 
> 
Specifics please. What are the self-contradictions and the logical
fallacies.

---

From: [email-masked] (Martin Rex)
Date: Fri, 17 May 2013 04:21:50 +0200 (CEST)

> removed from the CRL because it expired.

Correct, that is one possible consequence when allowing CAs
to remove revoked certs from CRLs after they have expired when
there were listed at least once on a complete CRL.

> Specifics please. What are the self-contradictions and the logical

Sorting that mess out will be a time-consuming job, and one that
I won't do.

Example provable non-sense (from the second paragraph of 5.2.3):

                     If a delta CRL and a complete CRL that cover the
   same scope are issued at the same time, they MUST have the same CRL
   number and provide the same revocation information.  That is, the
   combination of the delta CRL and an acceptable complete CRL MUST
   provide the same revocation information as the simultaneously issued
   complete CRL.

If the deltaCRL would reference the concurrently generated complete CRL
as BaseCRLNumber, then (allegedly intended meaning of) the second
sentence would result in a tautology (the concurrently generated
complete CRL being the only acceptable complete CRL in existence)
and the deltaCRL would have to be empty. 

Therefore I assume the idea here was to create a deltaCRL to a prior
baseCRL concurrently with a new complete CRL, so that CRL user could
continue to use a "technically expired" baseCRL with that deltaCRL.

The two defects in this paragraph are:
(1)  "the combination of the delta CRL and an acceptable complete CRL"
(2)  "MUST provide the same revocation information as ... complete CRL"

What it may have actually meant is
  "the combination of the delta CRL and EVERY acceptable complete CRL
   MUST provide NO LESS revocation information as the simultaneouly
   issued complete CRL".

(2) "The SAME revocation information" in the latter sentence
is formally provable non-sense, because a delta-CRL may contain
"removeFromCRL" entries that can not appear on the complete CRL,
and that will require any temporary revocation they refer to not
appear on the new complete CRL, although that temporary revocation
information may have been present on an earlier complete CRL that
is acceptable for combination with the deltaCRL.

On top of that, unless this requirement is supposed to entirely void
the permission for CAs to drop revoked certificates off the CRL after
they have expired, there may be further revocation information missing
on the new complete CRL that is available in the combination of
the deltaCRL and an acceptable complete CRL -- in case that deltaCRL
references a an earlier BaseCRLNumber than that of the concurrently
generated complete CRL.

(1) Since the first sentence starts with the premise
"If a delta CRL and a complete CRL that cover the same scope are issued
 at the same time", the new complete CRL will be _an_ acceptable
complete CRL for combination with the deltaCRL, so the use of
"an acceptable complete CRL" is a misleading tautology.  What is
really important here, is that the "NO LESS revocation information"
applies to combination of this delta CRL and *EVERY* acceptable
complete CRL.

I also believe that as a backwards compatibility requirement with
X.509, the weird fashion how rfc5280 abused the CRLNumber extension
in deltaCRLs (an idea that I did not see in X.509) implies that a
CA will *ALWAYS* have to issue a complete CRL with every deltaCRL,
otherwise it would create holes in the sequence numbers of
complete CRLS, breaking a fundamental promise/assumption of X.509.

-Martin

---

From: "Piyush J.comain" <[email-masked]>
Date: Thu, 16 May 2013 21:08:33 -0700

> If the deltaCRL would reference the concurrently generated complete CRL as
> BaseCRLNumber, 
[Piyush] That would be incorrect.  A delta cannot be combined with
concurrently generated CRL. Section 5.2.4 bullet (d).

then (allegedly intended meaning of) the second sentence
> would result in a tautology (the concurrently generated complete CRL being
> the only acceptable complete CRL in existence) and the deltaCRL would have
> to be empty.
> 

> Therefore I assume the idea here was to create a deltaCRL to a prior
baseCRL
> concurrently with a new complete CRL, so that CRL user could continue to
> use a "technically expired" baseCRL with that deltaCRL.
> 
[Piyush] correct. 
> (2)  "MUST provide the same revocation information as ... complete CRL"
[Piyush] I don't see the defect.

>    MUST provide NO LESS revocation information as the simultaneouly
[Piyush] An acceptable complete CRL to merge with a delta is one with the
CRL number greater than or equal to the one that is referenced as base CRL
number in the delta. Once the merging happens the merged CRL would contain
the same entries as a concurrently issued complete CRL.
> 
> (2) "The SAME revocation information" in the latter sentence is formally
> provable non-sense, because a delta-CRL may contain "removeFromCRL"
> entries that can not appear on the complete CRL, and that will require any
> temporary revocation they refer to not appear on the new complete CRL,
> although that temporary revocation information may have been present on
> an earlier complete CRL that is acceptable for combination with the
deltaCRL.
[Piyush] Depends on how you interpret "SAME revocation information".
"removeFromCRL" is a mechanism to indicate  that entry was removed from CRL
i.e. the cert referenced by that entry is not considered revoked anymore.
The absence of the entry in the concurrent complete CRL indicates the same
thing.

> On top of that, unless this requirement is supposed to entirely void the
> permission for CAs to drop revoked certificates off the CRL after they
have
> expired, there may be further revocation information missing on the new
> complete CRL that is available in the combination of the deltaCRL and an
> acceptable complete CRL -- in case that deltaCRL references a an earlier
> BaseCRLNumber than that of the concurrently generated complete CRL.
[Piyush] removeFromCRL just indicates that the entry was removed from the
complete CRL. It could be because the cert was reinstated or because it
expired.

> 
> (1) Since the first sentence starts with the premise "If a delta CRL and a
> complete CRL that cover the same scope are issued  at the same time", the
> new complete CRL will be _an_ acceptable complete CRL for combination
> with the deltaCRL, so the use of "an acceptable complete CRL" is a
misleading
> tautology.  What is really important here, is that the "NO LESS revocation
> information"
> applies to combination of this delta CRL and *EVERY* acceptable complete
> CRL.
> 
[Piyush] An acceptable complete CRL's number must be less than that of the
delta. So concurrently issued CRL cannot be an acceptable CRL to merge with
the delta.
> 
> I also believe that as a backwards compatibility requirement with X.509,
the
> weird fashion how rfc5280 abused the CRLNumber extension in deltaCRLs
> (an idea that I did not see in X.509) implies that a CA will *ALWAYS* have
to
> issue a complete CRL with every deltaCRL, otherwise it would create holes
in
> the sequence numbers of complete CRLS, breaking a fundamental
> promise/assumption of X.509.
> 
[Piyush] I don't think that your conclusion is correct. CAs can issue deltas
more frequently than complete CRLs.
e.g. CRL number 'n' could be associated with both a delta and a full,
numbers 'n+1', 'n+2', 'n+3' would be associated with just deltas and 'n+4'
would be again associated with both delta and complete.

---

From: [email-masked] (Martin Rex)
Date: Fri, 17 May 2013 09:10:56 +0200 (CEST)

> concurrently generated CRL. Section 5.2.4 bullet (d).

While I had not read through that section, this is relevant exclusively
to "CAs conforming to rfc5280" (if at all), but NOT for RPs, _unless_
the same exists in ITU-T Rec. X.509 08/2005 due to the guidance in
rfc5280 section 6.1:

   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.

> the same entries as a concurrently issued complete CRL.

(1) it says "the combination of ... revocation information" which is NOT
    equal to first merging the CRLs and then looking at the result.
(2) removing expired certs from any "merged CRL" locally created by the RP
    (a) is neither required, nor appropriate, nor reasonable, and
        the CRL does not even whether the CA would remove expired certs.
    (b) not even possible for the RP, because it only sees cert serials

> [Piyush] Depends on how you interpret "SAME revocation information".

I think we can safely ignore such unreasonable/illogical interpretations.

> The absence of the entry in the concurrent complete CRL indicates the same

Knowing that a cert was temporarily revoked during some time in the past
is _still_ "revocation information", no matter how you look at it.

Whether such information is useful or relevant for checks performed by
the RP is highly dependent on the RP's usage scenario and/or purpose.
For stuff that is also digitally timestamped (e.g. rfc3161), the certificate
status at the time indicated by the secure timestamp might be MUCH more
relevant than the current cert status (which may even be expired by then).

btw. which well-known CRL extension will be present on complete CRLs
where the CA does stupid things such as removing revoked certs after
they expire, or no longer accept and publish revocations for a cert
that has expired?

And where in rfc5280/pkix is the algorithm described for the RP software
to determine and obtain the necessary CRL to determine the cert status
for some point in the past for an already expired cert?

Allowing CAs to drop certs off CRLs without either of these being
standardized and used, would make S/Mime/CMS pretty useless for
offline use and archival, including use in EMail.

> > the weird fashion how rfc5280 abused the CRLNumber extension in deltaCRLs
> > to issue a complete CRL with every deltaCRL, otherwise it would create
> > holes in the sequence numbers of complete CRLS, breaking a fundamental

They technically could, but they will fundamentally break X.509 if they do.

> would be again associated with both delta and complete.

Nope, that would create 3 holes "n+1", "n+2" and "n+3" in the sequence
numbering of complete CRLs.  The X.509 promise about CRLNumber is that
it will be monotonically increasing, that the CRL user aka RP is allowed
to use CRLNumber to ensure that it has seen and processed all prior CRLs,
while allowing the very same RP to be entirely ignorant about delta CRLs.

-Martin

---

From: Erwann Abalea <[email-masked]>
Date: Fri, 17 May 2013 10:24:13 +0200

[...]
> while allowing the very same RP to be entirely ignorant about delta CRLs.

See X.509 Annex C for such examples.

--
Erwann.

---

From: "Jim Schaad" <[email-masked]>
Date: Fri, 17 May 2013 09:29:22 +0100

The following text is from RFC 5280

This says that the ASN.1 makes it a positive number

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Erwann Abalea
> Sent: Thursday, May 16, 2013 5:01 PM
> To: Jim Schaad
> Cc: Stefan Santesson; Paul Hoffman; [email-masked]; [email-masked]; RFC
> Errata System
> Subject: Re: [pkix] [Technical Errata Reported] RFC5912 (3623)
> 
positive
> integer.
> >> To: [email-masked]; [email-masked];
> >> [email-masked]; [email-masked]; [email-masked];
> >> [email-masked]
> >> The following errata report has been submitted for RFC5912, "New
> >> ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)".
> >>
> >> The CRLNumber extension was not defined to use the CRLNumber type.
> >> The CRLNumber type uses MAX to limit the maximum value.  This
> >> limitation is inconsistent with section 5.2.3 and Appendix B, which
> >> allow CRLNumber values up to 20 octets in length.
> >>
> >> Instructions:
> >> -------------
> >> use

---

From: [email-masked] (Martin Rex)
Date: Fri, 17 May 2013 12:06:08 +0200 (CEST)

Erwann Abalea wrote:
> See X.509 Annex C for such examples.

Whoa there!  more flying pigs (in Appendix B of X.509 08/2005):
(Thanks for the pointer, though).

  B.5.2 Validate delta CRL scope

  The dCRL shall be issued after the base CRL. One way to ensure this is
  to check that the CRL number in the crlNumber extension of the dCRL is
  greater than the CRL number in the crlNumber extension of the base CRL
  the relying party is using and the cRLStreamIdentifier fields in the
  base and the dCRL match.  This approach may require additional logic
  to account for number wrapping. Another way is to compare the thisUpdate
  fields in the base and dCRLs the relying party has;

Wrapping a CRLNumber that is defined as montonically increasing from the
INTEGER range (0..MAX) exceed "positive infinity" and wraps is a lame
argument (OK, CRLs require DER encoding, and DER doesn't allow
indefinite length encoding, but anyhow).

Curiously, I found the following in an X.509:

  BaseCRLNumber ::= CRLNumber

  The value of type BaseCRLNumber identifies the CRL number of the
  base CRL that was used as the starting point in the generation of
  this delta-CRL, i.e. this delta-CRL contains the changes between
  the base CRL and the complete CRL issued along with this delta-CRL.
  It is the decision of a CA as to whether to provide delta-CRLs.
  However, a delta-CRL shall not be issued without a corresponding
  complete CRL being issued at the same time. The value of the CRL
  number, as conveyed in the CRL number extension field (if present),
  shall be identical for both the delta-CRL and the corresponding
  complete CRL.

Some of this text is carried through in rfc5280.  Curiously, some of
it got dropped in a clearly backwards-incompatible and formally provable
breaking fashion from newer specs.  Ouch!

-Martin

---

From: "Piyush Jain" <[email-masked]>
Date: Fri, 17 May 2013 09:05:35 -0700

>     equal to first merging the CRLs and then looking at the result.

[[Piyush] The way I interpret it is following the combining rules which are
defined in 5280, though not using a mathematical notation.
Base CRL is a set. Delta is another set where each entry should be either
added or deleted from the Base CRL based on the reason code.
You are interpreting 'combination' as a simple search in both the base CRL
and delta CRL which is incorrect IMO.

>     (b) not even possible for the RP, because it only sees cert serials
[Piyush] I think you misunderstood me. RPs don't need to remove expired cert
from merged CRL. They just need to remove entries from the base CRL that are
marked as "removeFromCRL" in the delta while creating a merged CRL. Or if
you prefer the word "combination", the serial number must be searched in
both Base and delta to figure out the revocation status (even if an entry
for that serial exists in the base CRL).

> 
> 
> > "removeFromCRL" is a mechanism to indicate  that entry was removed
> > from CRL i.e. the cert referenced by that entry is not considered
revoked
> anymore.
> > The absence of the entry in the concurrent complete CRL indicates the
> > same thing.
> 
is
> _still_ "revocation information", no matter how you look at it.
>
[Piyush] You cannot conclusively  use a current CRL to determine the status
of a certificate sometime in the past.
But I hear your point. What you are saying is "add 1 to 0" and delete "1
from the result" is not same information as "0" because in former case you
know that add and delete operations were performed whereas in the latter
case you don't. 
However, I don't see any practical use of this information in context of
certificate revocation status check.
 
> Whether such information is useful or relevant for checks performed by the
> RP is highly dependent on the RP's usage scenario and/or purpose.
> For stuff that is also digitally timestamped (e.g. rfc3161), the
certificate status
> at the time indicated by the secure timestamp might be MUCH more
[Piyush] You cannot use current CRL to determine historical status. SO this
is a moot point.
> where the CA does stupid things such as removing revoked certs after they
> expire, or no longer accept and publish revocations for a cert that has
> expired?
[Piyush] Its optional. I wish you understand the tradeoffs before passing
judgments. In an environment where there is no need for historical
validation, including status of expired certificates is waste of space and
bandwidth. 
to
> determine and obtain the necessary CRL to determine the cert status for
> some point in the past for an already expired cert?
[Piyush] To find the status at time t, find a CRL whose thisUpdate is less
than t and nextUpdate is greater than t. 
How to find such a CRL is beyond the scope of the document. Consult your CRL
infrastructure administrator for additional information :).

> standardized and used, would make S/Mime/CMS pretty useless for offline
> use and archival, including use in EMail.
[Piyush] You have created an artificial requirement that historical
validations should be possible using current CRL. While it is nice to have,
it's not a requirement for every implementation, hence the option. In some
scenarios archival solutions can chose to archive the revocation information
source with the record of the transaction. In other scenarios they can
choose to include the revocation information beyond expiry.