[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [xcbf] SignedData Attributes - DigitalSignature Attributes
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> >>> >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC