RE: Attribute certificate

Hi all,

maybe the following Technical Specification developed by the
European Telecom Standardisations Organization (ETSI) ist of
interest for you:

  ETSI TS 101.903
  XML Advanced Electronic Signatures
  http://pda.etsi.org/pda/home.asp?wki_id=12532

The specification defines various signed and unsigned attributes
intended to cover electronic signatures for various types of 
transactions, including business transactions.

Regards, Gregor

> -----Original Message-----
> From: w3c-ietf-xmldsig-request@w3.org 
> [mailto:w3c-ietf-xmldsig-request@w3.org] On Behalf Of Tom Gindin
> Sent: Saturday, March 23, 2002 2:24 AM
> To: Serge Dussault
> Cc: 'w3c-ietf-xmldsig@w3.org'
> Subject: Re: Attribute certificate
> 
> 
> 
>       The X509Certificate element appears to restrict the 
> certificate specified to a v3 certificate, thus excluding 
> attribute certificates.  IMO it would be better to put an AC 
> into a SignatureProperty anyway, so the signer could sign 
> which AC he intends to use.  RFC 2634 has a place to put 
> AC's, and section 1.3.4 of that specification says in that 
> regard that "signingCertificate MUST be carried in a 
> SignedAttributes".  It is not clear that you can use AC's as 
> an alternative to PKC's to specify the signer in RFC 2630.  I 
> would think that you might not be able to because you have to 
> specify the signer by issuerAndSerialNumber or by 
> subjectKeyIdentifier, and issuerAndSerialNumber uses version 
> 1 to indicate backward compatibility with PKCS#7 before the 
> days of AC's.
>       Anyway, if people agree with me that a 
> SignatureProperty is the right place for an AC in this 
> format, should we standardize a format and name one?  My own 
> guess would be that the name of this signature property would 
> be "AttributeCert" (if people prefer to be wordy and spell 
> out Certificate they are welcome to) and that its format 
> would be the binary value of the AC converted to base 64, 
> just as for X509Certificate.  However, there is no place to 
> include the chain of certificates leading to an AC.  CRL's 
> are not constrained to point at PKC's by the definition of 
> X509Data, so you can put your CRL's there.
>       Do we need a chain for AC's as well?  A very simple way 
> to do it would be to require that the contents of the 
> AttributeCert SignatureProperty be a delimited ordered set of 
> certificates.  Since any subsequent certificates in the path 
> may be either AC's or PKC's, we must distinguish between them 
> and the two simplest ways I can think of are either by a rule 
> that an AC follows a comma while a PKC follows a colon, or by 
> preceding all PKC's in the list by "P:".  Somebody else can 
> come up with more native-XML like syntax if they wish.
> 
>             Tom Gindin
> 
> 
> Serge Dussault <serge.dussault@ramq.gouv.qc.ca>@w3.org on 
> 03/22/2002 02:12:37 PM
> 
> Sent by:    w3c-ietf-xmldsig-request@w3.org
> 
> 
> To:    "'w3c-ietf-xmldsig@w3.org'" <w3c-ietf-xmldsig@w3.org>
> cc:
> Subject:    Attribute certificate
> 
> 
> Hi, is it possible to use a attribute certificate in this 
> specification (XML-DSIG)?
> 
> If yes, is it possible to have a sample code?
> 
> Thanks
> 
> Serge Dussault
> Soutien au développement
> Régie de l'assurance maladie du Québec
> 
> Tél. : (418) 682-5159 poste 4570
> Téléc. : (418) 528-9231
> Courriel : serge.dussault@ramq.gouv.qc.ca
> 
> 
> 
> 
> 
> 
>