Enrollment over Secure Transport
draft-ietf-pkix-est-09

[Ballot discuss]
I'll end up as a yes for this but I have a one more thing
I'd like to DISCUSS first:

(1) cleared

(2) 3.2.1, .well-known URLs will often result in HTTP
re-direction. Don't you need to say more for HTTP
re-directions, e.g. that whatever is required for the
original server cert is also required to be true of the
location to which the HTTP client is re-directed? How
does the MUST for tls-unique values from the 1st TLS
session in 3.5 work with re-direction? I suspect that you
need to either work out how 3xx responses are done or
else explain it a bit more to me, because I didn't get
that it works now.

(3) cleared

(4) cleared

[Ballot comment]

-- this was a discuss but is now a non-blocking comment.
(I still don't like /.well-known/est/arbritaryLabel1 since
that ain't well-known!)

(1) I don't get how the client discovers the
"arbitraryLabel1" etc in 3.2.1? Don't you need to say
that they're assumed to be known to the client? (Or
provide a discovery mechanism, which sounds like too much
work.) I'm also unsure of the point of using .well-known
with those labels, but can live with it.

-- older comments below

- intro, why call out TLS1.1 and have no reference to
5246? I think at least adding 5246 would be good since we
would like folks to use TLS1.2 for this (and for
everything). I'm fine if this says that it doesn't really
matter (in functional terms) what version of TLS you use
which is what I think you're trying to say.

- intro, would it be worthwhile also saying that this
doesn't have any relationship with 6712 (which updates
4210) and sort-of attempts to do the CMP-like equivalent
of this? The only reason to add soemthing like that would
be to offset reader confusion if they go look at 4210,
see its updated by 6712 and then are puzzled that this is
very different from 6712. (And yes, all involved, incl.
me, are sorry about the 20-th century screw up that lead
to us having both CMP and CMC;-)

- 1.1: TA as the abbreviation for "Third Party Trust
Anchor" seems liable to confuse folks easily. Why not
TPTA to be clear? The two TA definitions following seem
to already allow for such confusion.

- 1.1: certificate-less TLS: what about DH-ANON? There's
no uniquely shared credential there. I thought you meant
TLS-PSK btw, but its turns out (in 3.3.3) that you really
mean TLS-SRP. Better to be clear about that up front.
(I'm not sure if TLS-SRP is really wise, but I guess this
is a corner case, right?)

- section 2, 2nd last para: this isn't really a "profile"
suggest s/profile/specification/

- 2.2.3: I think you could re-iterate that that better
take place via TLS here, or very bad things can happen:-)
(I know you say that in 3.2.3 but still...)

- 2.6: MAC addresses in CSR's seems a bit odd, maybe add
to the end of that sentence "...of an interface that the
EST CA is being asked to include in a public key
certificate" (but when does a cert include a MAC
address?) Seems like an odd example.

- 3.1, 2nd last para, last sentence: saying you MUST be
able to disable implicit TA databases seems likely to
mean that e.g. you couldn't do a client as a JS
application running in a browser or a browser plug-in. Is
that right and is that considered ok? Perhaps SHOULD
would be better there in terms of getting more/quicker
deployment? (3.2.3 also expresses this requirement.)

- 3.5 1st sentence: I think s/support/use/ here is right.
This is OPTIONAL to support but some servers might
REQUIRE it, which is bad for interop, but understandable
I guess. (Some server/CA policies will be such that not
all clients can work with 'em.)

- 3.5: Saying clients are RECOMMENDED to do this but that
PoP is OPTIONAL is confusing.

- 3.5: If tls-unique is MTI then you should say that in
section 3.3 somewhere. (The MUST verify for that in 3.5
makes it MTI for servers at least I think.)

- 3.5: Saying that you might need to hash the
challenge-password but not saying how seems wrong.  I'd
say just re-word to say that only <255 byte
challenge-passwords are supported here.

- 3.6.1: it seems odd to say that id-kp-cmcRA is used to
"authorize" an EST server.

- 4.1.1: (shameless self-promtion:-) If its useful you
could maybe make use of RFC 6920 for that out of band
confirmation. No problems if you'd rather not but the nih
format might be usable for that and might even help.
I expect you'll say that you've already implemented
something and its different, and that's fine.

- 4.1.1: what is a Publish Trust Anchor "control"?  I
don't recall the term control before.

- 4.2.1: I'm not clear from this what forms of PoP MUST
be implemented. Maybe 4.3 will make it clear.  (It
didn't.) I'd say maybe get rid of discussion of the more
complex forms of PoP from here.

- 4.2.2: is "rekeys the client certificate" sufficiently
clear?

- 4.2.2 and elsewhere: If human-readable content is
included, how do you know what language to use? Maybe
just say the EST server has to know somehow.

- 7, 2nd last para: typo: s/it is RECOMMEND/it is
RECOMMENDED/

- The secdir review [1] had a few comments that would be
good to address, (and I've not seen a response), in
particular, a generalisation of this seems worth a
mention in section 7: "In 2.6, the additional CSR
attributes are non-verifiable data.  E.g., if a client
puts a MAC address into its CSR, there is no way for the
EST server or CA to validate that input.  The client can
easily insert any data it wants into that request, which
can lead to MAC stealing or other impersonation attacks.
The CA should never put any normative information into
the certificate that it cannot validate from a trusted
source."

  [1] http://www.ietf.org/mail-archive/web/secdir/current/msg04029.html

[Ballot discuss]
D2. The way Section 3.2. is structured has ambiguities that seem likely to lead to interoperability problems.  It took me a couple of passes through Section 3.2 to realize that there are actually 5 different protocols here that have been glued together because they some superficial similarity.  It seems like it would be much clearer to organize this section in terms of the EST operations in Figure 5; for each operation, define the URI path it uses and the content types.  As it is, it's not immediately clear that you couldn't send a Full CMC message to an "enrollment of new clients" URI.

[Ballot comment]
This document is just mad for 2119 language. There are some places where I think they are used excessively, but I am trying to be on board with Stephen's philosophy of "if it's not going to mess up an implementation, ignore incorrect uses". There are no technical worries that I see. So, I will only mention two silly, more editorial points:

Section 2:

  This section does not include RFC 2119 key words.

Really? :-) I suggest deleting the sentence.

Section 3.1:

  The EST client is RECOMMENDED to be configured with...

I'm worried what the answer might be, but why didn't you say "The EST client SHOULD be configured with..." instead of contorting the adjective into a place perfectly suited for an auxiliary verb? (You've got similar things throughout the document: "It is RECOMMENDED that clients..." instead of "Clients SHOULD...".) Is there anything other than just a weird writing style that is making you use these strange passive sentences? It's not that you think SHOULD and RECOMMENDED mean two different things, right?

[Ballot comment]
Not sure I've seen any answer to Nevil's OPS DIR review:


I have reviewed this draft.  It "describes a simple yet functional
certificate management protocol targeting Public Key Infrastructure
(PKI) clients that need to acquire client certificates and associated
Certification Authority (CA) certificate(s)."

I'm certainly not a security expert, and this is a fine-detailed
document that's clearly intended for people who have a good understanding of public key infrastructure, in particular RFC 5274
(Certificate Management Messages over CMS).  Nonetheless, it's
well-written, and I had no difficulty understanding how an EST server
is intended to work.

When it comes to deploying an EST server, an organisation will obviously
need to understand how pkix works in considerable detail, and to make
sure that its various components will have to interwork properly with
each other.  That said, this draft document documents a new service -
as far as I can see - so anyone deploying it will need to be sure that
their existing pki infrastructure will support it properly.

I note that in several places (e.g. section 3.32.3) there's a reference
to "TLS 1.1 [RFC4346] or later versions."  That seems like a good idea,
allowing for newer versions of TLS to work with an EST server,  however
it does mean that EST implementors will need to check that their servers
continue to work properly with such newer versions.

Question: in section 1.1, Terminology, 'Implicit Trust Anchor:' gives
an example that includes "used by server's to authenticate
manufacturing installed client credentials."  Can you make it a bit
clearer just what that really means?


A few small typos:

section 3.4: s/the possesion and/the possesion of and/  ?

section 3.4  s/cipher suite pose such/cipher suite poses such/

section 3.7  /simpleenroll is split over a line break, leaving
            a lone / at the end of a line

section 4.2  s/verify the authorization the/
              verify the authorization of the/

section 4.2.1  s/used to for/used for/

sections 4.2.3 and 4.3.2  s/informative information/information/ ?

section 4.5.2  s/Csrattrs/csrattrs/  (why the uc C here?)

Cheers, Nevil

[Ballot discuss]
D1. The document requires the use of HTTP >=1.1.  Why is that the case?  It seems like HTTP/1.0 over TLS would be sufficient for what this document is trying to do.  Also, the queries in Section 3.2.2 would be valid HTTP/1.0, but are not with HTTP/1.1 (because they lack a Host field)

D2. The way Section 3.2. is structured has ambiguities that seem likely to lead to interoperability problems.  It took me a couple of passes through Section 3.2 to realize that there are actually 5 different protocols here that have been glued together because they some superficial similarity.  It seems like it would be much clearer to organize this section in terms of the EST operations in Figure 5; for each operation, define the URI path it uses and the content types.  As it is, it's not immediately clear that you couldn't send a Full CMC message to an "enrollment of new clients" URI.

[Ballot comment]
C1. The comment in Section 1 that EST doesn't define EST over UDP/DTLS seems a little non-sensical.

C2. In Section 3.2.1: This document doesn't "profile" the Content-Type header, it requires that specific values be used in it.  It seems like this section could be deleted in favor of Section 3.2.4.

C3. This may be obvious, but I don't see anywhere in the document that says that the EST application layer MUST NOT be used over bare HTTP, without TLS.  This might be good to note explicitly.

[Ballot comment]
This seems both explicit and wierdly non-specific.

  TLS cipher suites that include "_EXPORT_" and "_DES_" in their names
  MUST NOT be used.  These ciphers do not offer a sufficient level of
  protection; 40-bit crypto in 2013 doesn't offer acceptable protection
  and the use of DES is deprecated.

[Ballot discuss]
UPDATED: I've now sent the email for this twice, but Sean's not seeing it. Resending manually ...

My apologies - balloted this, but Sean hasn't seen the email yet. Just in case I managed to not send it at all, I'm sending it again.

The Discuss is not for the editors, but for some ADs ... I'll clear immediately after someone clubs me with a clue-by-four.

Dear APP and SEC ADs, in 1.  Introduction, there's this text:

  EST specifies how to transfer messages securely via HTTP over TLS
  (HTTPS) [RFC2818], where the HTTP headers and media types are used in
  conjunction with TLS.  HTTPS operates over TCP; this document does
  not specify EST over Datagram Transport Layer Security/User Datagram
  Protocol (DTLS/UDP). 

I wonder if the disclaimer about not specifying EST over DTLS/UDP is the right thing to say (it's not wrong, although I'm not sure why the parallel to EST/HTTP/TLS/TCP is EST/DTLS/UDP - isn't there a layer missing?).

Given that we already have CORE, which can be fairly characterized as an HTTP variant running over UDP, and given that we approved an IETF 87 BOF on "DTLS In Constrained Environments (DICE)" yesterday, EST over CORE/DTLS/UDP would be an reasonable proposal to think about in the not-too-distant future (not in the context of this document, of course!)

I know we're not going to speculate about possible future work that hasn't even been chartered yet in an RFC that lasts Internet-Forever, but if EST over DTLS/UDP is going to be mentioned at all, is there anything else that would be helpful to say?

At a minumum, I found myself wondering if "EST over DTLS/UDP" was excluded because of some deep security challenge that would prevent EST from ever working over CORE/DTLS/UDP, or just "silly rabbit, EST uses HTTP, and HTTP doesn't run over DTLS".

Even if there are obvious dragons in that direction, that may not be something to mention in the document, but if it is, I should probably ask now ...

[Ballot discuss]
My apologies - balloted this, but Sean hasn't seen the email yet. Just in case I managed to not send it at all, I'm sending it again.

The Discuss is not for the editors, but for some ADs ... I'll clear immediately after someone clubs me with a clue-by-four.

Dear APP and SEC ADs, in 1.  Introduction, there's this text:

  EST specifies how to transfer messages securely via HTTP over TLS
  (HTTPS) [RFC2818], where the HTTP headers and media types are used in
  conjunction with TLS.  HTTPS operates over TCP; this document does
  not specify EST over Datagram Transport Layer Security/User Datagram
  Protocol (DTLS/UDP). 

I wonder if the disclaimer about not specifying EST over DTLS/UDP is the right thing to say (it's not wrong, although I'm not sure why the parallel to EST/HTTP/TLS/TCP is EST/DTLS/UDP - isn't there a layer missing?).

Given that we already have CORE, which can be fairly characterized as an HTTP variant running over UDP, and given that we approved an IETF 87 BOF on "DTLS In Constrained Environments (DICE)" yesterday, EST over CORE/DTLS/UDP would be an reasonable proposal to think about in the not-too-distant future (not in the context of this document, of course!)

I know we're not going to speculate about possible future work that hasn't even been chartered yet in an RFC that lasts Internet-Forever, but if EST over DTLS/UDP is going to be mentioned at all, is there anything else that would be helpful to say?

At a minumum, I found myself wondering if "EST over DTLS/UDP" was excluded because of some deep security challenge that would prevent EST from ever working over CORE/DTLS/UDP, or just "silly rabbit, EST uses HTTP, and HTTP doesn't run over DTLS".

Even if there are obvious dragons in that direction, that may not be something to mention in the document, but if it is, I should probably ask now ...

[Ballot discuss]

I'll end up as a yes for this but I have a few things I'd
like to DISCUSS first:

(1) I don't get how the client discovers the
"arbitraryLabel1" etc in 3.2.1? Don't you need to say
that they're assumed to be known to the client? (Or
provide a discovery mechanism, which sounds like too much
work.) I'm also unsure of the point of using .well-known
with those labels, but can live with it.

(2) 3.2.1, .well-known URLs will often result in HTTP
re-direction. Don't you need to say more for HTTP
re-directions, e.g. that whatever is required for the
original server cert is also required to be true of the
location to which the HTTP client is re-directed? How
does the MUST for tls-unique values from the 1st TLS
session in 3.5 work with re-direction? I suspect that you
need to either work out how 3xx responses are done or
else explain it a bit more to me, because I didn't get
that it works now.

(3) 3.6.1: what does check "against" mean? Don't you need
to say more, e.g. URI has to be in a SAN of a TA or
something? (Similar question for 3.6.2.)

(4) 4.4.2 - is this the 1st mention of SMIME
Capabilities?  Don't you need it earlier if you use it
here? Maybe that's a cut'n'paste error?

[Ballot comment]

- intro, why call out TLS1.1 and have no reference to
5246? I think at least adding 5246 would be good since we
would like folks to use TLS1.2 for this (and for
everything). I'm fine if this says that it doesn't really
matter (in functional terms) what version of TLS you use
which is what I think you're trying to say.

- intro, would it be worthwhile also saying that this
doesn't have any relationship with 6712 (which updates
4210) and sort-of attempts to do the CMP-like equivalent
of this? The only reason to add soemthing like that would
be to offset reader confusion if they go look at 4210,
see its updated by 6712 and then are puzzled that this is
very different from 6712. (And yes, all involved, incl.
me, are sorry about the 20-th century screw up that lead
to us having both CMP and CMC;-)

- 1.1: TA as the abbreviation for "Third Party Trust
Anchor" seems liable to confuse folks easily. Why not
TPTA to be clear? The two TA definitions following seem
to already allow for such confusion.

- 1.1: certificate-less TLS: what about DH-ANON? There's
no uniquely shared credential there. I thought you meant
TLS-PSK btw, but its turns out (in 3.3.3) that you really
mean TLS-SRP. Better to be clear about that up front.
(I'm not sure if TLS-SRP is really wise, but I guess this
is a corner case, right?)

- section 2, 2nd last para: this isn't really a "profile"
suggest s/profile/specification/

- 2.2.3: I think you could re-iterate that that better
take place via TLS here, or very bad things can happen:-)
(I know you say that in 3.2.3 but still...)

- 2.6: MAC addresses in CSR's seems a bit odd, maybe add
to the end of that sentence "...of an interface that the
EST CA is being asked to include in a public key
certificate" (but when does a cert include a MAC
address?) Seems like an odd example.

- 3.1, 2nd last para, last sentence: saying you MUST be
able to disable implicit TA databases seems likely to
mean that e.g. you couldn't do a client as a JS
application running in a browser or a browser plug-in. Is
that right and is that considered ok? Perhaps SHOULD
would be better there in terms of getting more/quicker
deployment? (3.2.3 also expresses this requirement.)

- 3.5 1st sentence: I think s/support/use/ here is right.
This is OPTIONAL to support but some servers might
REQUIRE it, which is bad for interop, but understandable
I guess. (Some server/CA policies will be such that not
all clients can work with 'em.)

- 3.5: Saying clients are RECOMMENDED to do this but that
PoP is OPTIONAL is confusing.

- 3.5: If tls-unique is MTI then you should say that in
section 3.3 somewhere. (The MUST verify for that in 3.5
makes it MTI for servers at least I think.)

- 3.5: Saying that you might need to hash the
challenge-password but not saying how seems wrong.  I'd
say just re-word to say that only <255 byte
challenge-passwords are supported here.

- 3.6.1: it seems odd to say that id-kp-cmcRA is used to
"authorize" an EST server.

- 4.1.1: (shameless self-promtion:-) If its useful you
could maybe make use of RFC 6920 for that out of band
confirmation. No problems if you'd rather not but the nih
format might be usable for that and might even help.
I expect you'll say that you've already implemented
something and its different, and that's fine.

- 4.1.1: what is a Publish Trust Anchor "control"?  I
don't recall the term control before.

- 4.2.1: I'm not clear from this what forms of PoP MUST
be implemented. Maybe 4.3 will make it clear.  (It
didn't.) I'd say maybe get rid of discussion of the more
complex forms of PoP from here.

- 4.2.2: is "rekeys the client certificate" sufficiently
clear?

- 4.2.2 and elsewhere: If human-readable content is
included, how do you know what language to use? Maybe
just say the EST server has to know somehow.

- 7, 2nd last para: typo: s/it is RECOMMEND/it is
RECOMMENDED/

- The secdir review [1] had a few comments that would be
good to address, (and I've not seen a response), in
particular, a generalisation of this seems worth a
mention in section 7: "In 2.6, the additional CSR
attributes are non-verifiable data.  E.g., if a client
puts a MAC address into its CSR, there is no way for the
EST server or CA to validate that input.  The client can
easily insert any data it wants into that request, which
can lead to MAC stealing or other impersonation attacks.
The CA should never put any normative information into
the certificate that it cannot validate from a trusted
source."

  [1] http://www.ietf.org/mail-archive/web/secdir/current/msg04029.html

[Ballot discuss]
The Discuss is not for the editors, but for some ADs ... I'll clear immediately after someone clubs me with a clue-by-four.

Dear APP and SEC ADs, in 1.  Introduction, there's this text:

  EST specifies how to transfer messages securely via HTTP over TLS
  (HTTPS) [RFC2818], where the HTTP headers and media types are used in
  conjunction with TLS.  HTTPS operates over TCP; this document does
  not specify EST over Datagram Transport Layer Security/User Datagram
  Protocol (DTLS/UDP). 

I wonder if the disclaimer about not specifying EST over DTLS/UDP is the right thing to say (it's not wrong, although I'm not sure why the parallel to EST/HTTP/TLS/TCP is EST/DTLS/UDP - isn't there a layer missing?).

Given that we already have CORE, which can be fairly characterized as an HTTP variant running over UDP, and given that we approved an IETF 87 BOF on "DTLS In Constrained Environments (DICE)" yesterday, EST over CORE/DTLS/UDP would be an reasonable proposal to think about in the not-too-distant future (not in the context of this document, of course!)

I know we're not going to speculate about possible future work that hasn't even been chartered yet in an RFC that lasts Internet-Forever, but if EST over DTLS/UDP is going to be mentioned at all, is there anything else that would be helpful to say?

At a minumum, I found myself wondering if "EST over DTLS/UDP" was excluded because of some deep security challenge that would prevent EST from ever working over CORE/DTLS/UDP, or just "silly rabbit, EST uses HTTP, and HTTP doesn't run over DTLS".

Even if there are obvious dragons in that direction, that may not be something to mention in the document, but if it is, I should probably ask now ...

[Ballot discuss]
The Discuss is not for the editors, but for some ADs ... I'll clear immediately after someone clubs me with a clue-by-four.

Dear APP and SEC ADs, in 1.  Introduction, there's this text:

  EST specifies how to transfer messages securely via HTTP over TLS
  (HTTPS) [RFC2818], where the HTTP headers and media types are used in
  conjunction with TLS.  HTTPS operates over TCP; this document does
  not specify EST over Datagram Transport Layer Security/User Datagram
  Protocol (DTLS/UDP). 

I wonder if the disclaimer about not specifying EST over DTLS/UDP is the right thing to say (it's not wrong!).

Given that we already have CORE, which can be fairly characterized as an HTTP variant over UDP, an EST over CORE/DTLS/UDP would be an reasonable question to think about (not in this document, of course!)

If this topic is going to be mentioned at all, is there anything else that would be helpful to say? At a minumum, I found myself wondering if "EST over DTLS/UDP" was excluded because of some deep security challenge that would prevent EST from ever working over CORE/DTLS/UDP, or just "silly rabbit, EST is using HTTP, and HTTP doesn't run over DTLS".

That may not be something to mention in the document, but if it is, I should probably ask now ...

[Ballot comment]
These comments are for the editors. Please consider them as your document moves through the process.

In 3.2.  HTTP Layer

  HTTP 1.1 [RFC2616] and above support persistent connections.  As
  described in Section 8.1 of that RFC, persistent connections may be
  used to reduce network and processing load associated with multiple
  HTTP requests.  EST does not require or preclude persistent HTTP
  connections and their use is out of scope of this specification.

If I understand the final sentence correctly, EST works fine whether you use persistent HTTP connections or not. If that's so, and I suspect it is, that's not "out of scope", that's "good news! we've looked at it, and there's no problem". Please consider removing "and their use is out of scope of this specification".

In 4.4.1.  Server-side Key Generation Request

  The server needs to know a priori about the algorithms supported by
  the client.

I don't know whether this requirement is typical or not, but I wonder - is there some way this might be signaled?

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-pkix-est-07.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

IANA has questions about some of the actions requested in this document.

IANA understands that there are four actions requested.

First, the authors write, "There is one OID in Section 4.4.1.2 that needs to be registered in the PKIX Arc." However, IANA is not the registry maintainer for the PKIX ARC. We recommend examining http://www.imc.org/ietf-pkix/ and http://www.imc.org/ietf-pkix/pkix-oid.asn for further information about PKIX OID registration procedures.

Please add a sentence to the document noting that this registry is not maintained by IANA. It might also be appropriate to move this notice to another section of the document.

Second, in the Well-Known URIs registry located at:

http://www.iana.org/assignments/well-known-uris/well-known-uris.xml

IANA will register the following URI suffix as follows:

URI suffix: est
Change controller: IETF
Reference: [ RFC-to-be ]
Related Information:
Date Registered: [ TBD-at-registration ]
Date Modified:

IANA will submit this request to the registry expert for review.

Third, in the Application Media Types registry located at:

http://www.iana.org/assignments/media-types/application

a new application media type will be registered:

csrattrs

with a reference of [ RFC-to-be ]. The template for the registration is provided in Section 6 of the approved document.

Fourth, the authors note that "The application/pkcs7-mime content type defines the optional "smime-type" parameter [RFC5751]. The smime-type parameter for Server-side Key Generation Response is server-generated-key." The optional parameters for the "smime-type" are not registered separately. Instead, they are provided as part of the reference to the application/pkcs7-mime registration.

IANA Question -> Would the authors like to add a reference to this document to the established [RFC5751] reference for the application/pkcs7-mime media type?

IANA understands that these actions are the only ones required upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Enrollment over Secure Transport) to Proposed Standard


The IESG has received a request from the Public-Key Infrastructure
(X.509) WG (pkix) to consider the following document:
- 'Enrollment over Secure Transport'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2013-06-24. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document profiles certificate enrollment for clients using
  Certificate Management over CMS (CMC) messages over a secure
  transport.  This profile, called Enrollment over Secure Transport
  (EST), describes a simple yet functional certificate management
  protocol targeting Public Key Infrastructure (PKI) clients that need
  to acquire client certificates and associated Certification Authority
  (CA) certificate(s).  It also supports client-generated public/
  private key pairs as well as key pairs generated by the CA.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-pkix-est/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-pkix-est/ballot/


No IPR declarations have been submitted directly on this I-D.