Subject: RE: Open Issue in Part1: path length constraints

From: Ambarish Malpani <[email-masked]>
Date: Wed, 07 Mar 2001 08:41:56 -0800

Hi Denis,
    I don't have an issue with a single/multiple names. What I
was remarking is, is that IETF does have the concept of a
non-CA signing/providing validation responses.

We could call (a) an OCSP responder/server
              (b) an Indirect CRL Signer
              (c) a DPV/SCVP responder/server

Regards,
Ambarish

---------------------------------------------------------------------
Ambarish Malpani
Architect                                                650.567.5457
ValiCert, Inc.                                  [email-masked]
339 N. Bernardo Ave.                          http://www.valicert.com
Mountain View, CA 94043

> -----Original Message-----
> From: Denis Pinkas [mailto:[email-masked]]
> Sent: Wednesday, March 07, 2001 8:34 AM
> To: Ambarish Malpani
> Cc: 'Stephen Kent'; [email-masked]
> Subject: Re: Open Issue in Part1: path length constraints
> 
> 
> Ambarish,
> 
> > Hi Steve,
> >     While the term "VA" might not be part of the IETF standards,
> > it is the entity that can do the following:
> > 
> > a. Sign OCSP responses - where you directly trust the responder
> > b. Sign Indirect CRLs (I suppose this is a circular argument)!
> > c. Do the Delegated Path Validation protocol.
> > 
> > Agreed?
> 
> Certainly not !
> 
> This would create a confusion between:
> 
> 1) a server simply giving the revocation status of a certificate,
> 2) a server *advertising* revocation for others CAs,
> 3) a server saying if a certificate is valid according to some policy.
> 
> Please use different names!
> 
> Denis
> 
> > Regards,
> > Ambarish
> > 
> > 
> ---------------------------------------------------------------------
> > Ambarish Malpani
> > Architect                                                
> 650.567.5457
> > ValiCert, Inc.                                  
> [email-masked]
> > 339 N. Bernardo Ave.                          
> http://www.valicert.com
> > Mountain View, CA 94043
> > 
> > > -----Original Message-----
> > > From: Stephen Kent [mailto:[email-masked]]
> > > Sent: Wednesday, March 07, 2001 7:55 AM
> > > To: Ambarish Malpani
> > > Cc: [email-masked]
> > > Subject: RE: Open Issue in Part1: path length constraints
> > >
> > >
> > > Ambarish,
> > >
> > > >Steve, we use the Indirect CRL/Indirect delta CRL format to
> > > >propogate revocation information for particular CAs between
> > > >our VAs (Validation Authorities).
> > > >
> > > >Basically, as master VA can receive information that a particular
> > > >cert was revoked at a CA (even if the CA has not had time to
> > > >issue a new CRL as yet). It can (and does) create a Indirect
> > > >CRL with this information that it signs. The VA never acts
> > > >as a CA - it never issues certs, but still needs to be
> > > >responsible for creating and propogating revocation information
> > > >to other VAs.
> > > >
> > > >While we use these indirect CRLs to propogate information just
> > > >amongst VAs, it is not a stretch to seeing clients trust these
> > > >indirect CRLs for their own purposes.
> > > >
> > > >Hope this helps justify why it does make sense for non-CAs to
> > > >still issue CRLs.
> > >
> > > I understand the mechanism you are employing, and I see 
> nothing wrong
> > > with it. However, I don't think the notion of a "VA" is 
> part of ITU
> > > or IETF standards. Therefore, your use of it in a closed system
> > > environment is outside the scope of these standards.
> > >
> > > Steve
> > >
>

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 08 Mar 2001 10:32:28 +0100

Ambarish,

> Hi Denis,
>     I don't have an issue with a single/multiple names. 

This is fine. 

> What I was remarking is, is that IETF does have the concept 
> of a non-CA signing/providing validation responses.
> 

Some of them might be called Authorities. 

a) Revocation Status Authority - RSA  ;-)  
  (I am yet not sure if OCSP will or will not be extended and whether we 
  will keep the same name. If OCSP only relates to revocation status, then
OCSP Responder would be fine as well).

b) Not sure how we may call that service since indirect and direct entries
   can be mixed together in the same CRL. We have "CRL Issuer" has a generic
term, whether it is direct or indirect.

c) Path Validation Authority (DPV),

d) Path Discovery Helper (DPD).

Note: I am not strong on any of the above wordings. I only care that we use
different names for different security services and that we clearly identify
which service is performed by a given "Authority", "Issuer", "Responder",
"Helper", ...

Regards,

Denis