idnits 2.17.1
draft-ietf-smime-v31cert-00.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
** Looks like you're using RFC 2026 boilerplate. This must be updated to
follow RFC 3978/3979, as updated by RFC 4748.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
== There is 1 instance of lines with non-ascii characters in the document.
== No 'Intended status' indicated for this document; assuming Proposed
Standard
== The page length should not exceed 58 lines per page, but there was 1
longer page, the longest (page 1) being 117 lines
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
** The document seems to lack an Abstract section.
** The document seems to lack an IANA Considerations section. (See Section
2.2 of https://www.ietf.org/id-info/checklist for how to handle the case
when there are no actions for IANA.)
** The document seems to lack an Authors' Addresses Section.
** The document seems to lack a both a reference to RFC 2119 and the
recommended RFC 2119 boilerplate, even if it appears to use RFC 2119
keywords.
RFC 2119 keyword, line 31: '...the DSS and Diffie-Hellman as the MUST...'
RFC 2119 keyword, line 61: '...cate issuer. A receiving agent MUST be...'
RFC 2119 keyword, line 67: '... receiving agent MAY be capable of ver...'
Miscellaneous warnings:
----------------------------------------------------------------------------
** The document contains RFC2119-like boilerplate, but doesn't seem to
mention RFC 2119. The boilerplate contains a reference [MUSTSHOULD], but
that reference does not seem to mention RFC 2119 either.
-- The document seems to lack a disclaimer for pre-RFC5378 work, but may
have content which was first submitted before 10 November 2008. If you
have contacted all the original authors and they are all willing to grant
the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
this comment. If not, you may need to add the pre-RFC5378 disclaimer.
(See the Legal Provisions document at
https://trustee.ietf.org/license-info for more information.)
-- The document date (May 17, 2001) is 8373 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
-- Missing reference section? 'SMIMEV3CERT' on line 77 looks like a
reference
-- Missing reference section? 'MUSTSHOULD' on line 81 looks like a reference
-- Missing reference section? 'DSS' on line 79 looks like a reference
Summary: 6 errors (**), 0 flaws (~~), 3 warnings (==), 5 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
1 Internet Draft Author: Blake Ramsdell,
2 draft-ietf-smime-v31cert-00.txt Tumbleweed Communications
3 November 17, 2000
4 Expires May 17, 2001
6 S/MIME Version 3.1 Certificate Profile Addendum
8 Status of this memo
10 This document is an Internet-Draft and is in full conformance with all
11 provisions of Section 10 of RFC2026.
13 Internet-Drafts are working documents of the Internet Engineering Task
14 Force (IETF), its areas, and its working groups. Note that other
15 groups may also distribute working documents as Internet-Drafts.
17 Internet-Drafts are draft documents valid for a maximum of six months
18 and may be updated, replaced, or obsoleted by other documents at any
19 time. It is inappropriate to use Internet-Drafts as reference
20 material or to cite them other than as "work in progress."
22 The list of current Internet-Drafts can be accessed at
23 http://www.ietf.org/ietf/1id-abstracts.txt
25 The list of Internet-Draft Shadow Directories can be accessed at
26 http://www.ietf.org/shadow.html.
28 1. Overview
30 In light of the expiration of the primary RSA patent, it is proposed
31 that the RSA algorithm replace the DSS and Diffie-Hellman as the MUST
32 implement algorithms in the S/MIME profile. This draft will describe
33 only the proposed changes to the S/MIME Version 3 Certificate Handling
34 RFC [SMIMEV3CERT], and the rest of that RFC will remain identical.
36 1.1 Terminology
38 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
39 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
40 document are to be interpreted as described in [MUSTSHOULD].
42 1.2 Discussion of This Draft
44 This draft is being discussed on the "ietf-smime" mailing list.
45 To subscribe, send a message to:
46 ietf-smime-request@imc.org
47 with the single word
48 subscribe
49 in the body of the message. There is a Web site for the mailing list
50 at .
52 2. Changes to the S/MIME Version 3 Certificate Handling RFC
54 The following changes to are proposed to [SMIMEV3CERT]:
56 1. Section 4.3 is replaced with the following:
58 4.3 Certificate and CRL Signing Algorithms
60 Certificates and Certificate-Revocation Lists (CRLs) are
61 signed by the certificate issuer. A receiving agent MUST be
62 capable of verifying the signatures on certificates and CRLs
63 made with md2WithRSAEncryption, md5WithRSAEncryption and sha-
64 1WithRSAEncryption signature algorithms with key sizes from
65 512 bits to 2048 bits described in [PKCS#1V2].
67 A receiving agent MAY be capable of verifying the signatures
68 on certificates and CRLs made with id-dsa-with-sha1 [DSS].
70 3. Security Considerations
72 The security considerations are the same as for [SMIMEV3CERT].
73 Insert text about PKCS #1 v1.5 problems.
75 A. References
77 [SMIMEV3CERT] "S/MIME Version 3 Certificate Handling", RFC 2632
79 [DSS] NIST FIPS PUB 186, "Digital Signature Standard", 18 May 1994.
81 [MUSTSHOULD] "Key words for use in RFCs to Indicate Requirement
82 Levels", RFC 2119
84 [PKCS#1V2], "PKCS #1: RSA Cryptography Specifications Version 2.0",
85 RFC 2437
87 B. Acknowledgements
89
91 C. Changes from last draft
93 Changed name to put it in the working group, as opposed to an
94 individual submission.
96 Added placeholder text to section 3 explaining problems with PKCS #1
97 v1.5.
99 D. Author�s address
101 Blake Ramsdell
102 Tumbleweed Communications
103 17720 NE 65th St Ste 201
104 Redmond, WA 98052
105 +1 425 376 0225
106 blake.ramsdell@tumbleweed.com