Subject: I-D ACTION:draft-ietf-pkix-rfc3280bis-01.txt

From: [email-masked]
Date: Wed, 20 Jul 2005 15:50:04 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.

	Title		: Internet X.509 Public Key Infrastructure 
                          Certificate and Certificate Revocation List (CRL) Profile
	Author(s)	: D. Cooper, et al.
	Filename	: draft-ietf-pkix-rfc3280bis-01.txt
	Pages		: 138
	Date		: 2005-7-20
	
This memo profiles the X.509 v3 certificate and X.509 v2 Certificate
   Revocation List (CRL) for use in the Internet.  An overview of this
   approach and model are provided as an introduction.  The X.509 v3
   certificate format is described in detail, with additional
   information regarding the format and semantics of Internet name
   forms.  Standard certificate extensions are described and two
   Internet-specific extensions are defined.  A set of required
   certificate extensions is specified.  The X.509 v2 CRL format is
   described in detail, and required extensions are defined.  An
   algorithm for X.509 certification path validation is described.  An
   ASN.1 module and examples are provided in the appendices.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-01.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-rfc3280bis-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-rfc3280bis-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: "David A. Cooper" <[email-masked]>
Date: Wed, 20 Jul 2005 17:31:01 -0400

>http://www.ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-01.txt

I have posted two "diff" files on the NIST Web site: one showing the 
differences between 3280bis-00 and 3280bis-01 and one showing the 
differences between RFC 3280 and 3280bis-01.  They are available at:

http://csrc.nist.gov/pki/documents/PKIX/draft3280bis-00todraft3280bis-01_diff.html

and

http://csrc.nist.gov/pki/documents/PKIX/rfc3280todraft3280bis-01_diff.html

While I would encourage people to review the "diff" files to see what 
changes have been made, here is a list summarizing some of the changes 
that were made between draft -00 and draft -01:

1) The descriptions of some of the keyUsage bits have been changed based 
on discussions on the PKIX mail list.

2) Section 4.2.1.9 has been modified to clarify that while conforming CA 
certificates MUST include a basicConstraints extension, applications MAY 
use certificates that do not include the basicConstraints extension as 
intermediate certificates if the certificates are version 1 or 2.

3) The rules for specifying name constraints for URIs have been changed 
back to the rules that were in RFC 3280.

4) In order to align with draft-zeilenga-ldap-x509-01.txt, all example 
LDAP URIs (in the cRLDistributionPoints, authorityInfoAccess, and 
subjectInfoAccess extensions) specify the ";binary" option.

5) Sections 5 and 5.2.5 have been modified to clarify the meaning of an 
indirect CRL.

6) Section 6.1 includes a new paragraph that explains that the path 
validation algorithm is not intended to verify that certificates and 
CRLs are issued in conformance with the PKIX profile.

7) The sample certificates in appendix C have been changed.

Dave

---

From: Peter Sylvester <[email-masked]>
Date: Thu, 21 Jul 2005 19:29:08 +0200

It would be nice to see what remarks of make 3 months ago have been
taken into account, and which have not.

Anyway, so far, as I see, two months ago the discussion stopped
because some questions remained unanswered:

1 - The text still does not allow to include all elements that have
  been used in the decision making, as required by the requirement
  text.
  What problems do the authors see to add an SCVP reponse similar
  as an OCSP response. It is unacceptable to require an extension
  for this, since relaying and loop chaceking is already a supported
  feature.

2 - Russ Housley has not responded to the remark that an additional
  encapsulation of data types inside octet strings needs
  another invocation of a parsers.

3 - IMO, the ResponseFlags structure should be replaced by a bitstring
  with 4 named bits and an appropriate default value.

4-  The MUST concerning that an empty SEQUENCE of a responseflag
  MUST be omitted has not justification, is useless, and adds another
  rather irrelevant test case.

5 -  The ASN1 syntax should not use obsolete ASN.1 features.

6 - I think it has been said before that the ValidationAlgorithm should
  rather be a sequence of validation features, e.g. a new test  that
  is added globally an independantly from  any other algorithm
  requires that for all known algorithm, e.g. the name algorithm
  the parameters need to be repeated.

7 - specifying anKeyUsage as NULL and not just as an empty sequence
  requires two additional octets in the encoding, something that seems
  to be an important concern if I look at the response flag definition
  and the default handling.

8 - The usage of requesterRef for loop control is inconsistent with
  the definition of requesterRef which is named as of local relevance
  of the initial client and any intermediate server, thus it doesn' make
  sense to check for HIS own identifier.
  Since an initial client doesn't necessarily know whether a request is
  relayed, a relaying server cannot have one single requesterRef, since
  the client can accidentally use this one.
  at least the loop control should take into account the FIRST element
  in the requesterRef sequence.

  Since servers are required to encode the dns name of the server
  I don't think that a requester reference like this is the appropriate way
  to do loop control, and instead the requesterNames should be used.
  The dns name is not good anyway, since a server may relay to itself
  with a different backend policy, or just to a different URL on the same
  host. In the current text relaying implies uniqueness at the DNS level,
  a restriction that is not available at the transport level.

9 - The text about the BER encoding of the data structures does not
  say anything about the encoding of a CMS security envelope.
  Can one use XER encoding of a CMS envelope?
 
  I think the intent is to send ALWAYS a ContentInfo, which is either
  one of the SMIME types and which inside must have one encapsulated
  type defined in the doc, thus one does not send the raw CVRequest
  etc.

10 - There are three occurences of so called examples of CMS encapsulations
  which are not really examples, since they only differ in the content-type.
  Is there any reason why a ValPolRequest cannot benefit from CMS
  security encapsulations, and why does a ValPolResponse cannot alos
  be just authenticated in any way?
 
  It seems to me that both the citations of SignedData and AuthenticatedData
  should be either omitted or all of them folded into a single paragraph 
about
  'Data presentation and security envelopes' or actually all that could go
  into some  extension of 4.13 which seems to apply to ALL responses.

11 - 4.13 is inconsistent with the permitted use of TLS, which is 
mentioned in
  the security section, and in 3.2.5.2

12 - Using BER as an encoding rule is somewhat problematic when you want
  to refer to the HASH of the encoded request. It requires that the original
  encodings are kept in all cases.

Peter

---

From: Peter Sylvester <[email-masked]>
Date: Thu, 28 Jul 2005 19:16:22 +0200

I add some remark/question to my previous list of items.

- Some of them seem wrong to me.

-  4.6 says that requestRef is a Hash if CVRequest as an option.

  it is allowed to have an anonymous CVRequest just encapsulated
  in a ContentInfo. How is the hash is to be calculated in this case?

  Is it meant to hash the whole ContentInfo or something else?

- A COPY of the CVRequest does not contain
  the authenticated attributes, at least this is what seems to
  be written. Is this intended that the content-type is
  not included in this case?