Subject: draft-ietf-pkix-rfc3280bis-05.txt

From: "David A. Cooper" <[email-masked]>
Date: Mon, 16 Oct 2006 16:41:40 -0400

All,

I have just submitted draft -05 of 3280bis for posting.  As usual, a 
diff file highlighting the changes between draft -04 and draft -05 is 
available at 
http://csrc.nist.gov/pki/documents/PKIX/draft3280bis-04todraft3280bis-05_diff.html.

I will be out of the office, and not reading email, for the next two 
weeks.  I will read any comments submitted on this draft when I return.

The following is a summary of the changes in this draft:

1) Section 4.2.1.10 (name constraints) now states that conforming 
implementations SHOULD NOT impose name constraints on the x400Address, 
ediPartyName, or registeredID name forms.  Draft -04 said "MUST NOT"

2) Section 4.2.1.10 (name constraints) now states that conforming 
implementations MUST NOT issue certificates where name constraints is an 
empty sequence.

3) The descriptions associated with HTTP and FTP URIs have been modified 
in sections 4.2.1.13 (CRL Distribution Points), 4.2.2.1 (Authority 
Information Access), 4.2.2.2 (Subject Information Access), and 5.2.7 
(Authority Information Access).

4) Section 5.2.5  (Issuing Distribution Point) now states that 
conforming implementations MUST NOT issue CRLs where the DER encoding of 
issuing distribution point is an empty sequence.

5) Section 6.1.1 (Inputs) now includes initial-permitted-subtrees and 
initial-excluded-subtrees.  There is also a new paragraph at the end of 
section 6.1.1 state indicates that conforming implementations are not 
required to support all of the inputs (e.g., a conforming implementation 
could be designed to always initialize permitted_subtrees and 
excluded_subtrees in such a way that no initial constraints are imposed 
on names).  The descriptions for the initialization of 
permitted_subtrees and excluded_subtrees were changed in section 6.1.2 
to account for the two new inputs.

6) Section 6.2 now uses setting an initial path length constraint as an 
example of a possible extension to the path validation algorithm.  
Previous drafts used setting initial name constraints as an example.

7) Section 8:  References were updated as appropriate.

8) Comments were added to the ASN.1 in Appendix A.1 and a new paragraph 
was added to Appendix B (ASN.1 Notes) to clarify which attributes are of 
type DirectoryString.

Dave

---

From: "Anders Rundgren" <[email-masked]>
Date: Sun, 29 Oct 2006 11:12:02 +0100

The AIA caIssuers stuff is now a major improvement over RFC3280
which in this particular area had serious shortcomings.  Good job!

I still have some minor objections to some of the finer details.

That the pre-3280bis MIME-types embedded in millions of Web servers
are not mentioned is in my opinion somewhat odd taken in account that
the non-conformant but widely deployed use of RFC822 names in DNs
indeed is mentioned as a "legacy" (but deprecated) way of doing things.

I also believe that the "OR" regarding the SHOULD usage of HTTP
and LDAP access locators ought to be an "AND" since there is no
CA software of any significance that does not support both protocols,
while the same situation is AFAIK not the case with client software
such a mobile phones that typically only talk HTTP.   Deployers of
CAs do seldom have this information; it is in fact not even public.

thanx,
Anders Rundgren

----- Original Message ----- 
From: "David A. Cooper" <[email-masked]>
To: "pkix" <[email-masked]>
Sent: Monday, October 16, 2006 21:41
Subject: draft-ietf-pkix-rfc3280bis-05.txt

All,

Dave

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 31 Oct 2006 00:35:41 +0000

> I still have some minor objections to some of the finer details.

Personally, I'd be all for ignoring the n-th round of minor objections
to finer details that arrive without suggested text.

S.

---

From: "Anders Rundgren" <[email-masked]>
Date: Tue, 31 Oct 2006 22:08:08 +0100

When the id-ad-caIssuers accessMethod is used, at least one instance SHOULD specify an
 accessLocation that is an HTTP [RFC 1738] or LDAP [RFC 4516] URI. there SHOULD be at least one HTTP [RFC 1738] and one LDAP [RFC 4516] accessLocation URI specified.

Could this maybe fit in?
Anders

----- Original Message ----- 
From: "Stephen Farrell" <[email-masked]>
To: "Anders Rundgren" <[email-masked]>
Cc: "David A. Cooper" <[email-masked]>; "pkix" <[email-masked]>
Sent: Tuesday, October 31, 2006 01:35
Subject: Re: draft-ietf-pkix-rfc3280bis-05.txt

S.