[prev in list] [next in list] [prev in thread] [next in thread] 

List:       cfrg
Subject:    Re: [Cfrg] Fwd: [saag] possible BCP on public review being needed for standards-track crypto
From:       Stephen Farrell <stephen.farrell () cs ! tcd ! ie>
Date:       2016-03-23 20:17:57
Message-ID: 56F2F9F5.8040404 () cs ! tcd ! ie
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


Folks, please use saag@ietf.org for discussion of this
topic, not cfrg.

S

On 23/03/16 19:30, Phillip Hallam-Baker wrote:
> On Wed, Mar 23, 2016 at 2:38 PM, Yoav Nir <ynir.ietf@gmail.com> wrote:
> > 
> > > On 23 Mar 2016, at 7:23 PM, Phillip Hallam-Baker <phill@hallambaker.com> wrote:
> > > 
> > > On Wed, Mar 23, 2016 at 10:06 AM, Stephen Farrell
> > > <stephen.farrell@cs.tcd.ie> wrote:
> > > > 
> > > > FYI. Please send comments to saag@ietf.org.
> > > > 
> > > > If you just want to say "+1" that's as useful here I guess,
> > > > but if you think this is a bad idea, please explain why on
> > > > the saag list, and of course any detailed comments should
> > > > go to the saag list.
> > > > 
> > > 
> > > I think it a good idea to insist that any crypto that the IETF is
> > > apparently endorsing have been subject to public review.
> > > 
> > > I also believe that it should be possible to use arbitrary crypto with
> > > IETF protocols.
> > > 
> > > Using IANA assigned code points means it is not possible to satisfy
> > > both at once.
> > 
> > I don't think that it is impossible.  Suppose you have a registry for encryption \
> > algorithms such as the IKEv2 one ([1]), where identifiers are 16-bit. Currently \
> > it is partitioned so that 0-1023 are for assignment by the IETF (we're up to 28), \
> > while 1024-65536 is for private use.  It should be fairly easy to alter the \
> > partition so that 0-1023 is for the IETF with expert review (like it is today), \
> > 1024-2047 specification required (no implication about quality), 2048-4095 FCFS \
> > (no implication that you can even implement it), and the rest left for private \
> > use (like today).  That way the higher ranges are only used to avoid two private \
> > experiments colliding. 
> > The downside is what is happening right now with ChaCha20 and TLS. Someone starts \
> > using a value either by squatting or by the easy procedure. After that, if the \
> > IETF decides to "bless" it, a new identifier would hurt interop with a deployed \
> > base. So you end up with a recommended algorithm in the range we reserved for \
> > crypto that amateurs invent. 
> 
> That is why I suggest OIDs. Anyone can cut one. I have an arc. You can
> have one too.
> 
> If I am writing a general purpose library, I almost certainly need to
> cut an OID to support CMS, PKIX and the like. So supporting use of the
> IETF code point or the OID, isn't actually much of an overhead if
> anything.
> 
> Right now I have crypto libraries wrapping crypto libraries three deep
> because folk can't write decent, consistent APIs and because I need to
> support four different IETF naming and numbering schemes.
> 


["smime.p7s" (application/pkcs7-signature)]

_______________________________________________
Cfrg mailing list
Cfrg@irtf.org
https://www.irtf.org/mailman/listinfo/cfrg


[prev in list] [next in list] [prev in thread] [next in thread]