Subject: Backward-compatibility among certificates

From: "LUIZ CARLOS DO LAGO" <[email-masked]>
Date: Tue, 9 Jan 2007 16:18:48 -0300 (BRT)

Good Afternoon,

After create a new extension, does exist some kind of
backward-compatibility among certificates of
version 3 e earliers ?

If I have a certificate of version 3 appended with some extensions, and
I have legacy peers that know only to encode/decode certificates of
versions 1 or 2, do will that peers able to decode my certificate of
version 3 ignoring the extensions either something like that ?

Best Regards,

Luiz Lago

r (rsmail [10.1.1.3])
	by mscanner.perto.com.br (Postfix) with ESMTP id 7D9425FD2B
	for <[email-masked]>; Tue,  9 Jan 2007 16:21:06 -0300 (BRT)
From: "LUIZ CARLOS DO LAGO" <[email-masked]>
To: [email-masked]
Date: Tue,  9 Jan 2007 16:18:48 -0300 (BRT)
Subject: Backward-compatibility among certificates
Sender: [email-masked]

Good Afternoon,

After create a new extension, does exist some kind of
backward-compatibility among certificates of
version 3 e earliers ?

If I have a certificate of version 3 appended with some extensions, and
I have legacy peers that know only to encode/decode certificates of
versions 1 or 2, do will that peers able to decode my certificate of
version 3 ignoring the extensions either something like that ?

Best Regards,

Luiz Lago

---

From: Stephen Kent <[email-masked]>
Date: Tue, 9 Jan 2007 13:41:07 -0500

>version 3 ignoring the extensions either something like that ?

Luiz,

Only version 3 certs have extensions, so an implementation that 
understands only v1 or v2 certs will reject a v3 cert with any 
extensions.

For extensions in v3 certs, if the extension is NOT marked critical, 
then an implementation that does not know how to process the 
extension will ignore it.

Steve

---

From: Russ Housley <[email-masked]>
Date: Tue, 09 Jan 2007 16:43:48 -0500

Luiz:

RFC 2459, published in 1999, required support for v3 
certificates.  At this point, any application that cannot handle a v3 
certificate is stale.

Russ

---

From: "Moudrick M. Dadashov" <[email-masked]>
Date: Wed, 10 Jan 2007 03:05:45 +0200 (EET)

Hello,

I'm attaching a sample end entity cetrificate that the issuing CA claims
to be RFC 3280 compliant.

The certificate at least MUST provide document signing functionality.

Some of us say it's technically correct but has no legal purposes defined
and therefore can't be used for test purposes only, while others say it's
a universial one and can be used for all purposes.

Any comments are highly appreciated.

Thank you for your time,
M.D.

---

From: Russ Housley <[email-masked]>
Date: Wed, 10 Jan 2007 05:32:36 -0500

RFC 3280 does say:

    Conforming CAs MUST support key identifiers (sections 4.2.1.1 and
    4.2.1.2), basic constraints (section 4.2.1.10), key usage (section
    4.2.1.3), and certificate policies (section 4.2.1.5) extensions.

It does not seem to require that these be included in every 
certificate that is issued, but looking further into these sections, 
I find a MUST statement that is not supported by this certificate:

 From section 4.2.1.1  (Authority Key Identifier):

    The keyIdentifier field of the authorityKeyIdentifier extension MUST
    be included in all certificates generated by conforming CAs to
    facilitate certification path construction.

I would encourage the CA to include key usage and certificate 
policies extensions.

Russ

---

From: Alan Sill <[email-masked]>
Date: Wed, 10 Jan 2007 18:28:50 -0600

The document at the following link may be useful.  This is in fact  
the "Grid Certificate Profile" one mentioned in a previous thread,  
intended to give guidance on the issuance of end-entity host and  
personal certificates for grid use.  A correspondent of mine got it  
confused with an IETF document and sent a question based on it, which  
I inadvertently forwarded to this list, apologies.  It is not in fact  
an IETF document, but contains advice and "best practices" derived  
from the X.509-based grid community for the extensions, attributes  
and naming practices derived from several years from several  
organizations of issuing grid certificates.  I hope it is helpful as  
a reference.

Comments from the pkix list would probably be useful on this document.

Note it says regarding emailAddress, for example,

"The attribute type emailAddress SHOULD NOT be used in DNs. It has  
been obsoleted in RFC 3280, in favour of having an rfc822EmailAddress  
in the subjectAlternativeName X.509v3 extension, and many recent mail  
clients can deal with subjectAlternativeName.[1]

[1] String representation issues with the emailAddress attribute in  
DNs are caused by OpenSSL, where versions up to and including 0.9.6  
used the non-standard string representation "Email" for this  
attribute type, and later versions use “emailAddress”, thus resulting  
in different string representations for the same DN and leading to  
problems in subsequent authorisation decisions."

Other advice in this document is similarly based on real-world  
experience from various parties.  In almost all cases, arguments  
could be made on subtleties, but the document does try to place its  
statements in context where possible.  My hope in forwarding it is  
for useful comment, not extensive debate.

Hope this helps.

Document Name: Grid Certificate Profile

Document ID: doc13742

Description: This document describes the possibilities and  
limitations for attributes and extensions in X.509 certificates that  
are usable by grid infrastructures.

http://forge.gridforum.org/sf/go/doc13742?nav=1

On Jan 9, 2007, at 7:05 PM, Moudrick M. Dadashov wrote:

> <ivpk.cer>

Alan Sill, Ph.D
TIGRE Senior Scientist, High Performance Computing Center
Adjunct Professor of Physics
TTU

====================================================================
:  Alan Sill, Texas Tech University  Office: Admin 233, MS 4-1167  :
:  e-mail: [email-masked]   ph. 806-742-4350  fax 806-742-4358  :
====================================================================