Subject: [saag] Status of the SCEP RFC draft

From: Peter Gutmann <[email-masked]>
Date: Thu, 7 Dec 2017 03:48:43 +0000

After 18 years in the draft stage, this is finally ready for publication. The
one sticking point is its status, which I think should be Standards Track but
others think should be Historic.

The problem with Historic is two-fold, firstly RFC 2026 defines historic as "A
specification that has been superseded by a more recent specification or is
for any other reason considered to be obsolete is assigned to the "Historic"
level", which is in both cases the exact opposite of what SCEP is, it's not
superseded and it's in wider and more active use than the marked-as-standards-
track CMP and CMC.

The second is that SCEP is in extremely wide, and active use, and is
referenced in numerous other industry standards (usually with an apologetic
note about having to refer to a draft :-).  For example Apple's OTA profile
configuration and delivery protocol only supports SCEP, and it seems to be the
standard MDM mechanism in enterprise environments.  Microsoft has supported it
as standard since Server 2003 via NDES and that's then used to provision
mobile devices, as well as routers, firewalls, ... not to mention its use in
SCADA, ICS, embedded, etc.  There are (at least) a billion+ devices running
SCEP today.  Like C, it'll probably be around forever because so much
infrastructure depends on it.

In addition there are new implementations as recently as the last six months,
and more expected over time since it's pretty much the only protocol there is
for automated cert provisioning of devices, or at least the only one that's
widely deployed and that works.

So both from the RFC 2026 and the pragmatic point of view, I think this should
be published as standards-track.  It's definitely not Historic in either
sense.

Peter.

---

From: Tim Hollebeek <[email-masked]>
Date: Thu, 7 Dec 2017 15:07:26 +0000

I can confirm that SCEP is required for Apple MDM (I previously led a team
that implemented SCEP as part of a mobile security product).

I find the perspective that SCEP is only of historical interest to  be
somewhat baffling.

-Tim

-----Original Message-----
From: saag [mailto:[email-masked]] On Behalf Of Peter Gutmann
Sent: Wednesday, December 6, 2017 8:49 PM
To: [email-masked]
Subject: [saag] Status of the SCEP RFC draft

After 18 years in the draft stage, this is finally ready for publication.
The one sticking point is its status, which I think should be Standards
Track but others think should be Historic.

The problem with Historic is two-fold, firstly RFC 2026 defines historic as
"A specification that has been superseded by a more recent specification or
is for any other reason considered to be obsolete is assigned to the
"Historic"
level", which is in both cases the exact opposite of what SCEP is, it's not
superseded and it's in wider and more active use than the
marked-as-standards- track CMP and CMC.

The second is that SCEP is in extremely wide, and active use, and is
referenced in numerous other industry standards (usually with an apologetic
note about having to refer to a draft :-).  For example Apple's OTA profile
configuration and delivery protocol only supports SCEP, and it seems to be
the standard MDM mechanism in enterprise environments.  Microsoft has
supported it as standard since Server 2003 via NDES and that's then used to
provision mobile devices, as well as routers, firewalls, ... not to mention
its use in SCADA, ICS, embedded, etc.  There are (at least) a billion+
devices running SCEP today.  Like C, it'll probably be around forever
because so much infrastructure depends on it.

In addition there are new implementations as recently as the last six
months, and more expected over time since it's pretty much the only protocol
there is for automated cert provisioning of devices, or at least the only
one that's widely deployed and that works.

So both from the RFC 2026 and the pragmatic point of view, I think this
should be published as standards-track.  It's definitely not Historic in
either sense.

Peter.
_______________________________________________
saag mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/saag

---

From: "Paul Hoffman" <[email-masked]>
Date: Thu, 07 Dec 2017 07:14:34 -0800

+1 to standards track. This is not a shining moment of glory for the 
IETF, but we need to be honest about its status.

--Paul Hoffman

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 7 Dec 2017 15:17:03 +0000

> others think should be Historic.

FWIW, I think SCEP really ought be an RFC. It's an
embarrassment to the IETF that it's lingered long
enough to buy beer in most places;-)

I haven't read the latest version, when I last looked a
year-ish ago it wasn't quite done, but I'm sure it could
be by now. Good enough for some kind of last-call anyway.
If there was an IETF LC for it, I'd review it then if
that helped. I don't think this warrants any kind of
WG formation, unless it turned out (e.g. in last call
reviews) that there was a big difference between the
text and what's deployed.

I'd be just fine with standards track, we already
have multiple cert management standards track RFCs
and one more won't damage anything that's not already
busted, esp. if the new one is used in the wild. That
said, I don't have any real skin in that game, so I
don't much care about the RFC status.

Cheers,
S.

---

From: "Max Pritikin (pritikin)" <[email-masked]>
Date: Thu, 7 Dec 2017 16:38:12 +0000

Since I’m in the ironic position of having written much of SCEP, maintained the doc for years, and then forward much of the value into EST (RFC7030) to gain elliptic curve support and articulate CMC alignment and to avoid "propagation of standards" I suppose I’ll chip in… although in the latest draft only Peter is listed as an author.

I’ve believed for a while that recognizing SCEP as a standards track RFC is a recognition of reality. Ironically it’d be easier to explain the aspects of the protocol that are “outdated” (or “historic”) if that reality had been recognized long ago. My last updates to the SCEP introduction reflected that reality as we moved toward EST as the compromise. Peter’s updates to that text has reduced the assertion that CMC/CMP (or EST) “SHOULD” be used to a statement that they “MAY” be used. In the context of this conversation; we need this text to accurately reflect the position of IETF (presumably the output of this thread).

- max

On Dec 7, 2017, at 8:17 AM, Stephen Farrell <[email-masked]<mailto:[email-masked]>> wrote:

Cheers,
S.

Peter.
_______________________________________________
saag mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/saag

_______________________________________________
saag mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/saag

---

From: Peter Gutmann <[email-masked]>
Date: Thu, 7 Dec 2017 21:32:19 +0000

Max Pritikin (pritikin) <[email-masked]> writes:

>in the latest draft only Peter is listed as an author. 

Just to clarify this a bit, the previous authors asked that their names be 
removed from the top because they were no longer involved with the work 
and/or didn't want to keep getting bugged about it.  It wasn't an attempt
to claim ownership of the spec, and I hope the acknowledgements make it 
clear who the original authors were.  If it's not clear, let me know so I
can fix it.

Peter.

---

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 8 Dec 2017 08:13:04 -0500

Sent from my mobile device

> On Dec 7, 2017, at 4:32 PM, Peter Gutmann <[email-masked]> wrote:
> 

More importantly, do they still like this approach or do they want their names added back?

Kathleen

---

From: Peter Gutmann <[email-masked]>
Date: Sat, 9 Dec 2017 02:23:13 +0000

>More importantly, do they still like this approach or do they want their

They were pretty clear about it at the time... I felt somewhat uncomfortable
about it because I didn't want to appear to be claiming ownership, I'd be
happy to re-add a name or names if the authors want.  Or Alan Smithee :-).

Peter.

---

From: Dan Harkins <[email-masked]>
Date: Sat, 9 Dec 2017 00:31:30 -0800

You mention the "extremely wide" use of SCEP after you suggest that it
needs standards track status. If people have been able to implement it after
all these years what's the compelling case to get an RFC as a stable
reference? To avoid apologetic reference? Not too compelling!

   Given its limitations, I question why anyone would want to implement SCEP
when a superior alternative, EST (RFC 7030), exists. I understand Apple
implemented SCEP for it's MDM solution. Not having any insight into Apple's
decision making I can only surmise why they would implement an inferior
certificate enrollment protocol, and that surmising is that the reason was
not technical.

   SCEP deserves historic status because at the time it was proposed (a 
historic
moment back in the late 20th century) it was the best protocol to solve the
problem, and now it's not. Standards Track would enable SCEP to be 
referenced
by future Standards Track protocols and that would be really bad. All 
references
to IETF standards for certificate enrollment protocols going forward 
should be
to EST (RFC 7030).

   Dan.

---

From: Carl Wallace <[email-masked]>
Date: Sat, 09 Dec 2017 08:04:16 -0500

Inline...

>reference? To avoid apologetic reference? Not too compelling!

[CW] It's not just to avoid an "apologetic reference", though it's
certainly easier to reference RFCXXXX than to remember "nourse" and "23".
There are some algorithm updates in the new draft as well.
>certificate enrollment protocol, and that surmising is that the reason was

[CW] As Peter noted, Apple is not the only legacy SCEP to consider. There
are other OS APIs that provide SCEP support but not EST and some CA
products that support SCEP but not EST.
>to IETF standards for certificate enrollment protocols going forward

[CW] It's doubtful that the the ACME folks would agree 7030 is the right
reference for certificate enrollment and in some environments the best way
to reference 7030 would be via 7894. There are a variety of certificate
management protocols in use now, including some in still being developed.
Marking SCEP as historic would not clarify the landscape in the least, nor
serve to focus implementation/usage on 7030.
>>months,
>>should

---

From: "Henry B (Hank) Hotz, CISSP" <[email-masked]>
Date: Sat, 9 Dec 2017 07:35:28 -0800

+1

> On Dec 7, 2017, at 7:14 AM, Paul Hoffman <[email-masked]> wrote:
> 
> +1 to standards track. This is not a shining moment of glory for the IETF, but we need to be honest about its status.
> 
> --Paul Hoffman
> 

Personal email.  [email-masked]

---

From: Dan Harkins <[email-masked]>
Date: Sat, 9 Dec 2017 09:12:05 -0800

> serve to focus implementation/usage on 7030.

   At the mic in an ACME session I asked why they were rolling their own and
the answer was that EST did not support verification. Which is true but not
really a valid answer because after rolling their own they still had to add
verification to it so they could've just used EST and added their 
verification
as an extension. Then I was told that they were rolling their own 
because they
didn't like ASN.1. Isn't the PKCS#10 you send ASN.1, I asked? Well, we can't
get rid of it entirely.... But since both of those bad and non-technical 
answers
would've applied to SCEP as well this is really not a reason to go Standards
Track with SCEP.

   Dan.

---

From: Carl Wallace <[email-masked]>
Date: Sat, 09 Dec 2017 12:24:11 -0500

>would've applied to SCEP as well this is really not a reason to go

[CW] I agree this is not a reason for SCEP to go Standards track. The
large deployed base is the primary reason. My point was that EST is not
and will not be the lone way forward and thus has no bearing on SCEP's
status.

---

From: "Dr. Pala" <[email-masked]>
Date: Sun, 10 Dec 2017 12:23:39 -0500

Hi all,

I just want to add to the conversation that the discussion around the 
status of SCEP in the PKIX WG brought the group to decide that it should 
not be a standard track but historical. At that time, the argument of 
not duplicating protocols made sense since the selected way forward for 
certificate management was CMC.

Please also understand that SCEP was a one-vendor submitted protocol 
(CISCO) that was not submitted for discussion when the WG was working on 
the topic and that was presented at a later time when not much 
discussion around it was even possible because of the existing deployment.

This said, one main argument that should still be considered very 
carefully today, IMHO, is to avoid the duplication of functionalities 
across standards. Although today it seems that duplication of 
functionalities/protocols is not a concern (ACME is a very fitting 
example where the push for a "sponsored" solution overthrown the 
argument for having multiple standards that basically do the same 
thing), I would argue that avoiding it is still a valuable principle 
because of the following points:

  * *Having multiple standards that basically provide the same
    functionalities hurt interoperability*. In particular, for
    developers who might have to interact with different ecosystem, they
    will be required to write more code and have more complex
    implementation for apparently no good reasons. Having different
    standards for different ecosystem invalidates the concept of having
    standards in the first place as everybody will be doing things in
    their own different way.

  * *Having multiple standards require more effort when new
    functionalities need to be added and/or fixed*. Duplicate work is
    required to advance the status of different documents and fix
    possible issues that can be found at a later time. The work might be
    spread across different WGs and requires more coordination that does
    not come easily at IETF.

Personally, I was under the impression that EST was the selected way 
forward in this case (as Max Pritikin said) and that SCEP would be 
archived as historic - I am a bit surprised to see this topic being 
resumed again. Going back and forth with decisions that were already 
taken seems to foster confusion.*

If the above consideration still holds (EST as the way forward), then IF 
there is no real NEW substantial technical work that will be 
added/discussed to the current version of SCEP, the right choice here 
would be, IMO, to go for historic. *Even in that case, I would say that 
new efforts should be put toward EST and not SCEP.

Whatever the decision of the AD / WG is regarding this topic (i.e., 
historic vs. standard track), I would suggest that the points listed 
above should be properly and explicitly addressed in the decision.

Just my 2 cents,

Cheers,
Max

-- 
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
OpenCA Logo

---

From: Michael Richardson <[email-masked]>
Date: Sun, 10 Dec 2017 14:28:56 -0500

I think that SCEP should be passed into RFC status.
I think that Dan's arguments about marking it Historic are valid.

I believe that the IESG can mark any document as Historic; so it might be
that the appropriate process is to make it Draft Standard and then Historic
if publishing a Historic document seems too daft.

Given that SCEP it out there and in active use, I think that having it on
rfc-editor.org and able to receive errata is the rationalization for doing
this.

I don't think we should spend too much effort on the document though.

(Though the same arguments might apply to IKEv1 XAUTH!)

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: "Salz, Rich" <[email-masked]>
Date: Sun, 10 Dec 2017 20:34:58 +0000

Agree.

---

From: Peter Gutmann <[email-masked]>
Date: Mon, 11 Dec 2017 00:15:33 +0000

Dan Harkins <[email-masked]> writes:

Just a background note for those who aren't aware of this, Dan is one of the
co-authors of EST / RFC 7030, thus presumably the repeated mention of that
specific RFC while completely omitting to mention the various other protocols
like CMP and CMC that do the same thing.  I don't have an issue with that,
"everyone should be using my pet protocol" is a perfectly good motivation :-),
but I just wanted to put the comments in perspective.

However, to avoid turning this into a "my protocol is better than your
protocol" argument, lets set EST aside and use another protocol that does the
same thing, CMP, principally because AFAIK the authors aren't on this list so
it's not a personal issue for anyone.  Dan's comments are identical whether
you say "EST" or "CMP" or "CMC" or "Xenroll" or "ACME" or whatever that XML
mechanism for requesting certs is called, if it even has a name.

So:

>when a superior alternative, CMP, exists.

You're mistaking "more complex" for "superior".  Like the traditional Unix
utility, SCEP was designed to do one thing, provision a device with a
certificate, and do it well.  To the credit of its authors, it does a really
good job at this.  Nearly twenty years later, apart from the archaic use of
MD5 and single DES, the same thing that was originally published is what's in
the current draft.  You can take any PKCS #7 library (although now it's called
CMS) and roll a SCEP implementation in a couple of hours (it's just signed
encrypted PKCS #7). My implementation, in its basic interoperable form, is a
few pages of code, and from memory it worked the first time I ran it against a
server.

CMP, in contrast, is an absolute mess, containing every feature that everyone
on the standards committee could think of, in some cases several times over in
different locations.  The implementation requires a quarter of a megabyte of
code.  Interoperability out of the box is pretty much impossible, there are so
many features and options and poorly-explained mechanisms that the only way we
could get two implementations to talk to each other was by finding out who
wrote the other implementation and asking them what they were doing for each
option in the spec.

(For more on this, see
https://www.usenix.org/legacy/events/sec03/tech/full_papers/gutmann/gutmann_html/index.html,
specifically "5.2 Problems with CMP", and that's the abbreviated version).

Finally, for its use in SCADA, a CMP implementation is so big and bloated and
requires so much manual configuration for all the options that it's a complete
a non-starter for embedded use.  SCEP, which only does the one thing that most
vendors care about in this case, "get a certificate onto this box", is a fire-
and-forget solution.

And this is why both CMC and CMP have failed in the real world (CMC is used by
Microsoft because it's their protocol, CMP is used by some telcos for phone
network provisioning, typically by making sure they have the same
implementation running as both client and server so they can actually talk to
each other), while SCEP has seen large amounts of use throughout the industry.
SCEP is simple, effective, and gets the job done.

>I understand Apple implemented SCEP for it's MDM solution. Not having any
>insight into Apple's decision making I can only surmise why they would
>implement an inferior certificate enrollment protocol, and that surmising is
>that the reason was not technical.

Unfortunately there's no secret conspiracy behind it, the reason is purely
technical (or at least very pragmatic).  If you just want to provision a
device with certificates in the most straightforward manner possible, SCEP is
hard to beat.  It's simple to implement, easy to interop with, gets the job
done, and is supported out of the box by the (at the time, and probably still
the case) standard corporate/business server.

>SCEP deserves historic status because at the time it was proposed (a historic
>problem, and now it's not. 

The industry seems to view this very differently, given the broad deployment
of SCEP and the failure to launch of any of its alternatives.  If CMP really
was superior (in the sense of giving users what they want), we wouldn't be
having this discussion.

Peter.

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 11 Dec 2017 00:27:12 +0000

CMP co-author here...

On 11/12/17 00:15, Peter Gutmann wrote:
> lets set EST aside and use another protocol that does the
> it's not a personal issue for anyone

I don't think there's anything much personal here, for
me at least - I've gotten over the mistakes a bunch of
us (incl. me) made 20+ years ago for then-understandable
and now-boring reasons. More usefully, I hope I've also
learned from  those mistakes;-)

Separately, as it happens I don't think a supposed beauty
contest between ACME/CMC/CMP/EST/SCEP will be of any benefit
for anyone. Go right ahead if that's what floats your various
boats I guess, but fwiw that seems pointless to me.

S.

---

From: Peter Gutmann <[email-masked]>
Date: Mon, 11 Dec 2017 00:28:19 +0000

Dr. Pala <[email-masked]> writes:

Dr. Pala <[email-masked]> writes:

>Whatever the decision of the AD / WG is regarding this topic (i.e., historic
>vs. standard track), I would suggest that the points listed above should be
>properly and explicitly addressed in the decision.

If we were to seriously address them then we'd need to make CMC and CMP, which
have failed in the marketplace, Historic, and SCEP, which has succeeded,
Standards-track.  Then there's ACME, whose principal selling point seems to be
that it's what you use to talk to Let's Encrypt, and EST, which is mostly
Cisco's pet standard [0], neither of which look like they're gaining much
traction outside of those areas.  So you've got two Standards-tracks to
Historic, two where the jury is still out but given the history of CMC and CMP
I'm not holding out much hope, and SCEP to Standards-track.

Somehow I can't see that happening :-).

Peter.

[0] Apologies to Cisco folks, I know you guys are really keen on this but it's
    hard to work up much enthusiasm for yet another standard that does pretty
    much the same thing as CMC and CMP have already done.

---

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Mon, 11 Dec 2017 03:32:32 +0000

+1 on SCEP becoming an RFC, +1 on it being historic. 
It definitely should have been Standards Track at the time, but that does not mean it still needs to. 

The nourse-scep-23 used to say "fully support algorithm agility but the requester has to use a key type that is supported by the server.  RSA is the only algorithm supported by current implementations." I don't see that in draft-gutmann-scep-07, but I don't know of many SCEP implementations that support ECC today either. I also don't know how many implementations today distinguish between authentication and authorization with just the Challenge password. 

Regardless, indeed SCEP will exist for a very long time, and should be a historic RFC.

-----Original Message-----
From: saag [mailto:[email-masked]] On Behalf Of Dan Harkins
Sent: Saturday, December 09, 2017 3:32 AM
To: [email-masked]
Subject: Re: [saag] Status of the SCEP RFC draft

   You mention the "extremely wide" use of SCEP after you suggest that it needs standards track status. If people have been able to implement it after all these years what's the compelling case to get an RFC as a stable reference? To avoid apologetic reference? Not too compelling!

   Given its limitations, I question why anyone would want to implement SCEP when a superior alternative, EST (RFC 7030), exists. I understand Apple implemented SCEP for it's MDM solution. Not having any insight into Apple's decision making I can only surmise why they would implement an inferior certificate enrollment protocol, and that surmising is that the reason was not technical.

   SCEP deserves historic status because at the time it was proposed (a historic moment back in the late 20th century) it was the best protocol to solve the problem, and now it's not. Standards Track would enable SCEP to be referenced by future Standards Track protocols and that would be really bad. All references to IETF standards for certificate enrollment protocols going forward should be to EST (RFC 7030).

   Dan.

On 12/6/17 7:48 PM, Peter Gutmann wrote:
> After 18 years in the draft stage, this is finally ready for 
> publication. The one sticking point is its status, which I think 
> should be Standards Track but others think should be Historic.
>
> The problem with Historic is two-fold, firstly RFC 2026 defines 
> historic as "A specification that has been superseded by a more recent 
> specification or is for any other reason considered to be obsolete is assigned to the "Historic"
> level", which is in both cases the exact opposite of what SCEP is, 
> it's not superseded and it's in wider and more active use than the 
> referenced in numerous other industry standards (usually with an 
> apologetic note about having to refer to a draft :-).  For example 
> Apple's OTA profile configuration and delivery protocol only supports 
> SCEP, and it seems to be the standard MDM mechanism in enterprise 
> environments.  Microsoft has supported it as standard since Server 
> 2003 via NDES and that's then used to provision mobile devices, as 
> well as routers, firewalls, ... not to mention its use in SCADA, ICS, 
> embedded, etc.  There are (at least) a billion+ devices running SCEP 
> today.  Like C, it'll probably be around forever because so much infrastructure depends on it.
>
> months, and more expected over time since it's pretty much the only 
> protocol there is for automated cert provisioning of devices, or at 
> least the only one that's widely deployed and that works.
>
> So both from the RFC 2026 and the pragmatic point of view, I think 
> this should be published as standards-track.  It's definitely not 
> Historic in either sense.
>
> Peter.

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 11 Dec 2017 00:07:09 -0500

> On Dec 10, 2017, at 10:32 PM, Panos Kampanakis (pkampana) <[email-masked]> wrote:
> 
> Regardless, indeed SCEP will exist for a very long time, and should be a historic RFC

IMHO it makes little sense to mark something "historic", if, as Peter
says, it is not only currently practiced, but one of the most widely
practiced protocols in this space, and this is not about to change it
seems.  If the quantum crypto apocalypse is to be upon us as soon as
some speculate it might be, SCEP might be a dominant protocol right
up until both RSA and ECC are made obsolete.

-- 
	Viktor.

---

From: Dan Harkins <[email-masked]>
Date: Sun, 10 Dec 2017 23:31:45 -0800

> but I just wanted to put the comments in perspective.

   Damn. Busted. The jig is up. I blame google.

   But if we want to impugn the motives of people, then what do we say 
about
someone who removes the authors of a protocol (who indicated 
Informational or
Historic on *their document*, I might add), indicates himself as the new 
"author"
(not editor), and then declares that *his* protocol deserves Standards 
Track.
I don't have an issue with "I want to have more Standard Track RFCs with my
name on it", it's a perfectly good motivation :-), but I just wanted to put
the comments in perspective. (To quote you, including the smiley face).

> i

   Well since you outed me on EST let me tell you that I was in the group at
Cisco 20 years ago that came up with SCEP. This was a few years before 
-00 of
SCEP. I can't claim credit, it was more some of my co-workers (Xiaoyi, 
principally)
that should be credited (likewise I can't really take credit for EST as 
my co-editors
deserve much more credit). But we did it then not as a generic MDM 
protocol but to
get a certificate for a router on a network that trusted more than the 
Internet. And
it worked well enough for that use case. And it worked with with all we 
knew at the
time, which was RSA. SCEP does not work with ECC. That's a significant 
drawback. Also,
EST has a way for the policy preferences of the CA/RA to be expressed to 
the client
before the PKCS#10 is generated. This can be used to say, for instance, 
"the RSA public
key in your CSR MUST be 4096 bits" or "the curve you use when generating 
your public
key MUST be NIST's p384 curve", something not possible with SCEP. EST 
really is a
better protocol and it has nothing to do with "mine" versus "yours".

   How long did it take for you to implement EST? I'm sure it was less 
than SCEP.
The "basic implementation" should be very short, /simpleEnroll is really 
simple
after all.

   Dan.

---

From: Russ Housley <[email-masked]>
Date: Mon, 11 Dec 2017 11:58:04 -0500

I think that SCEP should be published as historic or informational RFC.  I think that standards track is inappropriate because the IETF was never given an opportunity to review and improve the specification.

If the document does get published as an RFC, we should encourage the original authors to put their names on it.

Russ

---

From: "Paul Hoffman" <[email-masked]>
Date: Mon, 11 Dec 2017 09:05:18 -0800

We don't get to decide what "informational" or "historic" means for the 
RFC series: those are defined by a standard, RFC 2026.

4.2.2  Informational

    An "Informational" specification is published for the general
    information of the Internet community, and does not represent an
    Internet community consensus or recommendation.  The Informational
    designation is intended to provide for the timely publication of a
    very broad range of responsible informational documents from many
    sources, subject only to editorial considerations and to 
verification
    that there has been adequate coordination with the standards process
    (see section 4.2.3).

    Specifications that have been prepared outside of the Internet
    community and are not incorporated into the Internet Standards
    Process by any of the provisions of section 10 may be published as
    Informational RFCs, with the permission of the owner and the
    concurrence of the RFC Editor.

. . .

4.2.4  Historic

    A specification that has been superseded by a more recent
    specification or is for any other reason considered to be obsolete 
is
    assigned to the "Historic" level.  (Purists have suggested that the
    word should be "Historical"; however, at this point the use of
    "Historic" is historical.)

    Note: Standards track specifications normally must not depend on
    other standards track specifications which are at a lower maturity
    level or on non standards track specifications other than referenced
    specifications from other standards bodies.  (See Section 7.)

--Paul Hoffman

---

From: "Dr. Pala" <[email-masked]>
Date: Mon, 11 Dec 2017 11:46:20 -0700

Hi Peter, all,

I think that in this brief response is the real point here: what do we 
want to plan for the future ? Since it seems we have many different 
solutions, is anybody interested in addressing the interoperability 
issues across ecosystems (isn't it the point of having standards in the 
first place?) ? Maybe a discussion about the possibility of having a 
common standard that could replace what we have today and that can be 
used across ecosystem might be appropriate at this point... ?

I personally think that CMP might have "failed" (there are, IMHO, large 
deployments that use it, so it is not just vaporware...) just because of 
its face complexity (i.e., many options) and maybe the lack of open 
source implementation (I am not sure about this point - does anybody 
have references to OS implementation of CMC / CMP ?). Would it be time 
to analyze what went wrong in those RFCs and maybe update them to 
reflect the options that make sense today (i.e., CMC/CMP v2).

Just my 2 cents...

Cheers,
Max

-- 
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
OpenCA Logo

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 11 Dec 2017 19:51:48 +0000

We have documented many other protocols because it was worth having them as RFC’s.  Simon Josefsson has almost made a “cottage industry” out of it.

But I didn’t know that the IETF didn’t have a chance to work on SCEP.

I am in favor of an informational RFC.

---

From: Jon Callas <[email-masked]>
Date: Mon, 11 Dec 2017 13:04:23 -0800

I want to comment on an aspect of the conversation that is not about SCEP per se, but the larger issue of what standards are and do. There's been discussion about what's a better standard, or what people should be doing as far as this standard or that one. That's the place where I want to make the comment.

I believe that the purpose of a standard, and thus a standards body is to promote interoperability. I came to this belief as part of participation in the IETF, and it is an opinion that I got from senior people in the IETF over the years.

This opinion is analogous to a descriptivist view of what dictionaries do. I think it's an apt analogy; a standard tells you how to interpret a message as well as how to construct a message for others to interpret. That's really what the protocol is.

It might very well be that there are other protocols that do similar things, and it might even be true that the other protocols are better. Even if it is true, it's also irrelevant in many cases. 

I think that if there's a community of interest for a protocol, then a standards body ought to support that standard. My reason is simple — if that body doesn't support it, then some other body will, or worse the protocol will be documented in some other way. In either event, I think this hurts the reputation of the standards body. If the standards body doesn't support the standard, they'll receive criticism that they're "not in touch with reality" or "political" or both, or other slurs. In many, most, or perhaps all of these cases, that criticism is even well-founded. Not supporting a protocol that has a community of interest is pretty much "not in touch with reality" even if it's a small community and thus a small reality. And not supporting one because there's a "better" one is precisely being political; it's a prescriptivist view of what I think should be a descriptivist task.

In language, while I'm a descriptivist when it comes to dictionaries, I firmly believe in style guides and stronger documents. I think that dictionaries should describe, and that description can (should?) (SHOULD?) also describe a controversy.

If there's a competing protocol that is better, then that conversation should happen outside the standard. I'm happy to hear why I should use protocol FOO over protocol BAR, but if I need to implement BAR then any discussion of FOO is at best informational. If I need to talk to some service that speaks BAR, it might be better if it spoke FOO, but it doesn't.

Similarly, a protocol being historic is something of an editorial decision, and I think that if there's any sort of controversy, then it's not really historic. If the answer to, "Do you think that BAR ought to be declared historic?" is "what's protocol BAR again?" then the answer is probably yes, it can be made historic. If it's actively being used in any sort of community of interest, then it's not. Even (or especially) if it hasn't been changed, it's not historic if people are using it.

To sum up and apply my observations, yes, I think SCEP ought to be standards-track, and not historic.

	Jon

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 11 Dec 2017 22:32:05 +0000

>     To sum up and apply my observations, yes, I think SCEP ought to be standards-track, and not historic.
   
But if Russ is correct, then Informational – documenting something done outside of the IETF – is more accurate.  Do you disagree?

---

From: Sean Turner <[email-masked]>
Date: Mon, 11 Dec 2017 20:50:48 -0500

As somebody who thought they’d brokering a deal to get SCEP published something like 7 years ago, I’m glad we’re finally here/there.  

1. Historic vs Informational vs Standard track

Back when the deal got brokered to get it published the deal was for informational, but it switched somewhere along the way to historic.  I think historic was based on the fact that the specification was considered to be obsolete because of all the *other* IETF standards track enrollment protocols available (so many flowers blooming!).  The thing though is that the specification, at least, has had quite a number of changes since then [0]. We were able to control ourselves and not make changes to SSL3 so it could go as historic [1], but not so much with this specification.  I can see that some folks might think the Historic designation might be crazy, but I could live with it or informational.

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

2. Change control

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?

And, I gotta chuckle that the top hit @ Cisco for SCEP points to a draft-nourse [2] ;)

3. Pre-5378 bolier plate

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

spt

[0] https://www.ietf.org/rfcdiff?url1=draft-nourse-scep-23&url2=draft-gutmann-scep-07
[1] https://datatracker.ietf.org/doc/rfc6101/
[2] https://www.cisco.com/c/en/us/support/docs/security-vpn/public-key-infrastructure-pki/116167-technote-scep-00.html?dtid=osscdc000283

> On Dec 11, 2017, at 17:32, Salz, Rich <[email-masked]> wrote:
>

---

From: Peter Gutmann <[email-masked]>
Date: Tue, 12 Dec 2017 02:48:46 +0000

[Subject changed to more accurately reflect the discussion]

Dr. Pala <[email-masked]> writes:

>its face complexity (i.e., many options) and maybe the lack of open source 
>implementation (I am not sure about this point - does anybody have 
>references to OS implementation of CMC / CMP ?). Would it be time to 
>analyze what went wrong in those RFCs and maybe update them to reflect the 
>options that make sense today (i.e., CMC/CMP v2).

Somehow I don't think that'll work.  The problem with the more complex/
heavyweight protocols is that they were designed to be all things to all 
people, when in most cases the marketplace just wanted a way to get a 
certificate onto a device.  So the question "can we redesign X to make it 
easier to work with" assumes that people want X in the first place 
(consider the equivalent "can we redesign X.400 to make it easier to work 
with?").  If all you want to do is get a cert onto a device, SCEP is hard to 
beat.  Sure, everyone can think of things to tack onto it and come up with 
missing bells and whistles, but you can't really strip anything out without 
breaking the security guarantees, and if you add more bits to it you could 
just be adding unwanted bloat.

There is an open-source CMP implementation, and has been for years.  The 
typical experience with it (and this is a paraphrasing of a number of 
conversations) goes something like this:

User: We're using SCEP.
Me: Why not switch to CMP, it's a one-line code change?
User: Why would we want to switch to CMP?
Me: (Sales pitch for all the things CMP does).
User: Yeah... on further consideration we've decided to stay with SCEP, but 
      thanks for the offer.

If your goal is to provision a device with a certificate, you can't get any
simpler than:

  sign( encrypt( gimme a cert ) )

which is exactly what SCEP is.  I'm not saying it's the perfect protocol, 
but it's the simplest, most straightforward way to implement "gimme a cert" 
(particularly when compared to CMC, CMP, ACME, EST, and XML).  It's also the 
one that's easiest to deploy, when I was doing my implementation the 
deployment consisted of "can you open a port to the Windows server" (which 
has a full-featured GUI interface to a SCEP CA server with everything you 
need) [0].  If you want to play with a client, there's JSCEP.

With the others, I wouldn't even know where to start.  EST has a reference
implementation (concidentally by Dan Harkins, see the earlier exchange) that 
was last touched four years ago and has a single contributor, zero pull 
requests, zero comments, and a single commit after the initial one 
(https://github.com/danharkins/est), and for CMC and CMP there's nothing 
(interop'ing against my own code doesn't really count) [1].  So even if you 
really wanted to deploy protocol X, there's not much to go with, or if there 
is it's reasonably well hidden.

To wind up this rather rambly post, it's not a question of deciding which 
protocol to fix and what needs fixing, it's figuring out what users want and 
what the most efficient way is to get it to them.  Whether by accident or by
design, SCEP seems to have managed that, presumably because it was designed
bottom-up, "here's a problem, how do we solve it", rather than top-down,
"let's put everything we can think of into a protocol and see if users want 
it".

Peter.

[0] This is a slight fib, the first server I talked to was a PLC monitor 
    running a SCEP server, but the first server that'd be recognisable as 
    such would be Windows Server.
[1] There are a few bits of abandonware that need to be linked to ten-year-
    old copies of libfoo around, but I'm not counting those.

---

From: Peter Gutmann <[email-masked]>
Date: Tue, 12 Dec 2017 03:14:14 +0000

[Most people will probably just want to skip to the last paragraph].

Dan Harkins <[email-masked]> writes:

>But if we want to impugn the motives of people, then what do we say about
>someone who removes the authors of a protocol 

As I've already explained previously, I removed the names of the authors from
the masthead at their request.  If you look at the -00 draft it has all the 
original names.  As it progressed, the various people involved contacted me 
and requested that, for various reasons, their names be removed.  They're all 
still listed in the acknowledgements.

Just to repeat this a third time in case it's still not clear:

  I removed the names of the original authors from the masthead AT THE 
  EXPLICIT WRITTEN REQUEST OF THE PEOPLE INVOLVED.

I'd have preferred to keep them there, but they gave valid reasons for
not having their names listed, and I honoured those requests.
  
>indicates himself as the new "author" (not editor), 

Are we reading the same document?  The one I've just got from the IETF says:

   The editor would like to thank all of the previous editors, authors
   and contributors: Cheryl Madson, Xiaoyi Liu, David McGrew, David
   Cooper, Andy Nourse, Max Pritikin, Jan Vilhuber, and others for their
   work maintaining the draft over the years.  Numerous other people
   have contributed during the long life cycle of the draft and all
   deserve thanks.  

>and then declares that *his* protocol deserves Standards Track.

I'm not sure how "Status of the SCEP RFC draft" (look up a bit at subject 
line of this email) has become "my protocol".

That's zero for three so far.  What else?

>How long did it take for you to implement EST? I'm sure it was less than 
>SCEP.

Uhh, are we talking about the same thing here?  SCEP is a PKCS #10 inside
a PKCS #7.  EST takes all the complexity of CMC, which is already vastly
more complex than SCEP, then adds more complexity of its own (why?  CMC
already has more than enough stuff in it), and finally throws in HTTP and 
TLS as well for no reason I can understand since CMC already has its own 
security mechanisms.  So you're expecting that 

  SCEP > CMC + EST extras + HTTP + TLS?

While this has been fun ("you do walk into these things, don't you 
Baldrick?"), I really, really don't want to continue such a pointless debate 
(given the number of incorrect claims in the message I'm replying to, I felt 
I had to respond at least to that).

As Paul Hoffman has pointed out, RFC 2026 probably makes it Informational.  
I'd prefer Standards-track because it causes less problems with downrefs 
from other industry standards, but I can live with Informational if that's 
what the docs say it should be.

Peter.

---

From: Peter Gutmann <[email-masked]>
Date: Tue, 12 Dec 2017 03:43:07 +0000

Sean Turner <[email-masked]> 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.

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

---

From: Jon Callas <[email-masked]>
Date: Mon, 11 Dec 2017 23:49:39 -0800

> On Dec 11, 2017, at 2:32 PM, Salz, Rich <[email-masked]> wrote:
> 

Well, many protocols developed outside of the IETF are on Standards Track. 

I tend to think of informational RFCs as being — something not quite real. On the other hand, as noted, SCEP as a protocol is pretty much done. If the IETF isn't going to be doing any work on it, then maybe informational is the proper thing.

	Jon

---

From: Sean Turner <[email-masked]>
Date: Tue, 12 Dec 2017 08:26:53 -0500

> On Dec 11, 2017, at 22:43, Peter Gutmann <[email-masked]> wrote:
> 

This is excellent news!

> if that's what the rules say.

Yeah I’m coming around to Informational.

> want to speak out publicly, feel free).

Since, this has been going on for so long - I suspect that if there was an issue they’d speak up; they’re not shy ;)

> dings you for the use of outdated boilerplate.

It ought to be easy, mind you I avoid xml2rfc like the plague.  But, I think in your xml you just need to make the following change to make the boilerplate appear:

OLD:

<rfc category="std" ipr="trust200902" docName="draft-gutmann-scep-07">

NEW:

<rfc category="std" ipr="pre5378Trust200902" docName="draft-gutmann-scep-07”>

Based on:
https://tools.ietf.org/tools/templates/mib-doc-template-xml.txt

spt

---

From: Ted Lemon <[email-masked]>
Date: Tue, 12 Dec 2017 09:36:52 -0500

> I tend to think of informational RFCs as being — something not quite real. On the other hand, as noted, SCEP as a protocol is pretty much done. If the IETF isn't going to be doing any work on it, t…

The rule historically, at least for the history when I was on the IESG, which isn't all that historical, is that if the IETF is going to change the protocol, then it's a standard, but if we want to publish what is deployed, for whatever reason (usually as a baseline for further work, but I think this use case also qualifies), we publish it as informational.   Not because it's not a standard, but because it's not a standard the IETF developed.

---

From: Carl Wallace <[email-masked]>
Date: Tue, 12 Dec 2017 09:50:57 -0500

From:  saag <[email-masked]> on behalf of Ted Lemon
<[email-masked]>
Date:  Tuesday, December 12, 2017 at 9:36 AM
To:  Jon Callas <[email-masked]>
Cc:  "[email-masked]" <[email-masked]>
Subject:  Re: [saag] Status of the SCEP RFC draft

>> I tend to think of informational RFCs as being — something not quite real. On
>> the other hand, as noted, SCEP as a protocol is pretty much done. If the IETF
>> isn't going to be doing any work on it, then maybe informational is the
>> proper thing.
> 
> The rule historically, at least for the history when I was on the IESG, which
> isn't all that historical, is that if the IETF is going to change the
> protocol, then it's a standard, but if we want to publish what is deployed,
> for whatever reason (usually as a baseline for further work, but I think this
> use case also qualifies), we publish it as informational.   Not because it's
> not a standard, but because it's not a standard the IETF developed.
> 
> [CW] While Informational seems like a better fit than Historic, the "not IETF
> developed" notion seems odd for a draft with over 30 IETF Internet Draft
> revisions with some significant differences between low version numbers and
> later versions (I.e., addition of GetCACaps, at a minimum). Even the draft
> that is the subject of this thread is introducing some changes to the spec
> within the IETF context (i.e., adding new algorithms and deprecating old).
>

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 13 Dec 2017 03:39:11 +0000

Sean Turner <[email-masked]> writes:

>I think in your xml you just need to make the following change to make the
>boilerplate appear:
>
>OLD:
>

Ah, that's easy enough, thanks.  I'll make that change and also reclassify it
as Informational, so category="info".

One question, to anyone in general, the draft currently has:

  Sample SCEP Messages

  (Omitted from the drafts to keep the size down).

What are people's thoughts on including samples like this?  I'd definitely
like to do it because, as the text says, it "gives implementers something to
aim for", but it's also going to blow the document size out enormously.  When
the S/MIME samples were created they were put in a separate, 135-page RFC,
presumably to avoid doing the same to the base S/MIME / CMS RFCs.  For SCEP,
because of the sign( encrypt( request ) ) form for requests and responses and
the presence of certs and attributes, the pretty-printed form will run to
40-50 pages at least.

What's the thinking on including sample messages?  In base64-encoded form?  As
broken-down pretty-printed structures?  Link to some web site somewhere?

Peter.

---

From: Jim Schaad <[email-masked]>
Date: Tue, 12 Dec 2017 20:06:11 -0800

> Sent: Tuesday, December 12, 2017 7:39 PM
> To: Sean Turner <[email-masked]>
> Cc: [email-masked]
> >I think in your xml you just need to make the following change to make
> >the boilerplate appear:
> >
> >OLD:
> >
> ><rfc category="std" ipr="pre5378Trust200902"
> >docName="draft-gutmann-scep-07">
> 
> Ah, that's easy enough, thanks.  I'll make that change and also reclassify
it as
> Informational, so category="info".
> 
like to
> do it because, as the text says, it "gives implementers something to aim
for",
> but it's also going to blow the document size out enormously.  When the
> S/MIME samples were created they were put in a separate, 135-page RFC,
> presumably to avoid doing the same to the base S/MIME / CMS RFCs.  For
> SCEP, because of the sign( encrypt( request ) ) form for requests and
responses
> and the presence of certs and attributes, the pretty-printed form will run
to
> 40-50 pages at least.
> 
> What's the thinking on including sample messages?  In base64-encoded form?
> As broken-down pretty-printed structures?  Link to some web site
somewhere?

My view would be a couple of very simple examples to show major concepts in
the document.  Base64 is better for me because I can run it through my code
and see what happens, this also implies needing any keys used as well.  If
you want to do a more complete set of examples (and I would encourage you),
then a pointer to a web site someplace would be my preference.

Jim

---

From: Sean Turner <[email-masked]>
Date: Wed, 13 Dec 2017 12:05:20 -0500

> On Dec 12, 2017, at 23:06, Jim Schaad <[email-masked]> wrote:
> 
> the document.

+1

spt