Subject: RE: SCVP, OCSP-X and DCS

From: Philip Hallam-Baker <[email-masked]>
Date: Tue, 7 Mar 2000 09:09:42 -0800

I am absolutely opposed to any involvement with anything
called a CSL for two reasons:

1) We have too many acronymns already. There is no need to
	introduce yet another TLA for CRLs that only have
	suspended certificates. The term CSLs will confuse 
	customers and users. Two vendors are already using
	the term ARL for different purposes with predictable
	results.

2) The idea of certificate suspension is unworkable in
	principle and in practice. Everything that can
	be acomplished by suspension can be accomplished
	by centralized management of authorization info.

We have been over this ground repeatedly. Certificate 
suspension through CRLs simply is not viable, there is
no practical circumstance in which a suspension can
be cancelled reliably using CRLs. Ergo there is no
difference between suspension and revocation.

Distributing suspension data through a real time service
makes no sense since the same effect can be achieved through
removing authorizations from the cert.

To summarise, suspension is a bad idea, it is really
a weak form of Athorization data and the requirements should
be met by a full authorization data infrastructure.

Lets mark all the references to suspension 'depricated'
and have done with it.

		Phill

-----Original Message-----
From: Massimiliano Pala [mailto:[email-masked]]
Sent: Monday, March 06, 2000 7:53 PM
To: IETF-PXIX
Subject: Re: SCVP, OCSP-X and DCS

Denis Pinkas wrote:
> 
> Ambarish made a nice presentation of OCSP and SCVP at the RSA
> Conference. The OCSP document has expired and no discussion has
> recently taken place about it. A revision is expected soon. The
> expired version included a large section on open issues.

I'd like very much to see added a new response status to the
Valid/Revoked/Unkown list: Suspended.

This issued was raised when writing about CSLs (Suspension Lists).
I do admit there is a way to implement it with extensions (as
suggested on the list), anyway I'd like to see the 'Suspended'
response added. Someone shares this point of view ??

C'you,

	Massimiliano Pala ([email-masked])

---

From: Peter Williams <[email-masked]>
Date: Tue, 7 Mar 2000 10:13:37 -0800

madwolf:

Phil is totally opposed to certificate suspension,
and seems to believe that certificate management
by repositories should be confused with authorization
and access control enforcement systems.

Like Phil, I also do not believe suspension support should be 
a mandatory feature. Russ's view of a simple system 
should be the mandatory feature set; more complex
features can be selectively implemented by those
with more ambition and more demanding users. On
this latter issue, Phil and I diverge in opinion.

I am very much for suspension generally, along with
other status services that indicate a relying-parties
designation of status on a user and CA certificate. 
  
With the way that X.509 is setup, CRLs (using
various status codes) indicate formal status
on id and privilge attribute certs, as does
an OCSP service using CRL, repository or
other sourced data TODAY, in complete
PKIX compliance . One can suspend attribute 
certs, as one can suspend id certs. PKIX's
draft standards do not differentiate between
the types.

Lets note that some reasons for suspending
certs are given in the VeriSign CPS; one
important rationale for that design was
the need to address the vulnerabilities
in some enrollment protocols (such 
as the VeriSign CPS) which needed
to tightly confer, withhold or suspend CPS-validity 
status on an issued certificate.

The Microsoft Certificate Server's repository
can set and return arbitrary text status on certs to any user
of the ICertAdmin COM interface, as we
noted in the 1998 "Digital Certificates" book with
Java sample code (pg 404). Contrary
to Russ belief, it is not complicated at all,
in practice. It was not difficult then,
it is not difficult now.

But, we should note that the policy assigned meaning of 
suspension, like revocation,
is mainly a function of the CPS. Where support for
suspension notices is mandated by law, as in at least
one statute, national repositories need to be able
to respond. Private-market, DoD, and Internet-standard
repositories can do whatever their communities like,
of course.  

So madwolf: for internet standard app purposes, I suggest
you use a CRLDP to signal a list of certs with the held status 
code. Apart from the name, this IS a CSL. If the
CA or a CA-delegate issues the list, use CRLDP
construct as is. If another party issues the list, use
the indirect flag, and a DP name other than
than that of the CA. Of course, a CRLDP ios
only a CRL with the relevant extensions set to
give it appropriate semantics - like suspension
listing.

Refinements on the CRLDP implementation
of the CSL Construct welcome.

Peter.

-----Original Message-----
From: Philip Hallam-Baker
To: 'Massimiliano Pala'; IETF-PXIX
Sent: 3/7/00 9:09 AM
Subject: RE: SCVP, OCSP-X and DCS

 <<SMIME.txt>>

---

From: [email-masked]
Date: Tue, 7 Mar 2000 13:59:08 -0500

I would also recommend the use of suspension-only CRL's for Madwolf's
usage, but there is one hole in the use of suspension-only CRL's in the
current standard, if one uses delta CRL's.  As I believe I pointed out once
before,  ReasonFlags include certificateHold but do not include
removeFromCRL.  If delta CRL's are partitioned using distribution points in
this way, it is not clear where the unsuspensions get recorded.  Should the
definition of issuingDistributionPoint (in new part1 section 5.2.5) be
changed to include a statement similar to the following: "in a delta CRL,
if onlySomeReasons contains the certificateHold flag, in addition to
revocations with reason code certificateHold (also known as suspensions)
revocation entries with reason code removeFromCRL may appear."?  Or perhaps
the following: "With the following exceptions, if onlySomeReasons appears
all revocations in the CRL must have reason codes with names matching flags
in onlySomeReasons.  The exceptions to this rule are that the 'unused' bit
governs the placement of revocations with reason code 'unspecified' and
also those with no reason code present, and that the 'certificateHold' bit
governs the placement of revocations with reason code 'removeFromCRL' as
well as those with reason code 'certificateHold'".

          Tom Gindin