Subject: Use of attribute certificates in SignedData

From: "Christopher S. Francis" <[email-masked]>
Date: Tue, 28 Aug 2001 13:46:08 -0400

I have a question for the group concerning attribute certificates. 
 
Is there an accepted location to put an attribute certificate associated with the signer in the SignedData data structure?  I have a SignedData object and I’m considering putting an attribute certificate associated with the signer in the ‘certificates’ field of SignedData in addition to the PKC of the signer.  
 
Is that a “philosophically correct” location?  I have some concern about standard decoders being able to successfully decode the SignedData structure if includes an attribute certificate.  Other options include burying the certificate in the encapsulated content or including it as a Signed or UnSigned attribute.
 
I’d appreciate any advice and or lessons learned that you can offer.  Thanks in advance.  
 
Chris Francis

---

From: "Blake Ramsdell" <[email-masked]>
Date: Wed, 29 Aug 2001 11:56:43 -0700

I found a comment in my code:
 
        // REVIEW: This will puke on Attribute Certificates and PKCS #6
certs!

Blake
-----Original Message-----
From: Christopher S. Francis [mailto:[email-masked]]
Sent: Tuesday, August 28, 2001 2:29 PM
To: [email-masked]; Pawling, John
Subject: RE: Use of attribute certificates in SignedData

John,
 
Understood.  So I'm interpreting RFC-2630 correctly then.  When I said I was
considering putting the AC in the 'certificates' field, I really meant that
I wanted to include it as an attrCert choice in the 'certificates' field. 
 
So if that's the "correct" place to put the AC according to 2630, what
experience have people had with real-world applications that process
SignedData?  Will applications/toolkits that understand how to verify the
signature on SignedData, but do not process ACs typically just ignore the AC
if it's included or do they choke because: 1) they can't successfully decode
the AC or 2) they can't successfully validate the AC?
 
Ideally, I'd like to make the AC available for applications that are capable
of using it and have applications that are not AC-enabled just ignore it and
verify the signature on the SignedData using the PKC.  In the description of
the 'certificates' field, RFC-2630 says the following regarding the
certificates in the set: "There may be more certificates than necessary, and
there may be certificates sufficient to contain chains from two or more
independent top-level certification authorities."  This seems to *imply*
that compliant, but AC challenged applications will just ignore the AC as
long as they can validate the signature using the PKC.  I'm just looking for
a bit of a reality check.  Is that the way it works in the real world?
 
Thanks for the heads up regarding the fact that CMS specifies the 1997 X.509
syntax.  I'll go do some reading on what the differences are.  Depending on
the answers to the questions above, it may not matter though.  We're writing
our own X.509 2000 compliant application to process the ACs.  At this point,
it's probably acceptable to say that other third-party AC-enabled
applications must support X.509 2000 to process our SignedData blob.  As I
mentioned above, as long as commonly available 3rd party validation software
doesn't choke, it's ok if it ignores the AC.
 
Chris
 
-----Original Message-----
From: Pawling, John [mailto:[email-masked]]
Sent: Tuesday, August 28, 2001 3:43 PM
To: 'Christopher S. Francis'; [email-masked]
Subject: RE: Use of attribute certificates in SignedData
 
Chris, 
RFC2630 specifies that an AttributeCertificate can be included in the
signedData certificates attrCert field.  Please note that RFC2630 specifies
the 1997 X.509 Attribute Certificate syntax (that is incompatible with the
2000 X.509 Attribute Certificate syntax).  Also, please note that RFC2630
states the following requirement regarding the value to be placed in the
signedData version field: "If attribute certificates are present, then the
value of version shall be 3."  
=========================================== 
John Pawling, [email-masked] 
Getronics Government Solutions, LLC 
===========================================