Subject: [Cfrg] Fwd: [saag] pkcs#1 -> IETF change control

From: Stephen Farrell <[email-masked]>
Date: Fri, 5 Aug 2016 18:09:53 +0100

FYI, folks here may be interested in also checking this.
Please respond to [email-masked] and not here though:-)

Ta,
S.

-------- Forwarded Message --------
Subject: [saag] pkcs#1 -> IETF change control
Date: Fri, 5 Aug 2016 18:07:21 +0100
From: Stephen Farrell <[email-masked]>
To: [email-masked] <[email-masked]>

Folks,

I've just asked to start IETF last call for drafts that
document pkcs#5 [1] and pkcs#1. [2] The main purpose
of these drafts is to hand change control to the IETF,
as we've recently done with other pkcs series documents.
(That's a good thing, and thanks to those who've made
the not-inconsiderable effort to make it happen.)

For pkcs#5 I think there are only nits to consider but
I do have a question to ask wrt the pkcs#1 draft. [2]

Please send responses here or in response to the last
call on [email-masked], which should pop out shortly.

If you look at the diff [3] between this draft and RFC
2437, there are substantial differences, including to
some data structures, the older versions of which may be
in widespread use, e.g., RSAPrivateKey is extended in a
way that I think could lead to interop issues in [2].

So my question is: what's the right way to handle getting
pkcs#1 under IETF change control without breaking anything?

Should we for example, not formally OBSOLETE RFC2347 perhaps,
or should we ask to add some statement to [2] that explains
that even though this is newer, it's the older version that's
widely implemented.

Bear in mind that we are in any case trying to move entirely
away from pkcs#1v1.5 so this shouldn't be too much of an issue
for future RFCs, which are likely to just use pkcs#1v.5 as-is
(if that's needed due to legacy h/w) or to use something else
entirely, e.g. based on the cfrg curves.

So, that's a bit long winded, but please take a look, in
particular at [2] and [3] and say what you think we should
be doing here.

Thanks,
S.

PS: Please note that it's taken the folks doing this
work quite a bit of effort, e.g. dealing with their
legal folks to get permission to move change control to
the IETF, so we should really try to avoid imposing
more work (and delay) on those folks if we can. IOW,
minimal change here is really good, and if the IETF
wants to and has the energy, we can modify whatever we
like after this transition has happened.

[1] https://datatracker.ietf.org/doc/draft-moriarty-pkcs5-v2dot1/
[2] https://datatracker.ietf.org/doc/draft-moriarty-pkcs1/
[3]
https://tools.ietf.org/rfcdiff?url1=rfc2437&url2=draft-moriarty-pkcs1-01.txt