CLR and AIA publishing properties unclear



CLR and AIA publishing properties unclear

I'm about to setup PKI and have more or less planned/tested the setup we are
going to have. In short it will consist of a offline root CA, online
enterprise issuing CA and a web server hosting CRL and AIA for external
revocation checking and cert. validation. For info, se my older post at
http://www.microsoft.com/technet/community/newsgroups/dgbrowser/en-us/default.mspx?&query=pki&lang=en&cr=US&guid=&sloc=en-us&dg=microsoft.public.windows.server.general&p=1&tid=a07b98b2-e5b9-4395-9f82-3ce761988998.

I am however in doubt of a few CRL/AIA publishing properties. The
description is not that clear to me, and I have not been able to find any
resource that clearly describes when to use or not use the following
properties:

A)
CRL: "Include in all CRLs (8)" - Am I correct assuming that this is only
needed for offline CAs, to define where the CRL goes when publishing
manually? Hence I have no use of it on my issuing CA?

B)
AIA: "Include in th OCSP extension (2)" - As far as I can see ("Online
Certificate Status Protocol Support",
http://technet2.microsoft.com/windowsserver/en/library/78c89e0f-44f8-452a-922c-5dd5b8eaa63b1033.mspx?mfr=true),
Windows 2003 CA does not even support OCSP so I figure that I shouldn't
need/want to include this?

C)
At least until I have figured out A and B above, these are the properties
I'm considering and why (where applicable):

Offline Root CA
CRL: Local=1, LDAP=10, HTTP=2
- LDAP: Delta CRL's are not used (no 4 or 64), since it's offline must
publish manually (no 1, but need 8). Finally I add 2 to include path in
certificates.
- HTTP: Apparently neither 1, 8 nor 64 are possible for HTTP. Delta CRL's
are not used (no 4), do not need DN for LDAP (no 8). Value set to 2 to
include path in certificates.

AIA: Local=0, LDAP=1, HTTP=1
- LDAP/HTTP: Need the path in certificates so added 1. Apparently I do not
need/support OCSP (see B) (no 2)

Online Issuing CA
CRL: Local=65, LDAP=71, HTTP=6
- Local: Publish CRL plus deltas (1 and 64)
- LDAP: It seems I don't need 8, as I'm not publishing to LDAP manually (see
A). I do however publish CRL and deltas (1 and 64), CRL path should be
included in certificates (2) and delta CRL path in CRL's (4).
- HTTP: Apparently neither 1, 8 nor 64 are possible for HTTP. CRL path
should be included in certificates (2) and delta CRL path in CRL's (4).

AIA: Local=0, LDAP=1, HTTP=1
- LDAP/HTTP: Need the path in certificates so added 1. Apparently I do not
need/support OCSP (see B) (no 2)

D)
Am I doing things the wrong way, or is it simply only possible to publish to
LDAP/local/file? I have tried both HTTP and FTP but both fails. If possible I
would like to avoid having to setup an automated process to deal with this,
if I can have the CA handle it directly :-).

E)
Default file name for AIA is something like <CA FQDN>_<CA Friendly
name>.crt. Any reason not to use the simpler form of just <CA Friendly
name>.crt (like with the CRLs). Obviously, it's not a major issue, I just
think is more tidy! :-)

Thanks in advance!

Best regards,
Rasmus Rask
.



Relevant Pages

  • RE: CLR and AIA publishing properties unclear
    ... enterprise issuing CA and a web server hosting CRL and AIA for external ... include path in certificates. ... I do however publish CRL and deltas, CRL path should be ... should be included in certificates and delta CRL path in CRL's. ...
    (microsoft.public.windows.server.general)
  • Re: Proposal for a new PKI model (At least I hope its new)
    ... it is online and it is dynamic. ... What is your solution in place of PKI and certificates? ... > distributed real-time CRL model. ... absolutely know all possible relying parties ... ...
    (sci.crypt)
  • RE: RADIUS IAS CRL CHECK
    ... However, when the workstation is turned on, it can establish a ... It seems that the IAS ignores the CRL. ... certificates' in the DC, we do get an error of "The certificate is ...
    (microsoft.public.internet.radius)
  • Problems with CRL
    ... I issued selfsigned root certificate, then issued user certificates signed ... Before I issued second root new CRL always replaced the old one. ... And when I revoke certificate issued by old root, ...
    (microsoft.public.platformsdk.security)