[CESG] CESG-P-2024-08-004 Approval to publish CCSDS 357.1-O-1, Intergovernmental Certification Authority (Orange Book, Issue 1)

Wed Nov 20 18:29:51 UTC 2024

Dear CESG Members,

Conditions for approval of CCSDS 357.1-O-1, Intergovernmental Certification Authority (Orange Book, Issue 1) have been disposed to the satisfaction of the AD(s) who voted to approve with conditions. The Secretariat will now proceed with CMC polling to authorize publication.
-------------- next part --------------
From:	Ignacio Aguilar Sanchez <Ignacio.Aguilar.Sanchez at esa.int>
Sent:	Wednesday, November 20, 2024 3:50 AM
To:	Howard.Weiss at parsons.us; Shames, Peter M (US 312B); Sheehe, 
Charles J. (GRC-LCN0); Thomas Gannett
Cc:	Tomaso.deCola at dlr.de
Subject:	RE: [EXTERNAL] IGCA CESG Approval

Categories:	Poll Condition Closure

Sure, Howie.

Kind regards,

Ignacio

Ignacio Aguilar Sánchez 
Communication Systems Engineer 
Electrical Engineering Department 

European Space Research and Technology Centre 
Keplerlaan 1, PO Box 299, 2200 AG Noordwijk, The Netherlands
Mob.+31641360257 
Fax  +31715655418 
Email: ignacio.aguilar.sanchez at esa.int 
www.esa.int

From: Howard.Weiss at parsons.us <Howard.Weiss at parsons.us>  
Sent: 19 November 2024 21:50 
To: Ignacio Aguilar Sanchez <Ignacio.Aguilar.Sanchez at esa.int>; Shames, Peter M (US 312B) 
<peter.m.shames at jpl.nasa.gov>; Sheehe, Charles J. (GRC-LCN0) <charles.j.sheehe at nasa.gov>; Thomas 
Gannett <thomas.gannett at tgannett.net> 
Cc: Tomaso.deCola at dlr.de 
Subject: Re: [EXTERNAL] IGCA CESG Approval

Ignacio

Sorry - missed a reply.  We accept your PID.  Will you lift your conditions for publication of the 
IGCA document?

regards

howie

From: Ignacio Aguilar Sanchez <Ignacio.Aguilar.Sanchez at esa.int> 
Sent: Thursday, September 12, 2024 3:09 AM 
To: Shames, Peter M (US 312B) <peter.m.shames at jpl.nasa.gov>; Sheehe, Charles J. (GRC-LCN0) 
<charles.j.sheehe at nasa.gov>; Thomas Gannett <thomas.gannett at tgannett.net>; Weiss, Howard [US-
US] <Howard.Weiss at parsons.us> 
Cc: Tomaso.deCola at dlr.de <Tomaso.deCola at dlr.de> 
Subject: RE: [EXTERNAL] IGCA CESG Approval 

Dear all,

I just need to know now how you want to disposition my PID. 

Cheers,

Ignacio

Ignacio Aguilar Sánchez 
Communication Systems Engineer 
Electrical Engineering Department 

European Space Research and Technology Centre 
Keplerlaan 1, PO Box 299, 2200 AG Noordwijk, The Netherlands
Mob.+31641360257 
Fax  +31715655418 
Email: ignacio.aguilar.sanchez at esa.int 
www.esa.int [esa.int]

From: Shames, Peter M (US 312B) <peter.m.shames at jpl.nasa.gov>  
Sent: Wednesday, September 11, 2024 11:10 PM 
To: Sheehe, Charles J. (GRC-LCN0) <charles.j.sheehe at nasa.gov>; Thomas Gannett 
<thomas.gannett at tgannett.net>; Howard.Weiss at parsons.us 
Cc: Tomaso.deCola at dlr.de; Ignacio Aguilar Sanchez <Ignacio.Aguilar.Sanchez at esa.int> 
Subject: Re: [EXTERNAL] IGCA CESG Approval

Thanks Chuck.

Let’s see what response we get from Ignacio and Tomaso.  We won’t move ahead with these changes to 
the document until we know that they concur.

Thanks, Peter

From: Sheehe, Charles J. (GRC-LCN0) <charles.j.sheehe at nasa.gov> 
Date: Wednesday, September 11, 2024 at 1:00?PM 
To: Shames, Peter M (US 312B) <peter.m.shames at jpl.nasa.gov>, Thomas Gannett 
<thomas.gannett at tgannett.net>, Howard.Weiss at parsons.us <Howard.Weiss at parsons.us> 
Cc: Tomaso.deCola at dlr.de <Tomaso.deCola at dlr.de>, Ignacio Sanchez-Aguillar 
<Ignacio.Aguilar.Sanchez at esa.int> 
Subject: RE: [EXTERNAL] IGCA CESG Approval
Hi
I am ok with and understand the comments.
I do agree that it is in a weird spot and needs to be built, in order to solidify processes, documentation 
and requirements. 
I sent to Howie and Tom what I understood needed to be done from the e-mail chain. Tom sent back an 
e-mail that he will maintain control and make the proper changes.

Aside: 
I think I am maybe missing something about the X509, that is in a different document I think, and would 
require an update to that document.

I will do what you all think best on this effort.

Thanks
Chuck

Charles J. Sheehe III
Computer Engineer
Secure Networks, System 
Integration and Test Branch (LCN)
Glenn Research Center
21000 Brookpark Rd
Cleveland, OH 44135
Charles.J.Sheehe at NASA.GOV  Email
Charles.J.Sheehe at NSS.SGov.Gov  SIPRmail
Charles.Sheehe at NASA.IC.Gov 
Office: 216-433-5179

There are two ways to design a system. One is to make it so simple there are obviously no deficiencies.
The other is to make it so complex there are no obvious deficiencies.
                                                                                                                                     -  C. A. R. Hoare

From: Shames, Peter M (US 312B) <peter.m.shames at jpl.nasa.gov>  
Sent: Wednesday, September 11, 2024 2:56 PM 
To: Sheehe, Charles J. (GRC-LCN0) <charles.j.sheehe at nasa.gov>; Thomas Gannett 
<thomas.gannett at tgannett.net>; Howard.Weiss at parsons.us 
Cc: Tomaso.deCola at dlr.de; Ignacio Sanchez-Aguillar <Ignacio.Aguilar.Sanchez at esa.int> 
Subject: Re: [EXTERNAL] IGCA CESG Approval

CAUTION: This email originated from outside of NASA.  Please take care when clicking links or opening 
attachments.  Use the "Report Message" button to report suspicious messages to the NASA SOC. 

Hi Chuck,

I just reviewed the draft OB again, in the light of the feedback from the CESG review and this email trail.

I agree with Howie, and Ignacio, that we should review, and update as appropriate, the X.509 currency.

I also agree with Ignacio that this is a somewhat unusual CCSDS document.  And I will note that it’s 
nature it is very close to a couple of the existing MOIMS DAI WG MB documents, such as:

CCSDS 650.0-M-2 
[urldefense.us]
Reference Model for an Open Archival Information System (OAIS)

And the related …

CCSDS 652.0-M-1 
[urldefense.us]
Audit and Certification of Trustworthy Digital Repositories

CCSDS 652.1-M-2 
[urldefense.us]
Requirements for Bodies Providing Audit and Certification of Candidate 
Trustworthy Digital Repositories

In much the same way that the IGCA is an overview architecture, process, and high level requirements 
driven document, the OAIS is similarly constructed.  The initial OAIS document was found to be 
valuable by the digital archive community because it provided a useful set of concepts and a conceptual 
architecture, as well as identifying the use of some specific standards for certain data exchanges.  The 
MOIMS DAI WG has elaborated upon this over time and then added these audit and certification 
documents.  

To reach closure on Tomaso’s concerns, I will note that as a “Magenta Book-style” Orange Book it does 
not require either a prototype or a PICS.  Here too, the existing MOIMS OAIS MB document series 
provides examples of what has been accepted in a similar context.   I have argued separately (copied 
below) that the CCSDS “Bible” identifies that Orange Books should be formulated as “Normative Track” 
documents without explicitly excluding Magenta Books, which are also Normative Track.  

In my opinion this IGCA concept might well follow a similar path to the OAIS, starting with this Orange 
Book.  I think we all agree that this is not yet at the level of maturity expected of a Blue Book, nor even, 
as yet, of a Magenta Book.  But I believe that it is a valuable concept and, once these technical concerns 
have been dealt with, worthy of publication as an Orange Book so as to permit further exploration and 
evaluation.  

I would, in addition, recommend that development of a prototype should be one of the next investments, 
and that consideration be given to the development of a separate “Audit and Certification” document as 
well as firming up the existing IGCA architecture itself, as a result of the prototyping effort.

Best regards, Peter

From: Sheehe, Charles J. (GRC-LCN0) <charles.j.sheehe at nasa.gov> 
Date: Wednesday, September 11, 2024 at 7:13?AM 
To: Shames, Peter M (US 312B) <peter.m.shames at jpl.nasa.gov>, Thomas Gannett 
<thomas.gannett at tgannett.net>, Howard.Weiss at parsons.us <Howard.Weiss at parsons.us> 
Subject: RE: [EXTERNAL] IGCA CESG Approval
Thanks Peter

Just getting back.

I am fine with dropping the PICs 
The latest rev to 9  will review to ensure no impact. 

I will go through the requirements section and indicate how they will be verified. 
May I put verification in the document in that section?

Thanks
Chuck

Charles J. Sheehe III
Computer Engineer
Secure Networks, System 
Integration and Test Branch (LCN)
Glenn Research Center
21000 Brookpark Rd
Cleveland, OH 44135
Charles.J.Sheehe at NASA.GOV  Email
Charles.J.Sheehe at NSS.SGov.Gov  SIPRmail
Charles.Sheehe at NASA.IC.Gov 
Office: 216-433-5179

There are two ways to design a system. One is to make it so simple there are obviously no deficiencies.
The other is to make it so complex there are no obvious deficiencies.
                                                                                                                                     -  C. A. R. Hoare

From: Shames, Peter M (US 312B) <peter.m.shames at jpl.nasa.gov>  
Sent: Monday, September 9, 2024 2:44 PM 
To: Thomas Gannett <thomas.gannett at tgannett.net>; Howard.Weiss at parsons.us 
Cc: Sheehe, Charles J. (GRC-LCN0) <charles.j.sheehe at nasa.gov> 
Subject: Re: [EXTERNAL] IGCA CESG Approval

Hi Guys,

As Tom anticipated, I do have “something to add” vis-à-vis the Magenta to Orange aspect.

First off, the way this document is written is to have content that is more typical of a Magenta Book, i.e. 
process, architecture, or recommended practice than it is Blue Book, i.e. directly implementable.  I made 
this judgement based on the contents of the document, as I do with all documents I am asked to review.

As a Magenta Book there is really no expectation of it being directly implementable in the way that a 
protocol or data exchange spec would be, so there is no anticipated need for 2 interoperable 
implementations.  It could be argued that this might be treated as a Blue Book of the form “Utilization 
Profile”, see YB Sec B1.1.a.3.  Here too, I do not think this document, in its current form, is sufficiently 
“normative” to meet that test.

Hence the proposal to publish it as an Orange Book.  It does meet that test, as documented in Sec B2.2.

I will further note that Sec B2.2 is a little ambiguous, since it references “the equivalent technical status of 
a Draft Recommended Standard” once, without ever saying “it must be a Blue Book”.  It also references, 
twice, “Experimental work may be rapidly transferred onto the Normative Track”, without further stating 
that it is a Blue Book Normative Track document.  It could equally well be a Magenta Track Normative 
document.

I think that these statements, in Sec B2.2, are really the salient ones:

it is not necessary to demonstrate broad support across the CCSDS community before a WG to 
produce an Experimental Specification is approved; one organization could volunteer to perform 
experimental work independently, provided that the Area Director is convinced that it is a 
positive contribution toward the work of CCSDS and that sufficient resources exist to produce a 
meaningful result. Demonstration of the work being a “positive contribution” is most important; a 
WG will not be allowed to form unless it has demonstrated that the proposed experimental work 
is architecturally relevant to CCSDS and will not be disruptive to the installed base if eventually 
implemented. 

Based on that I continue to support the request to publish this as an Orange Book, to get these concepts 
out and into view, with the expectation that further work will be done to either demonstrate the value, 
either in Magenta (or preferably Blue) form or to abandon the project because it is found wanting.

Best regards, Peter

From: Thomas Gannett <thomas.gannett at tgannett.net> 
Date: Monday, September 9, 2024 at 8:18?AM 
To: Howard.Weiss at parsons.us <Howard.Weiss at parsons.us> 
Cc: 'Sheehe, Charles J. (GRC-LCN0)' <charles.j.sheehe at nasa.gov>, Shames, Peter M (US 
312B) <peter.m.shames at jpl.nasa.gov> 
Subject: RE: [EXTERNAL] IGCA CESG Approval
Howie:

You may regard me as the choir. Procedurally, however, every condition needs to be explicitly resolved 
to the satisfaction of the AD who voted to approve with conditions, and my purpose in sending the 
advance warning yesterday was to give the WG a little extra time to prepare responses. I am CCing 
Peter, since he will have something to add on the Magenta-to-Orange aspect. My position is, it’s not not 
allowed, but there are indeed some Org&Procs requirements that assume all Orange Books are Blue by 
nature.

Tom

Logothete, L.L.C.
thomas.gannett at tgannett.net
+1 443 472 0805

From: Howard.Weiss at parsons.us [mailto:Howard.Weiss at parsons.us]  
Sent: Monday, September 09, 2024 11:08 AM 
To: Thomas Gannett 
Cc: 'Sheehe, Charles J. (GRC-LCN0)'; Howard.Weiss at parsons.us 
Subject: Re: [EXTERNAL] IGCA CESG Approval

Hi Tom,

I am usually sympathetic to Tomaso's MINOR1 issue - I have been beaten up over the years 
regarding poorly worded, compound, or untestable requirements. However, in this case, my 
thought is that, at least for 3.3.3, this would be verifiable by 'observation.'  

Chuck - can you go through the rest of the 'shall' statement to determine how they would be 
verified? 

As for Ignacio's comment regarding the version of X.509, we had an out-of-band email thread on 
that same subject.  I guess we should do some due diligence to ensure that any changes in the 
newer versions of X.509 don't have any appreciable effects on our document.  And if there are 
not effects, we should simply upgrade the reference. 

Regarding  the change from Magenta -> Orange, that was not our own doing and rather was 
instigated by Peter to gain some traction by publishing a document with the hope that if we 
publish, they will come.  The intent was to eliminate the need for 2 independent 
implementations, the need to write an accompanying Green Book (by putting a lot of the non-
normative GB info in section 2), and to get the concept in front of the other member Agencies. 

Thanks,

howie

From: Thomas Gannett <thomas.gannett at tgannett.net> 
Sent: Sunday, September 8, 2024 2:12 PM 
To: Weiss, Howard [US-US] <Howard.Weiss at parsons.us> 
Cc: 'Sheehe, Charles J. (GRC-LCN0)' <charles.j.sheehe at nasa.gov> 
Subject: RE: [EXTERNAL] IGCA CESG Approval 

Howie:

The CESG IGCA poll failed to achieve quorum and has been extended by one week.

In the meantime, of the three votes obtained so far, two are “Approve with Conditions” (see below).

Tomaso’s “MAJOR” condition is essentially a red herring: what he says of the procedures is true, but the 
procedures assume all Orange Books are experimental standards. Since this is an Orange practice, and 
since Magenta Books do not yield the sort of implementations for which the procedural requirement 
was intended, Tomaso will have to be cajoled to withdraw that particular condition (I will contact him 
about it after the extended poll closes).

Concerning his MINOR2 condition, in fact, Magenta Books do not normally include a PICS; I would 
propose deleting it.

Tomaso’s MINOR1 condition and Ignacio’s condition are yours to ponder (Ignacio’s remark 1 also 
wrestles with the unusual circumstance of attempting to make a Magenta Book Orange).

Tom

SEA-AD Peter Shames    APPROVE UNCONDITIONALLY   
                8/22/2024 1:26 PM

SIS-AD  Tomaso de Cola                APPROVE WITH CONDITIONS (state conditions that must be satisfied)
MINOR1: some requirements listed in section 3 sound to me a bit vague and not so easy get 
verified. For instance clause 3.3.3 states that "The IGCA and affiliated CAs shall have reviewed 
and agreed-upon operational 
protection policies.". How can this be verified? Same considerations may hold also for other 
requirements.
MINOR2: If I'm not wrong NPICS (as shown in Annex A) is a requirement for blue books, not 
for orange (though certainly not prohibited).
MAJOR: According to our org&proc yellow book in Annex B2.2, it is stated that "prior to 
publication at least one hardware or software prototype (or other implementation) must exist that 
demonstrates and exercises all of the options and features of the specification in an operationally 
relevant environment, either real 
or simulated. The WG chair shall assure that the specific implementations that qualify the 
specification for CCSDS experimental status are documented in an annex to the 
specification; that documentation shall include clear statements about support for each of the 
individual options and features of the specification". The present version of the book indeed 
includes an annex about a "possible implementation example", but does not describe an existing 
implementation, but provides a scenario in which the proposed concept could be implemented. In 
general, the "concept" of an orange book is that at some point could mature to a blue book, while 
here I've the impression that in some parts the document this is really bluish, but in other is more 
Magenta-style.
SLS-AD          Ignacio Aguilar Sanchez         APPROVE WITH CONDITIONS (state conditions 
that must be satisfied)
Please find attached a PID: Its disposition is my condition for approval of this poll. [attached below]
Furthermore, I would like to share a couple of remarks:
1.	This document is targeting an organisation, not a protocol or data structure or service. The only 
other CCSDS document I could find with a similar target is the CCSDS 313.0-Y-3 SANA Yellow 
Book. Hence, this Orange Book is quite exceptional.
2.	At the core of this Orange Book is the CCSDS 357.0-B-1 Authentication Credentials Blue Book. 
This standard relies on the following ISO standard: 
Information Technology—Open Systems Interconnection—The Directory: Public-Key and Attribute 
Certificate Frameworks. 7th ed. International Standard, ISO/IEC 9594-8:2014. Geneva: ISO, 2014.
Such standard has an equivalent ITU-T standard known as X.509. You can find it here: 
https://www.itu.int/ITU-T/recommendations/rec.aspx?rec=14033&lang=en [itu.int] [urldefense.us]
As part of my involvement on a related ESA Project in support of asymmetric key management for space 
links, we are examining both CCSDS 357.0-B-1 and ITU-T X.509 and noticed that such ISO/ITU-T standard 
has evolved. The change record is visible at the ¨History¨ section at the early pages with corresponding 
weblinks to past versions and corrigenda. 
To my understanding the CCSDS Authentication Credentials Blue Book was referring to edition 7. The 
latest published version is edition 9, with a couple of corrigenda.
Given the importance of the subject and the 5-year review cycle for the CCSDS Authentication 
Credentials Blue Book (published in 2019), I would recommend initiating it, including a detailed 
examination of the X.509 update.
        CESG POLL ITEM DISPOSITION (PID) INITIATION FORM

AREA PID NUMBER: 01
SUBMITTING AREA: Space Link Services
------------------------------------------------------------------
REVIEWER'S NAME: Ignacio AGUILAR SANCHEZ  
E-MAIL ADDRESS:  ignacio.aguilar.sanchez at esa.int  
------------------------------------------------------------------
DOCUMENT NUMBER:   357.1-O-0
DOCUMENT NAME:     Intergovernmental Certification Authority
DATE ISSUED:       August 2024
PAGE NUMBER:       2-2            PARAGRAPH NUMBER:  
PID SHORT TITLE:   Provision of PKI keys to CCSDS protocols
------------------------------------------------------------------
DESCRIPTION OF REQUESTED CHANGE:  (Use From: "..." To "..." format)

From:
¨The IGCA provides trust and PKI keys that can be used to facilitate the 
operation of CCSDS protocols such as Space Data Link Security (SDLS) and 
Delay Tolerant Networking (DTN) Bundle Protocol Security (BPSec) or secured 
service interfaces. ¨

To:
¨The IGCA provides trust and PKI keys that can be used to facilitate the 
operation of CCSDS security protocols or secured service interfaces. ¨

------------------------------------------------------------------
CATEGORY OF REQUESTED CHANGE:
     Technical Fact _X_    Recommended ___    Editorial ___
NOTES:
TECHNICAL FACT:  Major technical change of sufficient magnitude as to
 render the Recommendation inaccurate and unacceptable if not
 corrected.  (Supporting analysis/rationale is essential.)
RECOMMENDED:  Change of a nature that would, if incorporated, produce
 a marked improvement in document quality and acceptance.
EDITORIAL:  Typographical or other factual error needing correction.
 (This type of change will be made without feedback to submitter.)
------------------------------------------------------------------
SUPPORTING ANALYSIS:

The facts are that today CCSDS is working to define asymmetric key management 
for the CCSDS Space Data Link Security as well as publishing the DTN Bundle 
Security Protocol (BPSec). 

Strictly speaking, a provision of PKI keys would not be needed as no one 
could use them. Yet, we at CCSDS are working towards that goal in all fronts. 

The proposed edition of the sentence would avoid such inconsistencies.

------------------------------------------------------------------
DISPOSITION:

From:	Tomaso.deCola at dlr.de
Sent:	Tuesday, November 19, 2024 2:40 PM
To:	thomas.gannett at tgannett.net; Howard.Weiss at parsons.us; 
peter.m.shames at jpl.nasa.gov; Ignacio.Aguilar.Sanchez at esa.int; 
cesg at mailman.ccsds.org
Cc:	charles.j.sheehe at nasa.gov
Subject:	RE: Review / update CCSDS Org & Proc Yellow Book, was Re: 
[EXTERNAL] IGCA CESG Approval

Categories:	Poll Condition Closure

Hi all,

Given the fact that we reached agreement during the last week CESG meeting that the yellow book will 
be updated to better reflect also the magentish nature of orange book, my condition can be closed.

Regards,

Tomaso

From: Thomas Gannett <thomas.gannett at tgannett.net>  
Sent: Tuesday, November 19, 2024 6:30 PM 
To: Howard.Weiss at parsons.us; de Cola, Tomaso <Tomaso.deCola at dlr.de>; 
peter.m.shames at jpl.nasa.gov; Ignacio.Aguilar.Sanchez at esa.int; cesg at mailman.ccsds.org 
Cc: charles.j.sheehe at nasa.gov 
Subject: RE: Review / update CCSDS Org & Proc Yellow Book, was Re: [EXTERNAL] IGCA CESG Approval

Howie: Peter is updating the Yellow Book in preparation for a corrigendum. I require an explicit 
statement from Tomaso indicating his condition is closed. —Tom

Logothete, L.L.C.
thomas.gannett at tgannett.net
+1 443 472 0805

From: Howard.Weiss at parsons.us [mailto:Howard.Weiss at parsons.us]  
Sent: Tuesday, November 19, 2024 12:18 PM 
To: Tomaso.deCola at dlr.de; peter.m.shames at jpl.nasa.gov; thomas.gannett at tgannett.net; 
Ignacio.Aguilar.Sanchez at esa.int; cesg at mailman.ccsds.org 
Cc: charles.j.sheehe at nasa.gov 
Subject: Re: Review / update CCSDS Org & Proc Yellow Book, was Re: [EXTERNAL] IGCA CESG 
Approval

Hi Tomaso,

In the spirit of moving the IGCA document through Secretariat processing, are you OK with it 
based on this email thread? 

Do we need to modify the Procedures YB first?  Or can we progress this document and then 
make the changes to the YB?

regards

howie

From: Tomaso.deCola at dlr.de <Tomaso.deCola at dlr.de> 
Sent: Tuesday, September 17, 2024 12:53 PM 
To: peter.m.shames at jpl.nasa.gov <peter.m.shames at jpl.nasa.gov>; thomas.gannett at tgannett.net 
<thomas.gannett at tgannett.net>; Ignacio.Aguilar.Sanchez at esa.int <Ignacio.Aguilar.Sanchez at esa.int>; 
cesg at mailman.ccsds.org <cesg at mailman.ccsds.org> 
Cc: charles.j.sheehe at nasa.gov <charles.j.sheehe at nasa.gov>; Weiss, Howard [US-US] 
<Howard.Weiss at parsons.us> 
Subject: RE: Review / update CCSDS Org & Proc Yellow Book, was Re: [EXTERNAL] IGCA CESG Approval 

Personally I’d be more in favour of “quickly” reopening the book for fixing this ambiguity on the orange 
book. The points I’ve raised in my previous email in my very humble opinion may indeed cause 
confusion in future CCSDS people about the issue or request to the start orange book projects. In 
particular the corrigendum 2 (CCSDS
A02.1-Y-4 Cor. 2), clearly reports in my opinion about that “Experimental Specification prototypes and 
conformance tests must be documented in an annex”, which I see incompatible with magenta-flavour of 
orange books. Jonathan very correctly observed that the used text starts with “as general rule” hence 
suggesting a “should” requirement, i.e. ‘nice-to-have’. But what follows has a ‘must’ which makes it then 
less clear, i.e. is it a ‘should’ or a ‘must’? This is in my opinion something to be fixed.

I can certainly agree that magenta books have significantly evolved in nature and content since this 
corrigendum, but to memory this is the first case of an orange-magenta book for which this ambiguity 
with respect to the yellow book was spotted. As such, I see the need to make this aspect clear especially 
for the future CESGers, which as very first step will read the yellow book to get used with all procedures.

My 0.02 cents,

Tomaso

From: Shames, Peter M (US 312B) <peter.m.shames at jpl.nasa.gov>  
Sent: Montag, 16. September 2024 23:54 
To: Thomas Gannett <thomas.gannett at tgannett.net>; de Cola, Tomaso <Tomaso.deCola at dlr.de>; 
Ignacio.Aguilar.Sanchez at esa.int; 'CESG' <cesg at mailman.ccsds.org> 
Cc: charles.j.sheehe at nasa.gov; Howard.Weiss at parsons.us 
Subject: Re: Review / update CCSDS Org & Proc Yellow Book, was Re: [EXTERNAL] IGCA CESG Approval

Hi Tom, and CESG Members,

Interesting observation, especially the distinction between “leading requirements” and “requirements 
from actual practices”.   And the observation that leading requirements often require some level of 
interpretation, based on our understanding of the intent behind them.

I would agree that the situation with OBs right now is one of those “what is the intent” questions.  And I 
think that you and I, and likely most of us, have the same interpretation.  If that’s the case I am content to 
leave it alone.   If not, I would prefer to fix this nit so we can avoid the confusion.  

By the way, I am not advocating that we comb through the Org & Proc doc looking for other nits.  We all 
have more important work to do and limited time and resources.  But some things do require attention to 
avoid problems.

I will point out that there were two significant changes to the Org & Proc doc, years ago, that I insisted 
on, because the ambiguities created by their absence were just, to my eyes, too glaring to be 
ignored.  These were to add actual “Architecture Principles”, Annex A1, and to add clear documentation 
of “Consensus” in Sec 5.1.2, Annex G, and elsewhere.  The document used to say, in CESG and AD 
responsibilities in version 2:

Sec 1.5.3.2 AD Responsibilities
j)  ensuring that all Area work follows the set of architectural principles agreed by 
the CESG and is properly synchronized with the smooth evolution of the large 
installed base of CCSDS-compatible mission support infrastructure; 

So there were two mentions of “architectural principles” in that version of the document, but these were 
not written down and were nowhere to be found.  In my opinion this was beyond “leading requirements”, 
because there was no guidance aside from those words.  The same was true of “consensus”, where it was 
possible, and it occurred, that “consensus” was whatever the WG Chair said it was.

I could go on, but I think you all get the point.  These were big gaps, and they really needed to be filled to 
remove these glaring ambiguities in fundamentals of how we work and what we are supposed to be 
doing.  This “can a MB style formatted document be an OB?” is really modest by comparison.

There’s a last observation that I would like to share with all of you.  I believe that a big part of what is 
going on right now is that CCSDS is going through something of a “sea change” in terms of 
leadership.  This period of change is not over, since I have yet to retire (but am on that glide path) and 
other changes will surely follow.  A result of this is that new CCSDS Leaders, Area Directors, WG 
Chairs, and even CESG and CMC leadership have joined the ranks.   But we do not have any formal 
training, we expect On the Job Training (OJT) to work.

However, some of these folk have been elevated quite quickly from working members inside a WG to 
higher positions, without “learning the ropes” at intermediate stages.   The CCSDS Org & Proc was 
designed with the stated expectation that WG Chair candidates (and candidates for higher level positions) 
would have served for a period of time in lower level positions.  See Sec 2.3.2.4.1:

A candidate for selection as CESG chair (or deputy chair) must be an internationally 
recognized technical expert with broad expertise in the standardization aspects of space 
missions and their supporting infrastructure, plus extensive prior experience working 
within the CESG (such as having served as an Area Director or WG chair or having 
served as deputy CESG chair prior to succeeding to chair). 

A candidate for selection as an AD (or deputy AD) must be recognized as leading 
technical expert in the field covered by that Area and must have extensive prior 
experience leading a specific standards development task within the CCSDS, such as 
having served as a WG chair or deputy chair. 

This was intended to ensure that the CCSDS leaders moved up through the different leadership stages and 
thereby gained an understanding of how the organization works and also of what the usual interpretation 
is of the “leading requirements” and even of the “actual practices” were, especially where there were 
aspects that were not carefully documented.  We do not seem to be following these guidelines rigorously 
and it appears that there are consequences.

Here is a last recommendation, from one of the “old guard” to the relative newcomers to CESG (and WG 
Chair) roles.  

*         Read the CCSDS Org and Proc document, CCSDS A02.1-Y-4c, from beginning to end, 
become familiar with your role and the rules we operate by.  You are the leaders of this 
organization, you need to understand this stuff.

Or maybe we need to have a special one hour “CESG Boot Camp” at the next CESG meeting to make 
sure everyone is up to speed with how we are supposed to be operating and what the definitions of all 
these different procedures and document types really means?  I’d certainly support that.

Very best regards, Peter

From: Thomas Gannett <thomas.gannett at tgannett.net> 
Date: Monday, September 16, 2024 at 12:20?PM 
To: Shames, Peter M (US 312B) <peter.m.shames at jpl.nasa.gov>, Tomaso.deCola at dlr.de 
<Tomaso.deCola at dlr.de> 
Cc: Ignacio.Aguilar.Sanchez at esa.int <Ignacio.Aguilar.Sanchez at esa.int>, 'CESG' 
<cesg at mailman.ccsds.org>, charles.j.sheehe at nasa.gov <charles.j.sheehe at nasa.gov>, 
Howard.Weiss at parsons.us <Howard.Weiss at parsons.us> 
Subject: RE: Review / update CCSDS Org & Proc Yellow Book, was Re: [EXTERNAL] IGCA 
CESG Approval
Peter:

I support identification of potential changes to the Org&Procs book for the purpose of clarifying things. I 
do not feel that lack of an explicit statement authorizing publication of Magenta-type content as an 
Orange Book is in any way a prohibition of our doing so, because I do not believe the Org&Procs book 
currently prevents it, and I do not think adding such an explicit statement should be a priority activity. If 
somehow resolution of poll conditions against the IGCA book is now contingent upon updating the 
Org&Procs book, then I think we have failed to accomplish the objective of getting the IGCA book 
published quickly via the Orange Book path.

I will say that the Org&Procs book consists of two types of requirements, 1) leading requirements 
devised prior to their implementation, and 2) requirements documented from actual practices. Leading 
requirements, such as the Orange Book requirements, were devised without empirical knowledge of the 
actual work processes necessary to implement them. Such requirements tend to be vague and subject 
to interpretation, and for the sake of expediency, those of us who actually have to implement such 
requirements have always had to follow them more in spirit than in letter. There are a great many 
leading requirements in the Org&Procs book, and their modern implementation could very well be 
criticized for lack of rigorous adherence to what the book might be interpreted to state. So I think we 
could either enter into a new era of dysfunction, in which we are unable to act except as explicitly 
stated, however vaguely and ambiguously, in the Org&Procs book, or continue on as we always have, 
attempting to accomplish the intent of the requirements.

Tom

Logothete, L.L.C.
thomas.gannett at tgannett.net
+1 443 472 0805

From: Shames, Peter M (US 312B) [mailto:peter.m.shames at jpl.nasa.gov]  
Sent: Monday, September 16, 2024 2:44 PM 
To: Tomaso.deCola at dlr.de; thomas.gannett at tgannett.net 
Cc: Ignacio.Aguilar.Sanchez at esa.int; CESG; charles.j.sheehe at nasa.gov; Howard.Weiss at parsons.us 
Subject: Review / update CCSDS Org & Proc Yellow Book, was Re: [EXTERNAL] IGCA CESG Approval

Dear Tomaso and Tom,

Tom already knows this, but for Tomaso’s and Ignacio’s benefit, it has been the case for years that we 
periodically review the YB to clean up language, and sometimes, to add missing elements.  Sometimes 
these have been major updates, such as adding Architecture Principle, and documenting what a Consensus 
Process really is.  The last time we made any update was the c2 corrigendum, in 2016.  That was a 
relatively minor update relating to processes.  

In my opinion, this topic, of clarifying that an OB, as a Normative-style Document, could encompass both 
a BB and an MB is similarly minor.  I would support making this update.  I think it is small enough that a 
corrigenda item would handle it.  Others might have a different opinion.

At the same time, I would ask the question if there are other corrigenda, or more major items, that should 
be addressed?  I cannot think of any, but perhaps there are some.  

Comments?

Best regards, Peter

From: Tomaso.deCola at dlr.de <Tomaso.deCola at dlr.de> 
Date: Friday, September 13, 2024 at 9:15?AM 
To: thomas.gannett at tgannett.net <thomas.gannett at tgannett.net>, Shames, Peter M (US 312B) 
<peter.m.shames at jpl.nasa.gov>, charles.j.sheehe at nasa.gov <charles.j.sheehe at nasa.gov>, 
Howard.Weiss at parsons.us <Howard.Weiss at parsons.us> 
Cc: Ignacio.Aguilar.Sanchez at esa.int <Ignacio.Aguilar.Sanchez at esa.int> 
Subject: RE: [EXTERNAL] IGCA CESG Approval
Dear Tom,

If so then I’d be in favour of improving the text of the yellow book to avoid any ambiguity. This could be 
an opportunity to check also other sections of the book that may need a refresh (just guessing…).

Regards,

Tomaso

From: Thomas Gannett <thomas.gannett at tgannett.net>  
Sent: Freitag, 13. September 2024 17:45 
To: de Cola, Tomaso <Tomaso.deCola at dlr.de>; peter.m.shames at jpl.nasa.gov; 
charles.j.sheehe at nasa.gov; Howard.Weiss at parsons.us 
Cc: Ignacio.Aguilar.Sanchez at esa.int 
Subject: RE: [EXTERNAL] IGCA CESG Approval

Dear Tomaso:

Our procedures were not bestowed upon us by Providence. We wrote them. There was never any 
intension to exclude Magenta-type specifications  from the experimental path; it simply did not occur to 
anyone at the time to state explicitly that Magenta-type specifications could be preserved as Orange 
Books, which category of book was created to preserve good engineering that lacked multi-agency 
support and thus prevent having to recreate it later. Beyond that, the notion of what a Magenta Book is 
has evolved considerably since the procedures text about Orange Books was written.

So I would say if our procedures document appears to prohibit our doing things in the best interests of 
CCSDS, then our procedures document should be fixed, and in the meantime should not stand as an 
impediment to getting things done.

Best regards,
Tom

Logothete, L.L.C.
thomas.gannett at tgannett.net
+1 443 472 0805

From: Tomaso.deCola at dlr.de [mailto:Tomaso.deCola at dlr.de]  
Sent: Friday, September 13, 2024 4:32 AM 
To: peter.m.shames at jpl.nasa.gov; charles.j.sheehe at nasa.gov; thomas.gannett at tgannett.net; 
Howard.Weiss at parsons.us 
Cc: Ignacio.Aguilar.Sanchez at esa.int 
Subject: RE: [EXTERNAL] IGCA CESG Approval

Hi Peter,

As mentioned in a former exchange in August I think, my concerns are more from a formal viewpoint. It 
was and is still fully clear to me that the content of this book is towards a future magenta book and 
content-wise I’m not against it. However I’m afraid CCSDS A02.1-Y-4 is considering the transition from 
orange to blue only. In more detail the CCSDS A02.1-Y-4 book in Annex B2.2 states that:

Experimental work may be based on soft or “prospective” requirements; i.e., it may be looking into the 
future and may intend to demonstrate technical feasibility in anticipation of a hard requirement that has 
not
yet emerged. This designation therefore allows the work to progress roughly to the equivalent technical 
status of a Draft Recommended Standard without being actually on the Normative Track and therefore 
consuming large amounts of CCSDS resources. Experimental work may be rapidly transferred onto the 
Normative Track if a hard requirement emerges, thus shortening the response time in satisfying the 
new customer.

This clearly points to a draft recommended standard (blue book), while it does not mention the case of a 
draft recommended practice (magenta book). It is certainly true that then finally it is said that can be 
“rapidly transferred onto the normative track”, where in fact a normative track includes both magenta 
and blue books. However Figure 6.1 at the beginning of Section 6 clearly shows a relation between 
orange and blue books, but not with magenta books:

If instead we (CESG) all think that orange books could be for possible future blue or magenta 
books, I’m also fine but we need to update the yellow books to avoid the confusion that lead us 
to this discussion. In this sense, then probably we should also update the statement still in Annex 
B2.2 about the necessary condition to report on the existence of a prototype:

As a general rule, prior to publication at least one hardware or software prototype (or other 
implementation) must exist that demonstrates and exercises all of the options and features of the 
specification in an operationally relevant environment, either real or simulated.

This clearly makes sense in the current orientation of orange books, i.e. towards possible future 
blue books, but probably not for magenta books for which no prototypes are expected to grant 
their approval and consequent publication. 

Regards,

Tomaso

From: Shames, Peter M (US 312B) <peter.m.shames at jpl.nasa.gov>  
Sent: Mittwoch, 11. September 2024 23:10 
To: Sheehe, Charles J. (GRC-LCN0) <charles.j.sheehe at nasa.gov>; Thomas Gannett 
<thomas.gannett at tgannett.net>; Howard.Weiss at parsons.us 
Cc: de Cola, Tomaso <Tomaso.deCola at dlr.de>; Ignacio Sanchez-Aguillar 
<Ignacio.Aguilar.Sanchez at esa.int> 
Subject: Re: [EXTERNAL] IGCA CESG Approval

Thanks Chuck.

Let’s see what response we get from Ignacio and Tomaso.  We won’t move ahead with these changes to 
the document until we know that they concur.

Thanks, Peter

From: Sheehe, Charles J. (GRC-LCN0) <charles.j.sheehe at nasa.gov> 
Date: Wednesday, September 11, 2024 at 1:00?PM 
To: Shames, Peter M (US 312B) <peter.m.shames at jpl.nasa.gov>, Thomas Gannett 
<thomas.gannett at tgannett.net>, Howard.Weiss at parsons.us <Howard.Weiss at parsons.us> 
Cc: Tomaso.deCola at dlr.de <Tomaso.deCola at dlr.de>, Ignacio Sanchez-Aguillar 
<Ignacio.Aguilar.Sanchez at esa.int> 
Subject: RE: [EXTERNAL] IGCA CESG Approval
Hi
I am ok with and understand the comments.
I do agree that it is in a weird spot and needs to be built, in order to solidify processes, documentation 
and requirements. 
I sent to Howie and Tom what I understood needed to be done from the e-mail chain. Tom sent back an 
e-mail that he will maintain control and make the proper changes.

Aside: 
I think I am maybe missing something about the X509, that is in a different document I think, and would 
require an update to that document.

I will do what you all think best on this effort.

Thanks
Chuck

Charles J. Sheehe III
Computer Engineer
Secure Networks, System 
Integration and Test Branch (LCN)
Glenn Research Center
21000 Brookpark Rd
Cleveland, OH 44135
Charles.J.Sheehe at NASA.GOV  Email
Charles.J.Sheehe at NSS.SGov.Gov  SIPRmail
Charles.Sheehe at NASA.IC.Gov 
Office: 216-433-5179

There are two ways to design a system. One is to make it so simple there are obviously no deficiencies.
The other is to make it so complex there are no obvious deficiencies.
                                                                                                                                     -  C. A. R. Hoare

From: Shames, Peter M (US 312B) <peter.m.shames at jpl.nasa.gov>  
Sent: Wednesday, September 11, 2024 2:56 PM 
To: Sheehe, Charles J. (GRC-LCN0) <charles.j.sheehe at nasa.gov>; Thomas Gannett 
<thomas.gannett at tgannett.net>; Howard.Weiss at parsons.us 
Cc: Tomaso.deCola at dlr.de; Ignacio Sanchez-Aguillar <Ignacio.Aguilar.Sanchez at esa.int> 
Subject: Re: [EXTERNAL] IGCA CESG Approval

CAUTION: This email originated from outside of NASA.  Please take care when clicking links or opening 
attachments.  Use the "Report Message" button to report suspicious messages to the NASA SOC. 

Hi Chuck,

I just reviewed the draft OB again, in the light of the feedback from the CESG review and this email trail.

I agree with Howie, and Ignacio, that we should review, and update as appropriate, the X.509 currency.

I also agree with Ignacio that this is a somewhat unusual CCSDS document.  And I will note that it’s 
nature it is very close to a couple of the existing MOIMS DAI WG MB documents, such as:

CCSDS 650.0-M-2 
[urldefense.us]
Reference Model for an Open Archival Information System (OAIS)

And the related …

CCSDS 652.0-M-1 
[urldefense.us]
Audit and Certification of Trustworthy Digital Repositories

CCSDS 652.1-M-2 
[urldefense.us]
Requirements for Bodies Providing Audit and Certification of Candidate 
Trustworthy Digital Repositories

In much the same way that the IGCA is an overview architecture, process, and high level requirements 
driven document, the OAIS is similarly constructed.  The initial OAIS document was found to be 
valuable by the digital archive community because it provided a useful set of concepts and a conceptual 
architecture, as well as identifying the use of some specific standards for certain data exchanges.  The 
MOIMS DAI WG has elaborated upon this over time and then added these audit and certification 
documents.  

To reach closure on Tomaso’s concerns, I will note that as a “Magenta Book-style” Orange Book it does 
not require either a prototype or a PICS.  Here too, the existing MOIMS OAIS MB document series 
provides examples of what has been accepted in a similar context.   I have argued separately (copied 
below) that the CCSDS “Bible” identifies that Orange Books should be formulated as “Normative Track” 
documents without explicitly excluding Magenta Books, which are also Normative Track.  

In my opinion this IGCA concept might well follow a similar path to the OAIS, starting with this Orange 
Book.  I think we all agree that this is not yet at the level of maturity expected of a Blue Book, nor even, 
as yet, of a Magenta Book.  But I believe that it is a valuable concept and, once these technical concerns 
have been dealt with, worthy of publication as an Orange Book so as to permit further exploration and 
evaluation.  

I would, in addition, recommend that development of a prototype should be one of the next investments, 
and that consideration be given to the development of a separate “Audit and Certification” document as 
well as firming up the existing IGCA architecture itself, as a result of the prototyping effort.

Best regards, Peter

From: Sheehe, Charles J. (GRC-LCN0) <charles.j.sheehe at nasa.gov> 
Date: Wednesday, September 11, 2024 at 7:13?AM 
To: Shames, Peter M (US 312B) <peter.m.shames at jpl.nasa.gov>, Thomas Gannett 
<thomas.gannett at tgannett.net>, Howard.Weiss at parsons.us <Howard.Weiss at parsons.us> 
Subject: RE: [EXTERNAL] IGCA CESG Approval
Thanks Peter

Just getting back.

I am fine with dropping the PICs 
The latest rev to 9  will review to ensure no impact. 

I will go through the requirements section and indicate how they will be verified. 
May I put verification in the document in that section?

Thanks
Chuck

Charles J. Sheehe III
Computer Engineer
Secure Networks, System 
Integration and Test Branch (LCN)
Glenn Research Center
21000 Brookpark Rd
Cleveland, OH 44135
Charles.J.Sheehe at NASA.GOV  Email
Charles.J.Sheehe at NSS.SGov.Gov  SIPRmail
Charles.Sheehe at NASA.IC.Gov 
Office: 216-433-5179

There are two ways to design a system. One is to make it so simple there are obviously no deficiencies.
The other is to make it so complex there are no obvious deficiencies.
                                                                                                                                     -  C. A. R. Hoare