draft-ietf-lamps-rfc7030est-clarify-02.txt   draft-ietf-lamps-rfc7030est-clarify-03.txt 
LAMPS Working Group M. Richardson LAMPS Working Group M. Richardson
Internet-Draft Sandelman Software Works Internet-Draft Sandelman Software Works
Intended status: Standards Track T. Werner Updates: RFC7030 (if approved) T. Werner
Expires: September 6, 2020 Siemens Intended status: Standards Track Siemens
W. Pan Expires: October 27, 2020 W. Pan
Huawei Technologies Huawei Technologies
March 05, 2020 April 25, 2020
Clarification of Enrollment over Secure Transport (EST): transfer Clarification of Enrollment over Secure Transport (EST): transfer
encodings and ASN.1 encodings and ASN.1
draft-ietf-lamps-rfc7030est-clarify-02 draft-ietf-lamps-rfc7030est-clarify-03
Abstract Abstract
This document updates RFC7030: Enrollment over Secure Transport (EST) This document updates RFC7030: Enrollment over Secure Transport (EST)
to resolve some errata that was reported, and which has proven to to resolve some errata that was reported, and which has proven to
have interoperability when RFC7030 has been extended. cause interoperability issues when RFC7030 was extended.
This document deprecates the specification of "Content-Transfer- This document deprecates the specification of "Content-Transfer-
Encoding" headers for EST endpoints, providing a way to do this in an Encoding" headers for EST endpoints. This document fixes some
upward compatible way. This document fixes some syntactical errors syntactical errors in ASN.1 that was presented.
in ASN.1 that was presented.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 6, 2020. This Internet-Draft will expire on October 27, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 3. Changes to EST endpoint processing . . . . . . . . . . . . . 3
4. Changes to EST endpoint processing . . . . . . . . . . . . . 3 3.1. Whitespace processing . . . . . . . . . . . . . . . . . . 3
5. Clarification of ASN.1 for Certificate Attribute set. . . . . 4 4. Clarification of ASN.1 for Certificate Attribute set. . . . . 4
5.1. CSR Attributes Response . . . . . . . . . . . . . . . . . 4 4.1. CSR Attributes Response . . . . . . . . . . . . . . . . . 4
6. Clarification of error messages for certificate enrollment 5. Clarification of error messages for certificate enrollment
operations . . . . . . . . . . . . . . . . . . . . . . . . . 6 operations . . . . . . . . . . . . . . . . . . . . . . . . . 6
6.1. Updating section 4.2.3: Simple Enroll and Re-enroll 5.1. Updating section 4.2.3: Simple Enroll and Re-enroll
Response . . . . . . . . . . . . . . . . . . . . . . . . 6 Response . . . . . . . . . . . . . . . . . . . . . . . . 6
6.2. Updating section 4.4.2: Server-Side Key Generation 5.2. Updating section 4.4.2: Server-Side Key Generation
Response . . . . . . . . . . . . . . . . . . . . . . . . 6 Response . . . . . . . . . . . . . . . . . . . . . . . . 6
7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 6 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 6
8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
11.1. Normative References . . . . . . . . . . . . . . . . . . 7 10.1. Normative References . . . . . . . . . . . . . . . . . . 7
11.2. Informative References . . . . . . . . . . . . . . . . . 8 10.2. Informative References . . . . . . . . . . . . . . . . . 9
Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 9 Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
[RFC7030] defines the Enrollment over Secure Transport, or EST [RFC7030] defines the Enrollment over Secure Transport, or EST
protocol. protocol.
This specification defines a number of HTTP end points for This specification defines a number of HTTP end points for
certificate enrollment and management. The details of the certificate enrollment and management. The details of the
transaction were defined in terms of MIME headers as defined in transaction were defined in terms of MIME headers as defined in
[RFC2045], rather than in terms of the HTTP protocol as defined in [RFC2045], rather than in terms of the HTTP protocol as defined in
[RFC2616] and [RFC7230]. [RFC2616] and [RFC7230].
[RFC2616] and later [RFC7231] Appendix A.5 has text specifically [RFC2616] and later [RFC7231] Appendix A.5 has text specifically
deprecating Content-Transfer-Encoding. deprecating Content-Transfer-Encoding. However, [RFC7030]
incorrectly uses this header.
[RFC7030] calls it out this header incorrectly. Changes to [RFC7030] to bring it inline with typical HTTP processing
risk changes the on-wire protocol in a way that is not backwards
compatible. However, reports from the implementers suggest that many
implementations do not send the Content-Transfer-Encoding, and many
of them ignore it. The consequence is that simply deprecating the
header would remain compatible with current implementations.
[I-D.ietf-anima-bootstrapping-keyinfra] extends [RFC7030], adding new [I-D.ietf-anima-bootstrapping-keyinfra] extends [RFC7030], adding new
functionality, and interop testing of the protocol has revealed that functionality, and interop testing of the protocol has revealed that
unusual processing called out in [RFC7030] causes confusion. unusual processing called out in [RFC7030] causes confusion.
EST is currently specified as part of IEC 62351, and is widely used EST is currently specified as part of [IEC62351], and is widely used
in Government, Utilities and Financial markets today. in Government, Utilities and Financial markets today.
Changes to [RFC7030] to bring it inline with typical HTTP processing
would change the on-wire protocol in a way that is not backwards
compatible. Reports from the field suggest that many implementations
do not send the Content-Transfer-Encoding, and many of them ignore
it.
This document therefore revises [RFC7030] to reflect the field This document therefore revises [RFC7030] to reflect the field
reality, deprecating the extranous field. reality, deprecating the extranous field.
This document deals with errata numbers [errata4384], [errata5107], This document deals with errata numbers [errata4384], [errata5107],
and [errata5108]. [errata5108], and [errata5904].
2. Terminology 2. Terminology
The abbreviation "CTE" is used to denote the Content-Transfer- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
Encoding header, and the abbreviation "CTE-base64" is used to denote "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
a request or response whose Content-Transfer-Encoding header contains "OPTIONAL" in this document are to be interpreted as described in
the value "base64". BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. Requirements Language
In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119
[RFC2119] and indicate requirement levels for compliant STuPiD
implementations.
4. Changes to EST endpoint processing 3. Changes to EST endpoint processing
The [RFC7030] sections 4.1.3 (CA Certificates Response, /cacerts), The [RFC7030] sections 4.1.3 (CA Certificates Response, /cacerts),
4.3.1/4.3.2 (Full CMC, /fullcmc), 4.4.2 (Server-Side Key Generation, 4.3.1/4.3.2 (Full CMC, /fullcmc), 4.4.2 (Server-Side Key Generation,
/serverkeygen), and 4.5.2 (CSR Attributes, /csrattrs) specify the use /serverkeygen), and 4.5.2 (CSR Attributes, /csrattrs) specify the use
of base64 encoding with a Content-Transfer-Encoding for requests and of base64 encoding with a Content-Transfer-Encoding for requests and
response. response.
This document updates [RFC7030] to require the POST request and This document updates [RFC7030] to require the POST request and
payload response of all endpoints in to be [RFC4648] section 4 Base64 payload response of all endpoints use Base64 encoding as specified in
encoded DER. This format is to be used regardless of whether there Section 4 of [RFC4648]. In both cases, the Distinguished Encoding
is any Content-Transfer-Encoding header, and any value in that header Rules (DER) [X690] are used to produce the input for the Base64
is to be ignored. encoding routine. This format is to be used regardless of any
Content-Transfer-Encoding header, and any value in such a header MUST
be ignored.
5. Clarification of ASN.1 for Certificate Attribute set. 3.1. Whitespace processing
Note that "base64" as used in the HTTP [RFC2616] does not permit
CRLF, while the "base64" used in MIME [RFC2045] does. This
specification clarifies that despite [RFC2616], that white space
including CR, LF, spaces (ASCII 32) and, tabs (ASCII 9) should be
tolerated by receivers. Senders are not required to insert any kind
of white space.
4. Clarification of ASN.1 for Certificate Attribute set.
Section 4.5.2 of [RFC7030] is to be replaced with the following text: Section 4.5.2 of [RFC7030] is to be replaced with the following text:
5.1. CSR Attributes Response 4.1. CSR Attributes Response
If locally configured policy for an authenticated EST client If locally configured policy for an authenticated EST client
indicates a CSR Attributes Response is to be provided, the server indicates a CSR Attributes Response is to be provided, the server
response MUST include an HTTP 200 response code. An HTTP response response MUST include an HTTP 200 response code. An HTTP response
code of 204 or 404 indicates that a CSR Attributes Response is not code of 204 or 404 indicates that a CSR Attributes Response is not
available. Regardless of the response code, the EST server and CA available. Regardless of the response code, the EST server and CA
MAY reject any subsequent enrollment requests for any reason, e.g., MAY reject any subsequent enrollment requests for any reason, e.g.,
incomplete CSR attributes in the request. incomplete CSR attributes in the request.
Responses to attribute request messages MUST be encoded as the Responses to attribute request messages MUST be encoded as the
content-type of "application/csrattrs", and are to be "base64" content-type of "application/csrattrs", and are to be "base64"
[RFC2045] encoded. The syntax for application/csrattrs body is as [RFC2045] encoded. The syntax for application/csrattrs body is as
follows: follows:
CsrAttrs ::= SEQUENCE SIZE (0..MAX) OF AttrOrOID CsrAttrs ::= SEQUENCE SIZE (0..MAX) OF AttrOrOID
AttrOrOID ::= CHOICE { AttrOrOID ::= CHOICE {
oid OBJECT IDENTIFIER, oid OBJECT IDENTIFIER,
attribute Attribute {{AttrSet}} } attribute Attribute {{AttrSet}} }
AttrSet ATTRIBUTE ::= { AttributesDefinedInRFC7030, ... } AttrSet ATTRIBUTE ::= { aa-asymDecryptKeyId, ... }
An EST server includes zero or more OIDs or attributes [RFC2986] that An EST server includes zero or more OIDs or attributes [RFC2986] that
it requests the client to use in the certification request. The it requests the client to use in the certification request. The
client MUST ignore any OID or attribute it does not recognize. When client MUST ignore any OID or attribute it does not recognize. When
the server encodes CSR Attributes as an empty SEQUENCE, it means that the server encodes CSR Attributes as an empty SEQUENCE, it means that
the server has no specific additional information it desires in a the server has no specific additional information it desires in a
client certification request (this is functionally equivalent to an client certification request (this is functionally equivalent to an
HTTP response code of 204 or 404). HTTP response code of 204 or 404).
If the CA requires a particular crypto system or use of a particular If the CA requires a particular cryptographic algorithm or use of a
signature scheme (e.g., certification of a public key based on a particular signature scheme (e.g., certification of a public key
certain elliptic curve, or signing using a certain hash algorithm) it based on a certain elliptic curve, or signing using a certain hash
MUST provide that information in the CSR Attribute Response. If an algorithm) it MUST provide that information in the CSR Attribute
EST server requires the linking of identity and POP information (see Response. If an EST server requires the linking of identity and POP
Section 3.5), it MUST include the challengePassword OID in the CSR information (see Section 3.5), it MUST include the challengePassword
Attributes Response. OID in the CSR Attributes Response.
The structure of the CSR Attributes Response SHOULD, to the greatest The structure of the CSR Attributes Response SHOULD, to the greatest
extent possible, reflect the structure of the CSR it is requesting. extent possible, reflect the structure of the CSR it is requesting.
Requests to use a particular signature scheme (e.g. using a Requests to use a particular signature scheme (e.g. using a
particular hash function) are represented as an OID to be reflected particular hash function) are represented as an OID to be reflected
in the SignatureAlgorithm of the CSR. Requests to use a particular in the SignatureAlgorithm of the CSR. Requests to use a particular
crypto system (e.g., certification of a public key based on a certain cryptographic algorithm (e.g., certification of a public key based on
elliptic curve) are represented as an attribute, to be reflected as a certain elliptic curve) are represented as an attribute, to be
the AlgorithmIdentifier of the SubjectPublicKeyInfo, with a type reflected as the AlgorithmIdentifier of the SubjectPublicKeyInfo,
indicating the algorithm and the values indicating the particular with a type indicating the algorithm and the values indicating the
parameters specific to the algorithm. Requests for descriptive particular parameters specific to the algorithm. Requests for
information from the client are made by an attribute, to be descriptive information from the client are made by an attribute, to
represented as Attributes of the CSR, with a type indicating the be represented as Attributes of the CSR, with a type indicating the
[RFC2985] extensionRequest and the values indicating the particular [RFC2985] extensionRequest and the values indicating the particular
attributes desired to be included in the resulting certificate's attributes desired to be included in the resulting certificate's
extensions. extensions.
The sequence is Distinguished Encoding Rules (DER) encoded [X690] and The sequence is Distinguished Encoding Rules (DER) encoded [X690] and
then base64 encoded (Section 4 of [RFC4648]). The resulting text then base64 encoded (Section 4 of [RFC4648]). The resulting text
forms the application/csrattr body, without headers. forms the application/csrattr body, without headers.
For example, if a CA requests a client to submit a certification For example, if a CA requests a client to submit a certification
request containing the challengePassword (indicating that linking of request containing the challengePassword (indicating that linking of
skipping to change at page 5, line 37 skipping to change at page 5, line 41
OID: challengePassword (1.2.840.113549.1.9.7) OID: challengePassword (1.2.840.113549.1.9.7)
Attribute: type = extensionRequest (1.2.840.113549.1.9.14) Attribute: type = extensionRequest (1.2.840.113549.1.9.14)
value = macAddress (1.3.6.1.1.1.1.22) value = macAddress (1.3.6.1.1.1.1.22)
Attribute: type = id-ecPublicKey (1.2.840.10045.2.1) Attribute: type = id-ecPublicKey (1.2.840.10045.2.1)
value = secp384r1 (1.3.132.0.34) value = secp384r1 (1.3.132.0.34)
OID: ecdsaWithSHA384 (1.2.840.10045.4.3.3) OID: ecdsaWithSHA384 (1.2.840.10045.4.3.3)
and encodes them into an ASN.1 SEQUENCE to produce: ~~~ 30 41 06 09 and encodes them into an ASN.1 SEQUENCE to produce:
2a 86 48 86 f7 0d 01 09 07 30 12 06 07 2a 86 48 ce 3d 02 01 31 07 06
05 2b 81 04 00 22 30 16 06 09 2a 86 48 86 f7 0d 01 09 0e 31 09 06 07 30 41 06 09 2a 86 48 86 f7 0d 01 09 07 30 12 06 07 2a 86 48 ce 3d
2b 06 01 01 01 01 16 06 08 2a 86 48 ce 3d 04 03 03 ~~~ 02 01 31 07 06 05 2b 81 04 00 22 30 16 06 09 2a 86 48 86 f7 0d 01
09 0e 31 09 06 07 2b 06 01 01 01 01 16 06 08 2a 86 48 ce 3d 04 03
03
and then base64 encodes the resulting ASN.1 SEQUENCE to produce: and then base64 encodes the resulting ASN.1 SEQUENCE to produce:
MEEGCSqGSIb3DQEJBzASBgcqhkjOPQIBMQcGBSuBBAAiMBYGCSqGSIb3DQEJDjEJ MEEGCSqGSIb3DQEJBzASBgcqhkjOPQIBMQcGBSuBBAAiMBYGCSqGSIb3DQEJDjEJ
BgcrBgEBAQEWBggqhkjOPQQDAw== BgcrBgEBAQEWBggqhkjOPQQDAw==
6. Clarification of error messages for certificate enrollment 5. Clarification of error messages for certificate enrollment
operations operations
[errata5108] clarifies what format the error messages are to be in. [errata5108] clarifies what format the error messages are to be in.
Previously a client might be confused into believing that an error Previously a client might be confused into believing that an error
returned with type text/plain was not intended to be an error. returned with type text/plain was not intended to be an error.
6.1. Updating section 4.2.3: Simple Enroll and Re-enroll Response 5.1. Updating section 4.2.3: Simple Enroll and Re-enroll Response
Replace: Replace:
If the content-type is not set, the response data MUST be a If the content-type is not set, the response data MUST be a
plaintext human-readable error message containing explanatory plaintext human-readable error message containing explanatory
information describing why the request was rejected (for information describing why the request was rejected (for
example, indicating that CSR attributes are incomplete). example, indicating that CSR attributes are incomplete).
with: with:
If the content-type is not set, the response data must be a If the content-type is not set, the response data must be a
plaintext human-readable error message containing explanatory plaintext human-readable error message containing explanatory
information describing why the request was rejected (for information describing why the request was rejected (for
example, indicating that CSR attributes are incomplete). example, indicating that CSR attributes are incomplete).
Servers MAY use the "text/plain" content-type [RFC2046] Servers MAY use the "text/plain" content-type [RFC2046]
for human-readable errors. for human-readable errors.
6.2. Updating section 4.4.2: Server-Side Key Generation Response 5.2. Updating section 4.4.2: Server-Side Key Generation Response
Replace: Replace:
If the content-type is not set, the response data MUST be a If the content-type is not set, the response data MUST be a
plaintext human-readable error message. plaintext human-readable error message.
with: with:
If the content-type is not set, the response data must be a If the content-type is not set, the response data must be a
plaintext human-readable error message. plaintext human-readable error message.
Servers MAY use the "text/plain" content-type [RFC2046] Servers MAY use the "text/plain" content-type [RFC2046]
for human-readable errors. for human-readable errors.
7. Privacy Considerations 6. Privacy Considerations
This document does not disclose any additional identifies to either This document does not disclose any additional identifies to either
active or passive observer would see with [RFC7030]. active or passive observer would see with [RFC7030].
8. Security Considerations 7. Security Considerations
This document clarifies an existing security mechanism. It does not This document clarifies an existing security mechanism. It does not
create any new protocol mechanism. create any new protocol mechanism.
9. IANA Considerations 8. IANA Considerations
The ASN.1 module in Appendix A of this doucment makes use of object The ASN.1 module in Appendix A of this doucment makes use of object
identifiers (OIDs). This document requests that IANA register an OID identifiers (OIDs). This document requests that IANA register an OID
in the SMI Security for PKIX Arc in the Module identifiers subarc in the SMI Security for PKIX Arc in the Module identifiers subarc
(1.3.6.1.5.5.7.0) for the ASN.1 module. The OID for the Asymmetric (1.3.6.1.5.5.7.0) for the ASN.1 module. The OID for the Asymmetric
Decryption Key Identifier (1.2.840.113549.1.9.16.2.54) was previously Decryption Key Identifier (1.2.840.113549.1.9.16.2.54) was previously
defined in [RFC7030]. defined in [RFC7030].
IANA is requested to update the "Reference" column for the Asymmetric IANA is requested to update the "Reference" column for the Asymmetric
Decryption Key Identifier attribute to also include a reference to Decryption Key Identifier attribute to also include a reference to
this doducment. this doducment.
10. Acknowledgements 9. Acknowledgements
This work was supported by the Huawei Technologies. This work was supported by Huawei Technologies.
The ASN.1 Module was assembled by Russ Housley and formatted by Sean The ASN.1 Module was assembled by Russ Housley and formatted by Sean
Turner. Turner. Russ Housley provided editorial review.
11. References 10. References
11.1. Normative References 10.1. Normative References
[errata4384]
"EST errata 4384: ASN.1 encoding error", n.d.,
<https://www.rfc-editor.org/errata/eid4384>.
[errata5107]
"EST errata 5107: use Content-Transfer-Encoding", n.d.,
<https://www.rfc-editor.org/errata/eid5107>.
[errata5108]
"EST errata 5108: use of Content-Type for error message",
n.d., <https://www.rfc-editor.org/errata/eid5108>.
[errata5904]
"EST errata 5904: use Content-Transfer-Encoding", n.d.,
<https://www.rfc-editor.org/errata/eid5904>.
[I-D.ietf-anima-bootstrapping-keyinfra] [I-D.ietf-anima-bootstrapping-keyinfra]
Pritikin, M., Richardson, M., Eckert, T., Behringer, M., Pritikin, M., Richardson, M., Eckert, T., Behringer, M.,
and K. Watsen, "Bootstrapping Remote Secure Key and K. Watsen, "Bootstrapping Remote Secure Key
Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping-
keyinfra-37 (work in progress), February 2020. keyinfra-41 (work in progress), April 2020.
[IEC62351]
International Electrotechnical Commission, "Power systems
management and associated information exchange - Data and
communications security - Part 9: Cyber security key
management for power system equipment", ISO/
IEC 62351-9:2017, 2017.
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996,
<https://www.rfc-editor.org/info/rfc2045>. <https://www.rfc-editor.org/info/rfc2045>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 8, line 19 skipping to change at page 8, line 42
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<https://www.rfc-editor.org/info/rfc4648>. <https://www.rfc-editor.org/info/rfc4648>.
[RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed.,
"Enrollment over Secure Transport", RFC 7030, "Enrollment over Secure Transport", RFC 7030,
DOI 10.17487/RFC7030, October 2013, DOI 10.17487/RFC7030, October 2013,
<https://www.rfc-editor.org/info/rfc7030>. <https://www.rfc-editor.org/info/rfc7030>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8179] Bradner, S. and J. Contreras, "Intellectual Property
Rights in IETF Technology", BCP 79, RFC 8179,
DOI 10.17487/RFC8179, May 2017,
<https://www.rfc-editor.org/info/rfc8179>.
[X680] ITU-T, "Information technology - Abstract Syntax Notation [X680] ITU-T, "Information technology - Abstract Syntax Notation
One.", ISO/IEC 8824-1:2002, 2002. One.", ISO/IEC 8824-1:2002, 2002.
[X681] ITU-T, "Information technology - Abstract Syntax Notation [X681] ITU-T, "Information technology - Abstract Syntax Notation
One: Information Object Specification.", ISO/ One: Information Object Specification.", ISO/
IEC 8824-2:2002, 2002. IEC 8824-2:2002, 2002.
[X682] ITU-T, "Information technology - Abstract Syntax Notation [X682] ITU-T, "Information technology - Abstract Syntax Notation
One: Constraint Specification.", ISO/IEC 8824-2:2002, One: Constraint Specification.", ISO/IEC 8824-2:2002,
2002. 2002.
[X683] ITU-T, "Information technology - Abstract Syntax Notation [X683] ITU-T, "Information technology - Abstract Syntax Notation
One: Parameterization of ASN.1 Specifications.", ISO/ One: Parameterization of ASN.1 Specifications.", ISO/
IEC 8824-2:2002, 2002. IEC 8824-2:2002, 2002.
[X690] ITU-T, "Information technology - ASN.1 encoding Rules: [X690] ITU-T, "Information technology - ASN.1 encoding Rules:
Specification of Basic Encoding Rules (BER), Canonical Specification of Basic Encoding Rules (BER), Canonical
Encoding Rules (CER) and Distinguished Encoding Rules Encoding Rules (CER) and Distinguished Encoding Rules
(DER).", ISO/IEC 8825-1:2002, 2002. (DER).", ISO/IEC 8825-1:2002, 2002.
11.2. Informative References 10.2. Informative References
[errata4384]
"EST errata 4384: ASN.1 encoding error", n.d.,
<https://www.rfc-editor.org/errata/eid4384>.
[errata5107]
"EST errata 5107: use Content-Transfer-Encoding", n.d.,
<https://www.rfc-editor.org/errata/eid5107>.
[errata5108]
"EST errata 5108: use of Content-Type for error message",
n.d., <https://www.rfc-editor.org/errata/eid5108>.
[RFC2307] Howard, L., "An Approach for Using LDAP as a Network [RFC2307] Howard, L., "An Approach for Using LDAP as a Network
Information Service", RFC 2307, DOI 10.17487/RFC2307, Information Service", RFC 2307, DOI 10.17487/RFC2307,
March 1998, <https://www.rfc-editor.org/info/rfc2307>. March 1998, <https://www.rfc-editor.org/info/rfc2307>.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, Transfer Protocol -- HTTP/1.1", RFC 2616,
DOI 10.17487/RFC2616, June 1999, DOI 10.17487/RFC2616, June 1999,
<https://www.rfc-editor.org/info/rfc2616>. <https://www.rfc-editor.org/info/rfc2616>.
skipping to change at page 10, line 21 skipping to change at page 11, line 36
mechanisms(5) pkix(7) id-mod(0) id-mod-pkixCommon-02(57) } ; mechanisms(5) pkix(7) id-mod(0) id-mod-pkixCommon-02(57) } ;
-- CSR Attributes -- CSR Attributes
CsrAttrs ::= SEQUENCE SIZE (0..MAX) OF AttrOrOID CsrAttrs ::= SEQUENCE SIZE (0..MAX) OF AttrOrOID
AttrOrOID ::= CHOICE { AttrOrOID ::= CHOICE {
oid OBJECT IDENTIFIER, oid OBJECT IDENTIFIER,
attribute Attribute {{AttrSet}} } attribute Attribute {{AttrSet}} }
AttrSet ATTRIBUTE ::= { AttributesDefinedInRFC7030, ... } AttrSet ATTRIBUTE ::= { aa-symmDecrytKeyID, ... }
-- Asymmetric Decrypt Key Identifier Attribute -- Asymmetric Decrypt Key Identifier Attribute
AttributesDefinedInRFC7030 ATTRIBUTE ::= { aa-asymmDecryptKeyID, ... }
aa-asymmDecryptKeyID ATTRIBUTE ::= aa-asymmDecryptKeyID ATTRIBUTE ::=
{ TYPE AsymmetricDecryptKeyIdentifier { TYPE AsymmetricDecryptKeyIdentifier
IDENTIFIED BY id-aa-asymmDecryptKeyID } IDENTIFIED BY id-aa-asymmDecryptKeyID }
id-aa-asymmDecryptKeyID OBJECT IDENTIFIER ::= { iso(1) member-body(2) id-aa-asymmDecryptKeyID OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) aa(2) 54 } us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) aa(2) 54 }
AsymmetricDecryptKeyIdentifier ::= OCTET STRING AsymmetricDecryptKeyIdentifier ::= OCTET STRING
END END
 End of changes. 41 change blocks. 
102 lines changed or deleted 126 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/