Re: [saag] Status of the SCEP RFC draft

[Peter Gutmann <[e-mail]>]

Sean Turner <[e-mail]> writes:

>The thing though is that the specification, at least, has had quite a 
>number of changes since then

The bits-on-the-wire is still identical, the reason so much of the text has
changed is because the document grew by accretion and the rewrite was an
attempt to... well, as the appendix says:

   This specification has spent more than seventeen years in the draft
   stage.  [...]  To fit this role, extra features were bolted on in a
   haphazard manner through the addition of a growing list of appendices
   and by inserting additional, often conflicting, paragraphs in various
   locations in the body text.  Since existing features were never
   updated as newer ones were added, the specification accumulated large
   amounts of historical baggage over time. 

   [More text that basically says "this update cleans things up"]
   
So it's the same on-the-wire protocol, just with the text describing it 
cleaned up.

>Note that I believe all of RSA's PKCS specifications published through the 
>IETF stream were informational.

Ah, fair enough.  As I mentioned previously, I can live with Informational
if that's what the rules say.

>And that brings up another point that I think needs to be made clear.  
>Often, RSA has explicitly granted change control to the IETF.  Because SCEP 
>started out as "Cisco Systems' Simple Certificate Enrollment Protocol” and 
>was that way up until draft-nourse-scep-22 is Cisco doing the same here?

When I revived the draft, I posted messages to everywhere I could think of
that had SCEP people (the old SCEP mailing list, the JSCEP list, and there
was something done at an IETF) and asked if anyone had any objections if I 
continued with the work.  It was pretty informal.

(There was discussion about it with the original authors who could still be
contacted, but it was all in private email, if any of the original authors
want to speak out publicly, feel free).

>I gotta ask about the dropped pre-5378 boiler plate.  Was approval obtained 
>from each of the previous authors: Xiaoyi Liu, Cheryl Madson, David McGrew, 
>Andrew Nourse, Jan Vilhuber, and Max Pritikin?  It’s annoying process 
>mumbo-jumbo but because I couldn’t get an answer from everybody the pre-5378 
>boiler plate had to be included in the SSL RFC: 
>https://datatracker.ietf.org/doc/rfc6101/.

Some of the authors can't be contacted any more (some of the removal requests 
I mentioned in a previous message were things like "X left the company Y 
years ago, please remove their name"), so in general, "no".  However given 
that 5378 dates from the time of draft-nourse-scep-xx, wouldn't it already 
fall under 5378?

Just as an FYI, there wasn't any explicit move from boilerplate-X to 
boilerplate-Y, the draft just contains whatever xml2rfc puts in there by
default.  I really don't mind what boilerplate it comes with, as long as 
it's not too much of a headache to deal with via xml2rfc, which from memory
dings you for the use of outdated boilerplate.

Peter.