Subject: 3280-bis AIA update

From: "Anders Rundgren" <[email-masked]>
Date: Tue, 19 Sep 2006 16:53:28 +0200

A quick survey among existing CAs show that they indeed
do not return the CA cert that is "superior" to the CA that
issued the EE cert containing the AIA extension, but rather
[the only reasonable,] the CA cert that issued the EE cert.

Maybe 3280-bis should be updated to reflect the actual
implementation of the AIA caIssuers extension?

An off-list message verified that several FIPS201 implementations
in the workings rely on a revised AIA caIssuers definition.

I also believe that the following text is not entirely appropriate:

  "The referenced CA issuers description is intended to aid
   certificate users in the selection of  a certification path"

The "description" is a list of certificates isn't it?
What is a "certificate user"?  It includes "applications" like
TLS-client-authentication as well I guess?

BTW, it would not hurt to add a few lines about how a list of CA
certificates should be packaged including references to applicable RFCs.

Anders

----- Original Message ----- 
From: "Anders Rundgren" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, September 14, 2006 23:32
Subject: AIA - No Issuing CA support?

RFC 3280   
   "The id-ad-caIssuers OID is used when the additional information lists
   CAs that have issued certificates *superior* to the CA that issued the
   certificate containing this extension.  The referenced CA issuers
   description is intended to aid certificate users in the selection of
   a certification path that terminates at a point trusted by the
   certificate user"

Assume I have a FIPS201 card (that as far as I can tell do not contain
any CA certificates at all), how can I locate the actual issuing CA?

Anders

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 19 Sep 2006 17:06:46 +0100

Anders,

If you could propose text for inclusion that'd make the Dave's
editing job much easier, if there is consensus to make whatever
change you propose.

I'm not being picky, its just not clear to me what change you'd
like,

Stephen.

---

From: "Anders Rundgren" <[email-masked]>
Date: Tue, 19 Sep 2006 19:54:51 +0200

At this stage I would be happy to know if my interpretation [*]
of the AIA extension is correct or not.   IF my interpretation
is correct, Dave's job ought to be verifying my claim that the
defintion is in conflict with the current practice for FIPS201 CAs.
IF this also is verified, the issue is what to do next.

Anders

*]

RFC3280: the additional information lists CAs that have issued certificates
*superior* to the CA that issued the certificate containing this extension

                     <>

Practice: the additional information lists CAs that have issued certificates
*including* the CA that issued the certificate containing this extension

----- Original Message ----- 
From: "Stephen Farrell" <[email-masked]>
To: "Anders Rundgren" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, September 19, 2006 18:06
Subject: Re: 3280-bis AIA update

Anders,

Stephen.

---

From: "David A. Cooper" <[email-masked]>
Date: Tue, 19 Sep 2006 17:13:58 -0400

Anders,

I agree that the language in RFC 3280 was confusing.  I would suggest
that you read section 4.2.2.1 of 3280bis, since you may find that the
changes you seek have already been made.  If you look at
http://csrc.nist.gov/pki/documents/PKIX/rfc3280todraft3280bis-02_diff.html
you will see a version of draft 2 of 3280bis in which all changes from
RFC 3280 are highlighted.   The current draft of 3280bis is draft 4
(http://www.ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-04.txt),
but section 4.2.2.1 has been practically unchanged since draft 2 (a
couple of typographical errors were fixed and a few references to
updated to newer RFCs).

Dave

Anders Rundgren wrote:

Anders

*]

<>

----- Original Message -----
From: "Stephen Farrell" <[email-masked]>
To: "Anders Rundgren" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, September 19, 2006 18:06
Subject: Re: 3280-bis AIA update

Anders,

Stephen.

Anders Rundgren wrote:

Anders

----- Original Message -----
From: "Anders Rundgren" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, September 14, 2006 23:32
Subject: AIA - No Issuing CA support?

RFC 3280

Anders

---

From: "Anders Rundgren" <[email-masked]>
Date: Wed, 20 Sep 2006 06:55:16 +0200

Hi Dave,
It was extremely pleasing to note that AIA now is going to be described in the way it is actually used :-)

I do though not fully agree with the notion that there should be a MUST for .cer and a SHOULD for application/pkix-cert because this is against the general web practice where file extensions are largely irrelevant since the source of an object often is a web application rather than a file.  Maybe this is because you regard "certificate user" as a human with browser trying to download a file which he or she is going to click on?  I see AIA as a programmatic interface used by cryptographic software.  Such "users" do not have much chance doing anything but trusting the file extension or mime-type.  Mime-type seems like a better choice here.  MUST please.

Regarding current CA practice, the file extension .crt seems pretty common and unfortunately there are other MIME-types in use as well.  I would investigate this a bit a write a few lines of "legacy implementations" that you SHOULD support  This is the price we have to pay due to the fact that AIA was originally a bit underspecified.

Anders

----- Original Message ----- 
From: David A. Cooper 
To: Anders Rundgren 
Cc: Stephen Farrell ; [email-masked] 
Sent: Tuesday, September 19, 2006 23:13
Subject: Re: 3280-bis AIA update

Anders,

I agree that the language in RFC 3280 was confusing.  I would suggest that you read section 4.2.2.1 of 3280bis, since you may find that the changes you seek have already been made.  If you look at http://csrc.nist.gov/pki/documents/PKIX/rfc3280todraft3280bis-02_diff.html you will see a version of draft 2 of 3280bis in which all changes from RFC 3280 are highlighted.   The current draft of 3280bis is draft 4 (http://www.ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-04.txt), but section 4.2.2.1 has been practically unchanged since draft 2 (a couple of typographical errors were fixed and a few references to updated to newer RFCs).

Dave

Anders Rundgren wrote: 

Anders

*]

                     <>

----- Original Message ----- 
From: "Stephen Farrell" <[email-masked]>
To: "Anders Rundgren" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, September 19, 2006 18:06
Subject: Re: 3280-bis AIA update

Anders,

Stephen.

Anders Rundgren wrote:

Anders

----- Original Message ----- 
From: "Anders Rundgren" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, September 14, 2006 23:32
Subject: AIA - No Issuing CA support?

RFC 3280   

Anders

---

From: "Anders Rundgren" <[email-masked]>
Date: Thu, 21 Sep 2006 23:25:09 +0200

If you follow the spec and want to be sure to be compatible with all compliant CAs your crypto software MUST support HTTP, LDAP, FTP(!), DAP(!), and SMTP(!) for accessing caIssuers data.
If it does not, it may fail to verify (servers) or may not let the client use a certificate in TLS-client-auth. since the path cannot be created.

According to off-list messages from the editors, the "community" behind a PKI is supposed to specify the rules required by "their" PKI.

Assume that the community is the Internet and there are numerous clients created by different vendors (who typically don't declare what they support in terms of AIA caIssuers access methods).

The Minimum

IMHO, a CA that creates a scheme that depends on the use of AIA caIssuers SHOULD or MUST deploy at least one HTTP URI.

If the idea is that PKI should sometimes down the road be able to challenge the zillions of user-id/passwords currently required by banks, community sites, governments, and employers, there should be no need to read the source code of implementations, hire pricy PKI consultants, or perform n*n product matrix testing just to get the path right.

If this change or recommendation is infeasible, the only reasonable work-around for an Internet-scale community is to follow the market leader who will define the actual standard.

Specifications versus Reality

Talking about market leaders I cannot help mentioning the AIA caIssuers extension URI I found in a recently received Microsoft certificate:
 http://www.microsoft.com/pki/mscorp/mswww(2).crt

W.r.t. to 3820bis it uses an incorrect file extension.  To make it even more "fun" it returns the non-standard MIME type: application/x-x509-ca-cert

Note: I still think this mess is the result of an initially underspecified, and delayed RFC, rather than a naughty vendor who don't care about standards.

Why not try to make it right when you actually have chance?

Like specifying a miinimalistic interoperable SHOULD/MUST scheme, and then describe (to the best of your ability), the "legacy" implementations that you MAY encounter.  This should NOT break any code but would lower the bar for new users of PKI.

Anders