Re: Open Issue in Part1: path length constraints

[David Simonetti <dsimonetti@xxxxxxxxxxxx>]

Dave,

I agree with you on both points.

Dave S.

David Kemp wrote:

> Al,
>
> The question is what should be done about language such as RFC-2459
> section 5.1.2.5:  "This profile requires inclusion of <xxx> in all CRLs
> issued by conforming CAs."  In the case of CRLs signed by an end
> entity, I wouldn't want anyone to think that "This profile does not
> require inclusion of <xxx> in all CRLs issued by conforming end
> entities". :-)
>
> I'm quite happy with Warwick's "issued by conforming CRL Issuers".
> And I see you can accept that too.
>
> But to return to the original question: should path length constraints
> yield the identical results when the CRL Issuer is a CA and when the
> CRL Issuer is an end entity?   I say yes - a CRL should be accepted
> in one case iff it is accepted in the other case.
>
> Dave
>
> P.S. There is a difference between OCSP and CRLs - OCSP responses
> can be signed by a "trusted" responder (one which is not operated
> by the Certificate Management Authority, to use the DoD's term
> for the CA and it's authorized agents.)   CRLs, on the other hand,
> are never valid unless signed by the CA or the CA's designee.
> For that reason, I think it's reasonable to talk about CRLs being
> issued by the CA even when basicConstraints is absent in the CRL-signing
> cert.  But "CRL Issuer" says it all, so there is no reason pursue
> whether a CRL signed by the CA's agent is "issued" by the CA.
>
> > From: "Al Arsenault" <aarsenault@xxxxxxxxx>
> >
> > I would support the former, or some variant of it.  Let's be clear about
> > our terminology.  We don't call an entity which signs OCSP responses but
> > doesn't sign certificates and has basicConstraints absent a "CA".  We
> > shouldn't call an entity which signs CRLs but doesn't sign certificates and
> > has basicConstraints absent a "CA", either.
> >
> > If we're sloppy with the terminology, somebody later on is going to fail to
> > grasp the subtlety of it and get this wrong.

--
David Simonetti
Securify (www.securify.com), 410-356-2260