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

Hi Peter,

On 30/04/2018 15:43, Peter Gutmann 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.

Understood.

> 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 think it depends on how the changes look like at the end.

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

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.

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

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.

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

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.

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

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.

>> Again, this is neither correct formal syntax nor correct HTTP requests.
> 
> Quite probably.  What should it say?

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

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

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

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

Yes.

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

Seriously?

> will people really need to be given a
> reference to the AES spec in order to implement SCEP?

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.

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

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.

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

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

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

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.

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

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.

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

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.

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

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.

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

Fine with me.

>> 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
> saag@ietf.org
> https://www.ietf.org/mailman/listinfo/saag
> 