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

[Peter Gutmann <[e-mail]>]

Alexey Melnikov <[e-mail]> 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.