[saag] META Re: PKIX and related RFCs - definition of Key Packages

[Phillip Hallam-Baker <[e-mail]>]

I agree with much of Uri's frustration here. My concern is the meta level.
If LAMPS is going to ever close, we have to make sure we are not going to
need something similar in future. Which means that we need to define what
is required to specify a cryptographic algorithm so it is available for use
with IETF protocols.

Note that adding an algorithm to a registry does not mean it is approved
for use by a particular protocol.

CMS serves a much wider audience than S/MIME. PKIX, a wider audience than
either the WebPKI or PKI in general. Same for JOSE, XML Signature and
Encryption, etc. etc.

So I conclude that one of the exit criteria for LAMPS should be a
document describing the list of things that need to be specified so that an
algorithm can be used in various specific IETF protocols and conversely,
what applications using the IETF maintained IANA registries can expect.


I do not want to get into discussions of why the decisions of some
working group ten years ago on algorithm requirements should bind some
other group doing something different today. HTTP is not based on MIME but
it uses the same IANA registry. That is the correct approach in my view.

Going forward, I see no reason why it should be necessary to specify
separate identifiers for the use of a particular algorithm in every
different application protocol. The ASN.1 world is going to need OIDs for
quite some time and the JOSE world is going to be needing text based
labels. The XML world consumes URIs but there is no reason we couldn't
specify a URN prefix to the JOSE labels and use that to avoid further
maintenance issues.

TLS and IPSEC both operate at a layer that is sufficiently deep that we
should just let them do their own thing. And PEM probably isn't much of a
concern going forward.