[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