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

["Max Pritikin (pritikin)" <[e-mail]>]

> On May 31, 2018, at 3:38 AM, Alexey Melnikov <[e-mail]> wrote:
> 
> Hi Max,
> 
> On 08/05/2018 18:44, Max Pritikin (pritikin) wrote:
>> 
>> 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.   
> 
> 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.

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

> 
> Best Regards,
> Alexey
> 
>> - max
>> 
>>> On Apr 30, 2018, at 6:43 AM, Peter Gutmann <[e-mail]> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/saag
>> 
>> _______________________________________________
>> saag mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/saag
>> 
>