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

[Peter Gutmann <[e-mail]>]

Apologies for the long delay in responding, I've been buried in other work.
Also, I'm not sure who to send this to, I got notified via a do-not-reply
address, I assume it goes to the SAAG list?

A general response to this, I didn't write this document so as with the
previous review I'll have to say "it was like this when I got here" in several
cases, I've left the original authors' text intact wherever possible but
without rewriting half the doc in my own words I can't really defend a lot of
the text because I didn't write it.

Also, some of the comments apply to things that have already been picked over
and corrected.  What will happen if I start making alterations to the
alterations?  Will it go to publication after that, or will it reset the
counter back to requiring further changes if people object to the changes?
I'm concerned that I'm going to get caught between two lots of editing
changes, I tried to change/fix everything that people pointed out last time,
but if I make more changes now it may end up undoing or changing the things
that people wanted the last time round.

>1) In general, the document is using several unregistered MIME types with
>"x-" prefix:
>
>application/x-x509-ca-cert
>application/x-x509-ca-ra-cert
>application/x-pki-message
>application/x-x509-next-ca-cert
>
>These should be registered in the IANA Considerations as per Appendix A of
>RFC 6838.

Isn't the whole point of the x- type that it doesn't need to be, and indeed
can't be, registered?  RFC 6838 says:

  Types in this tree cannot be registered and are intended for use only with
  the active agreement of the parties exchanging them.

>application/x-x509-ca-cert
>
>  How is this different from application/pkix-cert registered in RFC 2585?

No idea, it was like that when I got here.  I assume one is a CA cert and the
other isn't.

>    "GET" CGI-PATH CGI-PROG "?operation=GetCACaps"
>
>This is not a correct ABNF (in case you intended to define a formal syntax
>here) and this is not a correct HTTP request line. Please make it one or
>another, or clarify somewhere syntax that you use.

What form should it be in?  It's been like this for close to twenty years, I
just left what the original authors had put there in place, I honestly don't
know what else to put in there.

>Also, I don't think CGI-PATH and CGI-PROG are significant for the request

They aren't, that's why I updated the text to mention this.  However everyone
seems to use fixed values for these based on close to 20 years of draft use,
so they're not used but their presence is required.

>Again, this is neither correct formal syntax nor correct HTTP requests.

Quite probably.  What should it say?

>Firstly, clients don't care about HTTP server using CGI, they just care about
>knowing where to send SCEP requests.

Sure, that's why I said so in the updated draft, just hardcode in "/cgi-
bin/pkiclient.exe" for compatibility with existing implementations.

>Secondly, hardcoded URI paths are in violation of RFC 7320. You can read more
>on this in Section 4.4 of
>
><https://datatracker.ietf.org/doc/draft-ietf-httpbis-bcp56bis/?include_text=1>

SCEP predates RFC 7320 by 14-15 years, so it's a bit late to the party...

>I understand that this is a deployed protocol and the default path used is
>unlikely to change. However, I don't think the document should pay so much
>attention to use of CGI-PATH/CGI-PROG. My suggestion is: a) Remove any
>reference to CGI-PROG/CGI-PATH from the document b) Replace the above section
>with something like this:

See above, the text already says that it's only there for backwards
compatibility.  I can change it to remove CGI-PROG/CGI-PATH if required, but
I'm worried about this triggering another round of comments and editing,
particularly since there are multiple places in the text that will require
changes.

>1) Missing references:

Are these really needed?  References to AES and SHA-2 and LDAP?  It's just
going to add a lot of noise to the spec, will people really need to be given a
reference to the AES spec in order to implement SCEP?

>2) Should ACME work be mentioned in the Introduction?

There are quite a lot of cert-enrolment protocols, the original SCEP text only
covers CMP and CMP which date from the same time as SCEP, I didn't want to get
into a survey of other protocols because it'd be a long and somewhat tedious
list.

>Clients shouldn't care whether or not SCEP is provided by a CGI program.
>Please change this to "CA HTTP URL path" or "CA HTTP URI path".

See above about potential cascading changes throughout the text, I'd really
prefer to just leave this stuff alone since it's worked OK for nearly 20
years.

>How often and for how long should a client poll? Recommending some defaults
>would be useful to set expectations.

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...

>Why not "MUST NOT" and what are possible implications of violating the SHOULD
>NOT?

Because some implementations may choose to parse at least a few common error
strings.  They shouldn't, but they can if they want to.

>What does the last requirement actually mean? Is this describing order of
>certificates or just saying that it is not an intermediate certificate?

It's saying that the leaf certificate in the chain is the issued certificate.

>So just to double check that I understood this correctly: the client is
>generating a self-signed certificate B in order to retrieve its certificate A
>signed by CA?

Yes.

>The last requirement is quite problematic for extensibility. I understand why
>this sentence is there though. Are future extensions to SCEP likely?

Why is it problematic for extensibility?  What's returned is lines of text,
you can add any further lines you like.

>    A SCEP CA is the entity that signs client certificates.  A CA MAY
>    enforce any arbitrary policies and apply them to certificate
>    requests, and MAY reject a request for any reason.
>
>I think this is pretty much granted and doesn't need to be said, especially
>the latter part.

This was something that previous people who commented on it requested, see my
earlier comment about being caught between conflicting requests for changes.

>When referncing RFC 4648 you should specify the section number to avoid all
>confusion. I assume you meant Section 4?

Yes, I've updated the text although it already points out that it's "base64"
and not "base64url" that's used.

Peter.