OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xcbf message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Re: [xcbf] SignedData Attributes - DigitalSignature Attributes


I will consult with Olivier.  It may be that you are right, in which
case one of us will forward the next approved masters for the VXER/XCN
work to the XCBF list.

John L


Phil Griffin wrote:
> 
> There is a liaison between OASIS and ITU-T SG17
> (and your SC6? Did that one get approved?) that
> should allow these documents to be shared by
> members of the XCBF list.
> 
> There is no need to wait for approval. And if you
> are really serious about XCBF being a primary customer
> for the work, I would think that you would wish to
> get feedback from the customers long before the ink
> is dry.
> 
> Phil
> 
> John Larmouth wrote:
> 
> > Unfortunately there are two separate issues.  One is about keeping
> > people informed, and I have no objections to that.  The second one is
> > about release of ITU-T and ISO Working Documents, and that is more
> > difficult.  Once the ITU-T approval is in place (hopefully no later than
> > Jan of next year), the texts for XCN/VXER will become freely available
> > as pre-published specs.
> >
> > John L
> >
> >
> > Phil Griffin wrote:
> >
> >>Ed,
> >>
> >>I agree that such work should not appear to be
> >>so secretive. If as John has stated XCBF is a
> >>primary and important user of this technology
> >>then the XCBF list would be a good one keep
> >>notified of developments.
> >>
> >>Also, there is still an asn1xml list hosted by
> >>OSS that seems to get little mail, and the ASN1
> >>list hosted by ITU-T. I'm on all of these and
> >>have seen no discussions of such work there.
> >>
> >>On the ITU-T list noted above, I would also
> >>mention that OASIS has a communication process
> >>with ITU-T that was formed with XCBF and SG17
> >>specifically mentioned.
> >>
> >>Would it be possible for John or Bancroft or
> >>Alessandro or Paul, all of whom attend the SG17
> >>meetings, to volunteer to serve as liaison to
> >>XCBF? If so, I will gladly update the XCBF web
> >>page to note this liaison and this channel could
> >>be used to keep XCBF members informed.
> >>
> >>Phil
> >>
> >>Phil
> >>
> >>Ed Day wrote:
> >>
> >>
> >>>>VXER - Variant XER - *will* provide a BASE64 transfer, but VXER is not
> >>>>canonical
> >>>>
> >>>>
> >>>What is this?  There is no mention of it anywhere I can find on the web
> >>>(this is also true of the XCN acronym used in some prior XCBF e-mails).  It
> >>>seems that if you are going to be using these standards to define new specs,
> >>>they should at least be published somewhere..
> >>>
> >>>Regards,
> >>>
> >>>Ed
> >>>
> >>>----- Original Message -----
> >>>From: "John Larmouth" <j.larmouth@salford.ac.uk>
> >>>To: "Ed Day" <eday@obj-sys.com>
> >>>Cc: "Phil Griffin" <phil.griffin@asn-1.com>; "xcbf"
> >>><xcbf@lists.oasis-open.org>
> >>>Sent: Monday, August 12, 2002 11:36 AM
> >>>Subject: Re: [xcbf] SignedData Attributes - DigitalSignature Attributes
> >>>
> >>>
> >>>
> >>>
> >>>>CXER does not support encoding instructions.  So an octet string value
> >>>>in CXER can only be transferred using hex.
> >>>>
> >>>>VXER - Variant XER - *will* provide a BASE64 transfer, but VXER is not
> >>>>canonical.
> >>>>
> >>>>(We have discussed providing a CVXER - Canonical Variant XER, but we
> >>>>have almost agreed not to, at least at present, for some very good
> >>>>reasons:  it is very difficult, and it will delay the progression of
> >>>>VXER, which we know is needed.)
> >>>>
> >>>>As Ed rightly says, there is no way you can have canonical encodings
> >>>>that allow both hex and base64 for an OCTET STRING, even if you have a
> >>>>"format=" attribute.  For canonical encodings, there is just one, and
> >>>>only one, way of encoding an octet string.  For CXER, that is hex.
> >>>>
> >>>>John L
> >>>>
> >>>>
> >>>>Ed Day wrote:
> >>>>
> >>>>
> >>>>>I thought in a canonical XER encoding things could be done one way and
> >>>>>
> >>>>>
> >>>only
> >>>
> >>>
> >>>>>one way.  Doesn't introducing these attributes violate the canonical
> >>>>>
> >>>>>
> >>>rules?
> >>>
> >>>
> >>>>>Regards,
> >>>>>
> >>>>>Ed Day
> >>>>>Principal Engineer
> >>>>>Objective Systems, Inc.
> >>>>>Tel: +1 (484) 875-3020
> >>>>>Fax: +1 (484) 875-2913
> >>>>>Toll-free: (877) 307-6855 (USA only)
> >>>>>mailto:eday@obj-sys.com
> >>>>>http://www.obj-sys.com
> >>>>>
> >>>>>----- Original Message -----
> >>>>>From: "Phil Griffin" <phil.griffin@asn-1.com>
> >>>>>To: "xcbf" <xcbf@lists.oasis-open.org>
> >>>>>Sent: Monday, August 12, 2002 9:02 AM
> >>>>>Subject: [xcbf] SignedData Attributes - DigitalSignature Attributes
> >>>>>
> >>>>>
> >>>>>
> >>>>>>I proposed on 8/6 that the following XML markup be used
> >>>>>>in XCBF.
> >>>>>>
> >>>>>>   <version> ........................ </version>
> >>>>>>   <digestAlgorithms> ............... </digestAlgorithms>
> >>>>>>   <encapContentInfo> ............... </encapContentInfo>
> >>>>>>   <certificates format='base64'> ... </certificates>
> >>>>>>   <crls format='base64'> ........... </crls>
> >>>>>>   <signerInfos> .................... </signerInfos>
> >>>>>>
> >>>>>>The signature component of the SIGNATURE parameterized
> >>>>>>type identifies a value of type BIT STRING. These bits
> >>>>>>are not used as bit flags, and signatures tend to be in
> >>>>>>the thousands of bits in length and can more easily and
> >>>>>>compactly be represented as OCTET STRINGs. I propose that
> >>>>>>the following XML markup be used for these values:
> >>>>>>
> >>>>>>   <signature format='hex'> ... </signature>
> >>>>>>
> >>>>>>So far, I have received no comments. Unless I hear comments
> >>>>>>that use of these attributes is unacceptable, I will include
> >>>>>>them in the next release of the XCBF document.
> >>>>>>
> >>>>>>Phil
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>----------------------------------------------------------------
> >>>>>>To subscribe or unsubscribe from this elist use the subscription
> >>>>>>manager: <http://lists.oasis-open.org/ob/adm.pl>
> >>>>>>
> >>>>>----------------------------------------------------------------
> >>>>>To subscribe or unsubscribe from this elist use the subscription
> >>>>>manager: <http://lists.oasis-open.org/ob/adm.pl>
> >>>>>
> >>>>--
> >>>>  Prof John Larmouth
> >>>>  Larmouth T&PDS Ltd
> >>>>  (Training and Protocol Development Services)
> >>>>  1 Blueberry Road
> >>>>  Bowdon                               j.larmouth@salford.ac.uk
> >>>>  Cheshire WA14 3LS                    Tel: +44 161 928 1605
> >>>>  England Fax: +44 161 928 8069
> >>>>
> >>>>----------------------------------------------------------------
> >>>>To subscribe or unsubscribe from this elist use the subscription
> >>>>manager: <http://lists.oasis-open.org/ob/adm.pl>
> >>>>
> >>>
> >>>----------------------------------------------------------------
> >>>To subscribe or unsubscribe from this elist use the subscription
> >>>manager: <http://lists.oasis-open.org/ob/adm.pl>
> >>>
> >

-- 
   Prof John Larmouth
   Larmouth T&PDS Ltd
   (Training and Protocol Development Services)
   1 Blueberry Road                     
   Bowdon                               j.larmouth@salford.ac.uk
   Cheshire WA14 3LS                    Tel: +44 161 928 1605
   England				Fax: +44 161 928 8069



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC