Subject: [KEYPROV] IANA URI registry proposal

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 16 Apr 2008 10:41:22 -0700

I am still working on this one but I wanted to show what I have to date, please see attached.
 
Note that this is sent to both the KEYPROV working group and CC'd to the W3C XML SEC Working group which has an interest in this.
 
The basic idea here is that we establish an IANA registry for canonical cryptographic identifiers represented as URIs. (we can argue later as to whether to extend this to OIDs). The identifiers entered need not be URNs, need not even be in IETF space. The only semantics attached to being specified in the registry is that registered identifiers should be considered canonical by implementations of specifications that state that the registry is the canonical source.
 
If the registrant wishes IANA to assign an identifier it will be a URN in the IANA space which is what IANA registers.

This document is 9 pages long as a standalone RFC and I have not yet dealt with the security considerations. This only includes declarations for the four algorithms directly affected by KEYPROV that do not yet have an assigned identifier.
 
The risk of separating this part out is that we then end up having to create and check an exhaustive compendium of algorithms. I would prefer to avoid that. We might end up taking the initial values section and putting that into the PSKC draft if we end up separating.

What you will note is absent from this proposal is any proposal to leverage the registry to distribute semantic statements describing the algorithms such as documentation, test vectors, revocation details, etc, etc. I am aware of this temptation. At the moment it is a rat hole. While I have in fact sent a dog down that particular rat-hole, I don't want either working group to follow. I want to establish the registry, not start a research project.
_______________________________________________
KEYPROV mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/keyprov

---

From: "Philip Hoyer" <[email-masked]>
Date: Fri, 18 Apr 2008 13:02:28 +0200

Phillip,

So for the next revision that I would love to submit today do you want
me to add this to the IANA section that Hannes added?

What do we do about Section 6.3 then, do we leave it for now and refer
to your section here or?

Philip

________________________________

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Hallam-Baker, Phillip
Sent: Wednesday, April 16, 2008 6:41 PM
To: [email-masked]
Cc: [email-masked]; Tim Polk
Subject: [KEYPROV] IANA URI registry proposal

I am still working on this one but I wanted to show what I have to date,
please see attached.

Note that this is sent to both the KEYPROV working group and CC'd to the
W3C XML SEC Working group which has an interest in this.

The basic idea here is that we establish an IANA registry for canonical
cryptographic identifiers represented as URIs. (we can argue later as to
whether to extend this to OIDs). The identifiers entered need not be
URNs, need not even be in IETF space. The only semantics attached to
being specified in the registry is that registered identifiers should be
considered canonical by implementations of specifications that state
that the registry is the canonical source.

If the registrant wishes IANA to assign an identifier it will be a URN
in the IANA space which is what IANA registers.

This document is 9 pages long as a standalone RFC and I have not yet
dealt with the security considerations. This only includes declarations
for the four algorithms directly affected by KEYPROV that do not yet
have an assigned identifier.

The risk of separating this part out is that we then end up having to
create and check an exhaustive compendium of algorithms. I would prefer
to avoid that. We might end up taking the initial values section and
putting that into the PSKC draft if we end up separating.

What you will note is absent from this proposal is any proposal to
leverage the registry to distribute semantic statements describing the
algorithms such as documentation, test vectors, revocation details, etc,
etc. I am aware of this temptation. At the moment it is a rat hole.
While I have in fact sent a dog down that particular rat-hole, I don't
want either working group to follow. I want to establish the registry,
not start a research project.

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 18 Apr 2008 06:09:07 -0700

I think that for this draft lets cut and paste the section, I turned it
into a full draft so I could verify it with RFC2XML, so it should just
work.
 
Lets leave 6.3 as is for now.
 
Hannes provided text for a KeyProv parameters registry, do we want an
additional standalone registry for shared XML parameter ID tags in
addition?

	From: Philip Hoyer [mailto:[email-masked]] 
	Sent: Friday, April 18, 2008 7:02 AM
	To: Hallam-Baker, Phillip; Hannes Tschofenig; Pei, Mingliang
	Cc: [email-masked]
	Subject: RE: [KEYPROV] IANA URI registry proposal

	Phillip,

	So for the next revision that I would love to submit today do
you want me to add this to the IANA section that Hannes added?

	What do we do about Section 6.3 then, do we leave it for now and
refer to your section here or?

	Philip

	From: [email-masked] [mailto:[email-masked]]
On Behalf Of Hallam-Baker, Phillip
	Sent: Wednesday, April 16, 2008 6:41 PM
	To: [email-masked]
	Cc: [email-masked]; Tim Polk
	Subject: [KEYPROV] IANA URI registry proposal

	I am still working on this one but I wanted to show what I have
to date, please see attached.

	Note that this is sent to both the KEYPROV working group and
CC'd to the W3C XML SEC Working group which has an interest in this.

	The basic idea here is that we establish an IANA registry for
canonical cryptographic identifiers represented as URIs. (we can argue
later as to whether to extend this to OIDs). The identifiers entered
need not be URNs, need not even be in IETF space. The only semantics
attached to being specified in the registry is that registered
identifiers should be considered canonical by implementations of
specifications that state that the registry is the canonical source.

	If the registrant wishes IANA to assign an identifier it will be
a URN in the IANA space which is what IANA registers.

	This document is 9 pages long as a standalone RFC and I have not
yet dealt with the security considerations. This only includes
declarations for the four algorithms directly affected by KEYPROV that
do not yet have an assigned identifier.

	The risk of separating this part out is that we then end up
having to create and check an exhaustive compendium of algorithms. I
would prefer to avoid that. We might end up taking the initial values
section and putting that into the PSKC draft if we end up separating.

	What you will note is absent from this proposal is any proposal
to leverage the registry to distribute semantic statements describing
the algorithms such as documentation, test vectors, revocation details,
etc, etc. I am aware of this temptation. At the moment it is a rat hole.
While I have in fact sent a dog down that particular rat-hole, I don't
want either working group to follow. I want to establish the registry,
not start a research project.

---

From: "Philip Hoyer" <[email-masked]>
Date: Fri, 18 Apr 2008 16:15:15 +0200

That  would be great,

I just pasted your registry into the IANA section so if you could knock
up a quick one for the XML parameter ID tags that would be great.

Thanks a lot for your help,

Philip

From: Hallam-Baker, Phillip [mailto:[email-masked]] 
Sent: Friday, April 18, 2008 2:09 PM
To: Philip Hoyer; Hannes Tschofenig; Pei, Mingliang
Cc: [email-masked]
Subject: RE: [KEYPROV] IANA URI registry proposal

	 

	Phillip,

	Philip