Subject: Re: Looking for Standards

From: [email-masked] (Peter Gutmann)
Date: Wed, 14 Feb 2001 08:06:06 (NZDT)

"David P. Kemp" <[email-masked]> writes:

>Presumably you meant to say "There's no standard for this other than RFC
>2585", which "specifies the conventions for using FTP and HTTP to obtain
>certificates and CRLs from PKI repositories."

I don't really regard that as any sort of useful specification, "If you want to
get a cert from a server, fetch it by its URL" is a tautology for which I've
always wondered why it was necessary to publish an RFC [1].  What I was talking
about is something specifying the mechanisms you use to grab a cert when you
have an issuerAndSerialNumber, subjectKeyIdentifier, cert hash, or one of a
number of other commonly used identifiers (the situations I've run into were
for use with cert chains and S/MIME, so those were the identifiers which were
being used... oh yes, and issuerName as well).

The last time this came up I scribbled down some comments:

  My general thoughts were to just profile the use of GET with attributes
  rfc822Name, issuerAndSerialHash, subjectHash, and subjectKeyIdentifier (eg
  "GET /foo-cgi?rfc822Name=[email-masked]").  If there's more than one cert, it's
  returned as a multipart response.  If the cert is elsewhere, you get a
  40<whatever> redirect.  That's about all there is to it, it's just a simple
  interop profile so that we don't end up with a hundred similar but
  incompatible ways of doing it.

(that was after some poking around revealed that we were already heading
towards a situation where there'd be a hundred similar but imcompatible ways to
do this).

Peter.

[1] No offense to the authors, but... "Fetch a cert by specifying its URL" is
    the subject of a standards-track RFC?

---

From: Tim Polk <[email-masked]>
Date: Wed, 14 Feb 2001 10:30:43 -0500

Folks,

As you may recall, name constraints had emerged as a thorny issue at the 
San Diego meeting.  ISO had determined that the current name constraints 
extension did not satisfy all of their requirements, and was contemplating 
revisions.  However, the current name constraints extension were an 
acceptable solution for PKIX because RFC 2459 (and its successor) mandated 
that the subject field of all CA certificates MUST contain a non-empty DN.

The changes under consideration at that time in ISO could have resulted in 
divergent IETF and ISO specifications.  I feared that changes in name 
constraints would delay or prevent implementation of this extension.  At 
the San Diego meeting, we agreed to convey our concerns to ISO and 
encourage them to explore other options.  We agreed that the issue needed 
to be resolved by the middle of February.  This was reasonable, since ISO 
had a meeting in Geneva at the end of January.

In between the San Diego and Geneva meetings, there was a flurry of 
activity on this topic.  Entrust, NIST, and Spyrus worked actively to flesh 
out the business requirements that name constraints should satisfy, then 
determine if a functional shortfall existed.  We determined that a 
shortfall existed, and it could not be satisfied with the current 
syntax.  We also determined that the current extension efficiently 
represented the remaining requirements.

This information was used by members of the ISO Directory Working Group to 
develop semantics and syntax for a new ISO extension which implements all 
of ISO's requirements.  This extension contains an additional optional 
field to specify that a name type is required to appear in all following 
certificates.  The extension incorporates both current fields and their 
semantics are preserved.  The new extension was discussed at the Geneva 
meeting, and seems likely to be accepted and incorporated in X.509 in the 
future.  A new OID will be assigned to identify the new extension.

What does this mean for PKIX?

(1) The name constraints text in son-of-2459 will not need to be 
modified.  The current OID can still be used with the specified syntax, and 
the semantics are preserved.  This means we can proceed with Last Call.

(2) The new extension is processed EXACTLY the same way as the current 
extension when the one new field is not present.  As a result, it will be 
straightforward to process paths that include both the current name 
constraints extension and the version ISO is currently working on.

(3) As the ISO documents (e.g., the defect report or proposed resolution) 
become available,  the PKIX WG should review the text to ensure 
compatibility and understand the new functionality that is being 
offered.  (Hoyt Kesterson has consistently brought these documents to the 
attention of the PKIX WG.  Thanks, Hoyt!)

(4) As the specification matures, PKIX can add the new name constraints 
extension to the recognized extension set.

There were numerous contributors in this process.  I would like to 
recognize the following people: Sharon Boeyen, Serge Mister, and Carlisle 
Adams from Entrust, Russ Housley from Spyrus, and David Cooper from NIST.

Thanks,

Tim Polk

---

From: Steve Hanna <[email-masked]>
Date: Wed, 14 Feb 2001 16:22:48 -0500

A hearty thanks to Tim, Sharon, David, Carlisle, Serge, Russ, and
everyone else who helped arrange this peaceful, speedy, and positive
settlement!

Steve Hanna

---

From: Denis Pinkas <[email-masked]>
Date: Tue, 20 Feb 2001 10:14:06 +0100

Tim,

> This information 

Would it be possible that you post this document (or a summary of it) to the
mailing list so that all PKIX WG members may fully understand the rational ?

Thanks,

Denis

> was used by members of the ISO Directory Working Group to