Subject: RE: Last Call: draft-ietf-pkix-new-part1-06.txt comments

From: Santosh Chokhani <[email-masked]>
Date: Wed, 18 Apr 2001 12:08:14 -0400

Russ:

More importantly, is the RFC saying that OCSP responder is a CA or AA.  I
think  it is neither.

-----Original Message-----
From: Jim Schaad [mailto:[email-masked]]
Sent: Wednesday, April 18, 2001 12:16 PM
To: 'Russ Housley'; [email-masked]
Subject: RE: Last Call: draft-ietf-pkix-new-part1-06.txt comments

Russ,

Two items:

1.  You also need to change the text on the basic constraints extension.
2.  This text implies to me that the cRLSign bit must be set for an OCSP
responder (it does revocation information) is that what you want?

jim

> -----Original Message-----
> From: Russ Housley [mailto:[email-masked]]
> Sent: Wednesday, April 18, 2001 8:07 AM
> To: [email-masked]
> Subject: Re: Last Call: draft-ietf-pkix-new-part1-06.txt comments
>
>
> Tim Polk and I just got off the phone.  After a lengthy
> discussion, we
> propose a revision to the cRLSign discussion:
>
>        The cRLSign bit is asserted when the subject public key is used
>        for verifying a signature on revocation information
> (e.g., a CRL).
>        This bit MUST be asserted in CA certificates that are used to
>        verify signatures on CRLs.  If the cRLSign bit is
> asserted in a CA
>        certificate, then the cA bit in the basic constraints extension
>        (see 4.2.1.10) MUST also be asserted.  If the cRLSign bit is
>        asserted in a non-CA certificate, then the cA bit in the basic
>        constraints extension MUST NOT be asserted.  Such non-CA
>        certificates MUST NOT be used to verify signatures on CRLs
>        containing revocation information for public key certificates;
>        however, these non-CA certificates MAY be used to verify
>        signatures on CRLs containing revocation information concerning
>        other types of certificates (e.g., attribute certificates).  If
>        neither the cRLSign bit nor the keyCertSign bit are
> asserted, then
>        the cA bit in the basic constraints extension MUST NOT be
>        asserted.
>
> Hey, this section was only one sentence in RFC 2459...
>
> Please let us know if anyone has any remaining concerns.
>
> Russ
>
>
> At 09:25 AM 4/18/2001 -0400, Russ Housley wrote:
> >Based on this discussion, I think that the working group wants the
> >keyCertSign and cRLSign key usage text to read as follows:
> >
> >       The keyCertSign bit is asserted when the subject public key is
> >       used for verifying a signature on public key
> certificates.  This
> >       bit MUST only be asserted in CA certificates.  If the
> keyCertSign
> >       bit is asserted, then the cA bit in the basic constraints
> >       extension (see 4.2.1.10) MUST also be asserted.  If
> neither the
> >       cRLSign bit nor the keyCertSign bit are asserted,
> then the cA bit
> >       in the basic constraints extension MUST NOT be asserted.
> >
> >       The cRLSign bit is asserted when the subject public
> key is used
> >       for verifying a signature on certificate revocation
> lists (CRLs).
> >       This bit MUST only be asserted in CA certificates and
> Attribute
> >       Authority (AA) certificates.  If the cRLSign bit is
> asserted in a
> >       CA certificate, then the cA bit in the basic
> constraints extension
> >       (see 4.2.1.10) MUST also be asserted.  If the cRLSign bit is
> >       asserted in an AA certificate, then the cA bit in the basic
> >       constraints extension MUST NOT be asserted.  If neither the
> >       cRLSign bit nor the keyCertSign bit are asserted,
> then the cA bit
> >       in the basic constraints extension MUST NOT be asserted.
> >
> >Let me know if you disagree.
> >
> >Russ
> >
> >At 02:31 PM 4/17/2001 +0100, Stephen Farrell wrote:
> >
> >>I'd also go along with Jim here - that an AA be allowed to
> >>have cRLSign set without having cA set in basicConstraints,
> >>i.e. that AA's be an exception to the general rule for EE's
> >>and that this be explicitly called out in son-of-2459. I'm
> >>assuming that keyCertSign is therefore not set for AA's too
> >>(and the text for keyCertSign shouldn't say "certificates",
> >>but "public key certificates").
> >>
> >>Stephen.
> >>
> >>Jim Schaad wrote:
> >> >
> >> > Russ,
> >> >
> >> > > -----Original Message-----
> >> > > From: Russ Housley [mailto:[email-masked]]
> >> > > Sent: Monday, April 16, 2001 10:33 AM
> >> > > To: [email-masked]
> >> > > Cc: [email-masked]
> >> > > Subject: Re: Last Call:
> draft-ietf-pkix-new-part1-06.txt comments
> >> > >
> >> > >
> >> > > Jim:
> >> > >
> >> > > >1. As currently written in section 4.2.1.3, it is not
> >> > > possible for a non-CA
> >> > > >CRL issuer to be created for attribute certificates.  Was
> >> > > this the final
> >> > > >resolution of this issue?  This seems to me to be
> >> > > problematic as it means as
> >> > > >an end-user one can issue an attribute certificate, but one
> >> > > must always use
> >> > > >a different agent, which is a CA, to issue the CRLs.  This
> >> > > means that all
> >> > > >attribute CRL issuers are indirect.
> >> > >
> >> > > I do not recall a consensus on this point.  Should an AA that
> >> > > supports CRLs
> >> > > have the cRLSign bit set in its public key certificate?  If
> >> > > so, this text
> >> > > must change.
> >> >
> >> > I don't recall anything except private discussions on
> this issue.  It is
> >> > here for the mailing list to comment on.
> >> >
> >> > It is my option that an AA that supports CRLs SHOULD
> have the cRLSign bit
> >> > set.  Either that or we ask X509 to create AACertSign
> and AACrlSign
> >> bits and
> >> > keep this current text as is.
> >> >
> >> > >
> >> > > >2. Section 4.2.1.3, paragraph last:  Current Text: "set in
> >> > > An instantiation"
> >> > > >modify to "set in an instantiation".
> >> > >
> >> > > Fixed.
> >> > >
> >> > > >3. Section 6.2 paragraph 2: change "prresented" to "presented"
> >> > >
> >> > > Fixed.
> >> > >
> >> > > >4. Section 6.2 paragraph 2:  The text "For example, an
> >> > > implementation may
> >> > > >specify name constraints that apply to a specific trust
> >> > > anchor." is diffcult
> >> > > >for me given that the validation algorithm explicitly states
> >> > > that name
> >> > > >constraints are not applied to self signed
> certificates. Suggest "For
> >> > > >example, an implemenation may modify the algorithm to apply
> >> > > name constaints
> >> > > >during the initialization phase."
> >> > >
> >> > > Self-signed certificates are a common mechanism for
> >> > > distributing public
> >> > > keys for trust anchors, but they are not a mandated
> >> > > mechanism.  That said,
> >> > > I think that your text it an improvement.   How about a hybrid:
> >> > >
> >> > >     For example, an implementation MAY modify the algorithm
> >> > >     to apply name constraints to a specific trust anchor
> >> > >     during the initialization phase.
> >> >
> >> > I have no problems with this new text.
> >> >
> >> > >
> >> > > >5. ASN module:
> >> > > >part1a.asn(352) : warning XXXXX: The imported symbol
> 'id-ad' is never
> >> > > >referenced
> >> > >
> >> > > Agree. I removed it.
> >> > >
> >> > > Russ
> >> > >
> >> > >
> >> >
> >> > jim
> >>
> >>--
> >>____________________________________________________________
> >>Stephen Farrell
> >>Baltimore Technologies,   tel: (direct line) +353 1 881 6716
> >>39 Parkgate Street,                     fax: +353 1 881 7000
> >>Dublin 8.                mailto:[email-masked]
> >>Ireland                             http://www.baltimore.com
>
>

---

From: "David Cross" <[email-masked]>
Date: Wed, 18 Apr 2001 09:21:04 -0700

I concur with Santosh.
 
David B. Cross

	-----Original Message-----
	From: Santosh Chokhani [mailto:[email-masked]] 
	Sent: Wednesday, April 18, 2001 9:08 AM
	To: [email-masked]; 'Russ Housley'; [email-masked]
	Subject: RE: Last Call: draft-ietf-pkix-new-part1-06.txt
comments

	Russ: 

	More importantly, is the RFC saying that OCSP responder is a CA
or AA.  I think  it is neither.

---

From: Santosh Chokhani <[email-masked]>
Date: Wed, 18 Apr 2001 13:12:58 -0400

Dave:

This text is clearer than your previous text and is also acceptable to me.
This accommodates OCSP responders nicely.

-----Original Message-----
From: David P. Kemp [mailto:[email-masked]]
Sent: Wednesday, April 18, 2001 1:08 PM
To: [email-masked]
Subject: Re: Last Call: draft-ietf-pkix-new-part1-06.txt comments

P.S., my preference is to not use the cA bit to make a distinction
between types of CRL signers, in which case the text is much simpler:

      The cRLSign bit MUST be asserted when the subject public key is
      used for verifying a signature on a CertificateList (e.g., a CRL).
      
      If the keyCertSign bit is asserted, then the cA bit in the 
      basic constraints extension (see 4.2.1.10) MUST be asserted.
      If the keyCertSign bit is not asserted, then the cA bit
      in the basic constraints extension MUST NOT be asserted.

Dave

"David P. Kemp" wrote:
> 
> The 9:25 AM version was clearer.  This version adds a restriction on
> which type of authority may sign which type of revocation list.  Neither
> version defines "CA certificate"; my impression was that
> 
>   If the cA bit is set, then the certificate *is* a CA certificate,
> 
> not the backwards-sounding
> 
>   If the cRLSign bit is asserted in a CA certificate, then the cA bit
>   MUST be asserted.
> 
> How about the following:
> 
>       for verifying a signature on a CertificateList (e.g., a CRL).
>       If the cA bit in the basic constraints extension (see 4.2.1.10)
>       is not asserted, then the public key MUST NOT be used to verify
>       signatures on CRLs containing revocation information for public
>       key certificates, however it may be used to verify signatures
>       on CRLs containing revocation information for other types of
>       certificates (e.g., attribute certificates).
>    *  If the cA bit is asserted, then the public key MUST NOT be used
>    *  to verify signatures on CRLs containing revocation information
>    *  for certificates other than public key certificates.
> 
>       If the keyCertSign bit is asserted, then the cA bit in the basic
>       constraints extension MUST be asserted.  If neither the cRLSign
>       bit nor the keyCertSign bit are asserted, then the cA bit in the
>       basic constraints extension MUST NOT be asserted.
> 
> The third sentence (marked ***) is new; I don't know if you intended
> the asymmetry of allowing CAs to revoke ACs but forbidding AAs from
> revoking PKCs.  If neither CAs nor AAs can revoke the other's certs,
> then the third sentence is needed.
> 
> Dave

---

From: Sharon Boeyen <[email-masked]>
Date: Wed, 18 Apr 2001 14:42:07 -0400

Hi Dave, you would use the SOAIdentifier extension (see 509 clause
15.3.2.1). 
This extension can ONLY be present in a public-key certificate issued to an
SOA. 
If an SOA wants to DELEGATE the authority to another AA to allow it to issue
attribute certs, that would be done in an attribute cert that contained the 
basicAttConstraints extension (see clause 15.5.2.1).

Sharon 

> From: David A. Cooper [mailto:[email-masked]]
> Sent: Wednesday, April 18, 2001 1:40 PM
> To: [email-masked]
> Dave,
> I agree with you. I see no basis in X.509 for setting the cA 
> flag in basicConstraints for certificate subjects that can 
> issue CRLs but not certificates. The current discussion about 
> how to deal with CRLs for attribute certificates vs. public 
> key certificates just further goes to show that it was a 
> mistake to suddenly change the rules at the last IETF meeting.
> 
> I must say, though, that I am still confused about what is 
> the correct thing to do when dealing with attribute 
> certificates. If the subject of a public key certificate can 
> issue attribute certificates but not public key certificates, 
> what bits in the key usage extension should be set? My 
> understanding is that the keyCertSign bit should not be set, 
> but this seems to leave digitalSignature as the next best option.
> 
> 
> At 01:08 PM 4/18/01 -0400, David P. Kemp wrote:

---

From: Russ Housley <[email-masked]>
Date: Wed, 18 Apr 2001 16:41:05 -0400

Sharon:

Russ, when I reviewed
your text, only one point came to mind. There are

cases where a single authority will act as both a CA for public-key
certificates

and an AA for attribute certificates. As such, it would
issue CRLs for the

public-key certs and CRLs for the attribute certs. If I'm interpreting
your

text correctly, you would not permit the same certificate to indicate
both?

The PKIX AC Profile explicitly forbids one entity from acting as both a
CA and an AA.  This restriction has been in the document from the
very first draft.

Russ

---

From: "Tom Gindin" <[email-masked]>
Date: Thu, 19 Apr 2001 11:23:30 -0400

Are there Key Purpose ID's defined for AA's and for OCSP responders
anywhere other than new-part1, where they don't exist?  If not, shouldn't
there be, and shouldn't we recommend that the PKC's for such entities
SHOULD contain them?  I think it's probably a little late for MUST.
     We also might want a separate Key Purpose ID for signing CRL's for
AA's only.

          Tom Gindin

Stephen Kent <[email-masked]> on 04/19/2001 10:40:37 AM

To:   "Michael Myers" <[email-masked]>
cc:   <[email-masked]>
Subject:  RE: Last Call: draft-ietf-pkix-new-part1-06.txt comments

At 9:34 PM -0700 4/18/01, Michael Myers wrote:
>Steve,
>>  From: Stephen Kent [mailto:[email-masked]]
>>  Sent: Wednesday, April 18, 2001 4:18 PM
>>
>>  . . .
>>  . . .  Nowhere in X.509 or in previous PKIX
>>  documents has there ever been text to suggest
>>  that other than a CA can sign a CRL for a
>>  public key certificate.
>
>I take it you mean CA as an entity vs. CA as the key the signed the
>certificate.

yes.

>
>>  Also, in responde to other messages I've just been reading, I want to
>>  pont out that OCSP responses are not CRLs . . .
>
>But one could (in fact it is being done) use OCSP to functionally replace
>CRLs.

yes, one could, but the name for the bit is specific to CRLs, not to
any revocation status mechanism that exists or might exist in the
future.

Steve

---

From: "David Cross" <[email-masked]>
Date: Thu, 19 Apr 2001 08:49:01 -0700

Denis said:

-->1) There has been a thread on the mailing list where I understand
that 
   the conclusion was that a "MUST" was not appropriate and should
either 
   be replaced by a "SHOULD" or even the whole sentence should been
deleted.

I concur.  This should be changed or hopefully eliminated.

David B. Cross