Subject: [pkix] I-D Action:draft-ietf-pkix-ta-format-04.txt

From: [email-masked]
Date: Thu, 15 Oct 2009 04:15:02 -0700 (PDT)

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           : Trust Anchor Format
	Author(s)       : R. Housley, et al.
	Filename        : draft-ietf-pkix-ta-format-04.txt
	Pages           : 19
	Date            : 2009-10-15

This document describes a structure for representing trust anchor
information.  A trust anchor is an authoritative entity represented
by a public key and associated data.  The public key is used to
verify digital signatures and the associated data is used to
constrain the types of information or actions for which the trust
anchor is authoritative.  The structures defined in this document are
intended to satisfy the format-related requirements defined in Trust
Anchor Management Requirements.

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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

---

From: "Erik Andersen" <[email-masked]>
Date: Fri, 16 Oct 2009 11:21:50 +0200

In line with a previous discussion, I have a couple comments on the
ta-format draft:

Somewhere down in subclause 2.5, a paragraph starts with:

"When the trust anchor is used to validate a certification path,
CertPathControls provides limitations on certification paths that will
successfully validate."

It would probably be more correct to say "When trust anchor *information is
used ..." 

In first paragraph of clause 3, it says: TrustAnchorList is defined as a
sequence of one or more TrustAnchorChoice objects.

I would replace the word "objects" with "data types" in line with ASN.1
terminology

The first two paragraphs of clause 4 should probably be updated as shown: 

Compromise of a trust anchor private key permits unauthorized parties
   to masquerade as the trust anchor, with potentially severe
   consequences.  Where TA-based constraints are enforced, the
   unauthorized holder of the trust anchor private key will be limited
   by the certification path controls associated with the trust anchor
*information*,
   as expressed in the certPath and exts fields.  For example, name
   constraints in the trust anchor *information* will determine the name
space that
   will be accepted in certificates that are validated using the
   compromised trust anchor.  Reliance on an inappropriate or incorrrect
*too many r"
   trust anchor public key has similar potentially severe consequences.

The compromise of a CA's private key leads to the same type of
   problems as the compromise of a trust anchor private key.  The
   unauthorized holder of the CA private key will be limited by the
   certification path controls associated with the trust anchor
*information*, as
   expressed in the certPath field or as an extension.

Erik Andersen
Andersen's L-Service
Elsevej 48,
DK-3500 Vaerloese
Denmark
Mobile: +45 2097 1490
e-amail: [email-masked]
Skype: andersen-erik
http://www.x500.eu/
http://www.x500standard.com/

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: 15. oktober 2009 13:15
To: [email-masked]
Cc: [email-masked]
Subject: [pkix] I-D Action:draft-ietf-pkix-ta-format-04.txt

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.

This document describes a structure for representing trust anchor
information.  A trust anchor is an authoritative entity represented by a
public key and associated data.  The public key is used to verify digital
signatures and the associated data is used to constrain the types of
information or actions for which the trust anchor is authoritative.  The
structures defined in this document are intended to satisfy the
format-related requirements defined in Trust Anchor Management Requirements.

---

From: "Carl Wallace" <[email-masked]>
Date: Fri, 16 Oct 2009 06:29:54 -0400

Inline...

> Sent: Friday, October 16, 2009 5:22 AM
> To: PKIX
> Subject: Re: [pkix] I-D Action:draft-ietf-pkix-ta-format-04.txt
> 

Since this draft has completed WG last call and these are editorial
changes, we will make these changes with an RFC editor's note.
 
>    expressed in the certPath field or as an extension.

I do not agree with most of this change.  The trust anchor information
only limits the damage when constraints are enforced, which is not
something that is currently required or described by this draft, RFC
5280 or X.509.  There is an individual submission that describes usage
of TA-based constraints during certification path processing:
http://tools.ietf.org/html/draft-wallace-using-ta-constraints-01. 

Will add suggested "information" with an RFC editor's note.

> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix

---

From: "Carl Wallace" <[email-masked]>
Date: Fri, 16 Oct 2009 08:22:33 -0400

I misread the last set of comments as presenting a paragraph then its
replacement.  However, it has been pointed out that the intent was to
show two paragraphs with edits similar to the others.  I'll make the
last set of changes as RFC editor's notes as well.  Sorry for the
confusion.

> Carl Wallace
> Sent: Friday, October 16, 2009 6:30 AM
> To: Erik Andersen; [email-masked]
> > In first paragraph of clause 3, it says: TrustAnchorList is defined
> as
> > a
> by
> > a