Subject: updated path validation text

From: Tim Polk <[email-masked]>
Date: Wed, 13 Oct 1999 17:36:39 -0400

Folks,

We are currently editing "son-of-RFC 2459" which should - no, *will* - be
posted by 5PM on October 22 (that is, before the Washington meeting
cut-off).  In general, that should be plenty of time to review and discuss
before the meeting.  Most of it is minor stuff, and pretty straightforward.

However, the current draft of section 6.1 (the path validation algorithm)
is significantly more detailed than the section 6.1 in RFC 2459.  It
probably bears additional review, so I wanted to circulate it ahead of the
rest of the I-D.  There are two basic changes:

#1 The old text left out details that appeared elsewhere in the
specification.  The new text is more comprehensive, addressing every field
or extension that affects whether a certification path is valid.

For example, the algorithm in section 6.1 assumed that unique identifiers
did not appear.  However, section 4.1.2.8 and 6.1 of RFC 2459 require that
UIDs be processed if they appear in a certificate, and this clearly affects
path validation.  The reader needed to augment the algorithm in 6.1 with
information from other sections of the document.  The new text explicitly
addresses the processing rules when UIDs apper in subject or issuer names.
This increases the bulk of the document, but should make it significantly
easier to use.

#2 ISO will be meeting Oct. 28 to consider some bug fixes that affect
processing of the certificate policies extensions and related constraints.
The bugs were important, causing unexpected acceptance of certain
certification paths!  Our goal is to incorporate the bug fixes into
"son-of-RFC 2459" so that policy and path processing in the ISO and IETF
specifications are equivalent. This text incorporates what we *expect* to
be the ouput of the Oct. 28 ISO meeting.  At least, it matches several
countries ballot comments...

Anyway, I have attached my current draft of section 6.1.  I believe this
text to be comprehensive, and I think it is in line with the changes ISO
will *probably* make regarding the defect report.

Please take a long, hard look at this text!  Your comments are appreciated!

Thanks,

Tim Polk

P.S.  Sorry about the Word attachment.  The straightforward conversion to
text lost all the formatting/indenting , and I think that really helps the
readers' comprehension.  If anyone asks, I will convert it to a nice UNIX
text file and repost.  Otherwise, it will get fixed when I convert to
nroff...

---

From: Robert Moskowitz <[email-masked]>
Date: Thu, 14 Oct 1999 17:02:16 -0400

>text file and repost.  Otherwise, it will get fixed when I convert to

here is it mostly cleaned up..

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

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Thu, 14 Oct 1999 14:31:07 -0700

>here is it mostly cleaned up..

That is *not* clean, *nor* is it complete. The beginning of the file you 
sent reads:

                Upon completion of all steps, path processing has
                succeeded if the value of explicit_policy variable is
                greater than zero, or the valid_policy_tree is not NULL.

             6
              .1

                .
                 6
                   O

                    ut
                      p
                       u
                        t

                         s

Could people who have alternative formats for documents pass those files to 
the document authors and let those authors turn them in? If you want to 
help Tim, send the file to Tim, not the whole list. He can decide whether 
or not to make this a list thing.

Also, as the maintainer of the web site, I'm happy to take a file from you 
and put it on the web site so you can just send a pointer. That way, the 
subset of the 1170 people on this mailing list who can't read your format 
don't have to waste their time with downloading a file they can't read.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: Denis Pinkas <[email-masked]>
Date: Mon, 25 Oct 1999 17:57:42 +0100

Tim,

Thanks for sending the section in advance, since we have not yet
since the draft, that was (?) posted by 5PM on October 22.  :-)

> before the meeting.  Most of it is minor stuff, and pretty straightforward.

(text deleted)

> Please take a long, hard look at this text!  Your comments are appreciated!

Since you asked, here is some feedback.

In RFC 2459, we had five state variables, now we have twelve !
Verifying the accuracy of the whole description can only be done
while implementing the specification. However, besides the
complexity, I would like to point to some concerns.

I tried to read the text as a new reader and found that the text on
contrained subtrees works fine when subject (DN) names are used, but
it is not clear to understand the description when subjectAltNames
are used in leaf certificates.

Another concern is the following : the whole approach is implictly
making the assumption that all the information for path validation
is within the certificates themselves. This is one approach. Another
approach, which can be used in combination, is to allow some of the
information normally carried out in certificates (e.g. the
equivalent of the contrained subtrees) to be defined in a local
policy. The text should allow for that alternative.

Denis