Hello Rogue,
I have no opinion to express yet. However, can you clarify your third
proposal ? You propose to modify RFC 3971 so a CPA message contains
both a Cert AND the corresponding CRL ? This is somehow an optimization of
your first proposal ?
Another advantage of solution 1 and 3 is that the node can verify the
validity of a prefix during the Stateless Address Autoconfiguraton
procedure, before assigning any addresses corresponding to this prefix to
an interface. This, IMHO, is an important feature.
Thanks for starting this discussion Rogue.
Regards,
Tony
On Wed, 18 Nov 2009, Roque Gagliano wrote:
Marcelo,
I would like to start the discussion on how the host should fetch the CRLs.
This will serve as a base for a future I-D.
We have at least three options:
1) To specify the "Certificate Revocation Solicitation / Certificate Revocation
Advertisement" messages just like in SEND to request certificates.
Advantages:
- The router could cache the CRLs, which will be the same ones for most
of the hosts. More-over the certs and the CRL may be pre-loaded by the router which only
needs to check for a new CRL before the "next update".
- Lightweight implementation at the hosts.
Disadvantages:
- Need specification, probable changes to RFC 3971.
2) To use the default fetching mechanism at the CRL Distribution Points
extension for each CA. Today the only mandatory fetching mechanism is RSYNC.
Advantages:
- no changes in the current specifications.
Disadvantages:
- need to implement RSYNC client in hosts.
- no cache, the same CRL will be fetch by every host from the
source.
3) To modify the Certification Path Advertisement Message in the sense that
every time a certificate is sent to the host, it will also include the CRL
shown in its CRL Distribution Points extension. So, you asked for a CERT, I
send you both the CERT and the CRL (for signed with the same key).
What does the WG think?
Roque.
-------------------------------------------------------------
Roque Gagliano
LACNIC
[email protected]
GPG Fingerprint: E929 06F4 D8CD 2AD8 9365 DB72 9E4F 964A 01E9 6CEE
_______________________________________________
CGA-EXT mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cga-ext
_______________________________________________
CGA-EXT mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cga-ext
