Subject: Five AES Candidates

From: Russ Housley <[email-masked]>
Date: Tue, 10 Aug 1999 16:41:22 -0400

For those of you who have not heard, on Monday NIST announced the five
finalists for the Advanced Encryption Standard:

	MARS
	RC6
	Rijndael
	Serpent
	Twofish

More information is available at http://www.nist.gov/aes.

---

From: Robert Moskowitz <[email-masked]>
Date: Thu, 12 Aug 1999 09:43:27 -0400

Certain extensions are defined in 2459 as being for 'CA' certs.
Particularly BasicConstraints, PolicyMapping, and PolicyConstraints.

What is meant by 'CA' certs?  Is this restricted to 'root' or signing
certs?  Does it include croos-certs?  Is it defined anywhere?

I would think that PolicyMapping and PolicyConstraints are a **Bad** thing
to put in root or signing certs, as they are subject to change.  Also in a
cross-certified PKI, these certs are never examined in path construction or
validation.

It makes BIG sense to put them into cross-certs, thus a CA could define its
relation with another CA by the constraints IN cert it signs.  Also the
constraints could be unilateral.

It is OK to respond privately to me on this if the answer is commonly known
and I just can't find the reference.

Robert Moskowitz
ICSA
Security Interest EMail: [email-masked]

---

From: Robert Moskowitz <[email-masked]>
Date: Thu, 12 Aug 1999 10:31:49 -0400

5.3.3  Invalidity Date

   The invalidity date is a non-critical CRL entry extension that
   provides the date on which it is known or suspected that the private
   key was compromised or that the certificate otherwise became invalid.
   This date may be earlier than the revocation date in the CRL entry,
   which is the date at which the CA processed the revocation. When a
   revocation is first posted by a CA in a CRL, the invalidity date may
   precede the date of issue of earlier CRLs, but the revocation date
   SHOULD NOT precede the date of issue of earlier CRLs.  

I can see many cases where the Invalidity date WOULD precede the date of
issue of the earlier CRLs.

-	Come back from a vacation, find your system broken into.
-	Short CRL cycle times (eg 4 hours) and find it was comprimised 'yesterday'.
-	Cert is for a system, and HAC attack dated footprints found.

and so forth.  It would be NICE if this date is before previous CRLs, but
SHOULD NOT is too strong.

Of course, what does it mean?  Will anything look at it?  Probably only for
archival, CYA, purposes for the CA.

Robert Moskowitz
ICSA

---

From: Robert Moskowitz <[email-masked]>
Date: Thu, 12 Aug 1999 10:55:00 -0400

At 10:31 AM 8/12/1999 -0400, Robert Moskowitz wrote:

too much reading.  Not reading staight.  this is a straight forward
mis-reading of the quoted text.

<blush>

>   SHOULD NOT precede the date of issue of earlier CRLs.  

"invalidity date may precede the date of issue of earlier CRLs"

<blush off>

Robert Moskowitz
ICSA

---

From: Russ Housley <[email-masked]>
Date: Thu, 12 Aug 1999 13:12:54 -0400

Bob:

If the certificate belongs to an entity that will issue certificate to 
other entities, then the identified extensions should be included.  This is 
not just the "root" CA, but any CA.  These extensions should be included in 
the CA signature certificate that contains the public key that corresponds 
to the private key used to sign subordinate certificates.

RFC 2459 says:

    Conforming CAs MUST support key identifiers (see sec. 4.2.1.1 and
    4.2.1.2), basic constraints (see sec. 4.2.1.10), key usage (see sec.
    4.2.1.3), and certificate policies (see sec. 4.2.1.5) extensions. If
    the CA issues certificates with an empty sequence for the subject
    field, the CA MUST support the subject alternative name extension
    (see sec. 4.2.1.7).  Support for the remaining extensions is
    OPTIONAL. Conforming CAs may support extensions that are not
    identified within this specification; certificate issuers are
    cautioned that marking such extensions as critical may inhibit
    interoperability.

So, if you do not wish to include PolicyMapping and PolicyConstraints, you 
are not required to do so.

When two CAs cross-certify, the point is to allow the subordinates to 
validate each other's cetriciates.  As you point out, these cross 
certificates are the most likely to contain PolicyMapping and 
PolicyConstraints extensions.  However, is a complex hierarchy, there may 
be CAs superior to the point of cross certification.  These parent 
certificates may also contain PolicyMapping and PolicyConstraints 
extensions to constrain the privileges of the CAs involved in the cross 
certification.  In such an environment, the trusted point may be superior 
to the point where cross certification is performed.

Russ

---

From: Marc Branchaud <[email-masked]>
Date: Thu, 12 Aug 1999 10:40:46 -0700

Of the three extensions Bob mentioned (BasicConstraints, PolicyMapping,
and PolicyConstraints), the only one that I'd leave out of "root" CAs is
PolicyMapping.  I can easily envision creating a root CA that is
constrained as to levels of sub-CAs (BasicConstraints' path length) or
to specific policies.

Only PolicyMapping seems to make sense exclusively in cross-certs.

So I'm agreeing with Russ here, but I gotta say that the bit that Russ
quoted ...

>     cautioned that marking such extensions as critical may inhibit

... has nothing to do with the contents of a CA's certificate.  Rather,
the above specifies what extensions CAs have to support (i.e., be able
to include in issued certificates) to be PKIX-compliant.

Bob did mention something that has me puzzled:

> Also in a cross-certified PKI, [root] certs are never examined in path
> construction or validation.

I don't think that's true.  Aren't root/trusted certs used to initialize
the path processing algorithm?

		Marc

+------------------------------------------------------------------------+
 Marc Branchaud                                  \/
 Chief PKI Architect                             /\CERT INTERNATIONAL
INC.
 [email-masked]        PKI References page:             
www.xcert.com
 604-640-6227          www.xcert.com/~marcnarc/PKI/
+------------------------------------------------------------------------+
  PGP key fingerprint:  60 11 4B 9D 4E E5 2F 47  BD C5 C2 BF 26 DF 5A E1

---

From: Robert Moskowitz <[email-masked]>
Date: Thu, 12 Aug 1999 14:12:15 -0400

>the path processing algorithm?

OK.  The path construction starts with the EE's trusted cert, typically a
root cert.  But any other CA in the path root cert is not needed if the
linkcage is cross-cert.

Robert Moskowitz
ICSA

---

From: Robert Moskowitz <[email-masked]>
Date: Thu, 12 Aug 1999 14:22:34 -0400

At 01:12 PM 8/12/1999 -0400, Russ Housley wrote:
>other entities, then the identified extensions should be included.  

ERGO  'CA Certificates' Includes:

Root Certs (self-signed and hierarchically signed)
Signing Certs (though not all signing certs, a VA can have a signing cert)
Cross Certs

Any others?

Robert Moskowitz
ICSA

---

From: Russ Housley <[email-masked]>
Date: Fri, 13 Aug 1999 08:53:29 -0400

You have the correct idea.  But, can't we keep it simple?  A 
CA  certificate has a subject that can issue other 
certificates.  Obviously, the CA  certificate must contain a digital 
signature public key (not a key management public key).

Russ

---

From: Robert Moskowitz <[email-masked]>
Date: Fri, 13 Aug 1999 11:32:03 -0400

>signature public key (not a key management public key).

This makes sense, then raises another question.

Is KeyUsage Non-Repudiation bit set, since it is signing tbsCertificate?
(along with cRLsign bit).

Robert Moskowitz
ICSA

---

From: Marc Branchaud <[email-masked]>
Date: Fri, 13 Aug 1999 11:18:05 -0700

> root cert.  But any other CA in the path root cert is not needed if the

I think I was slightly confusing the CA at the top of a hierarchy with
the root ca that is the trust source in a path (using the definitions
from the Roadmap now).

I still feel the need to niggle with your statement, though.  Consider
this:

   A    D
   |    |
   B----E
   |    |
   C    F
   |    |
   1    2

where A-F are CAs and 1 & 2 are users.  A is at the top of the A-B-C
hierarchy and D is at the top of the D-E-F hierarchy.  Also, B and E
have cross-certified.

The path that 1 uses to verify a cert for 2 is sourced either at A or
C.  That is, 1 either implictly trusts A or C.  If 1 trusts C, then I
agree with your statement that other CAs in the path to A (say, if there
were CAs between B and A) would not be considered in the path that is
validated.  That path would be C-B-E-F-2.

But if A is the trusted CA (as is common is hierarchical PKIs), then the
path that is validated is A-B-E-F-2, and so extensions in A's cert (and
any certs between A and B) are included in the validation.

		Marc

---

From: Russ Housley <[email-masked]>
Date: Fri, 13 Aug 1999 13:58:15 -0400

Bob:

Within the key usage extension, both keyCertSign and crlSign should be 
TRUE. (unless separate private keys are used for signing these two objects).

The setting of the nonrepudiation bit is a rat hole, as you can see on 
other threads on ietf-pkix.  It does not impact cert path validation, so I 
would like to avoid that rat hole....

Russ