Subject: RE: Use of attribute certificates in SignedData

From: "Pawling, John" <[email-masked]>
Date: Tue, 28 Aug 2001 15:42:55 -0400

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 
===========================================

---

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

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 
===========================================