Subject: Revocation scheme definition

From: Jorge López <[email-masked]>
Date: Tue, 7 Apr 2009 13:42:14 +0200

Hi all,

Next I merely offer personal considerations about the (in my opinion)
confusing scenario of PKI terminology classification. I would appreciate any
comment on this.

As can be seen in the literature, most people define CRL, Partitioned CRL,
Over-issued CRL, Delta CRL, OCSP, NOVOMODO, Certificate Revocation Status,
Certificate Revocation Tree, etc. as revocation schemes. I think this
"classification" is confusing.

I personally consider a revocation scheme as a scheme/protocol where the
owner (or an authorised party) is able to revocate the status of her
certificate. For example, the one defined in RFC 4210 CMP. However, the
terms mentioned above relate to data structures (CRL, Partitioned CRL, Delta
CRL), mechanisms to make that data structure available to others
(Over-Issued CRL, Over-Issued Segmented CRL, etc.) and both the managed data
structure and the associated publication mechanism (NOVOMODO, Certificate
Revocation Tree, etc.). But none of them to the procedure to be followed in
order to revocate the certificate! If fact OCSP is sometimes referenced as a
revocation scheme, when it is actually focused on "just" checking the
revocation status of a certificate...

>From my viewpoint, I would differentiate among the scheme, the certificate
status information itself - CSI (data structure) - and the method that
distributes/publishes the CSI. A revocation scheme updates the CSI. However,
the publication/distribution method is oriented to support the validation of
certificates. IMHO it has nothing to do with a revocation scheme. Perhaps
you may consider appropiate to include in the term "revocation scheme"
everything that has something to do with the revocation information...

Therefore, I distinguish a revocation scheme from another type of scheme
(validation scheme) which aim is to check the status of a certificate taking
into account the CSI. This CSI could be distributed/published by using one
of the methods defined above, or accessed in an online manner (an OCSP
service that retrieves the CSI from a fresh database).

I guess that the revocation scheme term has been extended to things not so
related to the revocation itself, like the validation procedure. I just want
to know what the PKI community think about this.

Thanks in advance,

--------
Jorge Lopez Hernandez-Ardieta

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 08 Apr 2009 01:00:29 +0200

Jorge,

Despite that I would love to put CSI expert on my business card, it might be
a bit problematic to hijack this acronym :)

Other than that I feel sympathetic to your distinction between revocation
and validation. It is however my belief that we have used that distinction
in our standards efforts.

/Stefan

On 4/7/09 1:42 PM, "Jorge López" <[email-masked]> wrote:

> I personally consider a revocation scheme as a scheme/protocol where the owner
> (or an authorised party) is able to revocate the status of her certificate.
> For example, the one defined in RFC 4210 CMP. However, the terms mentioned
> above relate to data structures (CRL, Partitioned CRL, Delta CRL), mechanisms
> to make that data structure available to others (Over-Issued CRL, Over-Issued
> Segmented CRL, etc.) and both the managed data structure and the associated
> publication mechanism (NOVOMODO, Certificate Revocation Tree, etc.). But none
> of them to the procedure to be followed in order to revocate the certificate!
> If fact OCSP is sometimes referenced as a revocation scheme, when it is
> actually focused on "just" checking the revocation status of a certificate...
> 
> certificates. IMHO it has nothing to do with a revocation scheme. Perhaps you
> may consider appropiate to include in the term "revocation scheme" everything
> that has something to do with the revocation information...
> 
> into account the CSI. This CSI could be distributed/published by using one of
> the methods defined above, or accessed in an online manner (an OCSP service
> that retrieves the CSI from a fresh database).
>

---

From: "David A. Cooper" <[email-masked]>
Date: Wed, 08 Apr 2009 10:19:25 -0400

Stefan Santesson wrote:
> Despite that I would love to put CSI expert on my business card, it 
> might be a bit problematic to hijack this acronym :)

Yes, RFC 5513 points out the problem of the overuse of three letter 
acronyms (granted it is an April 1 RFC).  If we used the acronym CSI, 
most people would tend to immediately think of the College of Southern 
Idaho ... I mean the College of Staten Island ... Computer Security 
Institute ... Construction Specifications Institute ... Commodity 
Systems Inc. ... Computers & Structures, Inc. ... Chi Sigma Iota ... 
Christian Schools International ... Computational Systems, Inc. ... 
Christian Solidarity International ... California Solar Initiative ... 
Canadian Solar Inc. ... Chandler Systems Inc. ... Communications 
Specialties, Inc. ... Cetacean Society International ... Coalition of 
Service Industries ... Church of South India ... Computer Society of 
India ... Cellular Specialties, Inc. ... College Student Insurance ... 
Custom Systems Integration ... Center for Social Innovation ... Center 
for Sustainable Innovation ... Creative Specialties International ... 
Control Sciences Inc. ... Conditional Symmetric Instability ... 
Community Services Infrastructure ... Coastal Studies Institute ... 
Curriculum Support Information ... Control Solutions International ... 
Conversion Services International ... Civil Society International ... 
Collaborative Software Initiative ... Consolidated Systems Incorporated 
... Center for the Study of Intelligence ... Combat Studies Institute 
... Coatings Societies International ... Chemical Sampling Information 
... California Steel Industries ... Cardiovascular Systems Inc. ... 
Conservation Study Institute ...  Cognitive Strategy Instruction ... 
Compliance Services International ... Cement Sustainability Initiative 
... Cyber Safety Initiative ... Center for Student Involvement ... 
Center for the Study of Inequality ... Chiropractic Sports Institute ... 
Closure Systems International ... Custom Scientific Instruments ... 
Crisis Simulations International ... Cooperative Sagebrush Initiative 
... Child Study Institute ... Climate Status Investigations ... 
Centrifugal Services, Inc. ... Conflict Solutions International ... 
Caregiver Services, Inc. ... Charter School Institute ... Component 
Sources International ...

So I can understand that you would be concerned that if you referred to 
yourself as a CSI expert, people might think you meant that you were an 
expert in Computational Sciences and Informatics.

> Other than that I feel sympathetic to your distinction between 
> revocation and validation. It is however my belief that we have used 
> that distinction in our standards efforts.

I think it would be helpful if specific examples were provided of places 
in PKIX documents in which the distinction between mechanisms for 
distributing certificate status information (e.g., CRLs and OCSP) and 
mechanisms for submitting revocation requests (e.g., a CMP revocation 
request message) is not clear.  Perhaps this confusion does appear in 
the literature, and those of us on this list simply don't notice it 
since we already clearly understand the concepts.  But without being 
provided specific examples of text that a non-PKI expert might find 
confusing, it is difficult for us to judge whether this is a problem in 
PKIX documents that the WG needs to be more careful about in future 
documents.

Dave

>     Next I merely offer personal considerations about the (in my
>     opinion) confusing scenario of PKI terminology classification. I
>     would appreciate any comment on this.
>
>     As can be seen in the literature, most people define CRL,
>     Partitioned CRL, Over-issued CRL, Delta CRL, OCSP, NOVOMODO,
>     Certificate Revocation Status, Certificate Revocation Tree, etc.
>     as revocation schemes. I think this "classification" is confusing.
>
>     I personally consider a revocation scheme as a scheme/protocol
>     where the owner (or an authorised party) is able to revocate the
>     status of her certificate. For example, the one defined in RFC
>     4210 CMP. However, the terms mentioned above relate to data
>     structures (CRL, Partitioned CRL, Delta CRL), mechanisms to make
>     that data structure available to others (Over-Issued CRL,
>     Over-Issued Segmented CRL, etc.) and both the managed data
>     structure and the associated publication mechanism (NOVOMODO,
>     Certificate Revocation Tree, etc.). But none of them to the
>     procedure to be followed in order to revocate the certificate! If
>     fact OCSP is sometimes referenced as a revocation scheme, when it
>     is actually focused on "just" checking the revocation status of a
>     certificate...
>
>     From my viewpoint, I would differentiate among the scheme, the
>     certificate status information itself - CSI (data structure) - and
>     the method that distributes/publishes the CSI. A revocation scheme
>     updates the CSI. However, the publication/distribution method is
>     oriented to support the validation of certificates. IMHO it has
>     nothing to do with a revocation scheme. Perhaps you may consider
>     appropiate to include in the term "revocation scheme" everything
>     Therefore, I distinguish a revocation scheme from another type of
>     scheme (validation scheme) which aim is to check the status of a
>     certificate taking into account the CSI. This CSI could be
>     distributed/published by using one of the methods defined above,
>     or accessed in an online manner (an OCSP service that retrieves
>     the CSI from a fresh database).
>
>     I guess that the revocation scheme term has been extended to
>     things not so related to the revocation itself, like the
>     validation procedure. I just want to know what the PKI community
>     think about this.
>
>     Thanks in advance,
>
>     --------

---

From: Jorge López <[email-masked]>
Date: Wed, 8 Apr 2009 16:57:54 +0200

Thanks Stefan and Dave for your responses.

Well, maybe CSI was not the best acronym as a proposal :-)

I wasn't talking about PKIX documents, but some research papers,
master/doctoral thesis where a classification of "revocation mechanisms" is
made. I understand that these domains are out of the scope of the PKIX
community, but maybe we should think of "standardizing" some concepts if the
"rest of the world" tends to confuse them. I think that's one of the tasks
of a standardization organization/work group/etc.

Possibly it is not worthy to work on it focusing merely on revocation scheme
related terms, but I have been following a thread about digital
certificate/end user certificate/etc. terms that seemed to be confusing as
well to some folks.

Is it crazy to propose an RFC Informational which collects a kind of
glossary and definitions of PKIX related technology?

Best,

--------

2009/4/8 David A. Cooper <[email-masked]>

> Stefan Santesson wrote:
>
>> Despite that I would love to put CSI expert on my business card, it might
>> be a bit problematic to hijack this acronym :)
>>
>
> acronyms (granted it is an April 1 RFC).  If we used the acronym CSI, most
> people would tend to immediately think of the College of Southern Idaho ...
> I mean the College of Staten Island ... Computer Security Institute ...
> Construction Specifications Institute ... Commodity Systems Inc. ...
> Computers & Structures, Inc. ... Chi Sigma Iota ... Christian Schools
> International ... Computational Systems, Inc. ... Christian Solidarity
> International ... California Solar Initiative ... Canadian Solar Inc. ...
> Chandler Systems Inc. ... Communications Specialties, Inc. ... Cetacean
> Society International ... Coalition of Service Industries ... Church of
> South India ... Computer Society of India ... Cellular Specialties, Inc. ...
> College Student Insurance ... Custom Systems Integration ... Center for
> Social Innovation ... Center for Sustainable Innovation ... Creative
> Specialties International ... Control Sciences Inc. ... Conditional
> Symmetric Instability ... Community Services Infrastructure ... Coastal
> Studies Institute ... Curriculum Support Information ... Control Solutions
> International ... Conversion Services International ... Civil Society
> International ... Collaborative Software Initiative ... Consolidated Systems
> Incorporated ... Center for the Study of Intelligence ... Combat Studies
> Institute ... Coatings Societies International ... Chemical Sampling
> Information ... California Steel Industries ... Cardiovascular Systems Inc.
> ... Conservation Study Institute ...  Cognitive Strategy Instruction ...
> Compliance Services International ... Cement Sustainability Initiative ...
> Cyber Safety Initiative ... Center for Student Involvement ... Center for
> the Study of Inequality ... Chiropractic Sports Institute ... Closure
> Systems International ... Custom Scientific Instruments ... Crisis
> Simulations International ... Cooperative Sagebrush Initiative ... Child
> Study Institute ... Climate Status Investigations ... Centrifugal Services,
> Inc. ... Conflict Solutions International ... Caregiver Services, Inc. ...
> Charter School Institute ... Component Sources International ...
>
> I think it would be helpful if specific examples were provided of places in
> PKIX documents in which the distinction between mechanisms for distributing
> certificate status information (e.g., CRLs and OCSP) and mechanisms for
> submitting revocation requests (e.g., a CMP revocation request message) is
> not clear.  Perhaps this confusion does appear in the literature, and those
> of us on this list simply don't notice it since we already clearly
> understand the concepts.  But without being provided specific examples of
> text that a non-PKI expert might find confusing, it is difficult for us to
> judge whether this is a problem in PKIX documents that the WG needs to be
> more careful about in future documents.
>
> Dave
>
>

---

From: "David A. Cooper" <[email-masked]>
Date: Wed, 8 Apr 2009 10:19:25 -0400

Dave

---

From: Jorge López <[email-masked]>
Date: Wed, 8 Apr 2009 16:57:54 +0200

Best,

--------

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 8 Apr 2009 01:00:29 +0200

Jorge,

/Stefan