PKIX WG Last Call Review Update - Security Area Director's Approval

1. SonOf3039 Status Russ Housley Security Area Director

2. History • 21-Jan-04 PKIX WG Last Call closed • 21-Jan-04 PKIX Chair sent document to IESG • 26-Jan-04 AD Evaluation complete • 26-Jan-04 Denis Pinkas posts 38 comments • 26-Jan-04 IETF Last Call begins • 31-Jan-04 Responses to 38 comments posted to PKIX mail list • 2-Feb-04 PKIX Chair confirms to AD that the rough consensus is maintained • 9-Feb-04 IETF Last Call ends • 11-Feb-04 Updated document posted • 19-Feb-04 IESG approved document • 23-Feb-04 Denis Pinkas declares that some comments were not resolved

3. Proposed Changes • Denis Pinkas will be “happy” if five changes are made • None of the changes impact MUST or SHOULD statements • No MUST or SHOULD statements are added • No existing MUST statements are changed • Editorial change to existing SHOULD statement • Next slides provide details

4. Change 1 • Change section 2.2, Statement of Purpose, 3rd paragraph OLD TEXT: "This profile defines two complementary ways to include this information:" NEW TEXT: "This profile defines two ways to include this information:"

5. Change 2 • Move the following paragraphs of section 3.2.6, Qualified Certificate Statements “A statement suitable for inclusion in this extension MAY be a statement by the issuer that the certificate is issued as a Qualified Certificate in accordance with a particular legal system (as discussed in Section 2.2).” and “Other statements suitable for inclusion in this extension MAY be statements related to the applicable legal jurisdiction within which the certificate is issued. As an example this MAY include a maximum reliance limit for the certificate indicating restrictions on CA's liability.” Place them after the ASN.1 declarations in the same section

6. Change 3 • Change text in section 3.2.3, certificate policies, 3rd paragraph: OLD TEXT: The certificate policies extension MUST include all policy information needed for certification path validation. If policy information is included in the QCStatements extension (see 3.2.6), then this information SHOULD also be defined by indicated policies. NEW TEXT: The certificate policies extension MUST include all policy information needed for certification path validation. If policy related statements are included in the QCStatements extension (see 3.2.6), then these statements SHOULD also be contained in the identified policies.

7. Change 4 • Change section 3.1.2, subject, 1st paragraph following the list of attributes: OLD TEXT: Other attributes MAY also be present; however, the use of other attributes MUST NOT be necessary to distinguish one subject name from another subject name. That is, the attributes listed above are sufficient to ensure unique subject names. NEW TEXT: Other attributes MAY also be present; however, the use of other attributes MUST NOT be necessary to distinguish one subject from another subject. That is, the attributes listed above are sufficient to uniquely identify the subject.

8. Change 5 • Replace paragraph in the Security Considerations section: OLD TEXT: Combining the nonRepudiation bit in the keyUsage certificate extension with other keyUsage bits may have security implications depending on the context in which the certificate is to be used. Applications validating electronic signatures based on such certificates should determine whether the present key usage combination is appropriate for their use. Replacement text on next slide …

9. Change 5 NEW TEXT: Combining the nonRepudiation bit in the keyUsage certificate extension with other keyUsage bits may have security implications depending on the certificate policy and the context in which the certificate is to be used. If the subject's environment can be fully controlled and trusted, then there are no specific security implications. For example, in cases where the subject is fully confident about exactly which data is signed or cases where the subject is fully confident about the security characteristics of the authentication protocol being used. If the subject's environment is not fully controlled or not fully trusted, then unintentional signing of commitments are possible. Examples include the use of badly formed authentication exchanges and the use of a rogue software component. If untrusted environments are used by a subject, these security implications can be limited through use of the following measures: - To not combine nonRepudiation key usage setting in certificates with any other key usage setting and to use the corresponding private key only with this certificate. - To limit the use of private keys associated with certificates that have the nonRepudiation key usage bit set, to environments which are considered adequately controlled and trustworthy.

10. Way Forward • Two choices • Tell Denis Pinkas that his comments are too late • Accept the changes, which requires a seven step process

11. The Seven Steps 1 - The authors post the list of changes that they will be requested to the working group mail list. 2 - Give a clear deadline for comments in the message.  I suggest one week. 3 - Address comments from the working group mail list immediately. 4 - At the end of the comment period, summarize the changes that the RFC Editor will be asked to make during AUTH48. 5 - The Working group chairs confirm that the changes do not break rough consensus. 6 - The Area Directors will handle IESG review of the changes, if needed. 7 - The Area Directors will submit the changes to the RFC Editor, avoiding the need for them to seek my approval for the changes.

12. Straw Poll • Choice 1: Tell Denis Pinkas that his comments are too late • Choice 2: Use the seven steps to determine if there is consensus to adopt the five changes