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

From: Sharon Boeyen <[email-masked]>
Date: Tue, 6 Mar 2001 10:34:42 -0500

From an X.509 perspective I want to clarify what DR 272 is intended to do. 
With respect to the portion of the path that includes the cert containing
the 
extension and the cert that is the final one in the path, that portion of
the path can
exceed the constraint value by 2. Here is the relevant text from the DR:

". Therefore the total length of this segment of the path, excluding
self-issued certificates, may exceed the value of the constraint by as many
as two certificates. (This includes the certificates at the two endpoints of
the segment plus the CA certificates between the two endpoints that are
constrained by the value of this extension.)".

If the term "end-entity" in the DR resolution is what is causing the problem
in PKIX, 
then I'm sure we can replace that term with another one (e.g. the final cert
in the path). The 
509 DR is NOT trying to comment on what the final cert represents (with
respect to a CA, end user etc). The 
term end-entity is this context was meant to differentiate that final cert
from an intermediary cert. This is exactly the same as what is done with the
similar text for delegation paths for attribute certs. 

Would replacing "end-entity" in the DR eliminate the PKIX problem?

I realize that the discussion has moved beyond the pure DR into the area of
"who can issue CRLs", but that is a separate issue from the path length
constraint in which the value in that integer represents the maximum number
of intermediary non self-issued certs between the two endpoints (where one
endpoint is the cert containing the extension and the other end-point is the
final cert in the path, regarless of the entity type that is its subject).

Sharon

> -----Original Message-----
> From: David Kemp [mailto:[email-masked]]
> Sent: Tuesday, March 06, 2001 9:18 AM
> To: [email-masked]
> Subject: Re: Open Issue in Part1: path length constraints
> 
> 
> Dave,
> 
> Then is it your suggestion that all PKIX words regarding issuance of
> CRLs by "conforming CAs" be extended to "conforming CAs and 
> end entities",
> or is it your suggestion that CRLs MUST NOT be verified except by a
> public key which is also permitted to verify certificates?
> 
> I strongly disagree with the latter, of course.
> 
> I disagree with the former too, since it is my belief that a 
> "conforming
> CA" is the organization which signs the CRL, not the public key which
> signs the CRL.  But if PKIX chooses to regard some CRL signers as end
> entities, then it must have words which permit some end entities to
> sign CRLs.
> 
> Dave
> 
> 
> 
> > Date: Mon, 05 Mar 2001 16:30:10 -0500
> > From: David Simonetti <[email-masked]>
> >
> > Dave,
> > 
> > Responding to your question:
> > 
> > > If that certificate has cA=false, and keyCertSign=0 and cRLSign=1,
> > > isn't the subject of the certificate "a conforming CA"?
> > 
> > No, it is an end entity.
> > --
> > David Simonetti
> > Securify (www.securify.com), 410-356-2260
> > 
>

---

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

Hi Steve,
    I think there is value to a non-CA providing status
information in all forms - CRLs, OCSP or DPV/SCVP. I agree that
we should clarify this.

Regards,
Ambarish

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

> From: Stephen Kent [mailto:[email-masked]]
> Sent: Wednesday, March 07, 2001 8:41 AM
> To: Ambarish Malpani
> Cc: [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?
> 
> Since you made the term up, I suppose a VA can do anything :-).
> 
> On a more serious note, we made an explicit provision for non-CA 
> signing of OCSP responses when OCSP was created. You are an author, 
> so you know this. But, you didn't seem to feel a need to create a 
> name for such entities at the time, which is OK too.  CRL signing 
> was, prior to v3, strictly the province of a CA. What it seems we 
> have in our docs, and to a lesser extent in the X.509 docs, is a 
> failure to clearly describe the intent to allow non-CA entities to 
> sign CRLs. I say this based on the mix of terms in 2459, and some 
> selected examples of text from X.509 that refer to an "authority" 
> without naming any sort of authority other than CAs (and AAs?).
> 
> So, going forward, if we want to allow non-CAs to perform this 
> function, let's just get the text to be clear on this point, and if 
> necessary, let's create a name for these entities, to minimize 
> confusion.
> 
> As for DPV, it is clear that it can be performed by a non-CA entity.
> 
> Steve
>

---

From: Sharon Boeyen <[email-masked]>
Date: Thu, 8 Mar 2001 09:38:58 -0500

I do think it is important that regardless of whether the entity signing a 
CRL or an OCSP response represents a CA or not, that relying parties have 
a clear path to determine whether or not to 'trust' such an indication of 
revocation status. For OCSP responders we have the AIA extension and for
CRLs
the issuer (if different than the cert issuer) can be indicated in the
crldp. 

Sharon

> Sent: Wednesday, March 07, 2001 5:19 PM
> To: Sharon Boeyen
> Cc: [email-masked]
> Sharon,
> >Re the X.509 language - The main reason you see terms  like 
> 'authority' and
> >CRL issuer instead of CA is that CRLs can also be issued for 
> >attribute certificates.
> >These CRLs would be signed by Attribute Authorities (AA) not by CAs. 
> >As editor,
> >one my editing tasks for the 2000 509 was to replace "CA" with 
> >"authority" wherever both CA and AA
> >were intended. That is the main reason you see these terms. There 
> >really hasn't been any
> >discussion in 509 on non CA, AA issued CRLs that I can remember. 
> >Taking this to the next
> >step, the definition of "authority" in X.509 (clause 3.3.6) is: "An 
> >entity, responsible for the issuance of certificates. Two types are 
> >defined in this Specification; certification authority which issues 
> >public-key certificates and attribute authority which issues 
> >attribute certificates." So, at least from the X.509 perspective an 
> >authority is either a CA or an AA.
> 
> Thanks for the clarification; it reaffirms my recent comments about 
> the scope of the term "authority." That says that there is no 
> explicit provision for non CA/AA issuance of CRLs in X.509. So, not 
> only does PKIX have to decide if it wants to create the notion of a 
> new sort of authority for CRL issuance, but then we have to see if 
> X.509 will follow this approach as well.
> 
> Steve
>

---

From: [email-masked] (Peter Gutmann)
Date: Fri, 9 Mar 2001 05:32:05 (NZDT)

"David P. Kemp" <[email-masked]> writes:

>Consider the following certificates:
>
>#  cA   CertSign  cRLSign    Effect
>- ----- --------  -------   ------------
>0  F     0         0        End Entity
>1  F     0         1        End Entity (can sign CRLs)
>2  F     1         0        End Entity
>3  F     1         1        End Entity (can sign CRLs)
>4  T     0         0    (Illegal*) Is a CA but can't sign certs or CRLs
>5  T     0         1    (Illegal*) Is a CA, can sign CRLs only
>6  T     1         0        CA, can sign certs
>7  T     1         1        CA, can sign certs and CRLs
>
>* As Dave S. points out, 4.2.1.10 prohibits cert types 4 and 5.

What about 2 and 3?  They can sign certs but they're not a CA, wouldn't this be
illegal?  (I proposed 2 in my autonomous certs draft for people who have
signing certs who want to issue their own encryption certs without going
through a CA, but apart from that special use I'm not sure what the semantics
for this combination are).

Peter.