Re: Missing Protocol ?

[Peter Sylvester <Peter.Sylvester@xxxxxxxxxx>]

> > > From: Denis Pinkas <Denis.Pinkas@bull.net>
> > >
> > > I see no reason for this. AAs (Attributes Authorities) are not the
> > > same like RAs (Registration Authorities).
> > > The response comes from the RA, not an AA. In any case the use of
> > > AAs is not mandated.
> > 
> > It's a question of assurance.  If you trust a directory, you don't need
> > signed attributes.  I lean towards end-to-end security whenever
> > possible, and therefore prefer the RA to sign attributes rather than
> > having the directory dish out unprotected information.  If the
> > authoritative RA database is available online, there is little reason
> > to prefer signed over unsigned.  But as soon as the information is
> > replicated, cached, passed along, or otherwise distributed, the RA's
> > signature becomes helpful.  When the RA signs attributes, it becomes,
> > by definition, an AA.
> 
> Certainly not. Using AC mandates a very precise data structure. So
> it is not because the answer is signed that the RA becomes an AA.
This has nothing to do with the content of the AC. It may be someone
else that the original RA, that creates the AC, but that's probably
not the slightly more difficult situation both of you had in mind.
 
It was discussed that an attrib cert could be appropriate vehicle to carry
a statement of the kind:

  We, the 'issuer' declare (sign) that  'holder' has been registered
  and we have stored the following 'attributes'.
  
Attributes are defined by oids, the CPS of the RA would define the semantics.
the requester can make a request without knowing the schema of the data.

It seems thus possible to me that the RA information can be represented
in an attrib cert.

If so, what does this tell us about the RA caracteristique of being an AA.
I don't care. 

> Note that the RA may respond without any signature and that the
> security may be provided using, e.g. TLS.

What you are saying here is very strange: A judge does not just want
to read a data base, but wants to create a verifiable decision.

There is not just 'one security'. The security of the transport of the
information is something else than the security of the objects. 

There is also the engagement / guarantee implied by the signature of the RA. 

It may be required that the requests/responses need to be archived
The certificate owner may have the right that the RA prooves exactly to whom the
information have been given, and why. There may be strict privacy laws, and
just standard security/audit rules, etc. 
This may mean that the transaction result may need to stored encrypted,
etc.  

It may be also useful to have a reponse: "We, the RA declare that YOU, the requester,
has asked at date X to obtain information about certuser XXXX, we delivered the
following information at date Y to You, you are already the 4711th one, we have
registered the transaction under id 123465." 

Now you can select your favorite more or less secure query protocol
or/and data format, e.g.:
LDAP, CMP++, CMC++ OCSP-Y-NOT, SCVP++, BERT++, DVCS, SNMP, DAP, YASSQPI, 
XML-DIGSIG/XER, POLICE/BLOCKS, JUDGE/SMIME, ... 

> Anyway the intent is not to place that information in multiple
> untrusted Directories, but to query one server (ain the same way
> this is done for OCSP). The idea is to allow to locally store that
> information in some data base that could be queried using LDAP.

This is an implementation detail of the RA. You could have:

'select * from RABASE where certhash=XXXXXXX and serialnumber=1234'

Why does all that need to be online with a direct response. Before handing out
these information, a human intervention may be required, or the information
may not be available online. someone might need to open a safe and get the
required archive cd. 

 cat cdrom/XXXXXXX/1234 | sign+-crypt+log ... 

Thus you should consider to make the transaction transport independant
(mail, http, blocks, pigeons + paper copy).   

P