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

From: "Max Pritikin (pritikin)" <[email-masked]>
Date: Tue, 8 May 2018 15:44:49 +0000

To re-enforce a point peter is making inline: there are “errors” in how SCEP uses a number of HTTP fields, and “unclean” uses of unregistered MIME types and a bunch of other little things. What SCEP got right was simplicity. This allowed it to endure for 20yrs or so. 

Updating SCEP to modern understandings of how all this stuff should be used (while maintaining the simplicity) is why EST (RFC7030) exists. If SCEP had been an RFC I’d suggest that EST “obsoletes” it. 

I don’t see the value in updating all this stuff in SCEP at this point — despite agreeing with the concerns. Doing so would only create yet another new protocol in this already crowded space. I wouldn’t even begin to know how to explain all this to somebody new to the field.   

- max

> On Apr 30, 2018, at 6:43 AM, Peter Gutmann <[email-masked]> wrote:
> 
> 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.
> 
> _______________________________________________
> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 31 May 2018 12:38:40 +0300

Hi Max,

> I don’t see the value in updating all this stuff in SCEP at this point — despite agreeing with the concerns. Doing so would only create yet another new protocol in this already crowded space. I wou…

I understand that this exercise is mostly about documenting a protocol
which was in use for a long time. So I don't expect SCEP to change on
the wire. However I don't think publishing an RFC that seem to bless
incorrect or outdated use of HTTP and MIME is a good idea. I would like
to have very clear disclaimers in the document, either at the beginning
or in specific cases where it deviates from best current practices. This
is not a big ask and this is not hard to do.

Best Regards,
Alexey

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 31 May 2018 13:13:37 +0300

Hi Peter,

> the text because I didn't write it.

Understood.

> counter back to requiring further changes if people object to the changes?

I think it depends on how the changes look like at the end.

> that people wanted the last time round.

Two comments on this:

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.

2) The argument "I am not going to modify this, because I already
modified this text" is generally not sufficient on my book. You need to
engage in a discussion about why the text is this way and whether it can
be made correct or clear.

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

To elaborate on my concern here:

1) using undocumented MIME types is like having an underspecified
protocol. Registering everything is my first preference.

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?

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.

> know what else to put in there.

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.

> so they're not used but their presence is required.

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.
There are at least 2 instances of this in the document which make it
look like it is Ok to hardcode HTTP URL paths in documents. As I
explained earlier in my reply, I don't like this document to be used a
precedent to violate best current practices.

> Quite probably.  What should it say?

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

> I'm worried about this triggering another round of comments and editing,

I don't think this is avoidable. Don't make it painful for yourself ;-)

> Are these really needed?  References to AES and SHA-2 and LDAP?

Yes.

> It's just
> going to add a lot of noise to the spec,

Seriously?

> will people really need to be given a

Yes, because it is a required part of implementing SCEP and people
shouldn't just try to Google to find the right spec and end up finding a
wrong one. So AES and SHA-2 are absolutely Normative references.

> into a survey of other protocols because it'd be a long and somewhat tedious

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.

> prefer to just leave this stuff alone since it's worked OK for nearly 20

I am really resisting not to have a sarcastic reply here, but I wouldn't.

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

> strings.  They shouldn't, but they can if they want to.

People can violate any kind of requirement. I think the question here is
whether the document should encourage that.

I am Ok with leaving this as is, but be prepared to answer this question
in IESG review.

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

I think this is unclear, as I don't know what "leaf" means here. Is it
the first or the last? If the order doesn't matter, than delete
everything starting from ", but the issued certificate MUST be" in this
sentence.

> you can add any further lines you like.

I think you are missing my point.

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.

Ok, if you say nobody should extend SCEP in such a way, you should say
so in the document.

> earlier comment about being caught between conflicting requests for changes.

Fine with me.

---

From: "Max Pritikin (pritikin)" <[email-masked]>
Date: Thu, 31 May 2018 22:40:44 +0000

> On May 31, 2018, at 3:38 AM, Alexey Melnikov <[email-masked]> wrote:
> 
> Hi Max,
> 

You accurately summarize part of why the document is in the current state. “Informational” or “Historic” is a solid way to document when we “don’t expect SCEP to change on the wire” and to acknowledge that it isn’t up to snuff. It also provides that clear disclaimer you’re looking for. Strengthening the discussion to your point in s1 Introduction to recommend RFC7030 might go further. (Current language is “MAY”, which might not be as clear as you’re looking for). 

- max