Subject: Re: WG last call re draft-pkix-acpolicies-extn-03.txt

From: Denis Pinkas <[email-masked]>
Date: Fri, 21 Nov 2003 16:37:33 +0100

Jim,

Thank you for your very valuable comments.

A updated document is now available on the server :
http://www.ietf.org/internet-drafts/draft-ietf-pkix-acpolicies-extn-04.txt

You will find hereafter a disposition of your comments.

The document should now be ready for the IESG last call.

Denis
Lead editor of draft-pkix-acpolicies-extn

Note for Russ: two new OIDs will need to be assigned.

=========================================================================

Gentlemen,

No judgement on good or badness of concept however the following present
implementation issues:

1.  Section 2.3 says that this document defines two policies which are
SIMILAR to those for public keys and then appears to use the save value.
Is this intended and if so then the text should be cleaned up.

The text has been fixed in the following way

     The policy qualifiers are similar but indeed different since they
     relate to an Attribute Certificate instead of a Public Key Certificate.
     To this respect two new OIDs will be needed in the id-qt arc and the
     updated document has been using two next one available in that category.

     Russ, as the custodian of the PKIX OID, would you assign these two new
     OIDs to acps and acunotice ?

     id-qt-acps       OBJECT IDENTIFIER ::=  { id-qt 4 }
     id-qt-acunotice  OBJECT IDENTIFIER ::=  { id-qt 5 }

2.  What is the correct behavior if the extension is non-critical, the
extension is recognized, but none of the policy identifiers are recognized?

The following sentence has been added:

"If none of the AC policy identifiers is adequate for the application,
then the AC MUST be rejected."

ASN Module:

1.  Need to uncomment the imports statement.
Done

2.  need to add a semi-colon following the import of PolicyQualifiedId
OK

3.  PolicyQualifiedId needs to be imported form PKIXImplicit88.
It is defined both in PKIXExplicit88 and in PKIXImplicit88.

4.  id-pkix needs to be imported.
id-pe is now directly imported instead.

5.  ac-policies does needs to have "SYNTAX" and "IDENTIFIED BY" changed
as this is not correct 1988 syntax.
Done

6.  EXTENSION is not an identified type.
Done

7.  ac-policiesSyntax should start with an upper case letter as it is a type.
Done

8.  acPolicyId should start with an upper case letter as it is a type.
Done

   ... and many thanks for these comments.

In addition:

1 - The introduction has been changed to state:

The purpose of this document is to define an AC policies extension
able to explicitly state the AC policies that apply to a given AC,
but not the AC policies themselves"

2 - id-pe-ac-policies has been changed into id-pe-acPolicies

3 - The name of the ASN.1 module is now :
AcPolicies instead of PKIXac-policies

Jim

 > Gentlemen,
 >
 > No judgement on good or badness of concept however the following present
 > implementation issues:
 >
 > 1.  Section 2.3 says that this document defines two policies which are
 > SIMILAR to those for public keys and then appears to use the save value.
 > Is this intended and if so then the text should be cleaned up.
 >
 > 2.  What is the correct behavior if the extension is non-criticial, the
 > extension is recognized, but none of the policy identifiers are
 > recognized?
 >
 >
 >
 > ASN Module:
 >
 > 1.  Need to uncomment the imports statement
 >
 > 2.  need to add a semi-colon following the import of PolicyQualifiedId
 >
 > 3.  PolicyQualifiedId needs to be imported form PKIXImplicit88.
 >
 > 4.  id-pkix needs to be imported.
 >
 > 5.  ac-policies does needs to have "SYNTAX" and "IDENTIFIED BY" changed
 > as this is not correct 1988 syntax.
 >
 > 6.  EXTENSION is not an identified type.
 >
 > 7.  ac-policiesSyntax should start with an upper case letter as it is a
 > type.
 >
 > 8.  acPolicyId should start with an upper case letter as it is a type.
 >
 >
 > Jim

---

From: Russ Housley <[email-masked]>
Date: Fri, 21 Nov 2003 18:01:10 -0500

These two OIDs have been assigned.

Russ

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 24 Nov 2003 11:28:37 -0800

Denis,

I just found a minor issue.

In the ASN.1 module you are referencing [PROFILE] rather than [RFC3280].

jim

---

From: Tim Polk <[email-masked]>
Date: Tue, 25 Nov 2003 10:18:09 -0500

Denis & Chris

I have reviewed the new document and am satisfied that all WG comments have 
been addressed.

The only outstanding issues identified on the list are the ASN.1 reference 
identified by Jim Schaad and inserting the  OIDs  assigned by Russ Housley.

However, I reviewed the "ID nits" (see http://www.ietf.org/ID-nits.html) 
and identified a number of minor issues that also need to be addressed:

(1) The current Abstract needs to be expanded; the requirement is that the 
abstract "be meaningful to someone not versed in the technology".
(2) Please keep RFC 3280 in the Normative References section.  Please 
create an Informative References section and move the ISO X.509 
specification to that section.
(3) Please add an IPR section and include the IPR notices in RFC 2026 
10.4(a) and 10.4(b). (See http://www.ietf.org/rfc/rfc2026.txt for the exact 
text.) [Note: To my knowledge, no IPR claims are known.  If that is not 
correct, please add 10.4(d) and let me know ASAP if we need to get an IPR 
notice filed with the IESG.]
(4) Please give some thoughts to your security considerations.  I believe 
they need to be expanded.  For example, I believe you should re-emphasize 
that trusting policy alone is insufficient.  The relying party must 
determine that the AC has the appropriate policy and was issued by a 
trusted AA.  I believe that all the security considerations for RFC 3281 
still apply, that might be worth adding.

Please submit a new draft that resolves the ASN.1 issues and the four 
issues that I have identified.  That draft will be forwarded to the ADs for 
consideration by the IESG.

Thanks,

Tim Polk