OASIS Emergency Management TC

Thanks Tony,

I misstated myself.  I didn't mean to give the impression that I thought 
ASN.1 was mainly aimed at European communities, but that the ASN.1 
representation of CAP 1.1 was. That  was why I said that this was the 
"first time I heard ASN.1 encoded CAP messages in
relation to any US-specific implementation..."  

That was my perception of it, but I was not involved with that effort 
except that it occurred at the same time as the CAP 1.1 errata, which I 
did work on, was working its way through the OASIS process.

I don't think the current situation is related to The CAP-IPAWS profile 
except insofar as it prompted the effort to update CAP to 1.2 with the 
new 

> representation of CAP 1.1 was. That  was why I said that this was the 
> "first time I heard ASN.1 encoded CAP messages in
> relation to any US-specific implementation..."  

I too have not heard of any US specific implementation, but I've also not heard of any European ones either :)  Actually outside of the H.323 work is anyone else aware of CAP ASN.1 implementations, it would be good to know as a reference and to get their feedback on any problems and areas of improvement.

The original question I believe was regarding XML to ASN.1 translations and the IPAWS Profile.  While the IPAWS Profile doesn't have any explicit references to ASN.1, it also doesn't contain anything specific to XML only, and there should be nothing that prevents ASN.1 encodings of IPAWS Profile messages.  I have little experience with ASN.1 however and would certainly be willing to work with anyone who has ASN.1 expertise to test and prove this.

Regarding XML to ASN.1 translations, while it should be possible, there is a concern here.  One of the major reasons for CAP 1.2 was correcting the schema to include XML Digital Signatures/Encryption.  However DSig's don't translate over into ASN.1.  So if you were translating from XML to ASN.1 the DSig will be lost and some other, probably transport related, security mechanisms would be needed.  Translating back to XML from ASN.1 would be even more problematic as you would have to resign the XML message for DSig, and if you were to compare the original XML DSig to the translated XML DSig they would not match.  Again though, take my comments with a grain of salt.  I'd certainly like to see if there is someone with ASN.1 expertise who would be willing to also test this out.

-- 
jake@jpw.biz
--

 

> 

                                                

					
                                                    

        
                                                
				
                                                

                                                    
                                                        
                                                        Original Message
                                                
                                                Original Message-----
> From: Jacob Westfall [mailto:jake@jpw.biz] 
> Sent: Wednesday, December 23, 2009 09:46
> To: rexb@starbourne.com
> Cc: tony@yaanatech.com; TIMOTHY.D.GILMORE@saic.com; 
> emergency@lists.oasis-open.org; MARTENA.M.GOOCH@saic.com; 
> olivier.dubuisson@orange-ftgroup.com; ejones@warningsystems.com
> Subject: Re: [Fwd: [emergency] Questions on ASN.1 and IPAWS 
> Profile / CAP 1.2]
> 
> > representation of CAP 1.1 was. That  was why I said that 
> this was the 
> > "first time I heard ASN.1 encoded CAP messages in relation to any 
> > US-specific implementation..."
> 
> I too have not heard of any US specific implementation, but 
> I've also not heard of any European ones either :)  Actually 
> outside of the H.323 work is anyone else aware of CAP ASN.1 
> implementations, it would be good to know as a reference and 
> to get their feedback on any problems and areas of improvement.
> 
> The original question I believe was regarding XML to ASN.1 
> translations and the IPAWS Profile.  While the IPAWS Profile 
> doesn't have any explicit references to ASN.1, it also 
> doesn't contain anything specific to XML only, and there 
> should be nothing that prevents ASN.1 encodings of IPAWS 
> Profile messages.  I have little experience with ASN.1 
> however and would certainly be willing to work with anyone 
> who has ASN.1 expertise to test and prove this.
> 
> Regarding XML to ASN.1 translations, while it should be 
> possible, there is a concern here.  One of the major reasons 
> for CAP 1.2 was correcting the schema to include XML Digital 
> Signatures/Encryption.  However DSig's don't translate over 
> into ASN.1.  So if you were translating from XML to ASN.1 the 
> DSig will be lost and some other, probably transport related, 
> security mechanisms would be needed.  Translating back to XML 
> from ASN.1 would be even more problematic as you would have 
> to resign the XML message for DSig, and if you were to 
> compare the original XML DSig to the translated XML DSig they 
> would not match.  Again though, take my comments with a grain 
> of salt.  I'd certainly like to see if there is someone with 
> ASN.1 expertise who would be willing to also test this out.


I think it's unlikely, but not impossible, that a signature would survive a
round-trip between XML and PER.

Alessandro

Just catching up on email.

I am not aware of any ASN.1 implementations. Further, from what I know of
EM solutions and policies in Europe in Asia, there will not be any in the
near future. And I suspect that the US NG 911 recommendations for
standards will not include any ASN.1 words. XML or binary payloads.

Regards

Carl
>> representation of CAP 1.1 was. That  was why I said that this was the
>> "first time I heard ASN.1 encoded CAP messages in
>> relation to any US-specific implementation..."
>
> I too have not heard of any US specific implementation, but I've also not
> heard of any European ones either :)  Actually outside of the H.323 work
> is anyone else aware of CAP ASN.1 implementations, it would be good to
> know as a reference and to get their feedback on any problems and areas of
> improvement.
>
> The original question I believe was regarding XML to ASN.1 translations
> and the IPAWS Profile.  While the IPAWS Profile doesn't have any explicit
> references to ASN.1, it also doesn't contain anything specific to XML
> only, and there should be nothing that prevents ASN.1 encodings of IPAWS
> Profile messages.  I have little experience with ASN.1 however and would
> certainly be willing to work with anyone who has ASN.1 expertise to test
> and prove this.
>
> Regarding XML to ASN.1 translations, while it should be possible, there is
> a concern here.  One of the major reasons for CAP 1.2 was correcting the
> schema to include XML Digital Signatures/Encryption.  However DSig's don't
> translate over into ASN.1.  So if you were translating from XML to ASN.1
> the DSig will be lost and some other, probably transport related, security
> mechanisms would be needed.  Translating back to XML from ASN.1 would be
> even more problematic as you would have to resign the XML message for
> DSig, and if you were to compare the original XML DSig to the translated
> XML DSig they would not match.  Again though, take my comments with a
> grain of salt.  I'd certainly like to see if there is someone with ASN.1
> expertise who would be willing to also test this out.
>
> --
> jake@jpw.biz
> --
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
>

Has the backward-compatibility issue been reported in some TC document or
email?

Without having it at hand right now, I'll make the following observation.

The X.694 standard, which was used to create the ASN.1 schemas in CAP 1.1
and CAP 1.2, specifies a rigorous mapping from XML Schema to ASN.1.  The
mapping rules are so rigorous that they ensure that one can seamlessly
translate between an XML encoding and a PER encoding just by applying the
standard encoding rules (PER and EXER) to the ASN.1 schema.  This makes it
easy to build an application that can handle both encodings, so long as the
application uses conforming ASN.1 encoder/decoders.

The downside of following strict mapping rules from XML Schema to ASN.1 is
that when the original XML schema is modified, the new ASN.1 schema may not
be backward-compatible with the old ASN.1 schema.  This can happen even in
case of seemingly minor changes such as a new item being added to an
enumeration, or a required attribute or child element becoming optional, or
vice versa.  In the case of CAP 1.2 vs. 1.1, the changes made to the XML
schema cause the PER encodings to change significantly.

But again, the upside of using X.694 is that applications will be able to
easily translate back and forth between ASN.1/PER and XML.

We cannot just have both benefits, and the X.694 standard determines which
one we can have.

Alessandro


> 

                                                

					
                                                    

        
                                                
				
                                                

                                                    
                                                        
                                                        Original Message
                                                
                                                Original Message-----
> From: Rex Brooks [mailto:rexb@starbourne.com] 
> Sent: Tuesday, December 22, 2009 23:16
> To: tony@yaanatech.com
> Cc: TIMOTHY.D.GILMORE@saic.com; 
> emergency@lists.oasis-open.org; MARTENA.M.GOOCH@saic.com; 
> Olivier DUBUISSON; Elysa Jones; Jacob Westfall
> Subject: Re: [Fwd: [emergency] Questions on ASN.1 and IPAWS 
> Profile / CAP 1.2]
> 
> Thanks Tony,
> 
> I misstated myself.  I didn't mean to give the impression 
> that I thought
> ASN.1 was mainly aimed at European communities, but that the 
> ASN.1 representation of CAP 1.1 was. That  was why I said 
> that this was the "first time I heard ASN.1 encoded CAP 
> messages in relation to any US-specific implementation..."  
> 
> That was my perception of it, but I was not involved with 
> that effort except that it occurred at the same time as the 
> CAP 1.1 errata, which I did work on, was working its way 
> through the OASIS process.
> 
> I don't think the current situation is related to The 
> CAP-IPAWS profile except insofar as it prompted the effort to 
> update CAP to 1.2 with the new 

Thanks Alessandro,

I appreciate the explanation.

Happy Holidays,
Rex

Alessandro Triglia wrote:
> Has the backward-compatibility issue been reported in some TC document or
> email?
>
> Without having it at hand right now, I'll make the following observation.
>
> The X.694 standard, which was used to create the ASN.1 schemas in CAP 1.1
> and CAP 1.2, specifies a rigorous mapping from XML Schema to ASN.1.  The
> mapping rules are so rigorous that they ensure that one can seamlessly
> translate between an XML encoding and a PER encoding just by applying the
> standard encoding rules (PER and EXER) to the ASN.1 schema.  This makes it
> easy to build an application that can handle both encodings, so long as the
> application uses conforming ASN.1 encoder/decoders.
>
> The downside of following strict mapping rules from XML Schema to ASN.1 is
> that when the original XML schema is modified, the new ASN.1 schema may not
> be backward-compatible with the old ASN.1 schema.  This can happen even in
> case of seemingly minor changes such as a new item being added to an
> enumeration, or a required attribute or child element becoming optional, or
> vice versa.  In the case of CAP 1.2 vs. 1.1, the changes made to the XML
> schema cause the PER encodings to change significantly.
>
> But again, the upside of using X.694 is that applications will be able to
> easily translate back and forth between ASN.1/PER and XML.
>
> We cannot just have both benefits, and the X.694 standard determines which
> one we can have.
>
> Alessandro
>
>
>   
>> 

                                                

					
                                                    

        
                                                
				
                                                

                                                    
                                                        
                                                        Original Message
                                                
                                                Original Message-----
>> From: Rex Brooks [mailto:rexb@starbourne.com] 
>> Sent: Tuesday, December 22, 2009 23:16
>> To: tony@yaanatech.com
>> Cc: TIMOTHY.D.GILMORE@saic.com; 
>> emergency@lists.oasis-open.org; MARTENA.M.GOOCH@saic.com; 
>> Olivier DUBUISSON; Elysa Jones; Jacob Westfall
>> Subject: Re: [Fwd: [emergency] Questions on ASN.1 and IPAWS 
>> Profile / CAP 1.2]
>>
>> Thanks Tony,
>>
>> I misstated myself.  I didn't mean to give the impression 
>> that I thought
>> ASN.1 was mainly aimed at European communities, but that the 
>> ASN.1 representation of CAP 1.1 was. That  was why I said 
>> that this was the "first time I heard ASN.1 encoded CAP 
>> messages in relation to any US-specific implementation..."  
>>
>> That was my perception of it, but I was not involved with 
>> that effort except that it occurred at the same time as the 
>> CAP 1.1 errata, which I did work on, was working its way 
>> through the OASIS process.
>>
>> I don't think the current situation is related to The 
>> CAP-IPAWS profile except insofar as it prompted the effort to 
>> update CAP to 1.2 with the new