Subject: [pkix] I-D Action: draft-ietf-pkix-rfc5280-clarifications-09.txt

From: [email-masked]
Date: Thu, 06 Sep 2012 15:26:23 -0700

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           : Updates to the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
	Author(s)       : Peter E. Yee
	Filename        : draft-ietf-pkix-rfc5280-clarifications-09.txt
	Pages           : 9
	Date            : 2012-09-06

Abstract:
   This document updates RFC 5280, the Internet X.509 Public Key
   Infrastructure Certificate and Certificate Revocation List (CRL)
   Profile.  This document changes the set of acceptable encoding
   methods for the explicitText field of the user notice policy
   qualifier and clarifies the rules for converting internationalized
   domain name labels to ASCII.  This document also provides some
   clarifications on the use of self-signed certificates, trust anchors,
   and some updated security considerations.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-pkix-rfc5280-clarifications

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-pkix-rfc5280-clarifications-09

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-pkix-rfc5280-clarifications-09

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

---

From: [email-masked]
Date: Fri, 7 Sep 2012 08:13:57 +0200

Thank you Peter for the additional text .
 
However, I have three comments:
 
1) The introduction is missing to advertise the change detailed in section 4.
 
2) I would think that a small vocabulary ajustement would improve the text:
 
One one side, we have:
 
|     If a CRL contains a critical CRL entry extension 
|     that the application cannot process, then the application MUST 
|     NOT use that CRL to determine the status of the certificate  
|     represented by the CRL entry.

On the other side, we have:
 
|     A critical extension in the crlEntryExtensions field of an entry
|     SHALL affect only the certificate specified in that entry, unless
|     there is a related critical extension in the crlExtensions field
|     that advertises a special treatment for it. 
 
The first sentence uses "represented by" while the second uses "specified in".
The same verb would be better. I would rather prefer to use for both "identified in"
My second choice would be "specified in".
 
This would lead in the first sentence to
 
|     If a CRL contains a critical CRL entry extension 
|     that the application cannot process, then the application MUST 
|     NOT use that CRL to determine the status of the certificate  
|     identified in the CRL entry.

while for the second sentence:
 
|     A critical extension in the crlEntryExtensions field of an entry
|     SHALL affect only the certificate identified in that entry, unless
|     there is a related critical extension in the crlExtensions field
|     that advertises a special treatment for it.  
 
3) During the discussion, I raised the point that Extensions was defined in this
    document and that other RFCs imported not only the ASN.1 syntax, but also 
    the semantics. However, the way the document is currently written does not 
    allow to import the semantics. I have made text proposals so that we can 
    have a clean and separate section to define what an Extension is in order to 
    allow such an import. As an example, OCSP makes such an import and does 
    it currently in a way which is not fully inappropriate because RFC 5280 is not 
    "clean" in that point.
 
Denis

[email-masked] a écrit : ----- 
A : [email-masked]
De : [email-masked]
Envoyé par : [email-masked]
Date : 07/09/2012 00:26
Cc : [email-masked]
Objet : [pkix] I-D Action: draft-ietf-pkix-rfc5280-clarifications-09.txt

Abstract:

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