Subject: Re: [saag] Comment added to draft-gutmann-scep history

From: Peter Gutmann <[email-masked]>
Date: Fri, 13 Jul 2018 08:49:28 +0000

Alexey Melnikov <[email-masked]> writes:

>1) I need help with you flagging to me which text was modified in the past
>due to comment. I might agree or disagree with these changes and they might
>be highlighting sections which might need more work anyway.

Ahhh... how much of a list do you want?  There's an awful lot of emails to go
through (maybe two years' worth of comments) to sort it all out, and most of
it is pretty uninteresting.  If you're OK with dealing with it on a case-by-
case basis (e.g. "this particular bit of text was based on comments about X
and Y") that would make it easier.

>If you can convince me that #2 is not an issue, then I suggest adding a note
>to the document saying that it is using a bunch of MIME types that are not
>registered (or have different registered aliases, but used here for historic
>reasons). I am happy to suggest some text.

That would be good, thanks.  Since it's a case of "Types in this tree cannot
be registered", I don't see how they could be registered without renaming
them, which breaks compatibility with all existing implementations, and the
primary goal of the draft was to keep it bits-on-the-wire identical to what's
been in use the entire time (modulo single DES + MD5 vs. AES + SHA-2).

In terms of:

>2) if I have a general Web Server that happens to return different MIME types
>here (because there are other already registered MIME types that mean the same
>thing), is this going to be a problem for SCEP clients?

I don't think so for two reasons, firstly I'm not aware of anyone actually
doing SCEP using a standard web server, it's always a standalone SCEP
application that isn't a web server (if anyone is implementing SCEP as a CGI
for a conventional web server, please speak up, I've never heard of one), and
secondly I don't know if anyone actually looks at the MIME types.  I wouldn't
want to put money on that, no doubt some client or other will break if you
change the strings, but I'd say that a lot of clients won't care what the
value is.

>I think either ABNF (which is pretty universally used in IETF RFCs) or in
>free text form which sort of looks like HTTP request line, but isn't. Please
>pick one and I can suggest some small specific edits to reflect that.

That would be really useful, thanks.  I think ABNF is best.

>I would like to use ABNF terminal for this and only explain that the path is
>typically as you describe only in one place in the document. 

OK, will that be part of the text above?  If you've got some appropriate
wording to put in that'd be helpful.

>As above: pick between ABNF and free form text and I can suggest some
>specific edits.

ABNF, thanks.

>So AES and SHA-2 are absolutely Normative references.

OK, I've added AES and SHA-2 refs.

>I am actually Ok with no mentioning ACME, but the text in the introduction
>reads like it is arguing that SCEP is the best thing since bread and butter
>and I don't believe what it is trying to say is accurate.

Hmm, it's just saying that it's widely used, which is why it's being
documented, it doesn't try and claim it's particularly good... the comparisons
to CMP and CMC didn't appear until draft 17, with more changes in wording
around draft 22.  As far as I know this wording was purely political, PKIX
wanted everyone to use their CMP or CMC protocols and so the references were
added to appease PKIX.  Since the market appears to have made their choice
between { CMP, CMC, SCEP }, it's probably easiest to just remove any mention
of them, so that I don't have to engage in a comparative analysis of who knows
how many different management protocols (there's a lot more than CMC and CMP
out there now).  So I can just remove that entire paragraph apart from the
first sentence and merge that with the previous paragraph:

-- Snip --

X.509 certificates serve as the basis for several standards-based security
protocols such as <xref target="TLS">TLS</xref>, <xref target="SMIME">
S/MIME</xref>, and <xref target="IKEv2">IKE/IPsec</xref>.  When an X.509
certificate is issued there typically is a need for a certificate management
protocol to enable a PKI client to request or renew a certificate from a
Certificate Authority (CA).  This specification defines a protocol, Simple
Certificate Enrolment Protocol (SCEP), for certificate management and
certificate and CRL queries.

-- Snip --

That's a pretty basic statement of functionality without trying to get into a
comparative analysis of a load of different protocols and mechanisms, and one
which will hopefully upset the least number of people.

>> I have no idea... I mean I literally have no idea, I don't know what
>> implementations do in practice.  I know that in some cases with manual
>> approval it can take hours, but I'm not sure if that's typical.  It could be
>> seconds, minutes, hours...
>
>I suspect you will get a blocking DISCUSS comment on this in IESG review. But
>if you want to take your chances, I am Ok with no change.

I've added the following, which formalises what's in the above sentence:

  The frequency of the polling operation is a CA/client configuration issue,
  and may range from seconds or minutes when the issue process is automatic
  but not instantaneous, through to hours or days if the certificate issue
  operation requires manual approval.

>I think this is unclear, as I don't know what "leaf" means here. 

It's the certificate at the end of the chain, the EE certificate.  It's a
standard PKI term, I've tried to find a definitive reference for it but it's
just used without references in other places, e.g. RFC 4043, RFC 7671, non-
IETF locations like MS Technet, etc.

>Here is a speculative example: a future extension to SCEP decides to use JSON
>for returning this information. JSON will have a different media type. If a
>client ignores it, it might be unable to parse it. Using media type names for
>signalling payload format is one of the main benefits of using MIME.

The text there already says:

  The Content-type of the reply SHOULD be "text/plain".  Clients SHOULD ignore
  the Content-type, as older implementations of SCEP may send various Content-
  types.

Given that implementations have in the past sent all sorts of stuff as the
content type (GetCACaps appeared in draft 10 but it wasn't until draft 19 that
a content type was specified), and the text says you should ignore it, which
implementations do, it won't matter what anyone puts in there.  Up until
revision 19 of the draft there was no content type specified, so you could
potentially find anything in there.  It could be text/plain or text/json or...
audio/midi and they'll all be ignored equally.  As I mentioned earlier, I
doubt anyone runs a SCEP server on an actual web server, the MIME types and
whatnot were presumably just specified because you need to put something in
there as a content type.  So most likely the Content-type will never be used
to select an actual content type.

I could perhaps add a note somewhere at the start saying that SCEP, like any
number of other PKI protocols, uses HTTP as a universal substrate, and that
you shouldn't expect that doing something HTTP-ish like setting a Content-type
will actually have any effect?  A reference to RFC 3205/BCP 56 should probably
accompany that.

Peter.

---

From: Peter Gutmann <[email-masked]>
Date: Sat, 14 Jul 2018 03:07:42 +0000

I wrote:

>you shouldn't expect that doing something HTTP-ish like setting a Content-
>type will actually have any effect?  A reference to RFC 3205/BCP 56 should
>probably accompany that.

How about this:

-- Snip --

Like many other Internet protocols, SCEP uses HTTP as a universal substrate,
for more on the implications of this see <xref target="BCP56">BCP 56</xref>.
While SCEP messages are carried over HTTP transport, neither the client nor
the server is likely to be a conventional HTTP-speaking web server or client,
providing only the minimum functionality required for HTTP transport, see the
"HTTP Considerations" section of <xref target="RFC6712">RFC 6712</xref> for
more on this.  Implementations SHOULD NOT use complex HTTP mechanisms such as
chunked encoding, Expect/Continue, HTTP redirects, and similar facilities.

To guard against establishing an erroneous connection to any of the myriad
other devices and services that speak HTTP, SCEP servers MAY choose to respond
to non-SCEP requests, for example a GET from a web browser, with an HTML
diagnostic message notifying the client that they're talking to the wrong
server or service.  Similarly, clients MAY check for an HTML response from the
server and report a configuration error, for example that the client is
connecting to the wrong server or port on a server.

-- Snip --

The latter is particularly useful, my code has been doing that for quite some
time to deal with "the client/server is broken, it's not getting
certificates".  The problem invariably is that they've specified the wrong
server name/IP address, or forgotten to specify a port so the default 80 is
used, or there's a proxy in the way that redirects the connection to a web
server on 80 rather than a SCEP server on 80, or something similar.

Maybe we need an updated BCP 56 that provides info on the general use of HTTP
as a substrate and how to deal with it that every other HTTP-as-substrate-
using RFC can refer to (no, I'm not volunteering to write it :-).

Peter.

---

From: Benjamin Kaduk <[email-masked]>
Date: Sat, 14 Jul 2018 10:15:47 -0500

> using RFC can refer to (no, I'm not volunteering to write it :-).

draft-ietf-httpbis-bcp56bis is active in the httpbis WG at the moment -- it
would be appropriate to make such suggestions to the WG :)

-Ben

---

From: Patrick McManus <[email-masked]>
Date: Sat, 14 Jul 2018 14:08:50 -0400

Ben - thanks for flagging this.

Referencing BCP56 is probably not a great idea - its not well tuned to the
way HTTP evolved.

BCP56bis otoh is designed to provide what you need. Its a work in progress
and would certainly benefit from review and comments:

editors copy:
https://httpwg.org/http-extensions/draft-ietf-httpbis-bcp56bis.html
current official draft:
https://tools.ietf.org/html/draft-ietf-httpbis-bcp56bis-06
github as easy place to leave feedback and suggested edits:
https://github.com/httpwg/http-extensions

-Patrick

On Sat, Jul 14, 2018 at 11:15 AM, Benjamin Kaduk <[email-masked]> wrote:

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

---

From: Peter Gutmann <[email-masked]>
Date: Sun, 15 Jul 2018 03:32:19 +0000

>would be appropriate to make such suggestions to the WG :)

That's exactly what I need, thanks!  Just grabbing a copy now.  And RFC 7322
allows referencing drafts as Informative refs, so I'm clear there as well.

Peter.

---

From: Peter Gutmann <[email-masked]>
Date: Sun, 15 Jul 2018 03:46:36 +0000

Patrick McManus <[email-masked]> writes:

>Its a work in progress and would certainly benefit from review and comments:
>

Is there a preferred forum specifically for discussing this document rather
than the high-volume HTTP list?  In terms of github, I've never been convinced
that a PR is the best substitute for a discussion list thread...

I've got some specific suggestions about wording around the (mis-)use of GET,
which early versions of SCEP did (and some still do *cough*Microsoft*cough*),
creating non-idempotent GET requests containing multiple kB of base64-encoded
binary gunk.  SCEP has provided a good litmus test for how many ways this
breaks in the presence of proxies, caches, and a wide range of server types,
being able to reference 56bis on this would mean I could remove a pile of text
from the draft.

Peter.

---

From: Patrick McManus <[email-masked]>
Date: Sun, 15 Jul 2018 09:10:52 -0400

I'm sorry I don't have any other approach to offer - github and the mailing
list are the normal mechanisms. Github works quite well for our working
group. If you'd like to substitute for a discussion thread I would
suggesting opening an issue rather than a PR (or perhaps in addition to).

in extremis you could of course mail the author or chair directly rather
than participating in the WG. That of course doesn't really scale.

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 30 Jul 2018 10:55:00 +0100

Hi Peter,

I will respond to your long email next week when I have a chance to 
catch up with my documents, in the meantime, a quick response to this email:

> for more on the implications of this see <xref target="BCP56">BCP 56</xref>.
Referencing existing version of BCP 56 doesn't sound great, considering 
that it is being revised by the HTTPBIS WG.

Also, can you please add some text that SCEP deviates from best current 
practices, like correct use of MIME types and non use of harcoded paths.
> to non-SCEP requests, for example a GET from a web browser,
I understand where you are going with this, but the above is non 
implementable. What is "non-SCEP request" and how a SCEP server can 
determine that the client is a browser? I think the above text can be 
made tighter.
>   with an HTML
If you change "HTML response" to "text/html", the above is agreable.

Best Regards,
Alexey