Clarifications regarding Private Internet Extensions - Authority Information Access of RFC 3280

[Oeser Thomas <Thomas.Oeser@xxxxxxxxxxx>]

> Hi Community,
> 
> can anyone please help me with my questions?
> 
> In section 4.2.2.1 "Private Internet Extensions - Authority Information
> Access" of RFC 3280 it reads:
> 
> 	....
> 	The id-ad-caIssuers OID is used when the additional information
> 	lists CAs that have issued certificates superior to the CA that 
> 	issued the certificate containing this extension.  The referenced 
> 	CA issuers description is intended to aid certificate users in the 
> 	selection of a certification path that terminates at a point trusted
> 
> 	by the certificate user.
> 	....
> 
> If I understand this right, here *NOT* the CA immediately issung the
> certificate is listed but CAs *superior* to this CA; i.e., if we have a
> chain RootCA-->SubCA-->SubSubCA-->IssuingCA-->EndEntityCert, SubSubCA,
> SubCA and potentially RootCA is expected to be listed, when we find this
> extension in the end entity certificate. 
> Is there any reason to leave out the CA immediately issuing the end entity
> certificate?
> Also is it expected that the end entity certificate points to a list that
> more or less represents the chain leading to a trusted Root CA, or that
> each certificate points only to its immediate issuing CA?
> 
> 	...   
> 	When id-ad-caIssuers appears as accessMethod, the accessLocation
> 	field describes the referenced description server and the access 
> 	protocol to obtain the referenced description.  The accessLocation
> field 
> 	is defined as a GeneralName, which can take several forms. Where the
> 
> 	information is available via http, ftp, or ldap, accessLocation MUST
> be 
> 	a uniformResourceIdentifier.  Where the information is available via
> the 
> 	Directory Access Protocol (DAP), accessLocation MUST be a 
> 	directoryName.  The entry for that directoryName contains CA 
> 	certificates in the crossCertificatePair attribute.  When the
> information 
> 	is available via electronic mail, accessLocation MUST be an
> rfc822Name.  
> 	The semantics of other id-ad-caIssuers accessLocation name forms 
> 	are not defined.
> 	...
> 
> My problem here is, that unfortunately only for the case DAP the exact
> syntax for how constructing this list of superior CAs is defined (by the
> attribute crossCertificatePair). There is no syntax specified of how to
> store this list when the access method is e.g. HTTP, FTP or LDAP. The URI
> can point to everything, e.g. a ZIP-File containg CA certs in DER format,
> a directory containing files of CA certs in whatever format, a DER file
> representing the ASN.1 equivalent of SET OF or SEQUENCE OF X.509
> certificates, ...;
> Have I missed a format specification anywhere?
> 
> 
> -- Thomas Oeser
> 
> Siemens AG, CIO - Information Security
> D-85356 Munich-Airport, Suedallee 1, Germany
> Tel.:	+ 49 (89) 636-36356		_0/
> FAX:	+ 49 (89) 636-7-18593		  |
> mailto:	Thomas.Oeser@xxxxxxxxxxx	< \
> 
>