Subject: [smime] New Version Notification for draft-josefsson-pkix-textual-06.txt

From: Sean Leonard <[email-masked]>
Date: Mon, 15 Sep 2014 22:17:26 -0700

Greetings S/MIME, PKIX, and SAAG lists:

A revised draft of the PKIX/PKCS/CMS text encodings has been published. 
There are "medium changes", including the addition of the PUBLIC KEY 
label (corresponding to SubjectPublicKeyInfo). It's worth a look.

It is pretty close to done, but look forward to reactions and comments.

Kind regards,

Sean Leonard

-------- Forwarded Message --------
Subject: 	New Version Notification for draft-josefsson-pkix-textual-06.txt
Date: 	Mon, 15 Sep 2014 21:54:19 -0700
From: 	[email-masked]

A new version of I-D, draft-josefsson-pkix-textual-06.txt
has been successfully submitted by Sean Leonard and posted to the
IETF repository.

Name:        draft-josefsson-pkix-textual
Revision:    06
Title:        Text Encodings of PKIX and CMS Structures
Document date:    2014-09-15
Group:        Individual Submission
Pages:        18
URL: http://www.ietf.org/internet-drafts/draft-josefsson-pkix-textual-06.txt
Status: https://datatracker.ietf.org/doc/draft-josefsson-pkix-textual/
Htmlized: http://tools.ietf.org/html/draft-josefsson-pkix-textual-06
Diff: http://www.ietf.org/rfcdiff?url2=draft-josefsson-pkix-textual-06

Abstract:
    This document describes and discusses the text encodings of the
    Public-Key Infrastructure X.509 (PKIX), Public-Key Cryptography
    Standards (PKCS), and Cryptographic Message Syntax (CMS), The text
    encodings are well-known, are implemented by several applications and
    libraries, and are widely deployed.  This document is intended to
    articulate the de-facto rules that existing implementations operate
    by, and to give recommendations that will promote interoperability
    going forward.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Tony Rutkowski <[email-masked]>
Date: Wed, 17 Sep 2014 13:05:10 -0400

For those interested in what is occurring over the
next few days in Geneva related to these subjects
in the all but extinct ITU-T group, the relevant
documents are pulled together here.  The "challenges"
material tends to be used to justify new work in
the group.  It's worth being aware of.  An operative
question is whether anyone cares.

Approval 	Certified Mail Transport and Certified Post Office Protocol 
TD 1259
Approval 	Current and new challenges for public key infrastructure 
standardization within ITU-T 	TD 1179
NWI 	Proposal for including whitelist support in Rec. ITU-T X.509 | 
ISO/IEC 9594-8 	C 268
NWI 	Proposal for new ITU-T | ISO/IEC JTC 1 joint work item for OID 
based device identifier for the Internet of Things 	C 239
NWI 	Proposal for including relevant cryptographic algorithm information 
into Annex B of Rec. ITU-T X.509 | ISO/IEC 9594-8. 	C 230
NWI 	Proposal for additional restructuring and updates of Rec. ITU-T 
X.509 | ISO/IEC 9594-8 	C 269

--tony

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 17 Sep 2014 19:56:14 +0100

Thanks Tony,

I've a question.

To sample this, I opened one of the files in the attachment
(TD1275) which seems to both reproduce a lot of CMS RFC text
and to extend that without (I guess?) having asked anyone who
implements CMS. If that is the case, that'd seem really dumb.
I don't recall any relevant liaison nor have I heard of such
work being wanted.

My question is: am I being unfair in the above or are the
authors of that actually in touch with folks who implement
CMS?

Other folks - if you care about ITU-T work that could overlap
with IETF work or with your code, you might want to take a
look here. (Or decide to just ignore the whole thing as
irrelevant enough to be harmless I guess.)

Cheers,
S.

On 17/09/14 18:05, Tony Rutkowski wrote:
> NWI     Proposal for including relevant cryptographic algorithm
> information into Annex B of Rec. ITU-T X.509 | ISO/IEC 9594-8.     C 230
> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix
>

---

From: Tony Rutkowski <[email-masked]>
Date: Wed, 17 Sep 2014 17:11:56 -0400

Hi Stephen,

You are being fair.

The responsible Rapporteur Group (Q11/17) consists
of essentially two people - who also serve as the rapporteur
and associate rapporteur, and editors of nearly all the work.
They propose and approve their own work items, then
evolve them.  There is an eMail list, but it is little used.

The basis for the CMS work item is attached and the
record of the approval is found in the report which
they prepared and approved in Sept 2013.
>
> oCryptographic Message Syntax (CMS): The purpose of this new work item 
> is to provide some enhancements to the existing CMS protocol and to 
> eliminate old ASN.1 features. The justification document can be found 
> in TD 0644. Cryptographic Message Syntax is used in many applications 
> so the meeting decided to send a liaison (TD 646) to ISO/IEC/JTC 1/SC 
> 27, ISO/TC 68/SC 2 and IETF/SMIME Working Group.
>
Liaison notes were sent to the indicated organizations twice now. Only
SC 27 replied stating:
> ISO/IEC JTC 1/SC 27/WG 2 also thanks ITU-T SG 17 for informing SC 
> 27/WG 2 of a new work item regarding Cryptographic Message Syntax 
> (CMS). SC 27/WG 2 would like to inform ITU-T SG 17 that SC 27/WG 2 has 
> established a Study Period on Cryptographic formatting to investigate 
> pre-existing formats, including CMS.
In Jan 2014, Q11/17 reviewed and approved its first
draft, noting:
> The first draft of X.cms has been reviewed during the meeting. The 
> revised draft can be found in TD 940 Rev.1. This Recommendation should 
> be part of the X.890 series (Generic applications of ASN.1) and the 
> meeting proposes to have a common text with ISO/IEC JTC 1/SC 6 (new 
> part of ISO/IEC 24824 standard) using the fast track procedure of 
> ISO/IEC JTC 1 after Consent 

It's not apparent who the editor here is in touch with
or not, but it's worth noting that there is a SG27 effort
of some kind underway as well.  It is what it is, and as
you note, the question revolves around whether it's
irrelevant enough to be harmless.

--tony

---

From: Sean Turner <[email-masked]>
Date: Mon, 22 Sep 2014 00:09:00 -0400

I’m not entirely sure they’re related but there was this:
https://datatracker.ietf.org/liaison/1283/
and then this:
https://datatracker.ietf.org/liaison/1294/

It looks to me like they’re updating the ASN.1 to a later version and adding a new content type.  Note we’ve already updated the ASN.1 to a later version.  And, you don’t need to update the base spec to add a new content type - we’ve done it a LOT.

spt

On Sep 17, 2014, at 14:56, Stephen Farrell <[email-masked]> wrote:

> smime mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/smime

---

From: Kathleen Moriarty <[email-masked]>
Date: Mon, 22 Sep 2014 12:49:26 -0400

Sorry for my delay in response, I was in Geneva at the ITU-T for the first
part of last week (to present on IETF security on a multi-SDO panel), then
on vacation.  I have a fair bit of experience with the ITU-T, so here is my
take on it as well as some possible next steps.

> I don't recall any relevant liaison nor have I heard of such

Here is my take (from experience) and we may need some help early this week
to identify possible issues.

1. We may want to take a look through all of the materials to see where
text is from an RFC (where we have copyright) as a first step.

There is a push within the ITU-T from several nations to only have the
ITU-T reference other SDO's materials and ensure that work is not
duplicated in multiple SDOs.  It should be easy enough to get support to
have text removed and replaced with a reference to any of the IETF RFCs.
The ITU-T leadership stated an interest in better cooperation between SDOs,
so hopefully this will be easier to address than in the past.

2. *IF* there is a standard that the IETF manages that has proposed changes
within these ITU-T documents, we should identify them and understand the
implications of such changes happening elsewhere.  If there are issues
along these lines, then we have a few options, on is that we can work with
heads of delegation (nations) prior to the ITU-T plenary for SG 17 at the
end of this week.   Essentially, we'll have to work to get the changes into
the IETF instead (this is simply stated, there is process behind all of
this that I am familiar with fortunately/unfortunately)).

3. If the ITU-T decides to update something they manage, it's good to know
that is happening and is within their right.  The IETF could decide to use
it if the work makes sense and update any of our standards for which we
wish to use the new version (X.509 for instance) or continue to reference
the current version if the changes don't make sense.

Do we have some volunteers to comb through the materials?

Thanks,
Kathleen

-- 

Best regards,
Kathleen

---

From: Tony Rutkowski <[email-masked]>
Date: Thu, 25 Sep 2014 09:31:06 -0400

PKIX and IETF/CABF groups - as part of their
collaborative roles - may be interested
in the proposed amendment document
just published.

-t

---

From: Tony Rutkowski <[email-masked]>
Date: Thu, 25 Sep 2014 17:24:24 -0400

The WG2 community might be interested
in the proposed amendment document
just adopted and published at the SG17
meeting this week.

This is primarily an initiative of the
editor.

-t